Support for Private Accounts

[h3zjp]

Prominent SNS (X [Twitter], Instagram, Mastodon, etc…) have the ability to make accounts private.
This means that the other party cannot follow you unless you allow them to.
Currently, Bluesky (AT Protocol) does not seem to have such a feature implemented, so there is a risk that an unknown user may see your posts and feel uncomfortable.
Please consider implementing private accounts to make it as easy to use as other SNS.

Thank you in advance for your cooperation in the above.

[bnewbold]

My understanding of private accounts on most platforms is that it isn't just following that is controlled, but general public access to all of the content.

The current version of the federated protocol that Bluesky is built on, atproto, only supports public content, not private content. A future iteration of the protocol may support private content, using group encryption, but this will be a large piece of work. We have ideas on how to achieve this (and we are not looking for suggestions or opinions at this time), but we are focusing on getting the public content use-case to work well before we tackle the private-content use case. We understand that this is an important feature and use case for many people.

[joeyoropesa-dev]

Well in that case can we expect (testers) to get an pre-release of an DM feature because using DM as temporary solution to share some private info with people we trust only seems much more safe than publishing it as an public post

What you think about this as an temporary solution while waiting for private posts/accounts support

Thanks in advance for your response and support!

[ghost]

could you techinally have a seprate server for that like have a verification badge/emoji that requires user id to view the profile or user permission depending on badge

[mmhil]

With Bluesky opening up to the general web public, what is the status of this feature? Privacy settings should always be a priority before any kind of open internet access to avoid opening the users to unfiltered abuse.

[Zero3K]

Then year(s)?

[Zero3K]

If so, then a lot of people are going to drop it and move on.

[heartpunk]

@pfrazee very worth considering partial measures in the meantime; it would be fairly trivial to do account wide reply limitations for example, and one could also do frontend level fixes for prohibiting access within the app.

None of this should in any way be considered an alternative to proper private account implementation later on, of course, but, it sure would mitigate possible harms a lot in the meantime!

[ghost]

i mean i had a idea of how bsky can make a private account without changing from atprotocols yk how in most emojis are only used for expression could you techinally make age verification badges/emojis where if someone trys accesses you account under that age they wont be able to, and maybe make so its hidden if your not verifed by the user or id

[mempler]

Just wanted to point out that there are also legal obligations, especially in countries like Germany that enforce strict privacy.

[blu3r4d0n]

I'm guessing this is still way down on the priority list since the complexity appears to be quite high. Is that the case?

[ghost]

yk how the atprotocol makes it so you cant make a private account is possible to make a seprate server that can hold verification and/or badge/emojis that if on a username it age restricts and/or privates there account such as this little mock up i made

[gausie]

It's not a UX issue, it's a protocol issue. If you have a good idea of how to implement private accounts in atproto, that is what you should be sharing.

[gausie]

Also please stop spamming this non-solution

[mempler]

Just wanted to point out that there are also legal obligations, especially in countries like Germany that have strict privacy laws.

[jkassel]

If you set up your own PDS server would it be possible to set restrictions there or implement such a feature?

[mangofunk]

This remains one of the biggest missing features virtually all friends and colleagues looking to leave Twitter continue to ask about when discussing migrating to Bluesky.

It’s great to see all the progress being made on AT broadly and in the Bluesky experience day to day, the team is doing amazing with the time and resources available, but I hope privacy controls are given greater priority if they’ve not been already.

I recognise it’s not core to how AT was envisaged, and likely poses challenges to implement, but in terms of adoption privacy controls are in very real terms one of the only reasons significant portions of users stuck on centralised platforms are holding out on leaving and fully adopting Bluesky (and AT broadly).

Privacy controls allow for greater safety, security, and while private accounts themselves are arguably not a big driver of engagement or discovery compared to fully public content, in practice private or personal accounts for friends/social groups increase time spent opening, checking, and interacting on the platform, and hopping between accounts. It makes the current platform, and any others built on AT in future, far for flexible for different use cases.

In terms of user safety and sustaining the momentum and longevity of Bluesky/AT I view this as an extremely high priority, and while I’m sure the team is aware of it and has many other areas that need attention right now, worry that this being overlooked or delayed too long harms growth and long term use.