-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Formalize IPFS hash into ENS(Ethereum Name Service) resolver #1062
Changes from 7 commits
0ce5a31
fed41a5
24088e3
b943093
dd6a474
afb0639
c4ad591
b17f545
18adca6
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,87 @@ | ||
--- | ||
eip: 1062 | ||
title: Formalize IPFS hash into ENS(Ethereum Name Service) resolver | ||
author: Phyrex Tsai <[email protected]>, Portal Network Team | ||
discussions-to: https://ethereum-magicians.org/t/eip-1062-formalize-ipfs-hash-into-ens-ethereum-name-service-resolver/281 | ||
status: Draft | ||
type: Standards Track | ||
category: ERC | ||
created: 2018-05-02 | ||
--- | ||
|
||
## Simple Summary | ||
To specify the mapping protocol between resources stored on IPFS and ENS(Ethereum Naming Service). | ||
|
||
## Abstract | ||
The following standard details the implementation of how to combine the IPFS cryptographic hash unique fingerprint with ENS public resolver. This standard provides a functionality to get and set IPFS online resources to ENS resolver. | ||
|
||
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 storage system. Here comes the IPFS, for three following advantages : | ||
- Address large amounts of data, and has unique cryptographic hash for every record. | ||
- Since IPFS is also based on peer to peer network, it can be really helpful to deliver large amounts of data to users, with safer way and lower the millions of cost for the bandwidth. | ||
- IPFS stores files in high efficient way via tracking version history for every file, and removing the duplications across the network. | ||
|
||
Those features makes perfect match for integrating into ENS, and these make users can easily access content through ENS, and show up in the normal browser. | ||
|
||
|
||
## 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hex strings are encoded binary data, not integers, typically (though they can be either). |
||
- 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 bridging that gap. | ||
When mapping the IPFS base58 string to ENS resolver, first we convert the Base58 to binary buffer, turn the buffer to hex encrypted format, and save to the contract. Once we want to get the IPFS resources address represented by the specific ENS, we can first find the mapping information stored as hex format before, extract the hex format to binary buffer, and finally turn that to IPFS Base58 address string. | ||
|
||
|
||
## Rationale | ||
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); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If you're happy to change to storing full multihash values in Also, to be consistent with existing resolver profiles, There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd happy renaming to |
||
``` | ||
|
||
Whenever users need to visit the ENS content, we call the `content` method to get the IPFS hex data, transfer to the Base58 format, and return the IPFS resources to use. | ||
|
||
``` | ||
function content(bytes32 node) public view returns (bytes32); | ||
``` | ||
|
||
## Test Cases | ||
|
||
To implement the way to transfer from base58 to hex format and the reverse one, using the ‘multihashes’ library to deal with the problem. | ||
The library link : [https://www.npmjs.com/package/multihashes](https://www.npmjs.com/package/multihashes) | ||
To implement the method transfer from IPFS(Base58) to hex encryption format : | ||
|
||
``` | ||
import multihash from 'multihashes' | ||
|
||
export const toHex = function(ipfsHash) { | ||
let buf = multihash.fromB58String(ipfsHash) | ||
let digest = multihash.decode(buf).digest | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Doing this hardcodes the use of SHA2-256. Could we just store the binary multihash in a This would be useful for swarm, too, who want to be able to store hash+key pairs in ENS. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. About Base58 hash convert to hex, here's a simple version just using To implement the method transfer from IPFS(Base58) to hex encryption format :
To implement the method transfer from hex encryption format to IPFS(Base58)
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That looks like it would work, yes. It looks like |
||
return '0x' + multihash.toHexString(digest) | ||
} | ||
``` | ||
|
||
To implement the method transfer from hex encryption format to IPFS(Base58) : | ||
|
||
``` | ||
import multihash from 'multihashes' | ||
|
||
export const toBase58 = function(contentHash) { | ||
let hex = contentHash.substring(2) | ||
let buf = multihash.fromHexString(hex) | ||
return multihash.toB58String(multihash.encode(buf, 'sha2-256')) | ||
} | ||
``` | ||
|
||
## Implementation | ||
The use case can be implemented as browser extension. Users can easily download the extension, and easily get decentralized resources by just typing the ENS just like we normally type the DNS to browser the website. Solve the current pain for normal people can not easily visit the total decentralized website. | ||
|
||
The workable implementation repository : [https://github.com/PortalNetwork/portal-network-browser-extension](https://github.com/PortalNetwork/portal-network-browser-extension) | ||
|
||
## Copyright | ||
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.