Switch CIDv1 from Base58 to Base32 (js-ipfs)

[lidel]

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:

• Migration to CIDv1 (default base32) https://github.com/ipfs/ipfs/issues/337
  • Make js-ipfs capable of working with cidv1b32 Make js-ipfs capable of working with cidv1b32 #1440
• go-ipfs counterpart: Switch CIDv1 from Base58 to Base32 (go-ipfs) kubo#6220

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

• Migration to CIDv1 (default base32) https://github.com/ipfs/ipfs/issues/337
• go-ipfs version of this issue Switch CIDv1 from Base58 to Base32 (go-ipfs) kubo#6220
• existing issues in the wild
  • "broken CIDv1 in subdomain" https://zb2rhk6GMPQF3hfzwXTaNYFLKomMeC6UXdUt6jZKPpeVirLtV.ipfs.dweb.link
  • "explore a bafy CID but in the breadcrumb & the CID info it's displayed as zdj CID" CID formatting changes ipfs-webui#999
  • IPFS Camp (we need to address this before the camp)

[alanshaw]

@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]

@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?

[lidel]

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

[alanshaw]

yes -> #2024