Generalize CIDv0 to PeerIDs

[Stebalien]

Currently, CIDv0 is defined to be a protobuf encoded IPFS node. Unfortunately, we're also using hashes that look like CIDv0s to point to public keys (PeerIDs). It would be nice to be able to treat these keys as IPLD objects.

Luckily, due to the way protobufs are encoded, we can use some ✨ magic numbers ✨ to make this work:

• PBNodes always start with either 0x0a or 0x12 (1<<3|2 or 2<<3|2).
• Public/Private keys always start with: 0x08

[ghost]

/ipfs multiaddrs will migrate to /p2p instead soon, so apart from the hash itself there's not going to be confusion anymore. /ipfs/QmFoo turns into /p2p/QmFoo so you know whether it's an address (/p2p) or a path /ipfs.

As for the hash itself I'm not sure that's neccessary.

We should discuss whether with the /p2p migration it makes sense to make PeerIDs first class IPLD objects, and generally let the Qm hashes fade out. (cc @whyrusleeping)

[ghost]

Related: ipfs/kubo#3859

[Stebalien]

In general, I'd like every object to be resolvable as an IPLD object (mumble thin waist). That is, given any /{PROTO}/{HASH_LIKE}, I would like to be able to fetch the object that HASH_LIKE is a hash of at /ipld/{HASH_LIKE}. However, I'd settle for /ipld/{translate(PROTO, HASH_LIKE)}.

---

More specifically, this issue is related to IPNS, IPRS, and my "policies" note (ipfs/notes#245). Basically, I'd like SOME_HASH in /ipns/{SOME_HASH} to point to an IPRS scheme, stored as an IPLD object, that describes how to validate associated IPNS records. For backwards compatibility, I'm planning on interpreting bare public keys as valid IPRS schemes for existing protocols (basically, I'm planning on interpreting them as they are currently interpreted).^†

Note: The same applies to /p2p addresses. Ideally (for me at least), HASH in /p2p/{HASH} would point to an IPRS scheme describing how to validate P2P address records.

Related: ipfs/kubo#3859

Yes, that looks related.

---

_{^†Yes, I'm aware that IPRS doesn't really exist yet but I'd like to make the transition as smooth as possible once it does.}

[Stebalien]

A more pressing concern is that I'm modifying floodsub to use IPLD (for both topic descriptors and messages, it makes a lot of problems simply disappear) and would like to be able to talk about keys as IPLD objects.

[Stebalien]

So, a related issue came up. For IPLD selectors, it would be nice if we could bake redefine CIDv0 as ProtoNode + UnixFS. As-is, the unixfs part is a binary blob in the data field which isn't going to be easy to select over without custom functions.

Unfortunately, this will likely break some existing DAGs. We will have to think carefully about this.