Bad Cidv1 Tor/Onion3 contenthash format

🪳 Bug Reports
4

onion is not encoded as a CID though! Maybe this was the same sticking point about Data URL.

ENSIP-7’s <protoCode><bytes> just says bytes follows the multicodec stuff and… onion is encoded just as bytes multiaddr not a CID — oh, interesting, well I have no idea what the proper multiaddr encoding of a onion is, nor does the official repo :rofl:. I agree the current encoding is not self-describing. But this is how I think onion and other new formats should be encoded.

Speaking more generally: I think all of the multicodec stuff is noise and it’s a solution to a problem that ENS doesn’t have. ENS can encode arbitrary bytes without any ambiguity.

There’s nothing wrong with IPFS and others using multicodec and CID but that decision shouldn’t be enforced universally.

All contenthashes can be mapped to an URI:

  • URI: <scheme>://<ascii-like>.
  • Contenthash: <protoCode><bytes>

Notice how this is exactly the same as ENSIP-7 except URI is constrained by legacy protocol transmission rules (ascii, octets, dns, small buffers, etc.) and contenthash simply assumes the parent protocol can transmit arbitrary bytes.

This is also conceptually the same as addr(coinType) where coinType (like protoCode) is sufficient for decoding the value. With addr() you ask the name for type X, whereas contenthash() embeds the type X because there is only one contenthash.

  • addr(x) = y
  • contenthash() = x + y

For example, I’ve made the point before that contenthash could of just been an exotic coinType: addr(CH) = x + y

1 Like