I ran a short 1 hour session about Private Data at the ATProto NYC mostly focused on definitions and talking about use cases.
Voting Software
- this might be able to be done anonymously with ZK proofs - talk to Kobi, Ted had found some projects that might be revived
Encrypted or not?
- some people feel strongly that all data should be encrypted at rest
- this would mean private data is also encrypted in a way that PDS hosts couldn’t see the data, and only those with the decryption keys could access it
Multi Sig PDS
- do we had multiple keys to a PDS or otherwise have shared encryption keys where multiple people can unlock it?
- Conversely, are there are some easier solutions related to Trusted Execution Environments (TEEs)
Moderation of Private Data
- can you moderate private data? whose responsibility is and how is it accomplished?
Appview Access
- following the current model, with private data records owned by the user and on their PDS, this private data needs to be aggregated somewhere in order to show aggregated views
- e.g. a group of people could post to a private group, each owning their posts, but to make a single feed, you need to give access to the data to an appview of some kind
- how does the appview access / decrypt / store private data?
Interest in Circles
- arbitrary groups of people posting “into” a circle or community for visibility / restricted access
- “like Google Circles”
Vote out an admin
- If a group or access is owned by an admin that is no longer trusted, can they be voted out?
- who has the permissions to admit or eject people from a privacy group?
- in the case of e.g. a private account / protected posts, obviously it’s the account owner
- needs more details on group / community “ownership” and specific use cases
- simplified model of “make a new group excluding the old admin” does solve for some cases
Protect Group Membership
- is the metadata around who is part of a group public?
- in many cases, you don’t want to disclose that someone is part of a group and/or the name of the group
OAuth Scope / Permission Bundles
- shipping now from the bsky team – can this be used to control access?
Nick’s Confidential Record Hydration
- Have parts of a record that are private (but all the other metadata and the field name are public)
- ATProtocol Record Hydration: Building Privacy-Aware Views - Blahg
Common Use Cases
Private data for any Lexicon record
There is a general big bucket use case of “I would like to store data that no one except for authenticated users can see” – not on the relay, not fetchable by the API, and not viewable except for a list of users that have permission to see it.
This mostly applies to non-bsky Lexicons and new types of apps that could be built.
Private Data as a building block for Bluesky experiences
The other big bucket of use cases that have open requests from many existing Bluesky users is related to privacy of their posts and accounts in the Bluesky app itself.
These need fleshing out and describing and more user research on expectations, as well as thinking about protocol and scaling implications. Just a few examples:
- protected accounts: users accept / allow access to followers before showing them posts
- groups / circles: arbitrary groups of users are created - can everyone post? is there more than one admin / owner? what does moderation look like?
- protected posts: can you post individual posts and decide on privacy as part of posting?