Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

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

Closed
lidel opened this issue Apr 15, 2019 · 4 comments · Fixed by #2068
Closed

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

lidel opened this issue Apr 15, 2019 · 4 comments · Fixed by #2068
Assignees
Labels
exp/wizard Extensive knowledge (implications, ramifications) required P2 Medium: Good to have, but can wait until someone steps up status/in-progress In progress

Comments

@lidel
Copy link
Member

lidel 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
Copy link
Member

@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
Copy link
Member Author

lidel 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 alanshaw added exp/wizard Extensive knowledge (implications, ramifications) required P2 Medium: Good to have, but can wait until someone steps up status/ready Ready to be worked labels May 3, 2019
alanshaw added a commit to multiformats/js-cid that referenced this issue May 8, 2019
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
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 pushed a commit to multiformats/js-cid that referenced this issue May 9, 2019
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
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 pushed a commit to ipfs/js-ipfs-bitswap that referenced this issue May 9, 2019
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
Copy link
Member Author

lidel 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
Copy link
Member

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
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
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 pushed a commit to libp2p/js-libp2p-kad-dht that referenced this issue May 13, 2019
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 status/in-progress In progress and removed status/ready Ready to be worked labels May 13, 2019
alanshaw pushed a commit that referenced this issue May 21, 2019
…2068)

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

Depends on

* [x] ipld/js-ipld-dag-pb#137
* [x] ipfs-inactive/interface-js-ipfs-core#473
* [x] ipfs-inactive/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 subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
exp/wizard Extensive knowledge (implications, ramifications) required P2 Medium: Good to have, but can wait until someone steps up status/in-progress In progress
Projects
No open projects
3 participants