Private/Locked accounts

[muchmich]

The option to make your account "private" as in only your followers can see your posts.

[pfrazee]

This is on the roadmap but it won't be in the near future

[atomicthumbs]

It's kind of bizarre that the site shipped without a crucial safety feature like private accounts. I effectively can't use it as a social media platform without them.

As-is, if someone is stalking you on Bluesky, or sending harassment your way in some fashion, your only option is to permanently delete your account. Leaving users open to this kind of danger seems irresponsible.

[olucaslab]

Hello, it's been around 10 months since this, any update on this actual issue. Like @atomicthumbs said:

As-is, if someone is stalking you on Bluesky, or sending harassment your way in some fashion, your only option is to permanently delete your account. Leaving users open to this kind of danger seems irresponsible.

[qazmlp]

I think this is to a large extent inherent to the architecture. Please excuse the harsh wording, but ATProto is genuinely a "privacy-last" specification where the concept of follower-approval and post privacy aren't meaningful, aside from temporarily deactivating an account entirely.

(Adding a locked account feature to apps isn't entirely impossible of course, but doing so with privacy would require at the least a parallel network with distinct architecture and protocol.)

That's not to say there wouldn't be any value in an appview- and app-side mechanism to limit exposure though, as long as it's made clear that it's trivial to circumvent with an alternative client. That may at least turn away the brunt of the harassment in such situations.

[olucaslab]

Thanks a lot for the answer, I was thinking about it and that maybe at-proto would be the 'guilty' for not getting this feature. What you said gave a new perspective of the issue.

[DeCat4]

Whenever this feature ships out and hopefully soon there should also be a remove follower feature and blocking should make a user unfollow you so if you unblock they aren't still following.

[dev0T]

As someone that had a stalker in the past, having a private profile is a must. I would even go as far as suggest an option to decide who will be able to see your posts like Mastodon has (for example, mutuals only).

[WAS-D]

I think this issue/feature request is even more relevant/important and needed now. Specifically because of twitter's own privacy features (blocking) being removed, and a lot of people who are inherently more vulnerable to targeted/group harassment join bluesky to get away from that.

[MixxyManiac]

Here to support this suggestion

and adding my own words here: I very much believe that now would be a great time to have the option to change our account visibility, with both either "Public" (open to anyone) or "Private" (can access by user sending a follow request).

[Nekkowe]

Thanks a lot for the answer, I was thinking about it and that maybe at-proto would be the 'guilty' for not getting this feature. What you said gave a new perspective of the issue.

Mind you, the AT Protocol is also developed by Bluesky PBC https://github.com/bluesky-social/atproto/tree/main?tab=readme-ov-file#about-at-protocol

[Rohmaioi]

hopefully comments/replies can be toggled to public or private (like instagram, private account comments are shown to public)

[LuisMayo]

I think this is to a large extent inherent to the architecture. Please excuse the harsh wording, but ATProto is genuinely a "privacy-last" specification where the concept of follower-approval and post privacy aren't meaningful, aside from temporarily deactivating an account entirely.

(Adding a locked account feature to apps isn't entirely impossible of course, but doing so with privacy would require at the least a parallel network with distinct architecture and protocol.)

That's not to say there wouldn't be any value in an appview- and app-side mechanism to limit exposure though, as long as it's made clear that it's trivial to circumvent with an alternative client. That may at least turn away the brunt of the harassment in such situations.

I don't know about AT Proto's shenanigans but I don't see why this couldn't be enforced Server-Side. ActivityPub does it. Sure, you have to trust all servers from all your followers, but it's stil a mile safer than doing it client-side

This is hurting adoption in some circles (specially queer/marginalized people) who are precisely the kind of people who're more likely to look for an alternative to Twitter/X

[atomicthumbs]

If privacy is impossible on ATproto, how did they implement DMs?

[Nekkowe]

If privacy is impossible on ATproto, how did they implement DMs?

Simple, they didn't implement them through AT Proto ("yet").
https://bsky.social/about/blog/05-22-2024-direct-messages
https://docs.bsky.app/blog/2024-protocol-roadmap#product-features

Basic "Off-Protocol" Direct Messages (DMs): having some mechanism to privately contact other Bluesky accounts is the most requested product feature. We looked closely at alternatives like linking to external services, re-using an existing protocol like Matrix, or rushing out on-protocol encrypted DMs, but ultimately decided to launch a basic centralized system to take the time pressure off our team and make our user community happy. We intend to iterate and fully support E2EE DMs as part of atproto itself, without a centralized service, and will take the time to get the user experience, security, and privacy polished. This will be a distinct part of the protocol from the repository abstraction, which is only used for public content.

[vinoff]

I am also adding my interest to this feature, namely: The ability to not allow other people to see our follows/followers.

Imagine you are in a more conservative country and you are gay/trans/whatever. Yet, you still want to see eye candy and follow some gay/trans/whatever people. You should be allowed to do so, in a somewhat private way. As it stands, you cannot do that, for fear of your friends/government/police/whatever stalking you and finding out about it and you suffering the consequences.

This should really go to the top of the list and be implemented as soon as possible, in my opinion.

[TogglesHappyZoo]

I really, really wish this would get pushed up the priority list. I have friends who desperately want to leave Twitter but haven’t explicitly because locked accounts don’t exist, AND they’re worried that Twitter is going to remove locked accounts, leaving them vulnerable.

I don’t know about other communities, but in my communities, this is the number one issue preventing Bluesky adoption as far as I can tell. Everyone keeps saying it will be really hard, but it’s a high priority for queer minorities, so it really should be an issue that’s tackled sooner than later.

[alastairvox]

I have many users/friends that exclusively use twitter for the private accounts, it is a meaningful and non-replicable in a public fashion way of using social media that needs to be prioritized. Understandably AT protocol doesn't like non-public posts, but being able to directly authorize certain clients or allow certain users IS conceptually possible

[sambc]

I don't know the underlying details of ATproto, so I can't comment from a real position of technical authority here, but with how I understand it works (with the Firehose at its core), in-protocol privacy could be done, but it would mean that every post from a private account was actually sent as a separate post for each account authorised to see it. So each new accepted follow would also generate a new instance of every existing post, as well.

The method would be by using keypairs - every account gets a keypair stored in the PDS, or at least the public part there. When a private account posts, it creates one post for each follower with metadata indicating which follower it is for, and with the post encrypted with that follower's public key. The follower, on receiving it, can decrypt it with their private key.

Not hideously complex to implement, but puts a potentially significant extra burden on the network/service, and with a lot of implementation wrinkles in terms of clients (apps) getting the private keys. And it's the people who follow the private account who have to make sure their private key is in every app they use, and entering the passcode for it if (as is sensible) they use a passcode.

But hey, this is open source, if anyone wants to do it and has the know-how and the free time, I'm sure they can offer a patch.

[Geist-Hund]

I've made an account, but I am very hesitant to really get into using bsky without any real privacy options. I do not feel safe on there as long as it's so open, and most of my friends feel the same.
It shouldn't be hard to implement something along the lines of follow requests for private accounts. Or, even simpler, the option to make individual posts private/mutuals only.

[C-crypto]

If the future private accounts implemented in Bluesky are like X, where the entire account is private, I would like to be able to “reject reactions from private accounts.”

In X, reposts, likes, replies, etc. from private accounts are not notified, and it is impossible to know from whom such reactions were made. Therefore, even if a private account sends us a malicious reaction, we cannot block it or take other actions because we do not know who sent it. Therefore, when private accounts are implemented in Bluesky, I hope this kind of harassment against individuals will be eliminated.

Possible ways to deal with this include a function to “reject reactions from private accounts” as well as “make it possible to know from whom reactions are coming, even from private accounts”.

[caffebreve]

Adding another drop to the "we understand that it's difficult given the underlying protocol architecture. but please try to prioritize this" bucket. For a majority of my community (mostly from the Japanese speaking Creatives cluster,) switching to Bluesky from X is a non-starter because of the lack of private accounts, and I struggle to convince people to migrate because of the lack of a safety feature that most people consider to be basic functionality for a Social Media platform. I myself am reticent to post because I do not enjoy the feeling of openness and do not welcome the immediate follows from strange accounts that come with posting.

[Tamschi]

[…]

The method would be by using keypairs - every account gets a keypair stored in the PDS, or at least the public part there. When a private account posts, it creates one post for each follower with metadata indicating which follower it is for, and with the post encrypted with that follower's public key. The follower, on receiving it, can decrypt it with their private key.

[…]

This offers considerably worse privacy than most existing solutions, since it makes all meta data (message contacts, times, likely at least size estimates) fully public.

(It would likely be overall more efficient to resolve this in a more privacy-friendly manner, too, in terms of operating costs, but the extent of the meta data leakage should be enough to rule this approach out already.)

[analogrelay]

We use Instagram to host a “family account” that has pictures and videos of our young kids, who can’t consent to fully public sharing because they’re too young. Private accounts have been a good balance to share content with trusted people only. I’d love to move off of Meta and over to something running on ATproto but the lack of privacy is a big blocker :(

[softcustomer]

There should be a setting when private accounts are added that make it so that you can't see replies to private accounts

[shaunc]

Perhaps this could be implemented on top of the ATProto with only minimal changes?

https://bsky.app/profile/shaunc.bsky.social/post/3lhd6ectypk2p

1. A private account can be a theshold-cryptographic group, in which the account holder controls key exchange/distribution.
2. To add a person, the server on behalf of the account holder sends out new keys w/ added member (all signed by account holders private key, which is only on client not sent to server). Removal also redistributes keys. Server just delivers and they are held by individuals in their clients.
3. The group is k=1 threshold security: anyone who can has a key can read and write messages that can be read by other group members.
4. The messages would simply be put into the ATProtocol encoded.
5. The protocol has a flag that marks messages as encoded, so that they can be filtered out of non-group-members' messages.
6. (Later) some delegation of encryption could be worked out so that feeds other than follower that need message text can process them.

[LuisMayo]

I don't know about ATProto's in deep but it seems like a sensible solution and an efficient one and that

[muchmich]

This is on the roadmap but it won't be in the near future

@pfrazee I was wondering if there is any update to this timeline? I and a lot of my friends haven't fully moved to bsky yet because of the lack of private accounts. I appreciate all the work y'all have put in so far of course though.

Also as a relevant but newer request if it's possible: as a private account, allow your followers to repost your posts. The repost would still only be seen by people who follow you. I'm not sure how complicated that would be, but it's something my friends and I would like.

[muchmich]

I did not mean to close this.... I don't know why it closed..

[shaunc]

I had gotten my hopes up! : ) ... there is no "reopen" available to you as author, @muchmich? @pfrazee - I know you are busy but the workflow is sort of glitchy here if the author cannot reopen.

[surfdude29]

It's very easy to close an issue by mistake unfortunately, but there should be a button saying Reopen issue @muchmich?

I have one but of course it's greyed out for me.

[muchmich]

Oh it said I wasn't allowed to reopen, but now it's giving me the option. Maybe there's a minimum amount of time lol.