Formalize IPFS hash into ENS(Ethereum Name Service) resolver #1062

PhyrexTsai · 2018-05-04T06:33:15Z

Initial pull request for the "Formalize IPFS hash into ENS(Ethereum Name Service) resolver" EIP.

The goal is to specify the mapping protocol between resources stored on IPFS and ENS(Ethereum Naming Service).

Arachnid · 2018-05-05T08:40:44Z

EIPS/eip-1062.md

+eip: 1062
+title: Formalize IPFS hash into ENS(Ethereum Name Service) resolver
+author: Phyrex Tsai <[email protected]>, Portal Network Team
+discussions-to: [email protected]


Please supply a URL where people can discuss, such as a post on the ethereum-magicians forum.

Arachnid · 2018-05-05T08:41:36Z

EIPS/eip-1062.md

+
+export const toHex = function(ipfsHash) {
+ let buf = multihash.fromB58String(ipfsHash)
+ let digest = multihash.decode(buf).digest


Doing this hardcodes the use of SHA2-256. Could we just store the binary multihash in a bytes field instead, which would provide forward compatibility?

This would be useful for swarm, too, who want to be able to store hash+key pairs in ENS.

About Base58 hash convert to hex, here's a simple version just using bytes:

To implement the method transfer from IPFS(Base58) to hex encryption format :

import bs58 from 'bs58' export const toHex = function(ipfsHash) { const bytes = bs58.decode(ipfsHash) return '0x' + bytes.toString('hex') }

To implement the method transfer from hex encryption format to IPFS(Base58)

import bs58 from 'bs58' export const toBase58 = function(contentHash) { const hex = contentHash.substring(2) const bytes = Buffer.from(hex, 'hex') return bs58.encode(bytes) }

That looks like it would work, yes. It looks like multihashes has toHexString and fromHexString too, though, which would probably be a better fit.

Arachnid · 2018-05-05T08:42:23Z

Pinging @homotopycolimit because this is of interest for Swarm, too.

cobordism · 2018-05-05T11:14:40Z

also ping: swarm. mutlihash support: @zelig @nolash @gbalint

come-maiz · 2018-05-05T17:17:13Z

EIPS/eip-1062.md

+We think that this implementation is not only aim to let more developers and communities to provide more use cases, but also leverage the human-readable features to gain more user adoption accessing decentralized resources. We considered the IPFS ENS resolver mapping standard a cornerstone for building future Web3.0 service.
+
+## Motivation
+To build fully decentralized web service, it’s necessary to have a decentralized file sotrage system. Here comes the IPFS, for three following advantages :


typo: sotrage -> storage

come-maiz · 2018-05-05T17:17:34Z

EIPS/eip-1062.md

+
+## Motivation
+To build fully decentralized web service, it’s necessary to have a decentralized file sotrage system. Here comes the IPFS, for three following advantages :
+- Address large amounts of data, and has unique cryptographic hash for every records.


typo: records -> record

come-maiz · 2018-05-05T17:17:49Z

EIPS/eip-1062.md

+## Motivation
+To build fully decentralized web service, it’s necessary to have a decentralized file sotrage system. Here comes the IPFS, for three following advantages :
+- Address large amounts of data, and has unique cryptographic hash for every records.
+- Since IPFS is also based on peer to peer network, it can be really helpful to delivers large amounts of data to users, with safer way and lower the millions of cost for the bandwidth.


typo: delivers -> deliver

come-maiz · 2018-05-05T17:18:51Z

EIPS/eip-1062.md

+- Different data type, one is string, the other is integer.
+- The way to process the condition requires not only we need to transfer from IPFS to Ethereum, but also need to convert it back.
+
+To solve these requirements, we can use binary buffer briding that gap.  


typo: briding -> bridging

PhyrexTsai · 2018-05-06T02:56:38Z

@ElOpio Thank you for helping fix the typos

Arachnid · 2018-05-06T09:42:35Z

EIPS/eip-1062.md

+
+
+## Specification
+The condition now is that the IPFS file fingerprint using base58 and in the meantime, the Ethereum using hex encryption. These comes the two restrictions :


It's "hex encoding", not "hex encryption", and it's not actually the case - Ethereum stores binary data, it just uses hex in API to encode the binary data. Internally it's stored in binary form.

Arachnid · 2018-05-06T09:42:50Z

EIPS/eip-1062.md

+
+## Specification
+The condition now is that the IPFS file fingerprint using base58 and in the meantime, the Ethereum using hex encryption. These comes the two restrictions :
+- Different data type, one is string, the other is integer.


Hex strings are encoded binary data, not integers, typically (though they can be either).

Arachnid · 2018-05-06T09:44:50Z

EIPS/eip-1062.md

+
+export const toHex = function(ipfsHash) {
+ let buf = multihash.fromB58String(ipfsHash)
+ let digest = multihash.decode(buf).digest


That looks like it would work, yes. It looks like multihashes has toHexString and fromHexString too, though, which would probably be a better fit.

Arachnid · 2018-05-06T09:46:21Z

EIPS/eip-1062.md

+To implement the specification, need two methods from ENS public resolver contract, when we want to store IPFS file fingerprint to contract, convert the Base58 string identifier to the hex format and invoke the `setContent` method below :
+
+```
+function setContent(bytes32 node, bytes32 hash) public only_owner(node);


If you're happy to change to storing full multihash values in bytes, I'd suggest renaming these to setMultihash and multihash.

Also, to be consistent with existing resolver profiles, setMultihash should be specified as optional; only the getter is strictly part of the public interface.

I'd happy renaming to setMultihash and multihash and use bytes to store

cobordism · 2018-05-07T17:03:29Z

Would we ever expect a name to store both a Swarm hash and an IPFS hash? Or are we expecting a name to store either one or the other and using the multihash format to determine what the content hash refers to?

Or shall we introduce the convention to use bzz.name.eth and ipfs.name.eth ? ;)

Arachnid · 2018-05-08T12:42:30Z

@homotopycolimit Good question! I'm fine with using different names, personally, but I think it's an issue worth considering. If this is desirable, we could specify that it returns a content-type, or other distinguishing field, maybe?

What do others think?

Georgi87 · 2018-05-16T16:29:41Z

I would favor to encode this information in a multihash. From a UX perspective users will prefer to type name.eth instead of specifying the protocol using a subdomain.

PhyrexTsai · 2018-05-18T03:04:35Z

If we do need both store IPFS hash and Swarm hash using same name.eth within the same resolver, we may have two functions for each, otherwise the setMultihash function only can store one hash in it.

For this issue, we can consider to implement a map for multihash, and specify IPFS hash or Swarm hash.

struct Record {
    address addr;
    bytes32 content;
    string name;
    PublicKey pubkey;
    mapping(string=>string) text;
    mapping(uint256=>bytes) abis;
    mapping(string=>bytes) multihash; // bytes multihash; to mapping(string=>bytes) multihash;
}

// Set (name.eth, swarm, 0xccef599d1...) and (name.eth, ipfs, 0x49ae177d1db...)
function setMultihash(bytes32 node, string key, bytes hash) public only_owner(node) {
    records[node].multihash[key] = value;
    MultihashChanged(node, key, hash);
}

// Get by (name.eth, swarm) or (name.eth, ipfs)
function multihash(bytes32 node, string key) public view returns (string) {
    return records[node].multihash[key];
}

nolash · 2018-05-18T19:14:19Z

Isn't storing dynamic bytes very expensive? Maybe it should be 3xbytes32 instead?

Also, I'm wondering what exactly does a "IPFS multhash" and "Swarm multihash" mean. Does it mean that there is an actual reserved identifier in the official-ish multihash table that unambiguously specifies this? (currently all of them seem to be actual hash algorithm names).

Arachnid · 2018-05-21T13:48:00Z

Isn't storing dynamic bytes very expensive? Maybe it should be 3xbytes32 instead?

Storing bytes costs one slot, plus the number of slots required for the data, rounded up.

Also, I'm wondering what exactly does a "IPFS multhash" and "Swarm multihash" mean. Does it mean that there is an actual reserved identifier in the official-ish multihash table that unambiguously specifies this? (currently all of them seem to be actual hash algorithm names).

People are talking about the resource the multihash is specifying - is it on Swarm, or IPFS?

PhyrexTsai and others added 2 commits May 4, 2018 14:31

Formalize IPFS hash into ENS(Ethereum Name Service) resolver

0ce5a31

Update and rename eip-X.md to eip-1062.md

fed41a5

Arachnid reviewed May 5, 2018

View reviewed changes

Arachnid added 2 commits May 5, 2018 09:42

Merge branch 'master' into master

24088e3

Remove superfluous space after 'category'

b943093

Update the URL for discussion

dd6a474

come-maiz reviewed May 5, 2018

View reviewed changes

PhyrexTsai added 2 commits May 6, 2018 10:11

Fix typos

afb0639

Fix typo

c4ad591

Arachnid reviewed May 6, 2018

View reviewed changes

PhyrexTsai added 2 commits May 7, 2018 00:29

Update Specification, Rationale and Test Cases

b17f545

Store multihash value in bytes

18adca6

Arachnid merged commit c2bfd23 into ethereum:master May 7, 2018

ghost mentioned this pull request Mar 15, 2019

EIP1577 - Multiaddr support for ENS multiformats/multiaddr#79

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Formalize IPFS hash into ENS(Ethereum Name Service) resolver #1062

Formalize IPFS hash into ENS(Ethereum Name Service) resolver #1062

PhyrexTsai commented May 4, 2018

Arachnid May 5, 2018

Arachnid May 5, 2018

PhyrexTsai May 6, 2018

Arachnid May 6, 2018

Arachnid commented May 5, 2018

cobordism commented May 5, 2018

come-maiz May 5, 2018

come-maiz May 5, 2018

come-maiz May 5, 2018

come-maiz May 5, 2018

PhyrexTsai commented May 6, 2018

Arachnid May 6, 2018

Arachnid May 6, 2018

Arachnid May 6, 2018

Arachnid May 6, 2018

PhyrexTsai May 7, 2018 •

edited

Loading

cobordism commented May 7, 2018

Arachnid commented May 8, 2018

Georgi87 commented May 16, 2018

PhyrexTsai commented May 18, 2018

nolash commented May 18, 2018

Arachnid commented May 21, 2018



		## Specification
		The condition now is that the IPFS file fingerprint using base58 and in the meantime, the Ethereum using hex encryption. These comes the two restrictions :

Formalize IPFS hash into ENS(Ethereum Name Service) resolver #1062

Formalize IPFS hash into ENS(Ethereum Name Service) resolver #1062

Conversation

PhyrexTsai commented May 4, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Arachnid commented May 5, 2018

cobordism commented May 5, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PhyrexTsai commented May 6, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PhyrexTsai May 7, 2018 • edited Loading

Choose a reason for hiding this comment

cobordism commented May 7, 2018

Arachnid commented May 8, 2018

Georgi87 commented May 16, 2018

PhyrexTsai commented May 18, 2018

nolash commented May 18, 2018

Arachnid commented May 21, 2018

PhyrexTsai May 7, 2018 •

edited

Loading