Portal Network - Integration ENS with IPFS.md

Portal Network - Integration ENS with IPFS

This tutorial is how to post website/application on IPFS and link with ENS domains(.eth).

• Try it: http://portalnetwork.eth

If you have any question please contact us for help:

• Telegram
• GitHub
• Medium
• Twitter
• Facebook
• Reddit

Build Dweb through Portal Network

• Web Builder: You can build your own DWeb Here
• Showcase: Take a look of other DWeb Here

Deploy website/application to IPFS

Introduce with IPFS

IPFS is a peer-to-peer hypermedia protocol to make the web faster, safer, and more open.

Interact with IPFS

• Manual Install: https://ipfs.io/docs/install/
• IPFS api library(JavaScript): https://github.com/ipfs/js-ipfs-api

Upload files to IPFS

Link IPFS content with ENS

Introduce with ENS

ENS is the Ethereum Name Service, a distributed, open, and extensible naming system based on the Ethereum blockchain.

ENS can be used to resolve a wide variety of resources. The initial standard for ENS defines resolution for Ethereum addresses, but the system is extensible by design, allowing more resource types to be resolved in future without the core components of ENS requiring upgrades.

• ENS Document: https://docs.ens.domains/

Set IPFS Hash to ENS Public Resolver

Using https://manager.ens.domains to set ENS Public Resolver and content with Public Resolver.

Step 1. Link to https://manager.ens.domains, and search ENS which you want to bind with IPFS hash

Step 2. Set Public Resolver to ENS

Step 3. Convert IPFS hash to Hex

This is a simple convert tool for convert IPFS hash to hex, link here.

Step 4. Set Content to Public Resolver

Website/application Hosting on IPFS

• http://portalnetwork.eth
• http://phyrextsai.eth
• http://christophershen.eth
• http://hozt.portalnetworkweb.eth

@rhlsthrm I agree, this is unclear.

They are using 0x1da022710df5002339274aadee8d58218e9d6ab5 in the screenshot.
That is the same ENS resolver that was set if you set up your domain via the legacy registrar.ens.domains interface.

Hitting the "Use default resolver" button populates 0x5ffc014343cd971b7eb70732021e26c35b744cc4

There is no explanation of what the "default" is - or why it would be preferred to the "default" set via the legacy registrar - or if the new "default" even works for the purposes here.

Briefly comparing the two resolver contracts, the new default is simple a clone of the old default - with the addition of a TEXT record and requisite methods to facilitate that addition.

So, I think either resolver contract would work for the functionality discussed here. This is, however, an unnecessary point of confusion for this exciting new feature. A little additional clarity would go a long way.

@PhyrexTsai is there a reason why you unwrap hash digest from multihash (CIDv0) in Step 3? (Convert IPFS hash to Hex)

It introduces a problem when default hash algorithm used by IPFS changes.
Just to be safe, update this instruction and ask people to use a specific hash algorithm when adding content to IPFS (eg. sha2-256).

That being said, unless you are limited by the hash size, consider future-proofing entire setup by switching from raw sha2-256 digest to full CID, a self-describing content-addressed identifier used in IPFS: https://github.com/ipld/cid#cid-content-identifier

FYSA IPFS ecosystem slowly moves from multihashes (CIDv0) to CIDv1, which adds fields with content type and text encoding in arbitrary bases (enabling text identifiers to be used in case-insensitive contexts).

tl;dr People will start using CIDv1 in near future, make sure to plan for that.

ps. Updated Step 3 to convert entire CIDv0 (not only digest) and also support CIDv1 : https://codepen.io/anon/pen/XBvPKg
Note that this produces different hex than current version and probably requires changes on the backend.

Please, update this spec to use contenthash:
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1577.md
https://content-hash.surge.sh/

none of these website links work...