ICRC-91 working branch #96
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
r-birkner
reviewed
Oct 28, 2024
|
|
||
| Canister smart contracts on ICP can expose an HTTP interface that can be accessed from an HTTP client like a regular browser via an HTTP gateway. The HTTP Gateway Protocol Specification mandates regular HTTP URIs to specify a resource of a canister. That is, the HTTP URI for a canister contains the boundary node as the authority, or host name. This is inflexible as the URI contains a specific boundary node host name that resolves to a set of boundary nodes and multiple different URIs with different boundary node hostnames refer to the same resource. | ||
|
|
||
| The following example shows a regular https URL,, which includes the hostname `ico.app` referring to a set of boundary nodes, to access a resource hosted by a canister: |
There was a problem hiding this comment.
Suggested change
| The following example shows a regular https URL,, which includes the hostname `ico.app` referring to a set of boundary nodes, to access a resource hosted by a canister: | |
| The following example shows a regular https URL, which includes the hostname `ic0.app` referring to a set of boundary nodes, to access a resource hosted by a canister: |
r-birkner
reviewed
Oct 28, 2024
|
|
||
| For example, an NFT standard can use this mechanism to specify HTTP-based canister-hosted resources of NFTs as part of NFT metadata. Parties who read the metadata can transform the `ic-http` URIs to HTTP URIs with their preferred boundary node provider and load the resources with those URIs. | ||
|
|
||
| This standard does not specify how to resolve a `http-ic` URI to a specific `https` URI that can be accessed in a browser. This is left to future ICRC standards that are expected to evolve once the boundary node ecosystem is growing with further community participation. Such future standard would need to compose an `https` URI from an `http-ic` URI based on the boundary node provider preference, and based on the preference choose a hostname. Not all boundary node providers will provide access to each canister on ICP. Thus, this constrains the transformation function from `http-ic` URIs to `https` URIs. A simple way to realize such transformation is with a registry of boundary node hostnames and canisters accessible through each boundary node to be available. |
There was a problem hiding this comment.
Here http-ic is mentioned whereas everywhere else ic-http is being used.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.