ENSIP-7: Contenthash field
Introduces a field for storing content addresses and hashes in ENS (formerly EIP-1577).
Last updated
Introduces a field for storing content addresses and hashes in ENS (formerly EIP-1577).
Last updated
This ENSIP introduces the new contenthash
field for ENS resolvers, allowing for a better defined system of mapping names to network and content addresses. Additionally the content
and multihash
fields are deprecated.
Multiple applications including Metamask and mobile clients such as Status have begun resolving ENS names to content hosted on distributed systems such as IPFS and Swarm. Due to the various ways content can be stored and addressed, a standard is required so these applications know how to resolve names and that domain owners know how their content will be resolved.
The contenthash
field allows for easy specification of network and content addresses in ENS.
The field contenthash
is introduced, which permits a wide range of protocols to be supported by ENS names. Resolvers supporting this field MUST return true
when the supportsInterface
function is called with argument 0xbc1c58d1
.
The fields content
and multihash
are deprecated.
The value returned by contenthash
MUST be represented as a machine-readable multicodec. The format is specified as follows:
protoCodes and their meanings are specified in the multiformats/multicodec repository.
The encoding of the value depends on the content type specified by the protoCode. Values with protocodes of 0xe3 and 0xe4 represent IPFS and Swarm content; these values are encoded as v1 CIDs without a base prefix, meaning their value is formatted as follows:
When resolving a contenthash
, applications MUST use the protocol code to determine what type of address is encoded, and resolve the address appropriately for that protocol, if supported.
IPFS
Input data:
Binary format:
Text format:
Input data:
Binary format:
Text format:
Example usage with swarm hash:
In order to support names that have an IPFS or Swarm hash in their content
field, a grace period MUST be implemented offering those name holders time to update their names. If a resolver does not support the multihash
interface, it MUST be checked whether they support the content
interface. If they do, the value of that field SHOULD be treated in a context dependent fashion and resolved. This condition MUST be enforced until at least March 31st, 2019.
To support contenthash
, a new resolver has been developed and can be found here, you can also find this smart contract deployed on:
There are also implementations in multiple languages to encode and decode contenthash
:
Copyright and related rights waived via CC0.
Author
Dean Eigenmann <dean@ens.domains>, Nick Johnson <nick@ens.domains>
Status
Final
Created
2018-11-13