O Estado da Web Descentralizada em 2026

Uma rede social é descentralizada, em sentido prático, quando um usuário consegue trocar de provedor sem perder sua identidade, seus dados ou seus seguidores — e o ActivityPub, o AT Protocol e o Solid passam, cada um, em um subconjunto diferente desse teste.

Escolher um servidor e seguir algumas contas é a parte fácil. O vocabulário que acompanha essas redes (PDS, relay, AppView, Pod, WebID) se acumula rapidamente, e nada disso importa muito até o dia em que você quer se mudar.

Este é um relatório de situação sobre os três protocolos que importam para a web descentralizada hoje. Ele explica como cada um modela identidade, dados e audiência, indica em que ponto cada um está em termos de adoção e especificação, mantém contas registradas separadas de usuários ativos nos números, e termina com um serviço que você pode colocar no ar em uma tarde.

O Que Significa Descentralizado na Prática?

Descentralizado significa que você pode deixar quem quer que hospede sua conta e chegar a outro lugar com três coisas intactas: sua identidade (o nome pelo qual as pessoas te conhecem e as credenciais por trás dele), seus dados (posts, mídia, quem você segue, configurações) e sua audiência (as pessoas que te seguem e continuam recebendo o que você publica). Perca qualquer uma das três e a troca vira um recomeço com passos extras.

Cada protocolo abaixo é medido contra esse teste, e não contra quantos servidores existem ou quem escreveu o software. A contagem de servidores diz respeito à redundância. O teste de três partes diz respeito ao aprisionamento (lock-in).

Como o ActivityPub Federa Entre Instâncias?

O ActivityPub, uma Recomendação do W3C desde 23 de janeiro de 2018, federa fazendo com que cada servidor entregue as activities de um usuário diretamente nas inboxes dos servidores que hospedam os seguidores desse usuário. Todo usuário é um actor com uma inbox e uma outbox; publicar escreve na sua outbox, e seu servidor faz POST da activity para a inbox de cada seguidor. Não existe índice central, apenas servidores empurrando JSON uns para os outros.

Mastodon, Pixelfed, Lemmy e PeerTube todos o implementam, e é por isso que uma conta do Mastodon pode seguir um canal do PeerTube ou uma comunidade do Lemmy.

A identidade é onde o teste falha. Um handle como @user@instance.example pertence à instância, então uma conta que não tenha sido migrada antes de seu servidor ser desligado não pode ser recuperada em nenhum outro lugar. A mudança de conta do Mastodon envia uma activity Move que transfere os seguidores para a nova conta, mas a documentação é clara de que tudo o que você publicou fica para trás, e o arquivo que você pode baixar não pode ser carregado em outra conta Mastodon. Pontuando contra o teste: a audiência sobrevive a uma mudança planejada, os dados sobrevivem parcialmente como uma exportação, a identidade não sobrevive de forma alguma.

AT Protocol: Identidade Portátil, Infraestrutura Concentrada

No AT Protocol, a identidade de um usuário é um DID que nenhum servidor possui, e seus posts, follows e perfil vivem em um Personal Data Server (PDS) que pode ser movido para outro host sem que o DID mude. Acima do PDS ficam os relays, que rastreiam todos os PDS e emitem um único firehose, e as AppViews, que indexam esse firehose no produto que um cliente renderiza. A especificação é publicada e mantida pela Bluesky Social PBC.

A portabilidade tem limites. O guia oficial de migração de contas trata esses passos como algo que está fora do protocolo propriamente dito e que pode mudar depois, e encaminha você para a CLI goat ou para uma ferramenta da comunidade, em vez de um fluxo dentro do aplicativo. Bryan Newbold, engenheiro de protocolo do Bluesky, escreveu em outubro de 2025 que mover uma conta funciona na rede em produção desde o início de 2025, mas ainda é trabalho para desenvolvedores, e que os hosts de PDS operados pelo Bluesky não aceitam uma conta migrando para dentro.

A segunda ressalva é operacional. O Relatório de Transparência de 2025 do Bluesky diz que a empresa detém mais contas do que qualquer outro e é onde a maioria das pessoas se cadastra, com o restante da rede espalhado por milhares de Personal Data Servers, a maioria operada por outras pessoas. Nenhum número oficial quantifica que fatia da rede passa pelo relay e pela AppView que o Bluesky opera. Críticos argumentam que hosts independentes de PDS e projetos de infraestrutura comunitária ainda se apoiam em serviços centrais operados pelo Bluesky, e alguns concluem que a rede não é descentralizada na prática; isso é um juízo, não uma medição. Pontuando contra o teste: identidade e dados sobrevivem a uma troca de provedor por design, os seguidores vêm junto porque os registros de follow referenciam DIDs, e as camadas acima do PDS permanecem majoritariamente de uma só empresa.

Solid: Pods de Dados Sem um Mercado de Consumo

O Solid armazena os dados de um usuário em um Pod que o próprio usuário controla e exige que cada aplicação solicite acesso. Um WebID identifica a pessoa, o Pod é um servidor HTTP que guarda recursos RDF, e as aplicações leem e escrevem esses recursos assim que as regras de autorização permitirem. No teste de troca de provedor, o Solid tem o design mais limpo dos três: identidade, dados e regras de acesso ficam todos com o usuário, e um app é apenas um cliente.

A adoção não acompanha o design. O Solid Protocol é um rascunho de W3C Community Group (v0.11.0, 12 de maio de 2024), não um padrão do W3C, e o índice TR não mostra nenhuma versão nova publicada desde então; as versões anteriores foram 0.9.0 (dezembro de 2021) e 0.10.0 (dezembro de 2022), e o trabalho na 0.12.0 está no editor’s draft. As especificações de extensão das quais os apps dependem — WebID Profile, Type Indexes e Application Interoperability — ainda são rascunhos, e a especificação permite dois sistemas de autorização incompatíveis, WAC e ACP, com os servidores livres para implementar qualquer um deles. Ferramental e documentação ficam atrás dos outros dois protocolos.

O obstáculo prático é onde se cadastrar. O solidproject.org lista cerca de quinze serviços hospedados de pod, a maioria pequena ou experimental, e a Inrupt, empresa cofundada por Tim Berners-Lee, hoje comercializa infraestrutura de carteira (wallet) empresarial para negócios. O desenvolvedor de apps Solid Noel De Martin, escrevendo em 2024, apontou a ausência de um mercado de pods de consumo como o maior entrave ao Solid: pedir a alguém que faça login com Solid manda essa pessoa primeiro procurar um provedor, e é aí que a maioria desiste.

Quantos Usuários Bluesky e Mastodon Têm?

O Relatório de Transparência de 2025 do Bluesky (29 de janeiro de 2026) contabilizou 41,41 milhões de contas ao final de 2025, acima dos 25,94 milhões anteriores, somando PDSs hospedados pelo Bluesky e independentes; a empresa acompanha, mas não publica, um número de usuários ativos mensais. O relatório normaliza seus dados de moderação por 1.000 usuários ativos mensais sem declarar o denominador.

O Mastodon publica um número próprio para toda a rede, na página de servidores em joinmastodon.org, e rastreadores de terceiros que consultam as APIs de estatísticas das instâncias publicam os seus. Os números não batem. O TechCrunch relatou em fevereiro de 2026 que o próprio site do Mastodon indicava cerca de 785.000 ativos mensais, enquanto os rastreadores variavam de cerca de 750.000 a um milhão, dependendo de qual você consultasse. Esses rastreadores colocam as contas registradas em algo em torno de 10 milhões distribuídas por aproximadamente 10.000 servidores, embora os totais variem em um milhão ou mais entre rastreadores, conforme a forma como cada um lida com servidores que ficaram inativos.

Registros e ativos diferem em uma ordem de magnitude no Mastodon, e a proporção do Bluesky é desconhecida. Uma comparação que coloca os registros de uma rede contra os ativos de outra está comparando grandezas diferentes.

O Que Você Pode Construir com ActivityPub, Solid e Bluesky?

Todos os três protocolos são HTTP puro, e é por isso que um terminal já basta para inspecioná-los:

# ActivityPub: resolve a handle with WebFinger, then fetch the actor document
curl -s 'https://mastodon.social/.well-known/webfinger?resource=acct:Mastodon@mastodon.social'
curl -s -H 'Accept: application/activity+json' https://mastodon.social/users/Mastodon

# Solid: read an RDF resource from a pod as Turtle (replace with a real pod URL)
curl -s -H 'Accept: text/turtle' https://alice.example.org/profile/card

O WebFinger é a RFC 7033 e uma convenção do ecossistema Mastodon, não parte do ActivityPub em si. Servidores Solid devem servir recursos RDF como Turtle ou JSON-LD quando solicitado.

O projeto mais acessível é um custom feed do Bluesky. Um custom feed do Bluesky é um serviço HTTP que retorna uma lista ordenada de URIs de posts; a AppView busca e renderiza esses posts por conta própria, de modo que o serviço de feed nunca precisa armazenar ou servir o conteúdo dos posts. Duas rotas XRPC são obrigatórias, e o lexicon getFeedSkeleton define os parâmetros (feed, limit até 100, cursor) e o erro UnknownFeed:

// feedgen.mjs — run with: node feedgen.mjs
import { createServer } from 'node:http';

const SERVICE_DID = 'did:web:feeds.example.com';
const FEED_URI = 'at://did:plc:yourpublisherdid/app.bsky.feed.generator/weekend';

// A real generator fills this from a firehose consumer or a database.
const POSTS = [
  'at://did:plc:ragtjsm2j2vknwkz3zp4oxrd/app.bsky.feed.post/3jux6xlrdb42v',
  'at://did:plc:ragtjsm2j2vknwkz3zp4oxrd/app.bsky.feed.post/3jux7x2uvip2v',
];

const json = (res, status, body) => {
  res.writeHead(status, { 'content-type': 'application/json' });
  res.end(JSON.stringify(body));
};

createServer((req, res) => {
  const { pathname, searchParams } = new URL(req.url, 'http://localhost');

  if (pathname === '/xrpc/app.bsky.feed.describeFeedGenerator') {
    return json(res, 200, { did: SERVICE_DID, feeds: [{ uri: FEED_URI }] });
  }

  if (pathname === '/xrpc/app.bsky.feed.getFeedSkeleton') {
    if (searchParams.get('feed') !== FEED_URI) {
      return json(res, 400, { error: 'UnknownFeed', message: 'Feed not found' });
    }
    // Requests may carry a JWT signed by the user's key. A feed that is
    // identical for every user can ignore it, as this one does.
    const limit = Math.min(Number(searchParams.get('limit') ?? 50), 100);
    const start = Number(searchParams.get('cursor') ?? 0);
    const page = POSTS.slice(start, start + limit);
    const cursor = start + limit < POSTS.length ? String(start + limit) : undefined;
    return json(res, 200, { feed: page.map((post) => ({ post })), cursor });
  }

  json(res, 404, { error: 'NotFound' });
}).listen(3000);

O cursor é opaco para a AppView e inteiramente seu; um índice de posição basta para uma lista fixa, e o tutorial oficial recomenda um cursor composto de timestamp mais CID assim que os posts passarem a vir de um índice ao vivo. Para colocar em produção, você faz o deploy sobre HTTPS, publica um documento DID que aponta para o host (o starter kit configura isso como um did:web por padrão) e executa o script publishFeedGen.ts dele para criar o registro app.bsky.feed.generator no seu próprio repositório. A partir daí o feed aparece no app do Bluesky como qualquer outro.

Onde as Coisas Estão

Medido contra o teste de troca de provedor, o ActivityPub carrega seguidores mas não identidade, o AT Protocol carrega os três no papel enquanto a maior parte da rede ainda passa pelo relay e pela AppView de uma única empresa, e o Solid carrega tudo em princípio, sem um mercado de consumo que o leve adiante. Escolha o protocolo cujo modo de falha você consegue tolerar e então dedique um fim de semana ao gerador de feed acima: é o caminho mais curto entre ler sobre a web descentralizada e operar um pedaço dela.

Perguntas Frequentes

Usuários do Bluesky e do Mastodon podem seguir uns aos outros?

Não de forma nativa: ActivityPub e AT Protocol não interoperam, então follows entre redes passam por uma ponte. O Bridgy Fed, mantido pela organização sem fins lucrativos A New Social, é opt-in: um usuário do Bluesky segue @ap.brid.gy, e um usuário do fediverso segue @bsky.brid.gy@bsky.brid.gy. Contas com ponte aparecem como user.instance.ap.brid.gy no Bluesky e handle@bsky.brid.gy no fediverso. Apenas posts totalmente públicos são levados pela ponte, e posts do fediverso com mais de 300 caracteres são truncados no Bluesky.

Qual é a diferença entre did:plc e did:web no AT Protocol?

O AT Protocol suporta apenas dois métodos de DID. O did:plc, desenvolvido pela Bluesky Social PBC, registra identificadores no diretório PLC, suporta rotação e recuperação de chaves, e é o que o instalador oficial do PDS cria para contas novas. O did:web deriva o identificador de um hostname que você controla, permite apenas identificadores em nível de hostname sem caminhos, e não oferece recuperação caso você perca o domínio — por isso é adequado a serviços como geradores de feed.

Posso usar meu próprio domínio como handle no Bluesky sem hospedar um PDS?

Sim. Um handle é um hostname DNS vinculado bidirecionalmente ao seu DID, e esse vínculo é independente de qual PDS armazena seus dados. Publique o DID em um de dois lugares: um registro DNS TXT chamado _atproto.seudominio com o valor did= seguido do seu DID completo, ou uma resposta em texto puro em https://seudominio/.well-known/atproto-did. A especificação recomenda o método DNS para pessoas físicas; o método HTTPS é voltado a serviços de grande porte.

Se eu hospedar meu próprio Personal Data Server, ainda posso usar o app do Bluesky?

Sim. O PDS oficial é distribuído como imagem Docker para uma VPS com endereço IPv4 público, um registro DNS wildcard e as portas 80 e 443 abertas; o Bluesky recomenda 1 GB de RAM e 20 GB de armazenamento para 1 a 20 usuários. Faça login informando a URL do seu PDS no app. A configuração padrão aponta para a AppView, o relay e o diretório PLC do Bluesky, de modo que o PDS ainda depende de serviços operados pelo Bluesky acima da camada de dados.