EIPs/EIPS/eip-1577.md

78 lines
3.5 KiB
Markdown
Raw Normal View History

---
eip: 1577
2018-11-19 03:10:36 +00:00
title: contenthash field for ENS
author: Dean Eigenmann <dean@ens.domains>, Nick Johnson <nick@ens.domains>
type: Standards Track
category: ERC
status: Draft
created: 2018-11-13
---
## Abstract
2018-11-19 03:10:36 +00:00
This EIP 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.
## Motivation
2018-11-19 03:10:36 +00:00
Multiple applications including [Metamask](https://metamask.io/) and mobile clients such as [Status](https://status.im) have begun resolving ENS names to content hosted on distributed systems such as [IPFS](https://ipfs.io/) and [Swarm](https://swarm-guide.readthedocs.io). 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.
2018-11-19 03:10:36 +00:00
The `contenthash` field allows for easy specification of network and content addresses in ENS.
## Specification
2018-11-19 03:10:36 +00:00
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.
2018-11-28 05:59:16 +00:00
The value returned by `contenthash` MUST be represented as a machine-readable [multicodec](https://github.com/multiformats/multicodec). The format is specified as follows:
```
<protoCode uvarint><value []byte>
```
protoCodes and their meanings are specified in the [multiformats/multicodec](https://github.com/multiformats/multicodec) repository.
2018-11-28 05:59:16 +00:00
2019-02-21 19:23:23 +00:00
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](https://github.com/multiformats/cid) without a base prefix, meaning their value is formatted as follows:
```
<protoCode uvarint><cid-version><multicodec-content-type><multihash-content-address>
```
2018-11-28 05:59:16 +00:00
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.
### Example
2018-11-19 03:10:36 +00:00
Input data:
```
2019-01-21 18:47:49 +00:00
storage system: IPFS (0xe3)
CID version: 1 (0x01)
content type: dag-pb (0x70)
2018-11-19 03:10:36 +00:00
hash function: sha2-256 (0x12)
hash length: 32 bytes (0x20)
hash: 29f2d17be6139079dc48696d1f582a8530eb9805b561eda517e22a892c7e3f1f
```
Binary format:
```
2019-01-21 18:47:49 +00:00
0xe3010170122029f2d17be6139079dc48696d1f582a8530eb9805b561eda517e22a892c7e3f1f
2018-11-19 03:10:36 +00:00
```
Text format:
```
ipfs://QmRAQB6YaCyidP37UdDnjFY5vQuiBrcqdyoW1CuDgwxkD4
```
### Fallback
2019-01-21 18:47:49 +00:00
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.
### Implementation
2018-11-19 03:10:36 +00:00
To support `contenthash`, a new resolver has been developed and can be found [here](https://github.com/ensdomains/resolvers/blob/master/contracts/PublicResolver.sol), which has been deployed at [0xd3ddccdd3b25a8a7423b5bee360a42146eb4baf3](https://etherscan.io/address/0xd3ddccdd3b25a8a7423b5bee360a42146eb4baf3)
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).