About private data in ATProto -- I'm currently pondering an idea of two ways it can be used together:
- Record metadata over the relay, with the origin PDS managing its access controls. The link is to the full proposal of that idea.
- Completely private data that doesn't get published at all, and can only be accessed by the user or an authorized application directly with the PDS.
I want to explore idea #2.
My concept is that it would be implemented by a new set of XRPC endpoints implemented by the PDS. Let's call this com.atproto.privateRepo.*. These endpoints would mirror most or all of the com.atproto.repo.* endpoints, without any access control bits involved. It would also not include a way to refer to any specific repo, since it can only ever be used for one: the one you're authorized as.
As far as OAuth goes, it would also have a separate family of repo scopes (I'm going by this version of the proposal by Brian Newbold right now), we can call it private-repo.
This private repo would be used for preferences, drafts, bookmarks, and other data that is only needed by client applications. #1 would be used instead for anything that an appview or other server (such as a feed generator) might need to access, even if access is restricted to everyone else.
The problem with #1 is that it generally publicly advertises the creation of these records. This is one way to solve that problem. It may be easier or more complicated, or delay it too much, to expand #1 with some ability to say "don't let relays see this".
Actually, I think #1 seems to misunderstand how relays get records: as far as I can tell, the relay crawls PDSes, rather than PDSes pushing to the relay? It also seems structurally AI-generated...
One problem with #2 is that this may complicate the process of exporting & importing repositories, depending on how those CAR files are structured... and PDS migration, too.