Title: EIP_1577___Multiaddr_support_for_ENS
Category: Working_Groups

Author: rachelhamlin
Date: 2018-11-21T13:45:42.610Z

Let’s get the party started, Provider ring.
Back in May, EIP1062 kicked off conversation about standardizing an ENS resolver field for resource hashes.
After some discussion, the group had consensus that:

Any storage protocol should be supported
The protocol should be identifiable w/o additional context

The latest proposal for the ENS resolver is now EIP1577. It uses a new contenthash field, which supports multiaddr, and calls for deprecation of the content and multihash fields.
@decanus and @Arachnid have updated PublicResolver.sol, and I’d like to propose that the Ethereum providers plan to add support for this new EIP in the coming weeks.
Should be a trivial change, and we can maintain backwards compatibility for DApps using the content field (rare, to my knowledge) until EOY. DApps moving to IPFS or Swarm will be able to follow this standard from the start.
Thoughts @p0s @marcgarreau @bitpshr?

Author: decanus
Date: 2018-11-22T01:52:16.219Z

I opened issues on Status and Metamask repositories to get this integrated.

Author: justelad
Date: 2018-11-25T05:32:12.524Z

Greetings from the Swarm team.
We’ve been following the discussion on EIP-1062.
We already have an issue to track this since September and now that the discussion has converged into something more concrete and extensible we could proceed to implement the necessary changes on our side too.
Great work on this topic.

Author: rachelhamlin
Date: 2018-11-28T12:35:20.374Z

Awesome @justelad. We’ll probably prioritize it in our next sprint.
Thanks for creating that issue @decanus!

Author: bitpshr
Date: 2018-11-29T15:28:36.005Z

Thanks for raising this @rachelhamlin and for filing a related issue @decanus. We’re planning to tackle this in our next sprint as well.

Author: andrey
Date: 2018-12-12T14:41:08.823Z

hey, I have a few questions

is new publicresolver deployed only in mainnet? do we have it deployed in testnets (ropsten, rinkeby) ?
how dapps developers can use this new contenthash  field . i know two ens managers
https://manager.ens.domains/
https://resolver.portal.network/
but both support only “old” content field, do we know who works on these two and if there are any plans to add contenthash  field support?

Author: Arachnid
Date: 2018-12-12T22:02:21.236Z

andrey:


is new publicresolver deployed only in mainnet? do we have it deployed in testnets (ropsten, rinkeby) ?



It’s deployed on mainnet; I don’t believe we’ve updated the Ropsten or other test network resolvers.



 andrey:

how dapps developers can use this new contenthash field . i know two ens managers


We’ll add support to the new manager soon. It’ll be up to others to add support themselves; we’ll be reaching out to them to help with that.

Author: angerborn
Date: 2018-12-14T12:14:36.968Z

Is there any known address that can be used to test a contenthash implementation?
I haven’t found any that use the new resolver yet.

Author: decanus
Date: 2018-12-20T16:45:18.320Z

angerborn:

Is there any known address that can be used to test a contenthash implementation?


yeah there is: pac-txt.eth

Author: pldespaigne
Date: 2019-01-10T13:32:27.491Z

Hi everyone !
I have just deployed an EIP1577 compliant resolver on ropsten so anybody can experiment 
The code has been verified so you can interact with the resolver directly on etherscan !
https://ropsten.etherscan.io/address/0xde469c7106a9FBC3fb98912bB00be983a89bDDca
Also, if you need I have made a small npm lib to encode / decode content hashes : content-hash

Author: justelad
Date: 2019-02-18T14:24:09.605Z

@Arachnid, @decanus


If I am not mistaken the public resolver code on the main go-ethereum codebase has to be updated (the one under contracts/ens/contract/PublicResolver.sol). Should I submit the change? I’m not sure about how you roll out these sort of changes and indeed this change affects all ethereum users that use ENS so it should be tested out thoroughly. Please advise how to proceed


The EIP description has a small mistake and mentions that Swarm and IPFS proto-codes are 0xee and 0xef, when in fact they are 0xe3 and 0xe4

Author: Arachnid
Date: 2019-02-18T18:38:39.746Z

You’re right, that will need updating for swarm. If you’d like to submit a PR, that’d be great.
I’ll fix the codes in the eip.

Author: justelad
Date: 2019-02-19T00:55:20.416Z

If you’d like to submit a PR, that’d be great.

I’m on it

Author: justelad
Date: 2019-03-07T06:01:19.497Z

The EIP specification mentions that the

values are encoded as v1 CIDs without a base prefix


This means that they are in fact not valid CIDs (as according to the CID spec)
This kind of pulls the rug out from using the multiformat libraries to maintain compatibility with the spec.
The EIP spec does not mention the default (only allowed?) encoding assumed (I am assuming base16 but IPFS assumptions are base58? so both should assume base16). Without a base prefix we must assume a certain encoding in order to unmarshal safely.

Thanks!

Author: Arachnid
Date: 2019-03-07T07:09:11.749Z

The CIDs are encoded in binary format. The CID spec says:

NOTE: Binary  (not text-based) protocols and formats may omit the multibase prefix when the encoding is unambiguous.

Author: mcdee
Date: 2019-03-18T14:03:59.643Z

FYI for testing purposes I’ve set up content hashes for ipfs.enstest.eth and swarm.enstest.eth on both ropsten and mainnet.
swarm is set with hash d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162 and ipfs with hash QmRAQB6YaCyidP37UdDnjFY5vQuiBrcqdyoW1CuDgwxkD4