- Expande o conceito de computação pessoal centrada em arquivos para a computação social, descrevendo uma estrutura em que todo o conteúdo criado pelo usuário pertence a ele, e não aos apps
- Com base no protocolo AT, apresenta o conceito de um sistema de arquivos social descentralizado que possibilita a interoperabilidade de dados entre apps
- Cada usuário tem sua própria pasta de tudo ou repositório (repository), onde posts, curtidas e follows são armazenados como arquivos (records) baseados em JSON
- Por meio de DID (Decentralized Identifier) e do esquema de URI
at://, mantém links permanentemente identificáveis mesmo com mudança de hospedagem ou troca de handle
- Essa estrutura forma um ecossistema social centrado em dados, e não em apps, permitindo que qualquer pessoa crie novos apps que operem sobre os dados existentes
O paradigma de arquivos e sua expansão social
- Arquivos existem originalmente em um espaço controlado pelo usuário, e não dentro de apps, e os apps atuam apenas como ferramentas para ler e escrever arquivos
- Formatos de arquivo abertos como
.svg permitem que vários apps compartilhem os mesmos dados
- Sob o princípio de que “o formato de arquivo é a API”, a interoperabilidade entre apps se torna possível
- Ao aplicar esse conceito a apps sociais, ações como posts, follows e curtidas também podem ser tratadas como arquivos
- Existe uma “pasta de tudo” que contém toda a atividade online do usuário
- Os apps refletem os dados dessa pasta, e a pasta atua como a única fonte da verdade (source of truth)
O protocolo AT e o sistema de arquivos social
- O protocolo AT é a tecnologia que implementa essa estrutura na prática, e Bluesky, Leaflet, Tangled, Semble e Wisp funcionam com base nele
- Os apps não possuem os dados do usuário; com o armazenamento separado de dados em nível de arquivo, novos apps podem reutilizar dados existentes
- As pastas de todos os usuários, juntas, formam um sistema de arquivos social descentralizado
Estrutura de records e collections
- Cada post é representado como um arquivo JSON (record) e não inclui informações do autor nem dados derivados, como número de curtidas
- Exemplo:
{ text: 'no', createdAt: '2008-09-15T17:25:00.000Z' }
- O nome do arquivo é gerado com uma chave de record baseada em timestamp (record key) para evitar colisões
- A estrutura do arquivo é definida por um schema chamado lexicon, e cada app pode projetar seu próprio lexicon
- Ex.:
com.twitter.post, fm.last.scrobble, io.letterboxd.review
- Mesmo para o mesmo conceito, apps diferentes podem ter lexicons diferentes, evitando conflitos com namespaces baseados em domínio
Validação e confiança
- Não existe Lexicon Police — nenhum app pode impor seus dados a outro app
- Os apps validam os dados na leitura (validate on read) e os ignoram se forem inválidos
- Ao mudar um lexicon, é obrigatório manter compatibilidade retroativa, e mudanças incompatíveis devem ser separadas em um novo lexicon
- Lexicons podem ser distribuídos publicamente, e a prova de propriedade do domínio pode ser feita via DNS
Links e identidade (Identity)
- Como curtidas e respostas criadas pelo usuário precisam referenciar outros records, é necessário um sistema de links permanentes
- Após várias tentativas, a identidade passou a ser estabelecida com DID (Decentralized Identifier)
- Um identificador como
did:plc:6wpkkitfdkgthatfvspcfmjo não pode ser alterado
- Cada DID é resolvido em um documento que contém as informações atuais de hospedagem, handle e chave pública
- A URI
at:// combina DID, collection e chave de record para fornecer links que não quebram mesmo com mudança de hospedagem
- Ex.:
at://did:plc:6wpkkitfdkgthatfvspcfmjo/com.twitter.post/34qye3wows2c5
Hiperlinks em JSON e representação de relações
- Cada curtida, repost e resposta tem uma estrutura de JSON com hiperlinks que referencia outro record
- Ex.: o campo
parent referencia a URI at:// de outro post
- Todas as informações da UI (autor, texto, número de curtidas etc.) podem ser calculadas a partir dessas conexões entre arquivos
Repositório (Repository) e fluxo de dados
- A pasta de tudo do usuário é chamada de repositório (repository) e é identificada por um DID
- Dentro dela, existem várias collections e records
- O repositório pode ser hospedado em qualquer lugar, e os links continuam válidos mesmo após mudança
- Os apps podem ler o repositório como um sistema de arquivos ou assiná-lo via stream (WebSocket) para sincronização em tempo real
- Cada commit é verificado com uma árvore de hash assinada (Merkle tree), evitando falsificação de dados
- Servidores de relay apenas retransmitem eventos, e a confiança é garantida por uma estrutura verificável
Explorando a Atmosphere e casos reais
- pdsls.dev funciona como um explorador do sistema de arquivos social, permitindo inserir um DID ou handle
- É possível consultar diretamente cada collection e record
- O app de exemplo Sidetrail reflete em tempo real as mudanças nos records do usuário, mostrando que os dados existem no repositório, e não no app
- A demo do teal.fm Relay visualiza o histórico de reprodução de músicas (scrobble) indexando records
fm.teal.alpha.feed.play, mesmo sem uma API real
- Com a ferramenta
lex-gql, é possível executar queries GraphQL baseadas em Lexicon
- No Bluesky, usuários podem publicar seus próprios algoritmos de feed customizados
- Ex.: o feed “For You” de
@spacecowboy17.bsky.social funciona de forma independente, permitindo que terceiros melhorem funcionalidades sobre dados compartilhados
Conclusão
- O sistema de arquivos social propõe uma estrutura de internet centrada em dados, e não em apps
- O usuário possui seu próprio repositório de dados, e os apps operam sobre ele de forma reativa
- O objetivo é migrar de “um app que faz tudo” para “um ecossistema em que tudo é possível”
1 comentários
Comentários do Hacker News
Os apps podem desaparecer, mas os arquivos permanecem
O texto do swyx enfatiza que o trabalho que dura no longo prazo acaba existindo na forma de arquivos/dados
Dados podem ser analisados sem permissão e continuam úteis mesmo quando parcialmente corrompidos, mas os incentivos econômicos ainda giram em torno do código
Quando surgem padrões que fazem o código aceitar e exportar dados, isso gera enorme valor para toda a civilização
Acho que um dos maiores pontos de alavancagem que temos é fazer o ecossistema de desenvolvedores induzir empresas como Google, Microsoft, OpenAI e Anthropic a participarem voluntariamente da padronização de dados
Mas os apps de hoje são sites dependentes de receita de anúncios, então não existe incentivo algum para operar dessa forma
Basta olhar para a Apple: muitas vezes padrões não conseguem mudar o mundo
Se o campo createdAt puder ter um valor arbitrário, então eu também poderia alterar registros retroativamente do jeito que quisesse, certo?
Fico curioso se existe alguma forma, por meio de assinatura (signing), de verificar o momento da criação e se houve alterações depois
POSSE e o AT Protocol podem ser entendidos como marketplaces interoperáveis
Como no Reddit ou Instagram, o conteúdo do usuário é o produto, a atenção é a moeda e a plataforma lucra com anúncios ou dados comportamentais
Mas essa estrutura não é inevitável.
Se o usuário tiver propriedade sobre seus dados sociais, o app passa a ser uma interface de leitura desses dados
Também estou aplicando um modelo parecido ao comércio — o vendedor hospeda sua própria lógica de pedidos e pagamentos, e o marketplace se integra diretamente à API do vendedor
Isso reduz as taxas da plataforma e devolve a propriedade a quem cria o valor
O texto era detalhado demais, a ponto de parecer excessivo para transmitir a ideia central
Ainda assim, a analogia é excelente. Se existisse um navegador de arquivos para PDS, daria para experimentar isso diretamente
O PDS do Bluesky é basicamente um sistema de arquivos público, e a replicação faz parte do projeto, como no Git
A replicação é impossível de controlar, mas também tem a vantagem de backup automático
No fim, tudo que você coloca num PDS fica como um registro permanente, então é preciso cuidado
Se for útil, mas longo, outras pessoas podem simplesmente aproveitar só as partes de que precisam
Na seção de demonstração no fim do texto, dá para ver um exemplo real de gerenciador de arquivos
A expressão “um mundo onde todo mundo vira scraper” é a essência da ideia
Acho que o conceito de “arquivo” já está ultrapassado
Se tudo for tratado como dados blob baseados em hash, muitos problemas desaparecem
O que o usuário quer não é um app, mas uma capacidade (capability)
Por exemplo, “a capacidade de assistir a vídeos de yoga” ou “a capacidade de compartilhar novidades com conhecidos”, e não o YouTube ou o Bluesky em si
Apps são apenas uma forma de agrupar essas capacidades
Precisamos de fluxos de trabalho personalizados, como pesquisar uma palavra num app de mensagens e compartilhar o resultado imediatamente dentro da conversa
Fui inspirado pelo PerKeep
Usei isso como metáfora para explicar a “relação muitos-para-muitos entre apps e formatos de arquivo”
Se você olhar a explicação da estrutura de repositório do ATProto, verá uma estrutura endereçada por conteúdo baseada em Merkle tree
O Lexicon não é 1:1 com apps, então o AT já está caminhando para uma era pós-app (post-app)
Acho que plataformas fechadas (walled gardens) são resultado da preferência dos consumidores
Quando a internet abriu tudo, as pessoas passaram a querer pequenos espaços centrados em culturas ou ideias específicas
IG e Snap são como esses chats de grupo mais segmentados
Para mim, é até melhor que minhas postagens do IG não sejam compartilhadas automaticamente no HN ou no Truth Social
Não consigo ver tão claramente o valor da portabilidade de dados. Cruzar plataformas com contextos diferentes me parece sem sentido
O Anisota que eu fiz foi projetado para oferecer suporte tanto aos arquivos do Bluesky quanto aos do Leaflet
Como exemplo, dá para ver a mesma postagem no Bluesky e no Anisota
E com o projeto Aturi, também ofereço links universais para conteúdo baseado em ATProto
No ATProto, se os apps usam o mesmo Lexicon, é possível uma migração completa de identidade e dados
As imagens originais estão no meu armazenamento local, e cada plataforma é apenas uma apresentação diferente
Não quero uma integração sem sentido entre plataformas
O AT apenas torna a interoperabilidade possível, não unifica tudo
Por exemplo, o Leaflet importa e exibe postagens do Bluesky para rastrear citações
Graças a essa estrutura, mesmo que você faça um fork do produto, ele continua totalmente compatível com a rede, o que incentiva a concorrência
Na prática, o Blacksky é um caso de fork do Bluesky com uma política de moderação diferente
Os textos do Dan são sempre interessantes. Você vai lendo e, em algum momento, percebe que ele era o autor
Sou cético quanto a um modelo de dados autodescritivo (self-describing data model)
A afirmação do ATProto de que “basta adicionar um Lexicon e surge um cliente” parece exagerada
Na prática, para criar uma UI você precisa entender o significado dos dados, e o Lexicon por si só não basta
No fim, não é tão diferente de ler a documentação e implementar por conta própria
Padronização é bom, mas isso não chega a ser um problema do nível de um banco de dados replicado globalmente
Ainda assim, valorizo bastante a tentativa de reduzir o lock-in
Só que o verdadeiro problema que o Twitter enfrentou foram fatores sociais, como conteúdo político e spam
Mas quando um serviço querido como o Bento desaparece, alguém provavelmente vai querer restaurar aqueles dados
Por exemplo, o Blento é uma alternativa ao Bento baseada em ATProto, e por ser open source qualquer pessoa pode recolocá-lo no ar
Esse tipo de estrutura representa um avanço significativo para garantir a persistência do conteúdo do usuário
Lendo “The Unix Programming Environment”, percebi como é possível fazer muita coisa só com ferramentas simples e arquivos de texto
Isso me fez imaginar como seria o Slack se tivesse sido construído num estilo UNIX centrado em arquivos
Quero voltar a sistemas simples e componíveis
Serialização legível por humanos é boa, mas ficar fazendo parsing e reformatando toda hora é doloroso
É interessante a ideia de novas plataformas sociais compartilharem protocolos comuns e formatos de dados em um ambiente distribuído e federado
Mas parece difícil convencer as plataformas comerciais já existentes
Se esses padrões se consolidarem, ferramentas de marketing para redes sociais poderão gerenciar várias redes com mais facilidade
Só que, na prática, ecossistemas fechados como Facebook, Instagram e TikTok ainda dominam