hayleigh.dev hayleigh.dev From what I know, no CIDs use padding.
Also as example, this is from at:
bafkreihmwlh56hxtkulft7nh5ungjzyscxialpq6pa2fefikjgn5dgaqnu======
This is a blob CID generated by official PDS:
bafkreihmwlh56hxtkulft7nh5ungjzyscxialpq6pa2fefikjgn5dgaqnu
at implements the the base32 algorithm from RFC4648 described in the CID spec as linked in the atproto data model.
From RFC4648 we can read:
Implementations MUST include appropriate pad characters at the end of encoded data unless the specification referring to this document explicitly states otherwise.
As neither the CID spec nor the atproto data model comment on the use of padding, a correct implementation should include padding as far as im concerned.
If there is something we can point to that says the use of padding is optional then I'd be happy to remove it, but just pointing to an implementation isn't enough for me: if at takes the spec more seriously than bluesky plc then that's a win as far as I'm concerned ^.^
Understandable, but feels wrong considering that I think all implementations don't include padding (checked the code for python, rust, go, typescript and alicia gleam implementations). Also checked if the PDS handles padded CID when fetching a blob from browser and it does not.
Also most implementations use/refer to multibase, which DASL spec also refers to with the b prefix, which is specified as:
U+0062, b, base32, RFC4648 case-insensitive - no padding
IPFS CID which DASL CID is a subset of refers to the prefix as multibase prefix: https://docs.ipfs.tech/concepts/content-addressing/#version-1-v1
Here's PR: #2