[Draft] ENSIP-17: DataURI Format in Contenthash

raffy · January 12, 2024, 10:12am

I was going make a different thread but I’ll bump this one instead.

Provided again for reference:

ENSIP-7: ENSIP-7: Contenthash field - ENS Documentation
ERC-1577: https://github.com/ethereum/ercs/blob/master/ERCS/erc-1577.md

The “known” multicodecs are listed here: https://github.com/multiformats/multicodec/blob/master/table.csv

Example: arweave is listed as:

name: arweave-ns
tag: namespace
code: 0xb29910
status: draft
description: Arweave Namespace

I don’t know what tag means or what “namespace” is.

The current ensdomains/content-hash library supports the following protocols:

github.com

ensdomains/content-hash/blob/master/src/map.ts

export const codeToName = {
  0xe3: "ipfs",
  0xe5: "ipns",
  0xe4: "swarm",
  0x01bc: "onion",
  0x01bd: "onion3",
  0xb19910: "skynet",
  0xb29910: "arweave",
} as const;

export const nameToCode = {
  ipfs: 0xe3,
  ipns: 0xe5,
  swarm: 0xe4,
  onion: 0x01bc,
  onion3: 0x01bd,
  skynet: 0xb19910,
  arweave: 0xb29910,
} as const;

This file has been truncated. show original

Example: predomain.eth’s contenthash is encoded as <uvarint(0xB29910)><bytes32> where those bytes are TX_ID (which apparently is a sha256 hash.) To resolve that content, you need to query an arweave gateway, which involves finding a public gateway and reading their API docs for how to make a query (eg. Base64URL encode the hash).

My point: trying to figure this stuff out from purely from documentation is hard.

I just want to make a few random comments:

We should update ENSIP-7 to include all the known protocols. We should include examples of how you decode and query the data, links to documentation, etc. For the CID examples, we should also put conditionals on the CID codec types. Like what happens if you get a IPFS CID that isn’t a dag-pb? Or an IPNS CID that isn’t a libp2p-key? I can do this if appropriate.

Why wasn’t the AddressResolver used to store this data? This is a historical question.

Is contenthash just for websites? Or are there other use-cases?

Since there’s no way to resolve the contenthash without multiple levels of interpretation (protocol → hash decoding → query hash → interpret), can we address ENSIP-17 and @NameSys’s request by simply having a contenthash that is a pointer to a text record? This could either be <uvarint(protocol)><utf8 bytes of text key> or just <uvarint(protocol)> which uses the fixed key "contenthash". Then, contenthash can just be any URI, which allows data:.., ipfs://..., bzz://..., arweave://..., https://, or whatever. This would be both self-describing and pre-formats the data for easy querying. And if the URL is 64 bytes or less, there’s no difference is storage gas.

There should also be discussion about how these protocols are dispatched. Many apps silently use cloudflare which doesn’t support IPNS and doesn’t give the user the opportunity to use their own gateway or traverse content that the app doesn’t understand. However, some browsers (and browser plugins) can handle these protocols natively.