Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save PhyrexTsai/cffcbfa1d752b9cf817d920dfcd1ec9f to your computer and use it in GitHub Desktop.
Save PhyrexTsai/cffcbfa1d752b9cf817d920dfcd1ec9f to your computer and use it in GitHub Desktop.

Portal Network - Integration ENS with IPFS

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

If you have any question please contact us for help:

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

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.

Set IPFS Hash to ENS Public Resolver

Using to set ENS Public Resolver and content with Public Resolver.

Step 1. Link to, 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

Copy link

Hi, can you tell me what to set the resolver to in the ENS manager app? My domain is currently set to 0x0. Should I copy your address or should I use what comes up when I press "Default Resolver"?

Copy link

CallMeGwei commented Aug 17, 2018

@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 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.

Copy link

lidel commented Aug 17, 2018

@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:

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 :
Note that this produces different hex than current version and probably requires changes on the backend.

Copy link

3esmit commented Jul 25, 2019

Copy link

none of these website links work...

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