Hi! Sorry this post is coming in so close to when the first kick-off meeting is. I’ve been working on a project with two collaborators built on top of atproto that requires private data. For now, we’ve been building this as a separate service that can be redirected to via the `services` in the DID document + `atproto-proxy` header, but as we’ve been prototyping, a couple of nice-to-have properties emerged, and I was hoping to create a space to discuss this with other folks! (Doesn’t have to be in the meeting 
)
The two properties that are really nice are:
-
The same level of portability as with public data–have credible exit from platforms that build apps over your private data, without having to leave that data behind. It seems like if the data isn’t stored directly in the PDS (or maybe even if it is?) this requires some additional verification properties, but does not necessarily require private data to be stored in an MST.
This seems at odds with some use-cases–specifically Nick Gerakine’s example about making privacy decisions at read time. Both seem useful and necessary?
-
First class support for some sort of RBAC/ACL read-permissioning over private data. This is similar to the SpiceDB / “spaces” permissioning pitched by verdverm, but the implementation space here is broader than that. The way we did it in our prototype was using simple ACLs served via casbin that granted particular DIDs permission to specific records, or specific lexicons.
The specific thing here that is nice is the ability to define “groups” as a native concept to the PDS for read permissions, which is a composable set of users (so I could have a group “family”, “friends”, and “family-and-friends” which is the union of the former two). For our purpose, we have been operating on the assumption that only you can write to your PDS, so write-permissions are out of scope.
With these two properties, a bunch of really nice use cases and user experiences emerge. For example:
-
This opens atproto up beyond open social, because private data + basic permission-ing has many more use cases.
-
As a user, can share data originating from different apps with the same group of people without any additional work – I can share photos with my “friends” group, and also write Bluesky posts that only my “friends” can see. Conversely, I can publish links to my writing that only my Bluesky followers can see. I could even make a Bluesky post to a few specific people.
-
As a user, I don’t need to think about different permission-ing systems within each app. Of course, there is some logic that doesn’t fit well into this framework, but there are plenty of apps that essentially implement the same logic over again, because as a user there is no way to share permission-ing logic across them. (i.e. I have the same team in Notion, Google drive, Dropbox etc.). I would argue this is more intuitive to think about as a user as well–it centers the who you’re sharing with over the what app you’re sharing in.
-
For app developers developing over private data, the initial barrier to get something going is much lower if you can piggyback off the users’ shared existing groups, rather than needing additional flows to get the user to create these groups. Apps also provide more value because they have a sort of shared context across each other.
Some of the open questions we have started to think about are:
-
Cohesive UI: How you present (read + write) permissions and groups to the user in a coherent way that also gives them granular control?
-
Conflicting writes: This hasn’t really been an issue yet as our prototype hasn’t run into this and we’ve locked down the scope of our thinking to read-permissions only, but if you grant multiple apps write access to the same data, then it would cause problems if not handled properly.
-
Updates to private data: We have been brainstorming a lot here and the use cases seem too wide to decide on a solution so we have not tackled this yet. We really like the idea of metadata notifications because it seems to be walking the middle nicely, but in all transparency have not thought about this very hard.
Boris and a couple of others have mentioned that it’s important that the design of private data is really driven by use-cases and as I said in my original post, the prototype I have with a couple collaborators is *deeply* in the prototype stage, mostly the result of us all having other full-time jobs. But what we have in a sometimes-demoable state is basic permissioning of records + lexicons using ACLs as mentioned above to drive our couple of use-cases–a Pocket-like links saving app, a photos album (with various share capabilities), and a basic docs editing app (where the shared-ownership of docs is very tbd). We’ve been trying to develop use-cases to replace our own personal usage of Google docs / photos etc.
Whew that ended up being a lot longer than I initially thought! Thanks for reading if you got this far. As someone who is very uncomfortable with the idea of my data just being out there and mostly only existing on the Internet in private spaces (and that definitely being a reason to be less active on Bluesky + same with my friends), I’m really excited and hopeful that atproto can integrate private data into its ecosystem. This is my first time posting in a group of any kind so thanks for driving this working group Boris and everyone else for hosting this space!
Thanks!!!