mirror of https://github.com/status-im/EIPs.git
67 lines
3.1 KiB
Markdown
67 lines
3.1 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 encoding of the value depends on the content type specified by the protoCode; for instance, types in the range 0x00-0xf0 are encoded using [multihash](https://github.com/multiformats/multihash), meaning their format is specified as follows:
|
|
|
|
```
|
|
<varint hash function code><varint digest size in bytes><hash function output>
|
|
```
|
|
|
|
When resolving a multiaddr, 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
|
|
|
|
Input data:
|
|
```
|
|
storage system: IPFS (0x01)
|
|
hash function: sha2-256 (0x12)
|
|
hash length: 32 bytes (0x20)
|
|
hash: 29f2d17be6139079dc48696d1f582a8530eb9805b561eda517e22a892c7e3f1f
|
|
```
|
|
|
|
Binary format:
|
|
|
|
```
|
|
0x01122029f2d17be6139079dc48696d1f582a8530eb9805b561eda517e22a892c7e3f1f
|
|
```
|
|
|
|
Text format:
|
|
|
|
```
|
|
/ipfs/7CRg9waUqSw8n2qweMebgzgBa4hxtpNonC7RBeWN5HSF4wx
|
|
```
|
|
|
|
### 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 `multiaddr` 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 December 31st, 2018.
|
|
|
|
### 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), 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/).
|