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

[sylv256]

I was very happy when I learned ActivityPub instances have follower limitations, but BlueSky does not. Would making follower requests a thing be possible or planned with how things work now?

[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.

[DigitallyNick]

Very surprised the EU haven’t gone after Bluesky for its severe lack of privacy.

[upintheairsheep]

Source?

[surfdude29]

Bluesky Social PBC (the company that runs Bluesky) has obligations under various data protection and privacy laws – e.g. the GDPR in the EU – to keep certain user data private. This would include data such as the user's email address and the date of birth they enter.

Content posted to a social network that the user is explicitly told will be public – such as posts made on Bluesky – are not private user data.

[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.

[ghost]

Social media is supposed to be public. Wanted to talk with someone privately? We have a thing for that it is called group messaging. You will ruin the simplicity and elegance of the philosophy of BlueSky.

There is no need to add private accounts. Not especially with these "surprised the EU haven’t gone after Bluesky for its severe lack of privacy." people.

God bless you all.

[sajixx]

How fortunate for you that you are not in a situation where you need privacy!

I escaped from a very abusive situation. Throughout my life I have continued to use Facebook in an old-fashioned way, posting about my daily life. My list is small, only about a hundred friends, all of whom I actually know and trust. They tell me regularly that they love seeing my updates online, and that it helps them feel connected to me even when they aren't able to see me much. But many of them have migrated to bluesky. I would love to, but I cannot; my abusers have been known to stalk me online and to use the information in my posts against me. I can't use a platform that doesn't feature harsh privacy controls, so I am stuck with Facebook until that becomes available.

Private messaging cannot fill this need. If you put 100 people who are largely unrelated to each other in a group chat, most of them are leaving.

[singularsyntax]

Maybe it would be useful to separate the discussion between Bluesky and ATProto. My takeaway from reading some of the technical specs is that ATProto has larger interoperability goals for generalized social networking and that Bluesky is only one application of it. Perhaps it is unfortunate that the ATProto repository is hosted under bluesky-social and deserves its own top-level namespace on GitHub.

Saying that social media is supposed to be public is an opinion. The most reductionistic (and tautological) interpretation of "social media" is that it is, well, social. And that includes private communities. Public social networks like Bluesky and Twitter before it seem more focused on "personal branding" and "influencers" and their sheep, and while I like Bluesky, I personally don't have much use for those use cases. I really just want to keep up with close friends and family. I don't see why a protocol with general interoperability aspirations and concerns cannot encompass both public and private use cases.

[surfdude29]

Support for group-private data is planned for ATProto (and thus Bluesky too), as was restated in the roadmap released in March that covers Spring/Summer 2025:

Privately Shared Data and E2EE DMs

We believe that robust support for group-private data will be necessary for the long-term success of the protocol (and for apps built on the protocol). Similarly, the ability to share private content with a specific group or audience continues to be a top feature request for both the AT Protocol and the Bluesky app. Just as we’re currently doing with public conversation on the Bluesky app and the AT Protocol, we also want to co-design the protocol specification for private data in tandem with specific real-world product features: this results in better outcomes for both. Designing for privacy is pretty different from designing for global broadcast, and we think the data architecture will probably look pretty different from the MST + firehose system.

Shared data will depend on Auth Scopes, and we don't expect to start design work until that is complete.

https://docs.bsky.app/blog/2025-protocol-roadmap-spring#privately-shared-data-and-e2ee-dms

[surfdude29]

For further info on how private data might be implemented in ATProto, please also see @bnewbold's comment in reply to a question on this. However, please keep in mind that this was a direction of thinking shared in February, so things might well have changed in the months since then:

• Private, non-shared data in repo? #3363 (comment)

[straiforos]

I would like to propose we allow for PDS to support private profiles. We could use a private IPFS gateway service like pinata.cloud to allow for this to be simpler. We put this feature into the hands of the users/market to provide paid and selfhosted solutions to allow private profiles.

I am experimenting with this now to see how viable this is.

It would be a large effort, but keeping it simple and iterative we could add to atproto/bskys lexicons private profile acceptance flow, use PDS for private profiles to make it not be a beta feature for those who are savvy by adding it to the logic, and use Pinata private IPFS gateway service to control exchanging content for feeds. Possibly even the profile information itself; avatar, bio etc.

[straiforos]

Hi @bnewbold and team!

I've been really enjoying bsky and other atproto powered sites. I was wondering if the team would be receptive to the idea I had. Since IPFS started I've envisioned a new kind of web, BlueSky and ATproto made it real. I dream of a web that is resilient when you need it to be and within the users control to secure and move their data.

IPFS is one of the core DiD providers I know of and Pinata offers private gateway solutions with authentication tokens.

I dug into this effort in my GitHub workspace I made with submodules to link the dependencies in one place:
https://github.com/CommunityStream-io/bsky-private-profile/tree/phase-1-3-api-endpoints

High-Level Approach

Three-layer strategy:

1. Private Profiles via PDS and Private IPFs gateways - Privacy settings and follow request records stored in user repositories
2. PDS Access Control - Middleware enforcing privacy checks at the repository level
3. Pinata Private Gateways - Time-limited access tokens for private media via IPFS

This could provide private profiles (approval-required follows, private content) without modifying the core protocol or public AppView.

Visual Overview

I've documented the architecture with sequence and component diagrams showing:

• Follow request approval flow
• Access control enforcement
• Private media token generation

📄 Full Technical Overview: Private Profiles Implementation

Guidance Appreciated

As a new contributor to the AT Protocol ecosystem, I'd love guidance on a few key areas:

1. Architecture Review - Are there any architectural concerns or gotchas I should be aware of with this PDS-level approach? What should I look out for to ensure compatibility with the protocol's evolution?
2. Community Coordination - How can I best coordinate with the official roadmap?
3. Any other advice If you have any wisdom to share or navitey on my part to dispell I'm open to learn 😄

[erlend-sh]

Looking good! The conversation about private data has largely moved over here: https://discourse.atprotocol.community/c/privatedatawg/16

So if you could kindly repost your work there, that’s the best place to solicit feedback.

Also did you read Paul’s two recent posts? They’re helpful for framing where your proposal fits into that context.

Have you talked to the Storacha folks? They’ve got a PDS backup service that aligns well with your work.

[straiforos]

Thanks for the direction! I have not spoken with anyone. I will repost over there once I get a little more context and possibly reach out to Storacha.