{
"$type": "site.standard.document",
"content": {
"$type": "at.markpub.markdown",
"text": {
"$type": "at.markpub.text",
"markdown": "A 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.\n\nCovers 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.\n\nThen 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.\n\nWith animated diagrams for the credential cascade and the end-to-end read sequence."
}
},
"coverImage": {
"$type": "blob",
"ref": {
"$link": "bafkreidlrj3rm57hxswlallblmmcq5g45fhvjdy7ob5vigorqmq3wegcju"
},
"mimeType": "image/png",
"size": 170885
},
"description": "The protocol mechanics, post by post, through the draft spec: spaces, permissioned repos, the credential cascade, off-firehose sync, and deliberately deniable signatures.",
"path": "/technical.html",
"publishedAt": "2026-06-24T19:56:04.452Z",
"site": "at://did:plc:h3wpawnrlptr4534chevddo6/site.standard.publication/3mp2gpgztdj22",
"textContent": "A developer-facing walkthrough of the atproto permissioned-data design, built from Daniel Holmgren six-post Permissioned Data Diary, the Modeling communities essay, and the draft proposal (bluesky-social/proposals number 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 own PDS; the three-credential cascade of delegation token, client attestation, and 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.",
"title": "Permissioned data on atproto: a technical walkthrough"
}