Permissioned data on atproto: a technical walkthrough
The protocol mechanics, post by post, through the draft spec: spaces, permissioned repos, the credential cascade, off-firehose sync, and deliberately deniable signatures.
developer-facing walkthrough of the atproto permissioned-data design, built from Daniel Holmgren's six-post Permissioned Data Diary, the "Modeling communities" essay, and the draft proposal (bluesky-social/proposals #94) plus the Spaces Design Spec.
Covers why access control is the right framing rather than end-to-end encryption; why the unit of access is a space (a member list under a DID) rather than a record or an app; where permissioned repos actually live (one per member, per space, on each member's own PDS); the three-credential cascade (delegation token, client attestation, space credential) and why an app gets the whole space; application allow and deny lists, and public permissioned spaces.
Then the layer above: modeling communities as many typed spaces under one DID rather than one universal container. And what the draft spec made concrete: push-then-pull sync that never touches the public firehose (notifyWrite, then getRepoOplog), and deliberately deniable commit signatures.
With animated diagrams for the credential cascade and the end-to-end read sequence.
Did you enjoy this article?
Recommend it — Standard Reader surfaces well-loved writing to more readers across the network.