The New ENS Manager Now Supports EIP1577 contenthash

Introduction

One of the most frequently asked questions we hear at ENS has been “How do you integrate IPFS/swarm into ENS?”. In addition to setting your domain to resolve to an Ethereum address, we have a function[setContent(bytes32 node, bytes32 hash](https://web3js.readthedocs.io/en/1.0/web3-eth-ens.html#setcontent)) to set content, but we haven’t standardised the format for this field, and it’s limited to 32 bytes — rendering it unsuitable for use with IPFS.

A few proposals were made, and the final version came up as EIP1577, proposed by

and

.

We are now pleased to announce that you can use the new protocol via our new ENS Manager.

With the new contenthash protocol, you do not have to encode an IPFS hash by yourself; the manager will take care of it on your behalf.

How do you start using contenthash?

The contenthash format is supported in the newly deployed Resolver contract which is set under resolver.eth (yes, we are eating our own dog-food). You can set the new resolver by clicking “Use Public Resolver”.

For testing on Ropsten, we don’t own the same domain so you need to set the address 0xde469c7106a9FBC3fb98912bB00be983a89bDDca manually (sorry).

When migrating to a new resolver, you will need to set any existing fields such as address again on the new resolver contract.

What about the existing content?

If you have already set Resolver into existing ENS name to resolve an Ethereum address, chances are you are using the old Resolver which does not have contenthash support. Changing the Resolver of existing names is time consuming so we continue to support the old Resolver.

What you will notice is a few warning signs, and you will have to convert content to hex format by yourself (as it used to be).

Does that make all sense? If it’s not clear yet, here is the brief walk-through video.

Open contribution from

With the new EIP 1577, we were going to start writing a library to encode/decode the new format.

We had a pleasant surprise when

joined our github issue conversation from nowhere with his own implementation so that I was able to concentrate on just integrating it into our app!

Thank you so much,

! We are looking for more open contribution like this.