Missing support in Contenthash (EIP-1577)

I would like to open the discussion to support more types of content in the Contenthash field.


The support of IPFS files does not seem to support IPNS, which points to a public key signing upgradable content in IPFS.

If a developer wishes to use IPNS to update their content, they should be able to.


As discussed in https://github.com/beakerbrowser/beaker/issues/33, dat can be consumed by ethereum dapps, however the dat devs won’t take the effort to integrate.
DAT is gaining popularity for developers willing to decentralize everything, including ethereum DApps (see the discussion below).

Torrents (?)

Torrents? Maybe torrents could also become a contenthash, so magnet links can be translated from Contenthash. Technically speaking, is feasible to use old good torrent technology to host a dapp.
Maybe it could work just with the plain hash of the file, not including the trackers, assuming that a decentralized messaging stack (as Whisper/Waku) could be used to implement a decentralized tracker.
Probably this can be left to future.

Other (?)

Please, suggest in comments.

1 Like

I don’t know about the others but IPNS is supported. Here is the example https://app.ens.domains/name/noahzinsmeister.eth

I don’t see the 0xe5 specified, unless not on the EIPs. https://www.npmjs.com/package/content-hash says it supports every multicodec specified on https://github.com/multiformats/multicodec, I see that EIP-1577 mention this, but I think this is confusing right now.

We should have very straight forward documentation about this formats, as they are very important for the use of ENS as a domain system.

For example, I grab the value from the ENS domain you examplified, and this returned me 1Ghg8vPvQZaVn2UkkRqBiXyKCpJY, what I do with this string?

$ npm install content-hash
+ content-hash@2.5.2
$ node
> const contentHash = require('content-hash')
> contentHash.decode("e501017000136e6f61687a696e736d6569737465722e636f6d")

You need to further decode bs58

import bs58 from 'bs58'

content-hash is maintained by the external contributor and I am not familiar to the overall protocol myself. I kinda figured out try&error. If you could enhance their doc, that would be actually great.

1 Like

Multiple providers for the same content

Currently Contenthash (EIP-1557) support a single value. I think this makes sense in the idea that we only want one content to be defined.

However, the content might be hosted in multiple systems, such as Swarm, IPFS, DAT, Onion, Torrent, etc, and therefore I want to give option to the user load the content from whatever it prefers.

I see that this is not possible with current Content field, perhaps we could use text field, however that won’t be a standard.

Maybe we could change support in Contenthash a keccak256 of content and load from text entries.

One problem with this proposal is that it’s not clear how a browser or other client should handle it - which system should they resolve to, if they support multiple?

it’s not clear how a browser or other client should handle it - which system should they resolve to, if they support multiple

Two ways on solving that:
a. The client itself could have a priority list, which it selects what it tries to load first.
b. The contenthash could have a priority list (similar to MX records in DNS).

Can’t we simply make PublicResolver support an array of contenthash? first positions are preferred sources.