mirror of https://github.com/status-im/EIPs.git
117 lines
4.6 KiB
Markdown
117 lines
4.6 KiB
Markdown
---
|
|
eip: 1577
|
|
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
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
The `contenthash` field allows for easy specification of network and content addresses in ENS.
|
|
|
|
## Specification
|
|
|
|
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](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.
|
|
|
|
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>
|
|
```
|
|
|
|
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
|
|
|
|
#### IPFS
|
|
|
|
Input data:
|
|
|
|
```
|
|
storage system: IPFS (0xe3)
|
|
CID version: 1 (0x01)
|
|
content type: dag-pb (0x70)
|
|
hash function: sha2-256 (0x12)
|
|
hash length: 32 bytes (0x20)
|
|
hash: 29f2d17be6139079dc48696d1f582a8530eb9805b561eda517e22a892c7e3f1f
|
|
```
|
|
|
|
Binary format:
|
|
|
|
```
|
|
0xe3010170122029f2d17be6139079dc48696d1f582a8530eb9805b561eda517e22a892c7e3f1f
|
|
```
|
|
|
|
Text format:
|
|
|
|
```
|
|
ipfs://QmRAQB6YaCyidP37UdDnjFY5vQuiBrcqdyoW1CuDgwxkD4
|
|
```
|
|
|
|
### Swarm
|
|
|
|
Input data:
|
|
|
|
```
|
|
storage system: Swarm (0xe4)
|
|
CID version: 1 (0x01)
|
|
content type: swarm-manifest (0xfa)
|
|
hash function: keccak256 (0x1b)
|
|
hash length: 32 bytes (0x20)
|
|
hash: d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162
|
|
```
|
|
|
|
Binary format:
|
|
```
|
|
0xe40101fa011b20d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162
|
|
```
|
|
|
|
Text format:
|
|
```
|
|
bzz://d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162
|
|
```
|
|
|
|
Example usage with swarm hash:
|
|
```
|
|
$ swarm hash ens contenthash d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162
|
|
> e40101fa011b20d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162
|
|
```
|
|
|
|
### Fallback
|
|
|
|
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
|
|
|
|
To support `contenthash`, a new resolver has been developed and can be found [here](https://github.com/ensdomains/resolvers/blob/master/contracts/PublicResolver.sol), you can also find this smart contract deployed on:
|
|
|
|
* Mainnet : [0xd3ddccdd3b25a8a7423b5bee360a42146eb4baf3](https://etherscan.io/address/0xd3ddccdd3b25a8a7423b5bee360a42146eb4baf3)
|
|
* Ropsten : [0xde469c7106a9fbc3fb98912bb00be983a89bddca](https://ropsten.etherscan.io/address/0xde469c7106a9fbc3fb98912bb00be983a89bddca)
|
|
|
|
There are also implementations in multiple languages to encode and decode `contenthash`:
|
|
|
|
* [JavaScript](https://github.com/pldespaigne/content-hash)
|
|
* [Python](https://github.com/filips123/ContentHashPy)
|
|
|
|
## Copyright
|
|
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|