I would like to open the discussion to support more types of content in the Contenthash field.
IPNS
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.
DAT
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.
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.
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).