Proposal: Use base32h for default CIDs

[daviddias]

TIL about https://base32h.github.io

base32h is a human friendly (easier to memorize, read) of base32. It looks like a great match for our primary usecase of base32 (e.g. subdomains).

Currently, it only has impl in JS+TypeScript, but getting implementations in other languages should be rather trivial https://base32h.github.io/implementations

[lidel]

Sadly the spec brings value only in upper-case version – from FAQ:

Why does Base32H keep L/l as its own digit? Won’t people mix up l with 1 and I?

The Base32H encoding specification requires encoders to emit uppercase letters exclusively, which should substantially mitigate the visual confusion (since L is much more distinct than l).

When case sensitivity of CID does not matter, IPFS uses lower-case variants.
This is because browser vendors force-lowercase authority part of URIs.
This means Base32H brings no real benefit over the current RFC-compliant base32 variant when displayed in web browser address bar.

Sidenote: DNS label length limit is 63, so ED25519 key in Base32* won't fit in a subdomain. That is why we use Base36 for IPNS in subdomains (ipfs/kubo#7441). If we decide to unify/change defaults, a variant of Base36* is more likely.

TLDR no added value in lowercase (subdomain) contexts, no reason to switch.

[daviddias]

Understood. Very valuable insight! (i.e. need to use Base36). Closing this one then.