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

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. Colocated seems simpler but it is too much like a Mastodon instance.