Skip to content
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
Merged

Multiaddr support for ENS #1577

merged 3 commits into from
Nov 13, 2018

Conversation

decanus
Copy link
Contributor

@decanus decanus commented Nov 13, 2018


eip: 1577
title: Multiaddr support for ENS
author: Dean Eigenmann [email protected], Nick Johnson [email protected]
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 Create eip-1577.md Multiaddr support for ENS Nov 13, 2018
@Amxx
Copy link
Contributor

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
Copy link

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
Copy link
Contributor Author

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
Copy link
Contributor Author

decanus commented Nov 13, 2018

@bgits
Copy link

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
Copy link

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
Copy link
Contributor

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

@Amxx
Copy link
Contributor

Amxx commented Dec 17, 2018

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
Copy link

jacqueswww commented Dec 18, 2018

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
Copy link

jacqueswww commented Dec 18, 2018

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
Copy link
Contributor

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
Copy link

lidel commented May 16, 2019

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

@wighawag
Copy link
Contributor

Thanks @lidel !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants