I've recently been attempting to produce a scoping document around AT Protocol "permissioned data" experiments 🧪. It's supposed to be concise but quickly turning into an essay!
One of the things I've tried to do is provide clarity and consistency on terms/definitions around "permissioned data". Although the high-level need and intent is clear enough:
presently ALL user records on PDS' are completely open/public, so we need some way(s) to restrict access
...it's amazing how quickly language and terminology becomes varied and inconsistent as this is increasingly discussed across the ATmosphere.
Paul Frazee's phrasing (sorry) seemed to land ok back in September - he spoke of finding (work)flows for "personal-private data" and "shared-private data". I also found it a decent entry point into this space.
Building on that (but moving away from the use of "private" terminology, which I'll bring back into the frame later) - and drawing from prior experience with local-first applications, syncing between devices/users, and configuring web services with access controls - I'm wondering whether the following "3 P's" taxonomy for permissioned data makes any sense to at least one person other than myself!...
"Personal sync"
data that is just for your viewing but you want to access across your devices, so will have to be synced (hello sync servers 👋)
"Protected sync"
data that is for you AND one or more other designated people to view/sync, but not everyone, therefore protected from open public consumption
"Public sync"
completely unprotected - anyone can view/sync your data
The first two fall under the "permissioned data" umbrella, the last is what we have with current AT Protocol PDS querying/syncing.
the "protected sync" logic in pseudo-code:
let category = undefined
let x = peopleWhoNeedAccess
if(me < x < everyone) {
category = 'PROTECTED_SYNC'
}Conflict Resolution
(don't worry, this is not going to turn into a CRDT thing 😉)
The first problem I see with the above is a conflict created between the "P" in PDS - Personal Data Server. What AT Protocol and PDS' currently do is "public sync" so in my little schema it should become Public Data Server.
But isn't this losing the notion of "owning" your data on AT Protocol? You know, because it is in my personal data server, not a public data server.
Well, I think there is some laxity here that gives us some rope to re-conceptualise things. I see a statement like this fairly regularly...
"each user has a PDS"
...which is not entirely wrong, but not quite right. Technically, each user has a dedicated repository (sqlite database). This repository lives on a server (the PDS) that likely contains 100's if not 1000's of these repositories, from which anyone can view any of the records...I wouldn't call that arrangement particularly "personal"!
Therefore, what if we allow more flexibility in what the "P" can stand for? For technical folk the "P" could now refer to implementation of one or a combination of Personal/Protected/Public Data Servers (yeah, that was the ulterior motive behind the "3 P's" - otherwise I could have just used Paul's "shared" term instead of "Protected").
These might be listed under "service" in a DID document...
"service": [
{
"id": "#atproto_public_ds",
"type": "AtprotoPublicDataServer",
"serviceEndpoint": "https://woodear.us-west.host.bsky.network"
},
{
"id": "#atproto_protected_ds",
"type": "AtprotoProtectedDataServer",
"serviceEndpoint": "https://permissioneddata.community"
},
{
"id": "#atproto_personal_ds",
"type": "AtprotoPersonalDataServer",
"serviceEndpoint": "https://permissioneddata.community"
}
]This is building on Evelyn's post below and the vibrant discussions still unfolding here
Community privacy is one of our top priorities at @transrights.northsky.social which isn't possible out of the box with any ATproto implementation today that doesn't just hide an entire PDS. We're developing in the open and so I've published a proposal on it, feedback as always is we
From those outside the technical community we probably want to keep hearing phrases like "my PDS", as it indirectly communicates data sovereignty ideals (ownership and portability) and the ethos of AT Protocol - potentially attracting more people into the ATmosphere(?)
How am I going so far?...clear as mud!? 😁
What about "private" data?
Well, I'm glad you asked!(h/t Deane Hutton from the Curiosity Show)
Paul used the term "private" in his September post in a way that aligns with the intent of "permissioned data", however I'm more inclined to anchor to something else.
So far we haven't touched on encrypting data at rest (E2EE) and whether that falls under "permissioned data". Although contested, I've seen a few threads mention that "private" and/or "secret" data conjures expectations of encryption, so I'm going to explore that now.
We could say encryption is a method/solution for permissioned data, ie only those with the keys to encrypt<>decrypt have permission to view the data. Trying to figure out why this didn't really resonate helped me realise there is further qualification required regarding potential solutions to permissioned data.
That qualification is the following: permissioned data solutions (services) will only allow data to end up on the machines of people (or other services) who have been granted permission to access the data.
Encryption alone fails to achieve this because it does NOT prevent access to the encrypted data (I've seen advocation for 'encryption at rest' because it allows data to be freely accessed, passed around and stored on any machine in a network).
Note, I'm not making any judgement here about how secure or suitable "permissioned data" (access control) and/or "private data" (encryption) is...just a distinction.
This distinction sets the scene for now proposing that...[drum-roll 🥁] ...permissioned and private data solutions could actually work together! 🤯 (oh right, you already saw that coming didn't you).
eg, we might want 'protected sync' AND 'encryption at rest' on the sync server.
Could this "additive" relationship be expressed using a "+" symbol? We then would have:
personal sync(+)
just I can view + encrypted on sync server
protected sync(+)
me and a few others can view + encrypted on sync server
public sync(+)
anyone can view + encrypted on sync server (PDS) (is this required?...what use-cases would there be? 🤔)
We could then use the following matrix to "fill in the squares" around what our apps/services (need to) cater for...
depiction of what is currently provided "out of the box" by the AT Protocol
How does all that sit with you? Feel free to put this taxonomy through the wringer for your app/uses-case(s) - I would love to hear if it's useful and where it holds up and/or breaks down.
cheers,
Mark
P.S. fun fact: now well into my fifth decade on this planet, this is my very first post going deep-ish into "tech stuff"...let's see if I can manage a follow-up in a shorter space of time.
(yes, that was also a subtle disclaimer warning that reading this post might have been a complete waste of your time - probably should've put it at the start 😁)
banner image:
AI-generated at https://perchance.org/ai-text-to-image-generator using prompt "at protocol logo and permissioned data"