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

Switch CIDv1 from Base58 to Base32 (js-ipfs) #1995

Closed
lidel opened this issue Apr 15, 2019 · 4 comments

Comments

Projects
3 participants
@lidel
Copy link
Member

commented Apr 15, 2019

This not about making CIDv1 the default, but a small UX tweak to remove confusion for users who opt-in to CIDv1 and expect Base32 (think IPFS Camp).

Actual move to CIDv1 as the new default is tracked in:

Problem

Right now if someone wants to use CIDv1 they can opt-in via --cid-version 1, but by default they get CIDv1 in Base58:

$ jsipfs add --cid-version 1 guardian.jpg
added zb2rhk6GMPQF3hfzwXTaNYFLKomMeC6UXdUt6jZKPpeVirLtV guardian.jpg                                                                                                                                                                  

To get the representation we aim for, they need to convert Base58 CIDv1 to Base32 in additional step:

$ jsipfs cid base32 zb2rhk6GMPQF3hfzwXTaNYFLKomMeC6UXdUt6jZKPpeVirLtV
bafkreigh2akiscaildcqabsyg3dfr6chu3fgpregiymsck7e7aqa4s52zy

OR pass additional --cid-base parameter:

$ jsipfs add --cid-version 1 --cid-base base32 guardian.jpg
added bafkreigh2akiscaildcqabsyg3dfr6chu3fgpregiymsck7e7aqa4s52zy guardian.jpg

The need for the conversion step is not only unnecessary, but harmful to our migration efforts. Users report confusion why CIDv1 produced by js-ipfs can't be used in <cid>.ipfs.dweb.link and why Web UI swaps out the CID.

It is really embarrassing when we need to ask people to use ipfs cid base32 during demos and workshops ("why do i need to convert? isn't base32 the future default for CIDv1?")

Solution

We should switch default representation of CIDv1 from Base58 to Base32 (without making CIDv1 the default itself).

This will ensure that:

  • one can just jsipfs add --cid-version 1 and use the output immediately
    (small change, huge UX improvement)
  • UX win: CIDv1 look the same everywhere
  • our CIDv1 tests can be written against bafy.. CIDs

References

@lidel lidel changed the title Switch CIDv1 from Base58 to Base32 Switch CIDv1 from Base58 to Base32 (js-ipfs) Apr 15, 2019

@alanshaw

This comment has been minimized.

Copy link
Member

commented Apr 17, 2019

@lidel I think this is a good idea and we should do this but as a stepping stone to CID v1 base32 by default. Can we capture this information in #1440 or link to this issue and close it?

@lidel

This comment has been minimized.

Copy link
Member Author

commented Apr 17, 2019

@alanshaw I'd like to keep this open until jsipfs add --cid-version 1 outputs Base32 without any additional parameters.

Rationale: switching to CIDv1 as the new default will require rewriting a lot of tests, across many packages.
Without switching CIDv1 to Base32 before that happens, we will have unnecessary work touching all those CIDv1 twice:

  • first time: writing them with CIDv1 in Base58
  • second time: changing all CIDv1 from Base58 to Base32

I wonder what would be the fastest way to do this.
Special handling of cidv1.toString() in js-cid?

alanshaw added a commit to multiformats/js-cid that referenced this issue May 8, 2019

refactor: default to base32 encoding for v1 CIDs
This switches the default encoding for v1 CIDs from base58btc to base32. See ipfs/js-ipfs#1995 for details.

License: MIT
Signed-off-by: Alan Shaw <alan.shaw@protocol.ai>

alanshaw added a commit to multiformats/js-cid that referenced this issue May 8, 2019

refactor: default to base32 encoding for v1 CIDs
This switches the default encoding for v1 CIDs from base58btc to base32. See ipfs/js-ipfs#1995 for details.

BREAKING CHANGE: The default string encoding for v1 CIDs has changed from base58btc to base32.

License: MIT
Signed-off-by: Alan Shaw <alan.shaw@protocol.ai>

vmx added a commit to multiformats/js-cid that referenced this issue May 9, 2019

refactor: default to base32 encoding for v1 CIDs
This switches the default encoding for v1 CIDs from base58btc to base32. See ipfs/js-ipfs#1995 for details.

BREAKING CHANGE: The default string encoding for v1 CIDs has changed from base58btc to base32.

License: MIT
Signed-off-by: Alan Shaw <alan.shaw@protocol.ai>

alanshaw added a commit to ipfs/js-ipfs-bitswap that referenced this issue May 9, 2019

chore: update cids dependency
BREAKING CHANGE: v1 CIDs created by this module now default to base32 encoding when stringified

refs: ipfs/js-ipfs#1995

License: MIT
Signed-off-by: Alan Shaw <alan.shaw@protocol.ai>

vmx added a commit to ipfs/js-ipfs-bitswap that referenced this issue May 9, 2019

chore: update cids dependency
BREAKING CHANGE: v1 CIDs created by this module now default to base32 encoding when stringified

refs: ipfs/js-ipfs#1995

License: MIT
Signed-off-by: Alan Shaw <alan.shaw@protocol.ai>

@momack2 momack2 added this to Ready in ipfs/js-ipfs May 10, 2019

@lidel

This comment has been minimized.

Copy link
Member Author

commented May 10, 2019

@alanshaw thank you for leading this on JS end!
Will multiformats/js-cid#89 land in the next js-ipfs release?

@alanshaw

This comment has been minimized.

Copy link
Member

commented May 10, 2019

yes -> #2024

@momack2 momack2 added this to Ready in ipfs/js-waffle May 10, 2019

alanshaw added a commit to ipfs/js-ipfs-http-response that referenced this issue May 12, 2019

chore: update cids dependency
BREAKING CHANGE: v1 CIDs created by this module now default to base32 encoding when stringified

refs: ipfs/js-ipfs#1995

License: MIT
Signed-off-by: Alan Shaw <alan.shaw@protocol.ai>

alanshaw added a commit to libp2p/js-libp2p-kad-dht that referenced this issue May 12, 2019

chore: update cids dependency
BREAKING CHANGE: v1 CIDs are now encoded in base32 when stringified.

ipfs/js-ipfs#1995

License: MIT
Signed-off-by: Alan Shaw <alan.shaw@protocol.ai>

vasco-santos added a commit to libp2p/js-libp2p-kad-dht that referenced this issue May 13, 2019

chore: update cids dependency (#117)
BREAKING CHANGE: v1 CIDs are now encoded in base32 when stringified.

ipfs/js-ipfs#1995

License: MIT
Signed-off-by: Alan Shaw <alan.shaw@protocol.ai>

@whyrusleeping whyrusleeping added in progress and removed ready labels May 13, 2019

@alanshaw alanshaw referenced this issue May 13, 2019

Closed

⚡️ v0.36.0 RELEASE 🚀 #2024

43 of 44 tasks complete

alanshaw added a commit that referenced this issue May 21, 2019

refactor: update ipld formats, async/await mfs/unixfs & base32 cids (#…
…2068)

This is part of the Awesome Endeavour: Async Iterators: #1670

Depends on

* [x] ipld/js-ipld-dag-pb#137
* [x] ipfs/interface-js-ipfs-core#473
* [x] ipfs/js-ipfs-http-client#1010
* [x] ipfs/js-ipfs-http-response#25

resolves #1995

BREAKING CHANGE: The default string encoding for version 1 CIDs has changed to `base32`.

IPLD formats have been updated to the latest versions. IPLD nodes returned by `ipfs.dag` and `ipfs.object` commands have significant breaking changes. If you are using these commands in your application you are likely to encounter the following changes to `dag-pb` nodes (the default node type that IPFS creates):

* `DAGNode` properties have been renamed as follows:
    * `data` => `Data`
    * `links` => `Links`
    * `size` => `size` (Note: no change)
* `DAGLink` properties have been renamed as follows:
    * `cid` => `Hash`
    * `name` => `Name`
    * `size` => `Tsize`

See CHANGELOGs for each IPLD format for it's respective changes, you can read more about the [`dag-pb` changes in the CHANGELOG](https://github.com/ipld/js-ipld-dag-pb/blob/master)

License: MIT
Signed-off-by: Alan Shaw <alan.shaw@protocol.ai>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.