Permissioned Data Diary 1: To Encrypt or Not to Encrypt

Dainel, head of protocol at Bluesky, has published a series of leaflets on permissioned data for atproto.

The first post introduces what permission data actually is - "a broad term, it covers many different social modalities & data flows. In its most basic sense, it means “not public”... data that lives on your PDS but isn't broadcasted... only accessible to users and services ... explicitly granted permission." - and gives examples, from Facebook groups to DMs, which are "the clear outlier", as all now use E2EE.

The rest of this post explains why Bluesky is not: " The threat models are different... Apps need to see the data... E2EE is hard... scaling issues". Moreover, "Permissioned data and E2EE" don't compete, "they operate at different layers:

• Permissioned data is about access and data flow. Who is allowed to see this data? How does it get from point A to point B? ...
• E2EE is about cryptographic confidentiality ... even if someone intercepts the data or compromises the infrastructure, they can’t read it", and you can layer this over permissioned data: " other social modalities can benefit from it".

Buckets for Groups

The second post introduces Buckets to achieve their goal of making "Permissioned data ... feel like a natural extension of how public data already works in atproto."

There are four basic environment types, in increasing order of complexity:

• "Personal data ... just you, your PDS, and maybe an application or two...
• Gated [eg subscriber] content is one-to-many with a clear gatekeeper...
• Social sharing introduces some dynamism around who is able to view your stuff, how they interact with it, and who can see their interactions.
• Groups are many-to-many... dynamic membership ... Many users are contributing content to a shared context. Users ... may want to view their groups in any number of different apps ... force you to confront the hardest questions" so let's design for them.

He then explores different solutions, starting with:

• realms, where "the protocol-level access boundary is too coarse", and where power will centralise around the main apps.
• Access control lists (ACL) attached to individual records, where "every social interaction creates a coordination problem"

We need "a way to say: “Here’s a space. Here’s who has access to it. Everything in this space inherits that access”. We need a bucket... container that holds records and has a single authoritative ACL... When you post into a bucket, your post inherits the ACL". 

Post 3: partitioned, not colocated

It's not necessarily a "colocated" folder on someone's PDS: like a Bluesky thread, it could have its "contents distributed across members’ PDSes" ("partitioned").

Post 2 ends with a lot of unanswered questions, bringing us to Post 3, which compares colocated and partitioned approaches, finding colocated looking simpler, but too much like a Mastodon instance, while "partitioned buckets are more complex technically but also more honest ... much closer to our “atproto ethos”. Users own their data. It lives on their PDS. Applications crawl it." They're complex problems, but they're solvable engineering problems, in contrast to the architectural problems with colocation.

Call them (Permission) Spaces

Between posts 3 & 4 they decided to rename buckets to Spaces, as "bucket implies data locality" - Ironic given that post three was arguing against co-location. There's also the problem of what to call "a user’s partition of the bucket ... Bucket partitions? Bucket shards? Bucket segments?"

So they're retiring buckets for “Permission Space” or “Space” for short... a particular member’s records in a given space is a “Permissioned Repo”... [ie] the user has a permissioned repo that is shared with a particular permission space".

Post 4

This post came out in the run up to the Atmosphere Conf 2026 in Vancouver, which I attended, and provides "a rough sketch of the full picture." He quickly recaps what a Permission Space is: "a coordination concept: a shared identity, access control list, and sync boundary", form "a user’s personal data ... up to a million(s) person forum or group".

Each has:

• "space owner: a DID that serves as the authority or root of trust for that space... For shared spaces like communities, a dedicated space DID is preferable..."
• Space type: "what kind of data it contains and how it's used... defined by a published lexicon and serves as the OAuth consent boundary."

He then recaps Permissioned Repos before outlining record addressing, access control, space credentials ("how applications gain access to sync repos within a space"), Sync, etc.