New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiaddr support for ENS #1577

Merged
merged 3 commits into from Nov 13, 2018

Conversation

Projects
None yet
5 participants
@decanus
Contributor

decanus commented Nov 13, 2018


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.

@decanus decanus changed the title from Create eip-1577.md to Multiaddr support for ENS Nov 13, 2018

@Arachnid Arachnid merged commit 5b39572 into ethereum:master Nov 13, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@Amxx

This comment has been minimized.

Amxx commented Nov 13, 2018

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

This comment has been minimized.

bgits commented Nov 13, 2018

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

This comment has been minimized.

Contributor

decanus commented Nov 13, 2018

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

@decanus

This comment has been minimized.

Contributor

decanus commented Nov 13, 2018

@bgits bgits referenced this pull request Nov 13, 2018

Open

add swarm protocol code #73

@bgits

This comment has been minimized.

bgits commented Nov 13, 2018

@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

This comment has been minimized.

mickys commented Nov 13, 2018

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

This comment has been minimized.

Amxx commented Nov 14, 2018

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment