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

Update the spec from the implementation. #14

Merged
merged 2 commits into from
May 12, 2018

Conversation

Stebalien
Copy link
Member

@Stebalien Stebalien commented Aug 30, 2017

  1. CIDv0 only supports SHA256 multihashes.
    2. In CIDv0, the multibase can be specified but defaults to base58btc.

This commit also describes the proper algorithm for decoding CIDs as it's non-obvious.

Fixes #11

@Stebalien
Copy link
Member Author

@kevina, @whyrusleeping, @jbenet

@Stebalien
Copy link
Member Author

Also, @diasdavid how does this work in JavaScript?

README.md Outdated
* The CID's version is 0.
* Otherwise, let `N` be the first varint in `cid`. This is the CID's version.
* If `N == 1` (CIDv1):
* THe CID's multicodec is the second varint in `cid`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/THe/The

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is the algo JS is doing: https://github.com/ipld/js-cid/blob/master/src/index.js#L18-L87 Some different heuristics, it trusts less the length and relies more on value checking.

README.md Outdated
@@ -86,10 +86,10 @@ For example:
### CIDv0

CIDv0 is a backwards-compatible version, where:
- the `multibase` is always `base58btc` and implicit (not written)
- the `multibase` defaults to `base58btc` (if not written)
Copy link
Member

@daviddias daviddias Aug 31, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍🏽 same in JS, although ipfs/kubo#4143 might become a thing soon

Copy link
Member

@daviddias daviddias Aug 31, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👎🏽 ah wait, read this wrong. CIDv0 is always base58, there is no way to change that.

@daviddias
Copy link
Member

daviddias commented Aug 31, 2017

In CIDv0, the multibase can be specified but defaults to base58btc.

Could you point me to the discussion where this decision 'was made'?

Me, @jbenet and @whyrusleeping talked about this extensively and the agreement was not to convert CIDv0 to CIDv0b (which is what is happening with that proposal), instead convert CIDv0 to CIDv1 if a different base is required to be used.

@kevina
Copy link

kevina commented Aug 31, 2017

A decision was never "made" it is just what works with go-cid and there is very little harm in allowing a multibase prefix to a CidV0 string and I personally think it will likely be required if we switch to a different base. The reasons it is likely required are discussed in ipfs/go-cid#34, in particular ipfs/go-cid#34 (comment) from @lgierth:

@diasdavid what Kevin and I are thinking about is the next step after receiving a gateway request with a CIDv0-in-CIDv1: content routing and bitswap, where we need the original CIDv0 because that's what provider records are published for, and what's used as a key in the blockstore of the provider nodes. It's kind of a matter of backward compatibility: there will always be nodes who continue to create CIDv0 stuff.

and ipfs/go-cid#34 (comment) by me:

The base used to encode a CID is for the most part an interface issue. The base is is not stored in the key of objects stored as part of a link or in the blockstore. The Cid version and hash used is, on the other hand, part of the key.

You can't retrieve an Cidv0 object if it is reformatted to be Cidv1 and sometimes you may still want to store a Cidv0 key in another object.

@daviddias
Copy link
Member

@kevina we posted at the same time, see here to learn about the actual issues: ipfs/go-cid#34 (comment)

1. CIDv0 only supports SHA256 multihashes.
2. In CIDv0, the multibase *can* be specified but defaults to base58btc.

This commit also describes the proper algorithm for decoding CIDs as it's
non-obvious.

Fixes multiformats#11
@Stebalien
Copy link
Member Author

I've updated it to not allow non-base58 CIDv0s.

@whyrusleeping
Copy link
Member

whyrusleeping commented Sep 1, 2017 via email

@Stebalien
Copy link
Member Author

I've now updated the algorithm to explicitly not support non-base58 v0 CIDs. We'll need to fix go-cid (and maybe js-cid) to match this as go-cid, at least, will currently decode multibase CIDv0 CIDs just fine.

@kevina
Copy link

kevina commented Sep 1, 2017

Can I please ask the reason for explicitly forbidding a multibase encoded Cidv0? Also see this comment ipfs/go-cid#34 (comment) I made on relevant issue.

@daviddias
Copy link
Member

daviddias commented Sep 1, 2017

@Stebalien js-cid limits CIDv0 to base58 encoding

@whyrusleeping
Copy link
Member

whyrusleeping commented Sep 1, 2017 via email

Copy link
Member

@daviddias daviddias left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you @Stebalien :)

@daviddias daviddias merged commit ef1b200 into multiformats:master May 12, 2018
@Stebalien Stebalien deleted the feat/multibase-cidv0 branch May 15, 2018 20:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants