Note that you can deploy your own resolver any time you like, and use that. ENS doesn’t have a system-wide resolver; the public one is only provided for convenience!
If a feature you want isn’t yet deployed, you can deploy your own resolver and use that instead.
Think of it like DNS; it doesn’t specify the protocol for an A record, only the IP address. The protocol is either contextual (eg, default to HTTP) or supplied by the user in the URI.
@portal-chris : This would work for us too!.
@Arachnid : In old DNS you don’t generally resolve a name by a content. When you do it, then the protocol is specified. See the ‘dnslink’ in ipfs example.
You resolve a name to an IP; it specifies the content locator (the IP) but not the protocol to use to talk to it. That’s effectively the same as this situation.
After a conversation with @jbaylina and others at DevCon, I’m fairly convinced that some kind of protocol hinting, or outright specification, would be helpful here - for permitting IPFS and Swarm (and possibly other) resource identifiers to be distinguished without additional context.
I can see two options here:
Thoughts?
I would go for the former or:
- Add a ‘protocol’ hint to the return value of multihash, which specifies the protocol to try to find the content with
This would allow us to easily standardize the the protocol to hash as an enum which is added to the bytes.
Peronally I like much more the second one. It is more similar to the one we have now, and it allows the option to define various protocols. So you can push content in Swarm and IPFS and say it’s in both places…
@jbaylina let us do it like that then. Is EIP-1062 inline with that decision @Arachnid, if not we should probably draft something new and then talk to the guys at Metamask and other tools that support ENS resolving in browsers to start switching over to the new standard. Better we do it asap cause if we wait too long everyone will have implemented something else and standardization will take forever.
We’d need a new or revised EIP that specifies multiaddr, instead of multihash. We’d also want to send a PR to the multiaddr repository to add a type for Swarm content hashes.
Let’s do it, I say a new EIP.
I’ve been quiet until now but following the discussion. My guess is that what we need is a standardized representation of mutliaddr for ethereum. This would benefit the ecosystem beyound just the ENS (I’m thinking of Oracles pointing to offchain ressources).
Once this is done, it would naturally become part of the ENS addressing mechanisms.