Enable canisters to make HTTP(S) requests

I thought that the following pattern would be preferable in an async world.

fn update(x_transid: i64, key:i32, value:i32) → bool {
// x_transid is expcted to be unique. Only one call to x_transid will succeed in external call ; if at all…every other call will fail

// therefore reducers will ALWAYS return true

}

fn lookup(x_transid: i64, key: i32) → bool {
// did update suceed in external call with key being updated with attached x_transid
}

So you make the call to update; but rely on lookup to know whether the update actually suceeded. Of course support is required from the external system.

Might be interesting to you, there’s currently an example of this feature in review.

3 Likes

Well observed! Indeed, we are implementing a simple sample dApp in Rust and Motoko. The dApp will pull ICP exchange rates from Coinbase and offer the rates over an on-chain API.

2 Likes

What the feature will be capable of is to allow canisters to make GET requests to external services and receive the (transformed) response. If responses of the Web 2 server are not deterministic, you need to define a transform function to make it deterministic, i.e., remove non-deterministic attributes like timestamps and session ids. This allows then all replicas to receive the same transformed response and let consensus agree on it.

POST
Doing POST calls is a rather small extension that would be added after an initial release. Doing a post with this feature assumes that the Web 2 service can handle that the same request be made by all nodes of the subnet. Web 2 services that support the Idempotency-Key header as specified in the draft RFC should work for correctly processing POST requests when using the Idempotency-Key header in the request.

8 Likes

Nice! Great feature. I wonder have ubiquitous the implementation is.

1 Like

It’s definitely not implemented by every service. So this is something that practically limits the possibility of POST requests to Web 2.0 HTTP-based services using the current version of this feature.

1 Like

Makes sense I like the idea …

1 Like

The feature is finalized in June?

big macs for sergey !!!

Progress update

We are currently wrapping up the MVP implementation of the feature, only a few small things remain to be done. We plan to launch the feature in July. The MVP will be an IPv6-only launch for the reason of our replicas not having IPv4 addresses. Going via boundary nodes, as initially planned, may be added at a later stage, but the main issue is that all subnets then share the rate limits of services as we only have 10-20 boundary nodes currently.

What is missing now are the following items:

  • Merge some MRs that are under review
  • Finish the sample dApp demonstrating the feature (ICP price quotes from Coinbase)
  • HEAD and POST extensions and corresponding system test
  • Local https-capable setup for system tests (currently going via external site); requires support for self-signed certificates
  • Enable SDK (almost done, still requires replica with feature to be shipped)
  • Cycles charging: decision on price (under discussion)
  • Rollout to selected subnet(s)
  • Full rollout to all subnets
10 Likes