Bluesky Adds an Algorithmic Opt-Out: What It Does and Where It Falls Short
Bluesky has introduced a new privacy setting that lets users keep their posts out of the platform's algorithmic "Discover" feed for anyone who doesn't already follow them. The toggle gives account holders a way to step back from algorithmic distribution without leaving Bluesky's public timeline.
The feature, described by TechCrunch as an "algorithmic opt-out," lives in the app's Privacy and Security settings. Flip it on, and none of your posts will show up in Discover for non-followers. It works at the account level, not per post — once enabled, every post you publish is excluded from Discover's non-follower recommendations. You can turn it on or off at any time, and Bluesky has framed it as one of several upcoming updates aimed at giving users more control over their experience. (Engadget, TechCrunch)
To understand what this setting covers, it helps to know how Discover works. The feed is one of the main places where Bluesky users encounter posts from accounts they don't follow. It blends personalized recommendations with trending content across the network, a design Bluesky laid out when it first described its custom feeds architecture in July 2023. (Bluesky Blog) By letting users suppress their own posts from this surface, Bluesky is carving out a middle ground between full public visibility and the locked-account privacy model that platforms like X offer. Notably, Bluesky does not support private accounts at all — every account on the network is publicly accessible. (Engadget)
Here is where the architecture matters. Bluesky runs on the AT Protocol, an open system designed so that any developer can access a real-time stream of all public posts — what's called the "firehose" — and build their own feeds, search tools, or analytics services on top of it. The opt-out toggle is scoped only to Bluesky's own Discover feed. It does not prevent your posts from appearing in other custom feeds or third-party applications that pull data through the protocol. Think of it like unlisting your number from one specific directory: other directories that already have your information can still list it.
Even with the setting enabled, your posts remain public at the protocol level. Any relay (a server that indexes and redistributes Bluesky data) can still find them, and any custom feed that chooses to include them will still show them. The toggle reliably removes your posts from Bluesky's first-party recommendation engine for non-followers, but it does not make your posts invisible to non-followers in any general sense.
What the setting does address is a narrower but real concern: the gap between the audience you think you're posting for and the audience an algorithmic recommendation system decides to show you to. On platforms with recommendation-driven discovery, a single well-timed post can be pushed to a massive audience the author never sought out. For users who treat Bluesky as a place for conversation within a small community rather than a broadcast channel, that amplification is not a feature but an unintended consequence. The opt-out lets them keep posting publicly to their followers while reducing the chances of algorithmic distribution to strangers through Discover.
Bluesky's positioning of this feature as part of a broader set of forthcoming updates suggests the platform is working through the tension between open-protocol design and user expectations for granular privacy controls. That tension is not unique to Bluesky; it is inherent to any federated or protocol-based social architecture where the data layer is separate from the presentation layer. The protocol guarantees that data is available; the client application decides what to recommend. An opt-out at the client level affects what that client recommends, not what the protocol itself exposes.
For developers building on the AT Protocol, the practical implication is that the Discover-feed opt-out is a signal about user intent rather than an enforcement mechanism at the data level. A post from an opted-out account still arrives in the firehose with the same visibility as any other public post. Custom feed generators, third-party clients, and analytics services that rely on protocol-level data will not be affected. Any application that wants to respect the user's preference would need to implement its own logic to check whether an account has opted out and suppress those posts accordingly — assuming Bluesky exposes that status through the protocol's API, which the available reporting does not confirm.
The broader design question this raises is whether and how user privacy preferences should be communicated across the federated layer. In a system where any relay can index and redistribute public posts, a preference like "don't surface my posts to non-followers in algorithmic feeds" only has force if downstream services choose to honor it. Bluesky can enforce it in its own app. It cannot enforce it across the protocol.
What the new setting provides is a straightforward, useful tool for Bluesky users who want to participate in the network conversationally without algorithmic amplification through the platform's primary discovery feed. It is a client-side control with a clear, defined scope, and users who understand that scope can use it effectively. Those who need stronger guarantees about visibility should note that Bluesky's protocol-level architecture makes absolute suppression impossible through any single setting, and plan accordingly.
