feat: provide cidv1 in base36 when needed

[lidel]

This adds Base36 version of CIDv1 if it fits inside a single DNS label.
Follows convention introduced in ipfs/kubo#7441 where we redirect to Base36 version if it helps with DNS limit.

Examples:

• regular CID, Base32 is enough, Base36 section is hidden
• libp2p-key, Base36 is provided
• super long CID, DNS label warning is displayed instead of Base36

Q: Is it ok to hide Base36 when it is not really needed? Or maybe should we always show it, to educate users that the same CID can be encoded in different bases? In that case we could have CIDV1 header and then multiple base versions listed under that.

cc @ribasushi @aschmahmann @jessicaschilling

[ribasushi]

maybe should we always show it, to educate users that the same CID can be encoded in different bases

👍 I like that idea

we could have CIDV1 header and then multiple base versions

I wouldn't list too many, just 32/36, anything else is kinda... esoteric

[lidel]

Folks, go-ipfs 0.7.0 will land soon (ipfs/kubo#7560) and we should merge this before that happens, to improve UX of working with ED25519 keys.

Can I have a quick temperature check about merging this as-is? (we can refine later)

[Gozala]

@lidel I like the educational idea of this. I think it would be great to visually illustrates what fits and what does not fit for subdomains. Maybe it would help to bring it into the context ? And actually render the link along with the CID e.g.

For: bafzaajaiaejcat4yhiwnr2qz73mtu6vrnj2krxlpfoa3wo2pllfi37quorgwh2jw

https://k51qzi5uqu5di608geewp3nqkg0bpujoasmka7ftkyxgcm3fh1aroup0gsdrna.ipfs.dweb.link/

For long CIDs that don't fit the subdomain requirements it would be great to render a broken link, maybe with fragment of URL highlighted red and comment explaining this is what tool X would interpret as.

[jessicaschilling]

Agree with @Gozala and @ribasushi, but suggest these additions go into their own issue for sake of expediency.

[jacobheun]

⛵