Bluesky Opt-Out Algorítmico 2026: Implicações para Arquivos

1 de Setembro de 2026 · ThreadGrab

Em 27 de agosto de 2026, o Bluesky lançou uma configuração que permite aos usuários pedir aos aplicativos para ocultar seus posts do feed algorítmico Discover. O post da conta oficial @bsky.app diz, 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." O toggle em si se chama "Ask apps to hide my posts from algorithmic recommendations" e fica em Configurações → Privacidade e Segurança no aplicativo oficial Bluesky (social-app v1.131.x).

Para uma ferramenta de arquivo X / Bluesky / LinkedIn como o ThreadGrab, o lançamento é mais do que uma história de privacidade. A configuração é armazenada como um registro singleton no PDS do usuário, na coleção app.bsky.actor.contentVisibilityDeclaration, com rkey literal:self e um booleano hideFromAlgorithmicRecommendations. Como o registro vive no nível da conta e não nas configurações locais do app, a preferência viaja com o usuário em todos os clientes AT Protocol. Sarah Perez, da TechCrunch, resumiu: "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."

O que o opt-out realmente muda

A configuração afeta uma única superfície algorítmica: o feed Discover do Bluesky para não-seguidores. Contas opt-out continuam aparecendo em:

Os posts continuam públicos. A conta não se torna privada. O toggle também é opt-in por padrão: pela descrição do lexicon, "Consumers must treat a missing record as false," então um usuário que nunca abriu o novo painel de privacidade continua elegível para recomendações algorítmicas. A invalidação de cache leva até uma hora, o que significa que um opt-out recém-ativado ainda pode aparecer em um snapshot do Discover dentro dessa janela.

Por que isso importa para ferramentas de arquivo social

Três implicações concretas de arquivo surgem do lançamento.

1. O "snapshot do Discover" agora tem timestamp

Antes de 27 de agosto de 2026, arquivar um perfil público do Bluesky e um snapshot da página Discover desse perfil produzia duas listas que sempre concordavam. Depois do lançamento, o mesmo pull de arquivo executado duas vezes — uma às 14:55 UTC e outra às 16:00 UTC — pode mostrar um conjunto diferente de recomendações "pessoas que talvez você goste" para a mesma consulta, porque sinais de opt-out começaram a propagar no meio do caminho. Um arquivo que queira afirmar "isto é o que o feed Discover mostrou na data X" deve agora também registrar:

• O timestamp UTC exato do snapshot,
• O estado de hideFromAlgorithmicRecommendations de cada conta no snapshot,
• Se a janela de uma hora de invalidação de cache havia transcorrido no momento da captura.

2. O flag cross-client quebra crawlers ingênuos

Como a preferência vive no nível da conta AT Protocol, um cliente de terceiros que não lê app.bsky.actor.contentVisibilityDeclaration vai produzir um snapshot que inclui contas cujos criadores explicitamente pediram aos apps para ocultá-las. Para uma ferramenta de arquivo que rastreia via um cliente AT Proto de terceiros, a jogada certa é ler a preferência diretamente do PDS do usuário (via chamada padrão com.atproto.repo.getRecord contra at://<did>/app.bsky.actor.contentVisibilityDeclaration/self) em vez de depender de qualquer filtro que o cliente aplique. O exemplo abaixo busca a preferência e a respeita.

// 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. Re-fetch histórico é um cutover suave

O lexicon app.bsky.actor.contentVisibilityDeclaration foi adicionado no atproto PR #5372 em 12 de agosto de 2026. O social-app PR #11417 (APP-2774) foi mergeado em 16 de agosto; a atualização do texto de ajuda em 26 de agosto; o v1.131.0 foi lançado em 18 de agosto com o toggle atrás de uma feature flag e foi habilitado para todos os usuários em 27 de agosto. Um pull de arquivo histórico datado antes de 12 de agosto não vai mostrar a preferência para nenhum usuário; um pull datado depois de 27 de agosto vai. Para ferramentas de arquivo que já têm snapshots pré-cutover, o padrão mais seguro é preencher o campo faltante com um valor sentinela (ex.: null para "desconhecido") em vez de inferir false como padrão — o lexicon diz "treat missing as false" para consumidores de app, mas o trabalho de um arquivo é registrar o que era observável, não o que o app assume como padrão.

Como o ThreadGrab trata a nova preferência

A camada de captura registra o flag hideFromAlgorithmicRecommendations do usuário junto a cada post arquivado e o expõe no output Markdown público como uma pequena nota de rodapé:

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

Dessa forma, qualquer pessoa que leia o arquivo depois pode saber se o post estava visível em um snapshot do Discover no momento da captura. A configuração não muda se um perfil pode ser arquivado (nunca tornou o post privado), apenas se aquele post teria sido superficializado algoritmicamente no Discover. Os pipelines X e LinkedIn do ThreadGrab já registram sinais equivalentes de proveniência (visibilidade logged-out, contexto de menção), então o padrão de schema se encaixa.

O que não muda

• Os posts continuam públicos. A configuração não é um toggle "conta privada". Contas privadas no nível de protocolo ainda estão sendo lançadas e foram explicitamente apontadas como ainda não disponíveis na matéria da TechCrunch.
• Seguidores existentes continuam vendo todos os posts. Apenas a superfície de recomendação para não-seguidores é filtrada.
• A superfície de clientes de terceiros está inalterada no lançamento. Skybridge, Skeets e outros apps AT Proto podem ler o flag, mas não são obrigados a honrá-lo. O app oficial do Bluesky honra.
• Não há enforcement sobre screenshots, compartilhamento de links ou viralidade fora da plataforma. O flag é um pedido para superfícies algorítmicas apenas.

Perguntas frequentes

Última verificação: 1 de setembro de 2026. Label do toggle Bluesky, números de PR e detalhes do recurso verificados via post oficial @bsky.app (at://bsky.app/app.bsky.feed.post/3mu3jzayuys2k) e cobertura da TechCrunch do mesmo dia. Mudanças de estado do toggle propagam dentro de ~1 hora.