idea/feature request - ability to blacklist or whitelist external accounts access to PDS

[mm14kwn]

Not sure on the current possibility of this by modifying current code, or if it would need to be something that could be developed and added on. If anyone's got any advice on where to start please let me know.

Basically as Bsky/atproto Devs seem to have little regard for privacy or moderation, I want to explore possibilities of my own, and a number of users and developers suggested hosting a seperate pds with the privacy features that I believe are necessary. What I'm looking to do is blacklist certain accounts from being able to access the repos from an account hosted on my pds, or ideally whitelist so only certain accounts can access the data in the repos on my PDS. This would enable something closer to a locked or private account, a feature bluesky sorely lacks. Similarly, it would let users opt out of feeds such as firehose and discover, which tend to drive unwanted interactions and compromise user safety and privacy.

Is there a datastream of requests into the data stored on this pds, and if so, does this have data related to the feed or the user account that has requested this information? There must be some information related to this, as it would be required for checking for blocks and for the toggle to hide the account from non-logged in users. I'd then intend to insert a blacklist/whitelist step at this stage to refuse requests from unwanted/unknown users.

[bnewbold]

We do care about privacy and moderation. Folks are free to experiment as they see fit, but our general stance is that the atproto data repository is an aspect of the protocol that is explicitly not designed to support exclusion. If you are seeking to share content with a limited audience, I would not recommend starting with the atproto data repository system.

If you are looking for something pragmatic, you could do something like the centralized bluesky DMs system. This makes use of other parts of the atproto system (Lexicon, identities, authentication, etc), but is much more private. It does rely on a central service, and we do want to replace it with proper E2EE and federated DMs, but it is a much more appropriate technology choice for your stated goals. I'd also recommend looking at generic technologies like Matrix, Signal protocol, or even ActivityPub if you need a system today that provides limited visibility for content. We do want to support this with new protocol primitives in atproto itself, but it may be some time until that is available.