Redefine CIDv1 to be <cidv1-multicodec><format-multicodec><multihash> about cid HOT 4 CLOSED

/cc @warpfork @mikeal @daviddias @vmx

from cid.

It took me a while to understand this, so I'll rephrase it to make sure I understood it correctly.

We are just changing the definition, of what the first few bytes (a varint) means. Currently that's the version of the CID, this issue proposes making it a multicodec. This would make a CID not its own special thing, but just another multicodec. So systems like libp2p could be designed to use any multicodec they warnt as identifier for certain things. Though they will probably use the CIDv1 multicodec, which is the same bytes as the CIDv1 we know today.

If I understand it correctly I'm in favour of this change, but certainly want to hear what others think.

from cid.

This would make a CID not its own special thing, but just another multicodec.

Not quite. CIDs are still (multicodec, multihash) tuples (although #26 is proposing to remove the "IPLD format" connotations from the multicodec part). They also still carry all string format, multibase, etc. concepts.

The proposal here is to redefine the 0x1 in CIDv1 to be a multicodec for CIDv1 instead of a version number. Currently, CIDv2 would start with 0x2, CIDv3 with 0x3, etc. After the proposed change, CIDv2 would start with an arbitrary multicodec (e.g., 0x40 (if unallocated)).

The motivation is to avoid conflicts. That is, if we eventually define a hash function with the multicodec 0x1, I may not be able to disambiguate between a CIDv1 and that multihash. We usually know what we should be expecting based on the context. This is just proposing to make it unambiguous, even without the context.

Note: The significant drawback here is that this would prevent us from ever choosing a CID version that conflicts with an existing multicodec. So, if we ever run out of single byte multicodecs and needed to create to change the CID format (bump the CID version), we'd need to use a two-byte (or more) multicodec.

from cid.

But yes, this is purely definitional. I'm not suggesting we change the representation, just that we:

1. Allocate 0x1 in the multicodec table for CIDv1.
2. If we ever need a CIDv2, we'd allocate a new multicodec instead of just using 0x2.

from cid.