Bluesky Algorithmic Opt-Out 2026: Archive Implications

September 1, 2026 · ThreadGrab

On August 27, 2026, Bluesky shipped a setting that lets users ask apps to hide their posts from the Discover feed's algorithmic recommendations. The post by the official @bsky.app account reads verbatim: "Now you can opt out of having your posts shown to non-followers in the Discover feed. We know not everyone wants to go viral. Sometimes you're just posting for your followers." The toggle itself is labelled "Ask apps to hide my posts from algorithmic recommendations" and lives under Settings → Privacy and Security in the official Bluesky app (social-app v1.131.x).

For an X / Bluesky / LinkedIn archive tool like ThreadGrab, the launch is more than a privacy story. The setting is stored as a singleton record in the user's PDS repo at collection app.bsky.actor.contentVisibilityDeclaration with rkey literal:self and a boolean hideFromAlgorithmicRecommendations. Because the record lives at the account level and not in the app's local settings, the preference travels with the user across every AT Protocol client. TechCrunch's Sarah Perez phrased it directly: "the preference is recorded at the account level. That means the choice travels with the user, even if they're posting from another app that is powered by the same underlying protocol that Bluesky uses, AT Proto. However, while those other apps have access to this information, they still have to choose whether to respect it."

What the opt-out actually changes

The setting affects a single algorithmic surface: Bluesky's Discover feed for non-followers. Excluded accounts still appear in:

Posts remain public. The account does not become private. The toggle is also opt-in by default: per the lexicon description, "Consumers must treat a missing record as false," so a user who has never opened the new privacy panel is still eligible for algorithmic recommendations. Caching invalidation is documented to take up to one hour, meaning a freshly-toggled opt-out may still appear in a Discover snapshot during that window.

Why this matters for social archive tools

Three concrete archive implications fall out of the launch.

1. The "Discover snapshot" is now time-stamped

Before August 27, 2026, archiving a public Bluesky profile and a Discover-page snapshot of that profile produced two lists that always agreed. After the launch, the same archive pull run twice — once at 14:55 UTC and again at 16:00 UTC — may surface a different set of "people you might like" recommendations for the same query, because opt-out signals started propagating partway through. An archive that wants to claim "this is what the Discover feed showed on date X" should now also record:

• The exact UTC timestamp of the snapshot,
• The hideFromAlgorithmicRecommendations state of every account in the snapshot,
• Whether the cache-invalidation one-hour window had elapsed at capture time.

2. The cross-client flag breaks naive crawlers

Because the preference lives at the AT Protocol account level, a third-party client that does not read app.bsky.actor.contentVisibilityDeclaration will produce a snapshot that includes accounts whose creators explicitly asked apps to hide them. For an archive tool that crawls via a third-party AT Proto client, that means the right move is to read the preference directly from the user's PDS (via the standard com.atproto.repo.getRecord call against at://<did>/app.bsky.actor.contentVisibilityDeclaration/self) rather than rely on whatever filter the client applies. The example below fetches the preference and respects it.

// Resolve DID and check the opt-out preference
const did = await resolveHandle(handle);
const uri = `at://${did}/app.bsky.actor.contentVisibilityDeclaration/self`;

const record = await agent.com.atproto.repo.getRecord({
  repo: did,
  collection: 'app.bsky.actor.contentVisibilityDeclaration',
  rkey: 'self'
});

const optedOut = record?.value?.hideFromAlgorithmicRecommendations === true;
console.log(`${handle} opted-out: ${optedOut}`);

// Skip the post in any "Discover-shaped" archive:
if (optedOut) {
  console.log(`Skipping ${post.uri} from alg-recommendation archive`);
}

3. Historical re-fetch is a soft cutover

Lexicon app.bsky.actor.contentVisibilityDeclaration was added in atproto PR #5372 on August 12, 2026. social-app PR #11417 (APP-2774) merged August 16; the helper-text update merged August 26; v1.131.0 shipped August 18 with the toggle hidden behind a feature flag and went live to all users on August 27. A historical archive pull dated before August 12 will not show the preference for any user; a pull dated after August 27 will. For archive tools that already hold pre-cutover snapshots, the safest pattern is to back-fill the missing field with a sentinel value (e.g. null for "unknown") rather than infer false as the default — the lexicon says "treat missing as false" for app consumers, but an archive's job is to record what was observable, not what the app defaults to.

How ThreadGrab treats the new preference

The capture layer records the user's hideFromAlgorithmicRecommendations flag alongside each archived post and surfaces it in the public Markdown output as a small footnote:

---
archived_at: 2026-09-01T17:24:11Z
author: jay.bsky.team
opt_out_algorithmic: true
source_post: at://did:plc:abc.../app.bsky.feed.post/3lx...
---

That way, anyone reading the archive later can tell whether the post was visible in a Discover snapshot at capture time. The setting does not change whether a profile can be archived (it never made the post private), only whether that post would have been algorithmically surfaced on Discover. ThreadGrab's X and LinkedIn pipelines already record equivalent provenance signals (logged-out visibility, mention context) so the schema pattern fits.

What it does not change

• Posts remain public. The setting is not a "private account" toggle. Private accounts at the protocol level are still rolling out and were explicitly called out as not-yet-shipped in the TechCrunch piece.
• Existing followers keep seeing every post. Only the recommendation surface for non-followers is filtered.
• The third-party client surface is unchanged at launch. Skybridge, Skeets and other AT Proto apps can read the flag but are not required to honor it. The official Bluesky app honors it.
• There is no enforcement on screenshots, link shares, or off-platform virality. The flag is a request to algorithmic surfaces only.

Frequently asked questions

Last verified: September 1, 2026. Bluesky toggle label, PR numbers and feature details verified via the official @bsky.app post (at://bsky.app/app.bsky.feed.post/3mu3jzayuys2k) and TechCrunch's same-day coverage. Toggle state changes propagate within ~1 hour.