Multiaddr support for ENS

[decanus]

---

eip: 1577
title: Multiaddr support for ENS
author: Dean Eigenmann dean@ens.domains, Nick Johnson nick@ens.domains
type: Standards Track
category: ERC
status: Draft
created: 2018-11-13
discussion-to: #1577

Abstract

This EIP introduces the new multiaddr 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 and mobile wallets 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 multiaddr field allows for easy specification of network and content addresses in ENS.

Specification

The field multiaddr 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 0x4cb7724c.

The fields content and multihash are deprecated.

Addresses MUST be represented as a machine-readable multiaddr. The format is specified as follows:

<protoCode uvarint><value []byte>

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

Text format:

/p2p/QmRAQB6YaCyidP37UdDnjFY5vQuiBrcqdyoW1CuDgwxkD4

Binary format:

a50322122029f2d17be6139079dc48696d1f582a8530eb9805b561eda517e22a892c7e3f1f

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 multiaddr, a new resolver has been developed and can be found here.

Copyright

Copyright and related rights waived via CC0.

[Amxx]

Are there tools to translate a readable multiaddress from/to an hex string? Even if it is beyound the scope of the EIP to implement such tools, having pointers to such tools would help adoption.

[bgits]

Should a proposal also be made with the maintainers of multiaddr to add swarm hashes? I don't believe there is protoCode for swarm hashes.

[decanus]

@bgits Yes, we are planning on doing that. However if you want to feel free to do it before us.

[decanus]

@Amxx check https://github.com/multiformats/js-multiaddr

[bgits]

@bgits Yes, we are planning on doing that. However if you want to feel free to do it before us.

I started a barebones issue at multiformats/multiaddr#73 . Additional details are likely needed.

[mickys]

Maybe this should be a separate EIP, but the first thing that popped into my mind when i saw this was a "/wallet/network/chainId/0xAddress"

It's bound to happen, so if anyone does this please use slip-0044 for the networkId and chainId.
https://github.com/satoshilabs/slips/blob/master/slip-0044.md so the wallet can easily decode this address.

[Amxx]

@Amxx check https://github.com/multiformats/js-multiaddr

That is not really user-friendly so I made: https://app.hadriencroubois.com/multiaddr/
UI is crap but anyone could use it to produce bytes to send to the resolver.

Edit: also available at https://gateway.ipfs.io/ipfs/QmRwwTz9Chq4Y7F7ReKKcx1GV6s3H7egmNGrku9XrwiDa8

[Amxx]

It seems that Vyper does not support bytes or more generally unbounded arrays... Any idea how to support multiaddr in that context. Should we disregard vyper and only consider solidity and ewasm for building compatibles smart contracts?

[jacqueswww]

Everything has it's limitations, Vyper's bytes just have a max length, which make it usable for most cases, but gives you the benefit of always knowing your bounds. And would still be very usable if a high value like 512 bytes was chosen (I mean this is implementation specific but it's all just bytes type on the ABI, the max length is asserted in the contract).

I am trying to understand why an array is required here? If you use a map with protocol_key => address/content_url one can ensure that one can easily replace a given hash/identifier for a given protocol (also it's a single lookup on the contract / much cleaner). If one uses an array, one could easily introduce duplicates and a node wouldn't know which address to resolve?

[jacqueswww]

I looked at the linked implementation
https://github.com/ensdomains/resolvers/blob/master/contracts/PublicResolver.sol#L37.

In vyper, to a consuming node

 struct Record:
     contenthash: bytes[512]

as solidity's

struct Record { bytes contenthash }

Would look and act exactly the same way, except - we have a maximum length on the amounts of bytes we store ;) So I think Vyper is still capable of implementing this (unless I am looking a the wrong code 😄 ).

[wighawag]

Hey just found out at https://eips.ethereum.org/EIPS/eip-1577 that you use string like ipfs://QmRAQB6YaCyidP37UdDnjFY5vQuiBrcqdyoW1CuDgwxkD4 for ipfs uri text format representation
Should it not be more like
fs:/ipfs/QmRAQB6YaCyidP37UdDnjFY5vQuiBrcqdyoW1CuDgwxkD4
or ipfs:/ipfs/QmRAQB6YaCyidP37UdDnjFY5vQuiBrcqdyoW1CuDgwxkD4
... ?

as described here ipfs/kubo#1678 (comment)

[lidel]

fs:/ is no longer a thing, please see ipfs/kubo#1678 (comment)

[wighawag]

Thanks @lidel !