As @willscott pointed out on discuss.ipfs.tech, in some contexts (e.g. filecoin block explorers, but also UCAN systems using vanilla CBOR and perhaps also some bsky contexts) binary CIDs (or other multiformats) get wrapped in the 42 tag to masquerade as CBOR data, and thus get printed as HEXADECIMAL (rather than multibased) when spit out of CBOR parsers. This results in "multiformats" that look like this:
42(h'000181E2039220200C7C257C5EA6BBA17053362...')
would it make sense to add second page for "CBOR CIDs" (https://cborcid.ipfs.tech? https://tag42.ipfs.tech?), even if all it does is transcode them and base58btc them, bouncing back to the https://cid.ipfs.tech/#{that-transcoded-cid} from there?
As @willscott pointed out on discuss.ipfs.tech, in some contexts (e.g. filecoin block explorers, but also UCAN systems using vanilla CBOR and perhaps also some bsky contexts) binary CIDs (or other multiformats) get wrapped in the
42tag to masquerade as CBOR data, and thus get printed as HEXADECIMAL (rather than multibased) when spit out of CBOR parsers. This results in "multiformats" that look like this:42(h'000181E2039220200C7C257C5EA6BBA17053362...')would it make sense to add second page for "CBOR CIDs" (
https://cborcid.ipfs.tech?https://tag42.ipfs.tech?), even if all it does is transcode them and base58btc them, bouncing back to thehttps://cid.ipfs.tech/#{that-transcoded-cid}from there?