Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make CID versions multicodecs #49

Closed
Stebalien opened this issue Jun 21, 2017 · 6 comments · Fixed by #187
Closed

Make CID versions multicodecs #49

Stebalien opened this issue Jun 21, 2017 · 6 comments · Fixed by #187

Comments

@Stebalien
Copy link
Member

This way, we can trivially disambiguate CIDs from, e.g., raw multihashes.

(To do this, we'd need to steal 0x1 from unary for CIDv1).

@Stebalien
Copy link
Member Author

@diasdavid and I discussed this offline but I figured it should be posted here to keep things public.

We and came across the theoretical problem of handling non-multibase CIDv18 (18 = 0x12 = SHA2-256 multicodec) and decided that we could just skip that or define CIDv0 = CIDv18.

@hobofan
Copy link

hobofan commented May 26, 2020

Is there a way to get this moving? Are there any blockers that need to be discussed?

I'm currently in the process of drafting our new format for rlay-project/rlay-ontology, which strongly revolves around CIDs.
In our current (older) format, we always have to have some knowledge which fields of a struct have which types (CID vs multicodec), and for the fields that accept both, we have a not so pretty "try to parse as CID and if that fails it's a multicodec" logic. Adding CIDs as proper multicodecs would be great step towards simplifying this.

@rvagg
Copy link
Member

rvagg commented May 27, 2020

I think the next step to move this forward is to open a PR against table.csv to add something like cid, ipld, 0x1, CIDv1, you're welcome to do that @hobofan and maybe we can move forward. The step after this might be to implement the spec change detailed @ multiformats/cid#25 to cement it.

0x1 isn't in here anymore, I believe it was extracted when multibase was split out and along the way somewhere base1 / unary was dropped entirely, so it's up for grabs here without needing to do conflict resolution.

I'm still not clear on why #94 is necessarily a different thing though tbh. It seems to be part of the same bundle of concerns and just a matter of definitions.

@Stebalien
Copy link
Member Author

#94 is proposing adding a new multicodec for CIDs. So a multicodec-identified CID would be <cid-multicodec><v1><ipld-codec>.... This proposal is to just treat v1 as a multicodec (<v1><ipld-codec> -> <cid-multicodec><ipld-codec>...).

@oed
Copy link
Contributor

oed commented Aug 1, 2020

Hey @Stebalien @rvagg I'm happy to create the PRs needed to help move this forward, as I'm interested in using multicodec similarly to CIDs without it causing conflicts. Is there anything I need to be aware of in terms of the two different options? (to me your approach @Stebalien makes the most sense)

@Stebalien
Copy link
Member Author

I believe all we need is two PRs:

  1. A PR to the multicodec (this) repo reserving 0x1 for cidv1, ipld, 0x1, CIDv1.
  2. A PR to the CID repo (https://github.com/multiformats/cid) replacing cid-version and version in the "cidv1" spec with `multicodec-cidv1".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants