Estudo de caso Mastodon: como servidores independentes formaram uma rede social

O Mastodon costuma ser apresentado como uma alternativa ao Twitter, mas seu caso mais relevante está na arquitetura. Em vez de concentrar todas as contas, publicações e regras em um único serviço, o projeto oferece software para que organizações ou comunidades operem servidores próprios. Esses servidores, chamados de instâncias, trocam atividades entre si e formam uma rede compartilhada.

O projeto começou em 2016, criado por Eugen Rochko, e teve lançamento público em outubro daquele ano. O código é distribuído sob a licença AGPLv3. Isso permite estudar, modificar e hospedar o servidor, com a obrigação de disponibilizar o código correspondente quando uma versão modificada é oferecida como serviço. A organização oficial afirma que o Mastodon é desenvolvido como iniciativa sem fins lucrativos e que iniciou, em 2025, a transição para uma fundação com governança comunitária.

A decisão central foi separar software e rede

Um servidor Mastodon guarda as contas de seus membros, aplica regras locais e oferece a interface de publicação. Ele não precisa pedir autorização ao projeto principal para existir. Ao mesmo tempo, seus usuários podem seguir pessoas de outros servidores, de maneira semelhante à comunicação entre provedores de e-mail diferentes.

Essa separação evita que “Mastodon” seja sinônimo de um único site. O projeto mantém servidores grandes, como mastodon.social, mas eles são apenas participantes da federação. Uma universidade, coletivo ou empresa pode operar outro domínio com política própria. Se o projeto central desaparecer, instalações existentes não são desligadas automaticamente; se um servidor individual fechar, porém, as contas hospedadas nele continuam expostas a essa decisão local.

O desenho repete uma lição vista em outras infraestruturas comunitárias. Assim como o OpenStreetMap separou sua base de dados dos muitos mapas e serviços construídos sobre ela, o Mastodon separa o software de servidor da rede social que emerge da interoperabilidade.

ActivityPub funciona como a camada comum

A federação depende principalmente do ActivityPub, protocolo baseado em ActivityStreams 2.0 e JSON-LD. O padrão define uma API entre cliente e servidor e outra entre servidores. Na segunda, cada conta é representada como um ator com caixas de entrada e saída. Ações como criar uma publicação, seguir alguém, curtir ou compartilhar são enviadas entre endereços identificados por URLs.

O Mastodon já existia quando o ActivityPub se tornou Recomendação do W3C, em 23 de janeiro de 2018. A adoção de um padrão externo ao próprio projeto ampliou a consequência da arquitetura: a outra ponta não precisa executar Mastodon. Qualquer software compatível pode participar do mesmo grafo social, ainda que recursos específicos precisem de extensões ou adaptações.

Essa interoperabilidade não significa que todos os produtos se comportem de forma idêntica. A documentação do Mastodon lista extensões para migração de contas, denúncias, enquetes, conteúdo sensível e controles de citações. Um servidor pode reconhecer apenas parte dessas capacidades. Protocolos comuns criam uma língua básica; não transformam implementações diferentes no mesmo aplicativo.

A moderação deixa de ser uma política universal

Em uma plataforma centralizada, a empresa publica uma política geral e executa as sanções. No Mastodon, administradores podem moderar membros locais e também limitar ou suspender domínios inteiros. Uma comunidade pode recusar interação com outra sem retirar o restante da rede do ar.

Um estudo preliminar publicado no arXiv em junho de 2026 analisou um ano de relações entre instâncias e decisões diárias de bloqueio. Os autores encontraram estabilidade estrutural apesar da atividade contínua de moderação e concluíram que bloqueios descentralizados podem isolar domínios considerados incompatíveis sem um controlador único. Como o trabalho é um preprint, seus resultados não devem ser tratados como consenso definitivo. O mesmo estudo também observou efeitos de câmara de eco, mostrando que autonomia local pode restringir a circulação de informação.

O que o caso Mastodon demonstra

O êxito técnico do projeto não está em eliminar administração, custo ou conflito. Cada servidor ainda precisa de hospedagem, atualizações, proteção contra abuso, backups e pessoas responsáveis. A descentralização transfere essas funções para muitos operadores e permite que comunidades escolham com quem se conectar.

O resultado é uma troca clara. Não existe um proprietário capaz de alterar toda a rede com uma única decisão, mas também não existe uma equipe única capaz de resolver todos os problemas. O Mastodon mostra que uma rede social pode ser organizada como infraestrutura interoperável. Sua durabilidade depende menos de um aplicativo específico e mais da combinação entre código aberto, protocolo público e instituições locais dispostas a manter o sistema.