… and who should we pester to make it happen?
Hey @willguest,
could you give a bit more context on your use case(s)?
Yes, sure.
This is a more macro-question in some ways, based on my (potentially faulty) understanding that the Internet Computer Protocol is a paradigmatic shift in the way data is handled on the web.
In my various pontifications about this technology, I regularly come into contact with people who fail to understand the scope of the ambition behind the IC, who erroneously see it more as a piece of software, token standard or bid for world domination.
What I am attempting to emphasise with this question is the protocol itself. We prepend ‘http’ to the beginning of web addresses to indicate that they are using the hypertext transfer protocol, so I think we should prepend ‘icp’ to indicate that the base protocol is this network.
I have used deep links before and the result is much the same, but not universal. I am interested in what it would take, and what the barriers are, to getting this to full standardisation.
This isn’t fully what you’re talking about, but Azle already uses icp:// for cross-canister communication. It’s an MVP protocol we’ve created just for Azle canisters for the moment and just for cross-canister communication.
Canisters are addressed like this: icp://[canisterId]/[methodName]
Not sure, but could this lower reliance on DNS as well? Maybe combined in a way with http-proxy?
Advanced users would install something like icp-proxy
to directly communicate with replica via icp://
, act as http gateway, verify responses locally and maybe some form of decentralized name resolution…
Not sure if this makes sense technically, but it may help in emphasizing the protocol itself as OP mentioned.
ICRC-91 (work in progress) describes a HTTP protocol for IC canisters to avoid the reliance on a specific IC gateway in e.g. an URL to a HTTP asset.
This is mostly meant for e.g. NFT metadata pointing to HTTP resources on the IC itself. But could be used beyond that. Though keep in mind, that custom protocols are reliant on browsers support.
As far as I know, you can’t add custom protocols with extensions. There is very limited custom protocol support in the web spec and it’s basically at verge of being phased out last time I checked
Spit-balling here, but isn’t @lastmjs describing a kind of IC-specific DNS. Rather than simply a tool for discovering and distributing canister addresses, wouldn’t it make sense for such a service to also track the interface presented by each domain name (i.e. canister)
This would be a ‘domain interface service’… It seems like rather a waste to not have that information tacked on to the canister id, since there is a deeper level of interoperability than ever existed over http, but maybe I’m getting a bit carried away