Onde fica o at://

• O AT Protocol é o protocolo que serve de base para redes sociais descentralizadas, e todos os dados são identificados por um URI at://
• O URI at:// define o criador dos dados (usuário) como autoridade, e o local onde esses dados estão realmente hospedados precisa ser descoberto separadamente
• O processo de resolução do URI ocorre na seguinte ordem: converter o handle em uma identidade (DID), verificar o servidor de hospedagem consultando o documento DID e então solicitar os dados JSON nesse servidor
• Há suporte a dois tipos de DID (did:web, did:plc), cada um com vantagens, desvantagens e formas de preservação de dados diferentes
• Essa abordagem enfatiza que a propriedade dos dados pertence ao usuário e garante persistência que mantém o vínculo mesmo que o handle e a hospedagem mudem

---

AT Protocol, URI at:// e o processo de resolução da identidade dos dados sociais

# Estrutura básica do AT Protocol e do URI at://

• O AT Protocol faz com que vários servidores distribuídos se comuniquem de acordo com um padrão específico, e esse conjunto como um todo é chamado de "atmosphere"
• Cada dado dentro da atmosphere recebe um URI exclusivo iniciado por at://, e esse URI funciona como uma espécie de link para dados JSON
• Diferentemente da estrutura tradicional de URI, no AT Protocol o criador dos dados (usuário) é definido como a autoridade do URI
  • Por exemplo, em at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z, ruuuuu.de indica quem é o proprietário daqueles dados
• O servidor físico onde os dados estão realmente hospedados não aparece diretamente no URI, e é necessário um processo adicional de resolução para encontrá-lo

# As três etapas da resolução de um URI at://

• São necessárias três etapas para mapear um URI at:// para os dados reais (JSON)
  1. Converter o handle (ruuuuu.de etc.) em uma identidade (DID: Decentralized Identifier)
     • O handle é um apelido para identificar o usuário e pode mudar
     • Por isso, ele precisa ser convertido em um DID, que é um ID global imutável
     • Formas de conversão:
       • Consultar o registro DNS TXT em _atproto.<handle> → verificar o valor did=...
       • Ou acessar https://<handle>/.well-known/atproto-did
  2. Verificar as informações de hospedagem dos dados consultando o documento DID (DID Document)
     • O documento DID inclui informações como a chave pública daquela identidade e o endpoint de serviço (servidor)
     • No caso de did:web:~, a abordagem é baseada em domínio (https://domínio/.well-known/did.json)
     • No caso de did:plc:~, a consulta é feita no diretório PLC (https://plc.directory/DID)
     • O endpoint de serviço (serviceEndpoint) é o servidor real de hospedagem dos dados
  3. Solicitar os dados JSON pela API do servidor de hospedagem
     • Solicitar os dados passando cada parte do at:// como parâmetro para o endpoint com.atproto.repo.getRecord
     • O JSON retornado corresponde aos dados reais mapeados para aquele URI at://

# Explicando o processo de resolução com um exemplo

• Exemplo: at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z
  • Etapa 1: ruuuuu.de → did:web:iam.ruuuuu.de (confirmado por DNS TXT record ou .well-known)
  • Etapa 2: consultar o DID Document em https://iam.ruuuuu.de/.well-known/did.json → serviceEndpoint é https://blacksky.app
  • Etapa 3: fazer uma requisição para https://blacksky.app/xrpc/com.atproto.repo.getRecord?... → retorno do JSON real

    {
      "uri": "at://did:web:iam.ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z",
      "cid": "...",
      "value": {
        "text": "posting from did:web, like a boss",
        "$type": "app.bsky.feed.post",
        ...
      }
    }
    

• Mesmo que o handle mude, se for usado um URI at:// baseado em DID (permalink), a ligação entre conta e dados continua preservada

# Formas de DID: diferença entre did:web e did:plc

• did:web:
  • Você pode gerenciar e autenticar seu próprio domínio
  • Se perder o controle sobre o domínio, pode acabar perdendo toda a identidade
• did:plc:
  • O PLC (Public Ledger of Credentials) é o responsável pela operação da identidade
  • Não está vinculado a um domínio, mas pode haver controle limitado, como a possibilidade de o operador do PLC recusar atualizações
  • Todo o histórico de mudanças pode ser verificado e rastreado por hash

# Separação entre identidade, hospedagem e dados, e sua persistência

• O at:// separa identidade e hospedagem dos dados, permitindo portabilidade dos dados do usuário e a criação de links permanentes
• O handle (apelido) pode ser alterado a qualquer momento, e o servidor de hospedagem também pode ser migrado da mesma forma
• O DID (identidade) é imutável, e um URI at:// baseado nele pode ser usado como permalink persistente
• O DID Document contém prova de posse do handle, chaves para verificação de assinatura e informações de hospedagem, garantindo confiança e flexibilidade

# Aplicações reais e observações para desenvolvimento

• Na prática, a maioria dos apps baseados em AT recebe dados por push via WebSocket etc. e os agrega em um banco de dados interno
• Ainda assim, entender como resolver um URI at:// é essencial para compreender as características da rede e a portabilidade dos dados
• O sistema at:// fornece uma abstração de rede social sobre HTTP, DNS e JSON, implementando tecnicamente o princípio de que a propriedade dos dados pertence ao usuário

# Conclusão

• O AT Protocol e o URI at:// representam uma evolução técnica na identidade, conectividade e persistência dos dados sociais
• Desenvolvedores precisam dominar o fluxo de trabalho central, como resolução de handles, uso de DID, estrutura de documentos DID e formas de solicitar os dados reais
• Graças a essa estrutura, é possível obter flexibilidade e propriedade sobre o próprio conteúdo, identidade e local de hospedagem

[GN⁺]

Comentários do Hacker News

• Entrei no bsky inspirado por alguns posts recentes sobre ATProto, mas tudo o que vejo é um fluxo interminável de política dos EUA. Mesmo clicando repetidamente em "mostrar menos disso", quase não faz diferença. Fico me perguntando se essa é a essência da plataforma; para a minha saúde mental, é bem ruim ter de ficar vendo só opiniões previsíveis sobre discussões estranhas do exterior.

  • Em contas novas, o feed "Discover" não é muito bom. Vai melhorando aos poucos conforme você acumula curtidas e follows, mas ainda assim não dá para dizer que é excelente. Pessoalmente, recomendo o feed "For You"; ele incorpora curtidas rapidamente e empurra menos conteúdo aleatório. O feed "Dev Trending" também é bem bom: For You Feed, Dev Trending
  • O que eu fiz foi encontrar algumas contas razoáveis para seguir e esconder completamente a aba "Discovery". Depois disso, fui expandindo naturalmente a minha lista de follows vendo as interações entre as pessoas de quem eu seguia/que me seguiam. Outra opção é encontrar contas em blogs ou sites e segui-las. Na minha opinião, é assim que isso funciona como rede social de verdade, e receber conteúdo recomendado automaticamente à força é ruim.
  • Felizmente, o bsky tem um feed não algorítmico que mostra apenas posts das pessoas que você segue. Acho que esse é o único jeito de preservar a saúde mental.
  • Usei o bsky por mais de um ano, mas a maior parte do conteúdo era política dos EUA. Como europeu, para mim isso parecia só ruído, então voltei para o Mastodon. Para seguir gente de tecnologia, o Mastodon funcionou muito melhor. Recebo todas as notícias por RSS no feedly. Hoje nem sei por que o Bluesky seria necessário; parece só uma versão de esquerda do Twitter. A tecnologia me pareceu interessante como uma evolução do Nostr, mas só isso.
  • Recomendo entrar em Configurações e desativar Contents and Media > Your Interests > News and Politics. Se você quiser ver notícias e conteúdo político de outros países que não os EUA, não sei de nenhum jeito específico.

• Ainda não sei se esse projeto realmente resolve de forma significativa os problemas de identidade e posse de dados. Em termos de identidade, no fim das contas é só usar o próprio domínio ou o domínio de outra pessoa (Bluesky etc.). Como a maioria das pessoas não tem domínio, a identidade delas acaba ficando com terceiros. Com os dados é a mesma coisa: se a conta for bloqueada no Bluesky ou em outro servidor, o repositório também é fechado e você perde até a chance de mover seus dados para outro lugar. Isso é igual ao e-mail: se você não tem o próprio domínio e servidor, na prática não controla nada.

  • No AT, os dados pertencem ao DID (Decentralized Identifier, Identificador Descentralizado), não ao handle nem à hospedagem. No meu texto eu explico isso em detalhe. Se você perder o domínio do seu "handle", o que acontece é só que o handle é invalidado e o app passa a mostrar "invalid handle" no lugar do nome de usuário. Os posts, seguidores e outros dados continuam lá, porque podem ser consultados pelo DID. O handle é só um apelido. Também dá para trocá-lo pelo recurso de "alterar handle" no app. A hospedagem é parecida: com alguns obstáculos, se você tiver backup do repositório, pode mover para outro lugar. Dá até para automatizar o backup, e já existem apps de terceiros que fazem isso automaticamente. O app oficial do Bluesky também permite exportar o repositório. Quando o provedor de hospedagem coopera, existem casos como o PDSMover. E mesmo se ele não cooperar, ainda é possível, como mostra adversarial pds migration. Hoje isso exige conhecimento técnico, mas espero que um dia esse processo fique simples. Quando você sobe o repositório em um novo host, tudo volta com a mesma identidade de antes, incluindo posts, seguidores etc., sem diferença perceptível. Isso é bem diferente de e-mail. Ainda é meio difícil agora, mas espero que fique muito mais fácil conforme o ecossistema AT evoluir.
  • Mesmo tendo um domínio, você pode deixar de tê-lo algum dia. Diferentemente de um servidor, o domínio depende de um registrador, então me parece mais vulnerável. Por isso escolhi um registrador que opera sob a legislação do meu país; assim, se houver um problema, tenho um pouco mais de esperança de conseguir alguma recuperação.
  • A maioria dos usuários sem domínio está sempre exposta ao risco que surge quando o provedor de hospedagem vira um "inimigo" — por exemplo, num bloqueio repentino de conta. Uma defesa completa só seria possível possuindo diretamente um domínio em um TLD neutro e roteando o tráfego por DNS. Ainda assim, dentro dessa realidade em que quase ninguém vai usar o próprio domínio, o projeto representa progresso ao adicionar alguma flexibilidade e proteção em comparação com o Big Social atual (Facebook, X, Instagram etc.), onde os dados ficam presos para sempre. O Bluesky parece se interessar por isso justamente porque, nesse modelo, você pode manter o mesmo handle e mudar apenas a hospedagem dos dados. Acho que a indústria não alcança a perfeição de uma vez; ela avança melhorando gradualmente problemas práticos.
  • Acho que a melhor forma de provar identidade é possuir a chave privada. Em termos de hospedagem, BitTorrent talvez seja o mais robusto. Também daria para considerar armazenar o conteúdo em um repositório git, assinar os commits e distribuir por torrent. Para avisos de atualização, pensei em NNTP ou RSS. O problema seria a discoverability e a ausência de interação, como comentários.
  • Pelo menos no e-mail você pode levar suas chaves PGP/SMIME para outro lugar; fico pensando se ATproto não é um conceito parecido.

• As explicações do Dan são sempre excelentes, e isso é oportuno com a notícia recente de que o Bluesky vai transferir a operação do PLC. Nosso time também escolheu o mesmo sistema DID na fair.pm para distribuição descentralizada de plugins do WordPress (seria algo como gerenciamento de pacotes no estilo App Store). O pessoal do Bluesky — especialmente o Bryan — ajudou bastante, e conseguimos até suporte a chaves Ed25519 para poder usar libsodium. Nosso protocolo está sendo projetado sobre DID e a moderação empilhável do Bluesky, mas não usa atproto diretamente. O importante é que DID é um padrão da W3C, então o PLC não fica preso ao atproto.

  • Fiquei curioso para saber quem é "nós" e, se isso for uma tentativa de resolver tecnicamente o drama do WordPress, gostaria de ouvir mais detalhes.
  • Você disse que o PLC não depende do atproto, mas o PLC (o método did) no fim não fica amarrado ao bluesky ou a alguma autoridade central? Se é assim tão centralizado, por que chamá-lo de DID? O did:plc não é portátil. Por que não escrever isso como did:web e adicionar um comportamento tipo PLC? Por que não fazer o method-specific-id baseado em hash de chave pública, por exemplo, para permitir portabilidade? E por que não seguir uma abordagem descentralizada tipo DHT, como did:pkarr? O PLC no fim parece apenas mais um sistema centralizado.

• Para localizar um at://, é preciso enviar uma requisição GET para plc.directory, e é aí que o sistema parece virar um modelo 100% centralizado. Eu gostaria que pelo menos fosse possível separar vários diretórios confiáveis do protocolo, como acontece com root DNS ou CA.

  • Se quiser fazer isso individualmente, também é possível usar did:web:fqdn; isso também é explicado no texto.

• Todo servidor que armazena links at:// no fim parece precisar passar por DNS/HTTPS para encontrar a representação formal (permalink). Se o DNSSEC não estiver funcionando direito, toda essa estrutura parece meio frágil. Ainda não pensei profundamente sobre isso, mas a preocupação imediata que me vem à cabeça é algo como envenenamento de DNS, que permitiria a um atacante publicar posts em meu nome (já que a chave pública está incluída no DID obtido via DNS).

  • Envenenamento de DNS pode parecer uma preocupação, mas na prática nem sempre é assim. O normal em at:// é colocar o DID no campo authority, então, se você fizer a consulta por DID em vez de handle, no fim depende de HTTPS e da web PKI. Mesmo começando pelo handle, ainda se passa por web PKI e por um registro TXT. A recomendação é resolver handles no lado do servidor e, se precisar fazer isso diretamente, consultar um provedor de DoH (DNS sobre HTTPS) confiável. Não é perfeito, mas reduz bastante a superfície de ataque. Claro que DNSSEC é a solução para esse problema, mas já tivemos vários problemas operacionais com DNSSEC em redes reais. Por exemplo, senadores dos EUA usam o domínio senate.gov para verificar identidade, e recentemente uma configuração quebrada de DNSSEC fez com que dezenas deles aparecessem como "invalid handle" no Bluesky. Por experiências decepcionantes assim, neste momento não estamos forçando DNSSEC com tanta ênfase. Se algum outro protocolo grande conseguir impor DNSSEC com sucesso, valeria reconsiderar.
  • Para um atacante publicar se passando por você, ele necessariamente precisaria da private key. O registro DNS apenas informa de onde buscar o documento DID, e esse documento DID precisa ser validado de volta pelo DNS. Há lógica de verificação nesse processo. O DNSSEC reduz o risco de adulteração dos registros DNS, mas a ausência de DNSSEC não torna possível que qualquer pessoa passe a publicar em seu nome; os servidores rejeitariam isso.
  • Essa parte é um pouco difícil, mas o DNS TXT method também declara explicitamente "DNSSEC not required". De todo modo, o DNS só faz a conversão Handle->DID, e a validação é um processo bidirecional via DID->Handle.

• O texto traz poucas informações sobre as chaves usadas no histórico de mudanças do DID. Por exemplo, se eu fosse foobar.bsky.social, não lembro de ter enviado uma chave eu mesmo nem de ter recebido instruções para baixá-la. Quero entender exatamente onde essa chave fica, quem a possui e como/quando ela é usada. E, se o DID está no plc.directory, qual é o mecanismo que impede o operador desse site de simplesmente sobrescrever meu DID arbitrariamente e roubar minha identidade?

• O conceito de at:// é interessante, mas também me preocupo com problemas que podem surgir em um sistema realmente baseado em posse de dados. Por exemplo, como o usuário tem os dados, ele pode alterar ou apagar o conteúdo quando quiser. Se alguém escrever algo aceitável no começo e depois mudar maliciosamente, um serviço novo talvez não saiba disso, mesmo que outro tenha guardado o hash antigo para detectar alterações. Também parece difícil rastrear coisas como upvotes; se cada um armazenar tudo como objetos próprios, fica complicado descobrir quem deu upvote. E nada parece impedir alguém de criar contas falsas e ficar promovendo os próprios posts. Por fim, se houver um número enorme de contas vindas de várias plataformas, não seria impossível moderar spam ou atividade maliciosa? Com a premissa de que cada conta gerencia seus próprios dados, não vejo claramente como o desenho do sistema fecha em termos de transparência, responsabilização, moderação e bloqueio de spam.

  • O gerenciamento de mudanças (history) pode ser publicado junto. Você pode incluir nas estruturas de dados (json) toda a informação que quiser, então é possível descrever posts antigos em cadeia, como uma linked list contínua por at://. O DID explica bem a questão da moderação de identidade, isto é, fornece base suficiente para saber quem é a pessoa, bloqueá-la ou fazer algum julgamento sobre ela. O ponto é que isso não é blockchain, e sim um modelo centrado no dono dos dados, que pode compartilhá-los quando quiser. É uma estrutura atraente, desde que ninguém esteja tentando sabotar tudo de forma maliciosa. Como fica claro "quais dados dessa pessoa estão onde", quem não se importa com esse tipo de transparência simplesmente não precisa usar.
  • Para evitar alterações maliciosas no conteúdo original, existe o strongRef, que é um permalink real baseado em hash. O Dan não entra em detalhes sobre isso no texto, mas se você guardar o strongRef consegue detectar rapidamente se o conteúdo de um post antigo mudou. Um dos motivos para o Bluesky não ter implementado edição é justamente o risco de alterações maliciosas. (Referência: resumo do experimento de permalink, experimento de histórico de edição de records). Rastrear upvotes é mais ou menos viável coletando os dados da rede e usando algo como roaring bitmap (exemplo com roaring-bitmaps). Quanto à moderação, existe a stackable moderation, que é muito mais legal do que os sistemas existentes. Também há discussões sobre transformar labeler/feedgen em um DAG, com composição de regras baseada em operações de conjunto. Já a adulteração de dados pode ser detectada pelos hashes CID de cada item, e o rastreamento de histórico também é tecnicamente possível.

• Isso me lembra vários protocolos cripto que falam de descentralização, mas acabam presos a uma plataforma no mundo real.

  • Ainda está no começo, mas tangled.org (parecido com GitHub), leaflet.pub (parecido com Medium) etc. já são usados ativamente. Com ferramentas que automatizam a indexação da rede (slices.network), a barreira para criar novos apps continua caindo, então devem surgir mais apps. O texto explica como isso funciona. O importante é que, para usuários "normais", esse tipo de tecnologia não importa muito. A maioria dos usuários do Bluesky é basicamente indiferente — ou até hostil — à ideia de "descentralização". Mas, como essa estrutura descentralizada não aparece diretamente na superfície do produto (como na navegação web em geral), esse tipo de adoção parece viável. No fim, o usuário só quer que "funcione".
  • Isso também me lembra a história do Git e do GitHub (ficaram um pouco mais distribuídos e flexíveis com o tempo, à medida que ganharam recursos).

• Há uma dúvida estrutural do tipo "como encontrar o JSON a partir de um URI at://". Mesmo lendo a documentação, eu não consigo sentir intuitivamente por que seria necessário "aquele JSON"; pessoalmente, esse modelo não me agrada.

  • Desculpe se a introdução ficou brusca. O protocolo at:// permite incorporar e exportar livremente dados entre apps, compartilhar identidade de usuário, e possibilitar auto-hospedagem ou migração de conteúdo. Ele fornece URIs permanentes que não ficam presas a handles/servidores. O funcionamento técnico é explicado ao longo do texto. Como exemplo, leaflet.pub e bsky.app agregam dados da mesma rede pública, então conseguem mostrar e integrar facilmente os dados uma da outra sem precisar de APIs separadas (post de demonstração).
  • Para facilitar a intuição, dá para comparar com a pergunta "como encontrar HTML a partir de um URI https://?";. É uma simplificação excessiva, mas funciona para explicar a alguém que está aprendendo DNS, HTTP e TLS pela primeira vez.

• Estou curioso se o protocolo funciona como uma espécie de grande tópico público de Kafka. Por exemplo, ao criar um novo webapp, em vez de armazenar os dados diretamente, cada usuário salvaria seus dados no próprio espaço, e o app teria um listener para escutar isso, contando que o protocolo garanta a propagação dos dados para o app ouvir e armazenar em cache. Conceitualmente isso é fascinante, mas também me pergunto se conceitos do Kafka, como offsets para não perder atualizações e partições para escalar, se aplicam aqui.

  • Sim, o firehose praticamente cumpre esse papel. Qualquer um pode assinar ou até operar o próprio firehose. Veja ATProto para engenheiros de sistemas distribuídos. O firehose e o jetstream têm cursores, então mesmo quem conecta depois consegue receber atualizações até chegar aos dados mais recentes. O período de cobertura varia conforme a instância, entre 1 e 72 horas. Se você precisar do histórico completo, dá para complementar com backfill.