Move CIDs to the "multiformats" project

[Stebalien]

So, when proposing to use CIDs as peer IDs, I got a bit of push-back as CIDs currently imply IPLD and bring in the concept of IPLD formats, links, dags, data-structures, etc. However, that doesn't have to be the case. Really, CIDs are just (codec, content-addr) tuples. That is, they're just "typed pointers".

Proposal: Move the CID spec/concept to multiformats.

This would mean that the codec in <version><codec><mhash> wouldn't necessarily map to a defined IPLD codec. Instead, it would just be some multicodec that may or may not have an IPLD format defined (yet).

Why?

• People can start using CIDs without thinking about IPLD. Typed pointers are really nice and it would be great to be able to use them everywhere without having to sell all of IPLD.
• We can retroactively define IPLD formats for these codecs. Then, when projects realize "oh shoot, I wish I had used IPLD", they'll have an easier time upgrading.

Why not?

• This may encourage users a proliferation of multicodecs/IPLD formats. In IPLD, we use multicodecs to indicate structure not semantics.

---

Thoughts? Should we just keep CIDs where they are but say "you can use these without the rest of IPLD" (not sure we can really sell that).

[mikeal]

Makes sense to me.

At some point, we're going to have to figure out a governance structure that is compatible with standards bodies for the multicodec registry. CID, and the constraints/concerns regarding codec proliferation, should be a part of that discussion.

[mikeal]

Also, the spec for CID has moved to ipld/specs, so we'll want to move that along with this repo.

[whyrusleeping]

Sounds good to me.

[daviddias]

👍 from me as well.

[mikeal]

I'm not admin in both of those orgs so I can't complete a migration :(

[Stebalien]

The migration will take a while anyways. I just wanted to see if there were any objections.

[note: @jbenet's fine with whatever increases adoption]

---

@tomaka

If CIDs didn't imply IPLD, would you feel better about using them as peer IDs? A CID is really just a (codec, multihash) tuple (see the issue summary). They're really on a layer below IPLD and don't actually need to drag in concepts like DAGs, formats, paths, etc.

Note: This won't really change anything from a technical perspective. The alternative is to just leave CIDs where they are (in IPLD) but say that they can be used independently. Moving them makes it clear that they can be used independent of IPLD, leaving them makes it clear that they're a building-block for IPLD.

[daviddias]

The JS people can start moving as we have it easier cause we don't use the github urls as import paths. The spec can be moved right away too

[daviddias]

Opened an issue on all the CID repos to point to this thread ^^

[ianopolous]

Sounds fine to me. Though you make it sound like the "rest of ipld" is large and complicated. In my opinion it is not. Or at least the minimum to use cids is not - cbor + a special cbor tag for merkle links.

[Stebalien]

Though you make it sound like the "rest of ipld" is large and complicated. In my opinion it is not.

It's not. However, it brings in a bunch of concepts (merkledags, formats, hash-linked data, etc.). Really, we might be better served by improving the documentation.

Basically, I don't want CIDs being a part of IPLD to scare people away from using them. I'd rather leave them here (absent additional motivation) but I'm highly biased towards "IPLD everywhere".

[mikeal]

I agree with @Stebalien. CID is an address and can be used in a lot of very simple cases that aren't even linked data.

Once you start using CID's as links (IPLD) you open the floodgates of knowledge and terms that are going to get thrown at you.

If you look at the main topics right now in the project it's mostly second order problems we're already facing working with these data-structures, like replication. Understanding all of that isn't necessary to derive value from CIDs.

[mikeal]

It sounds like we have a consensus.

I'm going to move this repo to multiformats and move the current spec from ipld/specs to this repo on Monday December 3rd if there are no objections.

[daviddias]

This has been done :)