EIP-1062: Formalize IPFS hash into ENS(Ethereum Name Service) resolver

If that’s the case, MetaMask will probably update its support to resemble the EIP more closely, especially now that other clients are following that.

1 Like

@danfinlay @rachelhamlin
This version of public resolver contract (0x1da022710dF5002339274AaDEe8D58218e9D6AB5) which has been widely used right now, does not support the multihash method, so we decided to use the SHA256 hash in content method to set mappings of IPFS/swarm. For the EIP-1062, we use the supportInterface method to determine whether or not the public resolver support multihash.

We are currently developing a new feature that’ll detect whether the ENS is using the old/new resolver; and it’s compatible with SHA256 content and multiash. After testing, we’ll make a pull request to MetaMask.

chris@portal.network
phyrex@portal.network

(kaizen.portal.network)

3 Likes

Great, sounds good, thank you!

In my opinion, the standard MUST define a way to specify the protocol: “ipfs”, “swarm”, “utorrent”, “storej”, “filecoin” or what ever.

If not, the browser (or any user using the entry) will have to query all possible providers in order to resolve the hash. This is not efficient and can generate a lot of confusion in case that new protocols are defined.

3 Likes

@jbaylina agreed.

We’ve discussed this a bit further and now I understand that multihash doesn’t actually specify the protocol. Add to that the complication of working with a library for binary storage… it seems like your option #2 above is more straightforward and comprehensive.

@danfinlay @portal-chris being agnostic about the storage we support is probably our number one priority. What are your thoughts?

I’m all for staying transport agnostic, but we should start with transports we’re ready to support. IPFS first makes a lot of sense because we already have gateways for it. Swarm isn’t quite as web friendly yet, so I would leave it for the future.

In my opinion, the standard MUST define a way to specify the protocol: “ipfs”, “swarm”, “utorrent”, “storej”, “filecoin” or what ever.

If not, the browser (or any user using the entry) will have to query all possible providers in order to resolve the hash. This is not efficient and can generate a lot of confusion in case that new protocols are defined.

Or we follow the path of MIME and support fallback protocols within an ENS resolver type. It could say “I prefer Swarm, but here’s an IPFS hash, and here’s a URL if you don’t have either of those.”

@jbaylina @rachelhamlin
The multihash could have stored with a map structure which the resolver can identify with a specific protocol (IPFS, swarm, storj, and etc.).

We will update EIP-1062 and add the specify protocol.

Rationale
function setMultihash(bytes32 node, string protocol, bytes hash) public only_owner(node);
function multihash(string protocol, bytes32 node) public view returns (bytes);

Our team has commented the EIP-1062 for the above issue on May 18, and I think we can upgrade the EIP1062 and public resolver contract.

Link:

2 Likes

@portal-chris nice, simple enough. That would suit us fine.

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:

  • Add a ‘protocol’ hint to the return value of multihash, which specifies the protocol to try to find the content with
  • Instead of storing multihashes, store a multiaddr, which permits specifying the protocol (eg, IPFS or Swarm) as part of the field.

Thoughts?

2 Likes

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.

2 Likes

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.

@Arachnid and I just published EIP-1577 to try and better define a system of mapping names to network and content addresses.

2 Likes

Nice work.

Calling for Ethereum Provider ring members to implement EIP1577 here.

3 Likes