You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As @willscottpointed 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?
The text was updated successfully, but these errors were encountered:
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 thehttps://cid.ipfs.tech/#{that-transcoded-cid}
from there?The text was updated successfully, but these errors were encountered: