The Private Data Working Group is focused on private lexicon records stored in PDS, and sending them between other PDS securely, plus how to aggregate and restrict access to such data in a private appview.
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/community use cases, rather than “app” use cases – e.g. a private blog post, article, recipe, event, etc
E2EE Messaging is covering DMs / group chats and is a different set of chat-centric use cases, and is focused on encryption as a core requirement.
Some people would like fully encrypted data (that is, hidden from PDS hosts) to be a core requirement of Private Data, but that makes other use cases and requirements harder or not possible.
3 Likes
It would be useful to expand the last part: which use cases and requirements are harder/impossible with E2EE.
I would also clarify that depending on paranoia level, encrypted data could go to relays and app views, especially if they gated access to the ciphertext.
1 Like
I’m trying to not put in strong opinions of my own and just channel what some discussions have pointed out.
So, how to aggregate, search, and moderate fully encrypted data is harder. Role of AppView and arbitrary apps for Lexicons seems harder.
And, not putting encrypted data on relays is another seeming point of agreement.
There is definitely a cluster of people who do want encrypted private data - but it’s not clear to me that any of those are actually building an app. Hopefully this space and process will flush some out that want to work on this.
2 Likes
A question about private data and forgive me if this is covered elsewhere. I’m thinking through a use case for a bookmarking/bibliographic app, and would be interested in a range of public/private permissions, rather than just a binary public/private. For example: owner, editor (with password), editor (public), read-only (with password), read-only (public). Thinking that this, at the PDS level, would be very powerful. Is a permissions range part of the discussion?
1 Like
Yes, including different ways of applying such a thing. Your description is “roles”, groups consisting of lists of accounts would be another.
@wesleyfinck.org is building a social bookmarking app with “collections” that might do something similar eventually.
I’m not sure what you mean by “with password” – more likely to use the current OAuth flow. Maybe you mean “when logged in”?
For taxonomy example was imagining to Wordpress or Vimeo experience, where the admin can set a password to share with someone in order to see content.
That would be a centralized app feature that could be built, but if it’s expected to work on any app, it would need to get implemented at the protocol layer.
yes, that’s exactly what I was thinking: might it be implemented at the protocol layer. Understanding that you are advocating for private data at the protocol layer anyway, yes?
Well, let’s say as one or more interoperable implementations that are running at scale across multiple services that see good usage is my personal goal.
And somewhere along there is something that Bsky PBC will also use for interop. And they may surprise us and ship something sooner but I’d hope they share some timing and plans.
Right now - use cases and proof of concepts and having different teams adopting shared codebases.
1 Like
Yeah eventually we’d like to support more granular access controls for a collection. Until I write up a leaflet explaining our approach, this thread does a decent job: @wesleyfinck.org on Bluesky
I’m catching up so it seems a good time to summarise some of the different things I’ve read on this and take a moment to abstract… apologies if this synthesis isn’t useful.
I’m going to be bold and say that what we are talking about here is content visibility, although you will see that broaden quickly even within this post. Let’s start simply; for single-author content there are several types of audience:
- Self - keeping visibility closed while drafting prior to publication, e.g., or writing journal entries and notes which will never be seen by another user. Some are making the explicit assumption that this ought to be managed by an app but that solution raises all sorts of questions about data resilience and backup which users will make their own incorrect assumptions about.
- One other - the classic DM where a post is sent to one other trusted user is not currently dealt with on proto. An on proto solution should be able to handle all the things people are used to with public posts. Reactions and replies are easy to envisage. Reposts and quote posts are harder to think about. This cannot be handled by an app alone… there needs to be a way to route the content. This immediately exposes us to metadata leakage and throws minds towards e2ee about which @ianopolous.bsky.social has written , so we need a way to scope this requirement such that it remains useful while meeting the expectations of general users. @davenash.com has opened the dialogue.
- A group of homogenous others - at this point we introduce the need for management of the list of others and different people have very different assumptions about what this means. We introduce
reply to all on top of reply, i.e.
- Everyone - this seems to work pretty well…
For multi-author content there are a bunch of other considerations some of which are identified by @btrs.co in their post. One of the interesting things to consider here is that we add the concept of roles to the groups. As a consequence we’ve bought ourselves even more first order primitives which need to be handled: the content, the roles, the groups (author, editor, subscriber, e.g.), the users, the metadata. Each of these needs visibility consideration and we’ve suddenly introduced workflow onto some of them.
These things are important because there are wide expectations that, for non-public content, its organisation and the visibility of those with rights to it also needs to be non-public. Either those expectations need to be reset or thorny questions about metadata visibility and e2ee need to be addressed.
There are questions about legal risk and who carries it. If a PDS owner can be identified then they can be coerced. If a PDS chimney is smoking you can be certain that the owners’ door will be knocked on. Maybe that’s OK. Maybe it’s not. Does discoverability outweigh anonymity or should that permeability be a PDS owners’ choice?
We have to answer questions about whether a new addition to a group can see content posted prior to their addition. The mail example from Paul’s leaflet, for instance, comes with assumptions about state both for the post and the group itself - valid assumptions which make some use cases impossible.
There are also questions about who can manage the groups and how big they can be - someone wanting to build a subscription service handling 1b users with 10,000 content flavours is coming from a very different set of assumptions than someone trying to coordinate their pub quiz team.
2 Likes
I don’t think the PDS should be making any choices. The PDS largely amounts to a database with an oauth server and some xrpc endpoints. The choice about privacy tradeoffs should be at the user / app relationship level, like everything else in atproto.
Groups and roles are non-negotiable for Blebbit’s use case and I’ve built the concepts into the permissioned spaces poc. The permissions available are designed for allowing many of the use case patterns onto a shared permission structure or schema. This example is from the Record type in that schema, there are also Groups and Roles with similar permissions, and Spaces which have all of them. This system also does not leak the existence of membership, permissions, or content (if permissions are set aptly, there are always footguns)
ReBAC is a really significant UX/DX improvement on ACL/ABAC/RBAC imho
atproto/packages/pds/src/authz/spicedb/schema/atproto.zed at main · blebbit/atproto · GitHub
Love the @dynamicalsystem.com handle btw, shared with one of my favorite math courses at uni.
1 Like
