Participants
Resources
The Private Data Working Group is focused on private lexicon records stored in PDS, and sending them between other PDS securely.
Right now, encryption at rest is not a goal. This is more like a "classic app" - access control is applied by the PDS, and sent securely to devices or other PDS instances.
An adjacent space is groups / audiences / private accounts. If people don't want their content seen at all, then it can't be part of their public repo, and can't hit the relay. This may be a major part of private data, with a focus on social use cases, rather than "app" use cases -- e.g. a private blog post, article, recipe, event, etc.
Note: the Bluesky team is working on this, and the point is to learn together, with active experimentation and running code.
The E2EE Working Group is covering DMs / group chats, which might embed or share certain lexicon types (e.g. images, bsky microblog posts, profiles), but is a different set of use cases, and is focused on encryption.
See Private Data -- covered both DMs / Chat, which is E2EE, as well as private data which this group will cover.
TODO: grab github threads and link / summarize here
This proposal introduces a mechanism for gating access to blob content within ATProtocol. While blobs are traditionally public byte arrays accessible by anyone through a content identifier (CID), this extension enables access control by requiring signed URLs for protected blobs.
This RFC proposes a mechanism for private content in ATProto by modifying the data flow between Personal Data Servers (PDSes) and AppViews. Instead of transmitting private content through the Firehose, PDSes would send metadata notifications for interested AppViews to receive, which can then fetch the actual content directly from the PDS using existing OAuth authentication.