Trabalho na Bluesky, então tenho um viés óbvio aqui. O foco desse post não é a empresa — é o protocolo, que é aberto e vai além dela; mesmo assim, transparência é importante.

Desde que entrei na Bluesky, percebi um padrão nas perguntas que pessoas próximas me faziam. A maioria não vinha de desconhecimento sobre a ideia de uma rede social descentralizada, mas tinham raízes em dois pontos específicos:

1. misturar o produto Bluesky com o protocolo por baixo dele, o AT Protocol (ou atproto, de forma sucinta);
2. pensar a abstração rede social descentralizada com conceitos de uma forma específica popularizada com pelo ActivityPub (conhecido pelas implementações do Mastodon e da ideia do fediverso).

Mas então o que é o protocolo?

A Bluesky é uma empresa que mantém uma rede social de mesmo nome, e essa mesma empresa também criou o atproto, o protocolo aberto sobre o qual essa rede é construída. A distinção importa.

De certa fiorma, a Bluesky está para o atproto assim como o Gmail está para o e-mail: um é produto de uma empresa, o outro é um protocolo aberto que qualquer pessoa pode implementar. Você pode usar o Gmail, o Tuta ou hospedar seu próprio servidor de e-mail — e todos se comunicam. No atproto a lógica é parecida, mas a arquitetura é diferente da esperada para que quem se familiarizou com o ActivityPub.

Vale ressaltar que própria Bluesky está trabalhando ativamente para que o protocolo não dependa dela. Dois exemplos concretos:

1. estão transferindo o controle do diretório de identidades (o PLC) para uma organização independente na Suíça;
2. estão submetendo o protocolo ao IETF para padronização formal.

E, como era de se esperar, o foco é ainda o mesmo: descentralizar a ideia de uma rede social, dar mais autonomia para as pessoas e para seus dados pessoais. Como? Vou falar um pouco disso respondendo perguntas comuns que tenho recebido ultimamente.

Posso hospedar minha própria instância?

Essa é a pergunta que mais ouço de quem vem do fediverso, onde é comum ter um servidor completo — você hospeda tudo, sua comunidade vive ali, e você se federa com outras instâncias.

No atproto as coisas não funcionam assim. O protocolo separa as responsabilidades em camadas:

• Personal Data Server (PDS): é onde seus dados ficam — posts, quem você segue, seu perfil, etc. Sempre que algo muda, o PDS publica para o mundo um evento via WebSocket; é assim que o resto da rede fica sabendo da foto de gatinho fofo que você acabou de compartilhar.
• Relay: fica escutando os WebSockets de todos os PDSs da rede e consolida tudo num único fluxo de eventos — a firehose — que qualquer serviço pode consumir. Lembram daqueles experimentos consumindo todos os tuítes em tempo real? Pois é, o atproto permite isso de forma nativa, no coração da sua definição, de forma muito mais transparente e impossível de qualquer um chegar e desativar.
• AppView: consome os eventos de um ou mais relays e entrega a experiência social — feeds, notificações, moderação, busca, etc. O aplicativo Bluesky é basicamente um AppView. Mas não é o único — esses dias mesmo a Blacksky, uma comunidade majoritariamente negra, abriu o código da AppView deles.

Então a pergunta certa não é posso ter minha instância?, mas o que eu quero controlar? Você pode cuidar, você mesmo, de uma ou mais dessas camadas, ou confiar em comunidades específicas para uma ou mais dessas camadas.

Quer só ter sua identidade com seu próprio domínio ou subdomínio como handle, servindo como uma espécie de verificação de que você é você, ou que trabalha em certa organização? Não precisa hospedar nada — basta apontar seu domínio ou o domínio da organização. É o que eu faço na minha conta @cuducos.me e como o Pikachu de Terno prova ao mundo que, sem sombra de dúvidas, é um membro honorário do glorioso Boteco do Tião: @pikachu.botecodotiao.com.br.

Quer controlar onde seus dados ficam? Hospedar um PDS é simples, há várias implementações de código aberto disponíveis, e roda até num Raspberry Pi. Ou, se não quer hospedar e lidar com o trabalho disso, pode delegar isso a uma comunidade na qual você confie, como a Blacksky ou diversas outras opções além dos PDS oferecidos pela Bluesky.

Quer uma experiência diferente, com outra moderação ou comunidade? Use ou crie um AppView diferente.

E o melhor: sua identidade é portável — e isso funciona de forma bem diferente do ActivityPub. No Mastodon, sua identidade está atrelada à instância: mudar de @[email protected] para @[email protected] é criar uma conta nova, sem nenhum vínculo com a anterior além da coincidência de ser a mesma pessoa. Seus posts anteriores ficam na instância antiga.

No atproto, o centro da sua identidade é o seu DID — um identificador único que não muda. Por exemplo, minha arroba é @cuducos.me, mas essa é uma identidade transitória. Meu DID é did:plc:3272gdrjsuikiff7qsgokgas — era esse quando eu usava @cuducos.bsky.social e continuou o mesmo quando passei a usar meu domínio.

Quem gerencia isso é o PLC. Você pode ver o meu registro aqui: ele diz qual é o meu PDS atual. Como eu sou dono do meu DID, posso atualizar esse registro para apontar para qualquer servidor que eu quiser — toda pessoa é dona do próprio DID; isso não é um privilégio ou nerdice minha. E o protocolo define claramente como mover todos os dados de um PDS para outro.

Posso participar sem dar meus dados para a Bluesky?

Sim. Como o atproto é aberto, outros grupos estão construindo sua própria infraestrutura — PDSs, relays e AppViews independentes da Bluesky:

• Blacksky: mencionada antes, já opera com moderação e algoritmos pensados para a própria comunidade; tem as três camadas — PDS, relay e AppView — próprios.
• Northsky: uma cooperativa construindo infraestrutura para comunidades marginalizadas, com foco especial na comunidade 2SLGBTQIA+ e dados hospedados fora dos EUA. A comunidade, majoritariamente canadense, já opera PDS próprio (mas ainda com lista de espera e convites), e planejam criar um AppView em breve.
• Eurosky: oferece PDS hospedado na União Europeia, com foco em soberania de dados para europeus. Eles deixam claro: não operam feeds nem recomendam conteúdo — é infraestrutura, não plataforma.

Fora isso, existem diversas pessoas hospedando seus próprios PDS. Esse projeto lista quase 3 mil PDS em mais de 50 países.

Todos esses projetos conversam entre si através do atproto — seus posts e conexões ficam acessíveis independente de qual infraestrutura você escolhe. Um AppView pode tecnicamente optar por não indexar dados de determinados PDSs, mas isso seria uma escolha ativa e explícita de fechar o acesso — não é o que o protocolo incentiva, mas é tecnicamente viável.

A Bluesky está desenhando suporte a dados com permissão — dados que circulam no protocolo apenas para um grupo selecionado de pessoas. A pessoa liderando esse projeto isso tem escrito publicamente sobre as decisões de design, como a escolha de não usar criptografia de ponta a ponta para a maioria dos casos, e a ideia de buckets como primitiva para espaços compartilhados com controle de acesso.

A Blacksky, por sua vez, não esperou — já implementou dados privados na própria rede deles: o conteúdo vai para o protocolo encriptado, e a chave fica no servidor deles. Para o resto da rede é só um monte de bytes sem significado algum.

É complicado hospedar meu próprio PDS?

Não. Há documentação, a implementação oficial e implementações prontas em diversas linguagens. Roda até num Raspberry Pi. E se você quiser ter seu próprio PDS sem cuidar da infraestrutura, existem empresas oferecendo PDS como serviço. Se você quiser começar assim, ótimo.

Se não quiser lidar com servidor nenhum, pode migrar sua conta para qualquer provedor que implemente o atproto — seja Blacksky, Eurosky, Northsky, ou outros — sem perder seguidores ou histórico. Normalmente as ferramentas dessas plataformas já automatizam a migração de dados e a atualização do seu registro no PLC. Simples assim!

Se você já iniciou sua atividade em outro PDS e agora quer ter seu próprio PDS, os passos são: subir seu próprio PDS, migrar os dados, e atualizar o registro no PLC. Um processo técnico mas todo padronizado pelo atproto, então existe ferramentas da comunidade para facilitar tudo.

Em qualquer um desses casos, feita a migração e atualização do PLC, quando alguém acessar um post seu, por qualquer cliente que seja, o AppView vai consultar o PLC — quase como um DNS — para saber onde está o seu servidor, seu PDS. E vai buscar o conteúdo lá, naquele servidor específico que você escolheu.

A promessa do atproto é que nenhuma empresa pode te trancar na plataforma — nem a própria Bluesky. Seus dados ficam no seu PDS. Se um AppView tomar decisões que você não gosta, te bloquear, por exemplo, você continua tendo acesso aos seus dados e pode mudar sem perder sua identidade, conexões ou histórico.

A arquitetura já está lá. E projetos como Blacksky, Northsky e Eurosky mostram que descentralização não é só teoria. E isso que nem falei das trocentas outras iniciativas possíveis com o atproto, como uma alternativa ao GitHub ou ao Google Reader, um visualizador de pacotes NPM ou mesmo a plataforma dos blog posts mencionados na oarte de dados com permissão! Sim, blogs construídos com atproto — mas isso é papo para um outro post.

O objetivo desse post não é convencer ninguém a migrar de plataforma nem comparar tecnologias. É oferecer um vocabulário diferente para pensar redes sociais descentralizadas — um que não dependa dos conceitos que o ActivityPub popularizou.

A ideia de que seus dados são seus, que o aplicativo que você usa é apenas uma janela para eles, que trocar de janela não significa perder o que você criou, que você pode levar tudo isso consigo ao mudar de servidor, e que indivíduos e comunidades têm cada um suas próprias possibilidades de controle e autonomia — é o que o atproto torna realidade. E quando você entende essa arquitetura, começa a ver possibilidades que talvez você ainda não tenha imaginado.

Se quiser se aprofundar, recomendo dois textos. Para quem tem perfil mais técnico, atproto for distributed systems engineers explica a arquitetura do protocolo em detalhes, conectando as decisões de design com problemas clássicos de sistemas distribuídos. Para uma introdução mais intuitiva, o texto do Dan Abramov, A Social Filesystem, parte de uma analogia simples — arquivos e sistemas de arquivos — e constrói uma boa intuição sobre o que significa ter uma rede social onde os dados pertencem às pessoas, não aos aplicativos.