add swarm protocol code

[bgits]

Currently there does not exist a protocol code for Ethereum's Swarm content hashes (https://swarm-guide.readthedocs.io/en/latest/usage.html#bzz-url-schemes).

This makes it difficult to use multiaddr in Ethereum Improvement Proposal #1577 (ethereum/EIPs#1577).

[Stebalien]

Is this a hash function or a transport protocol?

[Arachnid]

@Stebalien Swarm is a content addressed store, just like ipfs.

[Stebalien]

Yes, but which parts need multicodecs for what. That is:

• we have multicodecs for hash functions.
• we have multicodecs for IPLD formats (eth, git, dagcbor, etc.)
• we have multicodecs for protocols in multiaddrs (ip4, tcp, quic, etc.)

It looks like you need an IPLD format but I'm not sure.

[Arachnid]

We need a multiaddr protocol, so we can address, eg, /swarm/hash. The necessary hash functions are already in place.

[Arachnid]

To clarify, our end goal is to have a content field that can contain either a swarm hash or an IPFS hash (or other related content identifiers). If multiaddr isn't the appropriate way to do that, please let us know.

[Stebalien]

We generally distinguish between names and addresses. Addresses generally tell you where to look for some resource (multiaddr), names generally tell you what resource to look for (peer ID, content ID).

So, a multiaddr in an ENS record would address some endpoint (network or otherwise), not a piece of content. To name a piece of content, you'd probably just want a free-form path. For example, /ipns/Qm..., /ipns/a.com, /ipfs/Qm.../path/to/file.txt, /ipld/.../path/to/data, etc.

(One of the motivations in switching away from using /ipfs/$PEER_ID in multiaddrs was to remove this ambiguity).

[Arachnid]

Is there a multiformat suitable for encoding an ipfs hash or path? Storing text isn't ideal due to the high cost of onchain storage.

[Arachnid]

It looks like multicodec might be suitable? Would it make sense to add ipfs and swarm multihash types to the public multicodec table?

[jbenet]

Would it make sense to add ipfs and swarm multihash types to the public multicodec table?

I filed multiformats/multicodec#94 and multiformats/multicodec#95 for these ^

[jbenet]

@Stebalien can you take ownership of these issues for ENS?

[Stebalien]

@jbenet I'll see what I can do but this will need quite a bit of consensus.

@Arachnid multicodec is really just a common table of unique codes. Other multiformats then use these codes but multicodec doesn't really describe a generalized path spec.

I think what you're looking for here are CIDs. CIDs are (multicodec, multihash) tuples where the hash is the hash of the content and the codec indicates how one should interpret the content. We use this datastructure in IPLD to support arbitrary merkle-dag formats (e.g., ETH, git, etc.).

It looks like the correct path forward here is to:

1. Assign a multicodec to swarm.
2. Optionally (see Move CIDs to the "multiformats" project cid#26): define an IPLD format for swarm.
3. Add a CID field to ENS.

---

However, there are two drawbacks to 3:

1. It requires adding a new field to ENS.
2. It won't support paths. This isn't really an issue for swarm but other IPLD formats expect users to be able to path through datastructures, key by key.

To handle this (and unify our path concepts) we could introduce a new generalized "multipath" spec, subsuming multiaddr. This spec would define a universal pathing system, a global conflict free namespace (basically, the string version of the multicodec table), and a "compact" path form.

This would basically just be taking the current multiaddr spec as-is and extending it slightly to say "and you can use this to address content as well".

---

Thoughts on this?

[Arachnid]

I think what you're looking for here are CIDs. CIDs are (multicodec, multihash) tuples where the hash is the hash of the content and the codec indicates how one should interpret the content. We use this datastructure in IPLD to support arbitrary merkle-dag formats (e.g., ETH, git, etc.).

That sounds right. What's the value of the multicodec field, though? Or are you saying it's a multicodec type prefix, followed by multihash content? Isn't that what we're already proposing?