s@ : rede social descentralizada baseada em sites estáticos

 (satproto.org)
9 pontos por GN⁺ 2026-03-13 | 1 comentários | Compartilhar no WhatsApp
  • Protocolo de rede social descentralizada usando sites estáticos, com uma estrutura em que cada usuário possui e gerencia diretamente seus próprios dados
  • Todos os dados são armazenados em um repositório JSON criptografado, e o cliente no navegador agrega o feed e publica posts
  • Funciona por comunicação direta entre sites e navegadores de amigos, sem servidor nem relay
  • O nome de domínio do usuário é sua identidade, autenticada via HTTPS/TLS
  • Implementa uma rede social de soberania própria com uma estrutura simples, focada em interações baseadas em confiança entre indivíduos

Visão geral do protocolo sAT

  • s@ é um protocolo de rede social descentralizada baseado em sites estáticos no qual cada usuário armazena dados em seu próprio site
    • Todos os dados são armazenados como arquivos JSON criptografados, que o cliente no navegador lê para publicar posts e agregar o feed
    • Funciona sem servidor central ou relay, e os dados vão diretamente do site do usuário para o navegador do amigo
  • É necessário haver uma relação de follow mútuo para que a troca de posts seja possível, excluindo uma estrutura centrada em influenciadores
  • O protocolo não depende de um serviço de hospedagem específico, como GitHub Pages

Identidade

  • O nome de domínio do usuário funciona como identidade
  • HTTPS/TLS autentica que o proprietário do domínio publicou o conteúdo

Descoberta

  • O caminho https://{domain}/satellite/profile.json fornece a versão do protocolo e a chave pública 
    {
  "satproto_version": "0.1.0",
  "public_key": "<base64-encoded X25519 public key>"
}
  • Se for usado um caminho diferente do padrão /satellite/, é possível indicar a localização real do repositório com o arquivo .well-known/satproto.json

Modelo de criptografia

  • Todos os dados do usuário são armazenados em um repositório JSON criptografado, e só o usuário e seus seguidores podem descriptografá-los
  • Usa par de chaves X25519: a chave pública é publicada em profile.json, e a chave privada é armazenada no localStorage do navegador
  • Os dados dos posts são criptografados com XChaCha20-Poly1305, e a chave de conteúdo é criptografada para cada seguidor com crypto_box_seal do libsodium
  • O arquivo keys/_self.json contém a chave de conteúdo do usuário e os segredos de publicação, e só o próprio usuário pode descriptografá-lo

Rotação de chaves e unfollow

  • Ao deixar de seguir alguém, uma nova chave de conteúdo é gerada e todos os posts são criptografados novamente
  • Novos envelopes de chave são gerados para os seguidores restantes, e keys/_self.json é atualizado
  • O usuário que deixou de seguir não consegue mais descriptografar os posts

Fluxo de descriptografia

  • Quando um visitante acessa o site de um amigo, ele descriptografa keys/{follower-domain}.json com sua própria chave privada para obter a chave de conteúdo
  • Depois disso, busca posts/index.json e os posts individuais (posts/{id}.json.enc) para descriptografá-los

Estrutura de dados (Data Schema)

  • Cada post é armazenado como um arquivo criptografado individual, e posts/index.json lista os IDs dos posts do mais recente para o mais antigo
  • Exemplo de objeto de post: 
    {
  "id": "20260309T141500Z-a1b2",
  "author": "alice.com",
  "created_at": "2026-03-09T14:15:00Z",
  "text": "Hello, decentralized world!",
  "reply_to": null,
  "reply_to_author": null
}
  • O ID do post é composto por um timestamp UTC em ISO8601 e um hash aleatório de 4 caracteres

Lista de follows

  • Armazenada como JSON em texto plano no caminho https://{domain}/satellite/follows/index.json 
    { "follows": ["bob.example.com", "carol.example.com"] }
  • Não é criptografada, pois a relação de follow já fica exposta pelos envelopes de chave

Agregação do feed

  • O cliente lê a lista de follows e descriptografa os posts de cada seguido para montar um feed cronológico
  • Os posts são ordenados em ordem decrescente com base em created_at

Resposta

  • Uma resposta é um post com os campos reply_to e reply_to_author definidos
  • Respostas aninhadas não são suportadas, e só é possível responder diretamente a posts de nível superior
  • Se o post original não puder ser visto (por exemplo, por não seguir o autor), a resposta não será exibida

Publicação

  • Criar um novo post → criptografar com a chave de conteúdo → fazer upload para o site estático → atualizar posts/index.json
  • É possível usar o GitHub Contents API, entre outros, para o upload
  • Os segredos de publicação são armazenados de forma criptografada em keys/_self.json

Exemplo de estrutura de site estático

{domain}/satellite/
  profile.json              # chave pública e perfil
  posts/
    index.json              # lista de IDs dos posts
    {id}.json.enc           # post criptografado
  follows/
    index.json              # lista de follows
  keys/
    _self.json              # chave de conteúdo e credenciais
    {domain}.json           # chave de conteúdo por seguidor

FAQ

  • “É RSS + criptografia?” → Sim
  • “É uma versão do AT Protocol sem firehose?” → Sim
  • “É escalável?” → Não (“amizade também não escala”)
  • “O s significa slow/shitty?” → Sim
  • “Dá para fazer self-host?” → Sim, mas é necessário ativar CORS

Leituras relacionadas

1 comentários

 
GN⁺ 2026-03-13
Comentários do Hacker News

  • Sinto que este projeto sofre dos mesmos problemas que muitas redes sociais alternativas e auto-hospedadas enfrentam
    O design centrado em criptografia é legal, mas ao trocar de dispositivo fica difícil recuperar os follows dos amigos, e conceitos como pares de chaves X25519 também são difíceis para pessoas comuns entenderem
    Acho que uma estrutura baseada simplesmente em usuário e senha, em que o servidor cuida da criptografia, é mais realista
    Vejo esse tipo de abordagem como o caminho para algo que usuários não técnicos consigam usar e que possa substituir as big techs

    • Penso de forma parecida. Mas, se queremos um mundo sem intermediários, no fim vai ser necessária uma mudança cultural em que até usuários não técnicos cuidem um pouco mais dessas coisas por conta própria
    • Depois da configuração inicial, basta exportar a chave privada e guardá-la em um gerenciador de senhas ou algo do tipo. Não é complicado, a menos que você vá implementar o protocolo por conta própria
      Ainda assim, talvez eu precise fazer a configuração para familiares ou amigos. Mesmo assim, acho que eles gostariam bastante de ter seu próprio site
    • Segundo o FAQ no fim do texto, isso está mais para um experimento conceitual com alguns elementos do AT Protocol (BlueSky) removidos
      Na prática, dá para ver como uma ideia de integrar blogs estáticos ao BlueSky.
      Também daria para melhorar usando a identidade do BlueSky ou trazendo automaticamente as credenciais por meio de um plugin de gerador de site estático
    • Já tentei antes a ideia de usar e-mail como camada de transporte para uma rede social, mas não deu certo
      Veja este texto relacionado
    • Não sei se o objetivo é substituir as big techs. Se isso puder ser útil para pequenas comunidades, já considero um sucesso

  • Fiquei surpreso com a parte sobre armazenar a chave privada no localStorage do navegador
    Se as configurações do navegador forem resetadas ou ele for reinstalado, os dados somem, fazer backup é difícil e malware pode acessar isso com facilidade
    No fim, se a chave for perdida, o feed também desaparece para sempre, então há risco de os usuários abandonarem a plataforma

    • Concordo. Só de ver termos como “par de chaves X25519” sendo usados com naturalidade, parece que este projeto está mais para um experimento conceitual do que para algo com apelo de massa
    • Acho que isso pode ser resolvido com um botão tipo “exportar chave para um local seguro”. Com um código simples como URL.createObjectURL(localStorage.getItem(...)), já daria para induzir o salvamento em arquivo
    • Não dá para deixar passar uma solução boa o suficiente por buscar a perfeição. Só de adicionar download/upload da chave, a maior parte dos problemas já se resolve
      Claro, perder a chave significa perder o acesso, mas usuários de 2FA e carteiras de cripto também assumem responsabilidade parecida, então não é algo totalmente inviável

  • Sugeriram usar /.well-known/ em vez do caminho /satellite/
    A referência é o padrão Well-known URI

    • Responderam em tom de piada, chamando de “.poorly-known”
    • Isso fez lembrar que, no começo do AT Proto, usar o caminho raiz acabou criando uma vulnerabilidade de segurança
    • Houve quem argumentasse que .well-known é para o host inteiro, então não seria adequado para algo no nível do stream. Na visão dessa pessoa, é melhor manter vários diretórios separados

  • Acho que a sugestão de /.well-known/ merece consideração séria
    Já é um padrão registrado na IANA e amplamente usado, com arquivos de segurança e descoberta ficando ali
    Em vez de /satellite/satproto.json, colocá-lo em /.well-known/satproto.json evitaria conflitos e deixaria mais claro que se trata de um endpoint de protocolo

    • Mas houve a objeção de que .well-known é no nível do host, então não combina bem com casos em que se quer ter vários diretórios por conta

  • Protocolos de rede social não devem existir pela tecnologia em si, e sim gerar benefício direto para o usuário
    Como no BitTorrent, as pessoas precisam participar simplesmente porque precisam daquilo; só assim o efeito de rede aparece
    Acho mais realista partir da gestão de dados e da conveniência no compartilhamento

    • Pela minha experiência usando várias redes sociais descentralizadas, no fim as pessoas não voltam se não houver estímulo dopaminérgico
      Lemmy e Pixelfed tinham pouco conteúdo e pareciam “lugares onde nada acontece”
      O Signal também é assim: como serve só para mensagens, não existe motivo para ficar rolando a tela
      No fim, é preciso haver conteúdo e FOMO (medo de ficar de fora) para que as pessoas continuem voltando
    • Ainda assim, um bom desenho de protocolo importa. Se for complexo demais ou pouco preparado para o futuro, até uma boa ideia desaparece rápido

  • Para criar um mensageiro social realmente descentralizado e com E2EE, seria preciso uma estrutura em que cada servidor seja de fato hospedado de forma independente, como no Discord
    As contas seriam gerenciadas por um protocolo como o Nostr, e tudo rodaria sobre a Yggdrasil Network para reduzir a dependência de IPv4/6 e DNS
    Se o tráfego for encapsulado em HTTPS e a travessia de NAT for automatizada, qualquer pessoa poderia operar um servidor
    Só com uma estrutura assim seria possível escapar do controle das big techs e dos governos

    • Mas só tecnologia não basta. O grande público vai acabar indo para plataformas com mais capital de marketing
    • Eu acho melhor uma abordagem de rede distribuída baseada em cache, como BitTorrent e IPFS
      Mesmo que o servidor desapareça, os dados continuam nas pontas, e o navegador do usuário também poderia atuar como host
      Veja ephemeral-p2p-project
    • Esse tipo de estrutura já está sendo testado em geogram.radio
      Cada dispositivo atua como servidor, e o WebRTC implementa mensagens totalmente P2P
      Mesmo sem internet, também dá para trocar dados por conexão via rádio
    • Estou construindo algo parecido na Mikoto Platforms. Os “Spaces” podem existir em qualquer nó físico, e as DMs passam por múltiplos nós com roteamento E2EE

  • No passado já houve tentativas de redes sociais totalmente descentralizadas, como FOAF e Pingback

    • A versão moderna disso é o Webmention
      Recomendo a wiki do IndieWeb como uma boa referência para explorar esse tipo de tecnologia social baseada em sites pessoais
    • Outro exemplo que não deve ser esquecido é o XFN

  • Ao ler a descrição “o sAT Protocol é uma rede social descentralizada baseada em sites estáticos”, senti vontade de desenhar um gráfico de sobrancelhas subindo cada vez mais

    • Ainda assim, como o escopo é limitado, acho que faz sentido como sistema
      Só que o fato de o texto cifrado poder ser enumerado publicamente pode ser um risco na era dos computadores quânticos
    • Isso se parece com uma combinação de PGP + RSS. Cada feed é criptografado para que só pessoas específicas possam descriptografá-lo
      Funciona para redes pequenas, mas deve ser difícil escalar por causa dos problemas de distribuição e rotação de chaves
    • Entendi isso como um conceito em que “se transmite um banco de dados e o cliente constrói um site estático”
    • A parte “Key Rotation (Unfollow)” foi apresentada como piada em ASCII art

  • Do ponto de vista do usuário, senti falta de uma explicação mais clara sobre que tipo de serviço isso faz
    Está cheio de termos técnicos como fork, path, JSON e criptografia, mas não fica visível qual seria o cenário real de uso

    • Mesmo assim, tenho vários amigos interessados em tecnologia, então penso em experimentar isso com gente de “gosto por segurança paranoica”
      É um espaço que Mastodon ou Signal não atendem, então vale testar com isso

  • Acho realmente interessante ver esse tipo de experimento com redes descentralizadas
    Mesmo que estruturalmente haja muitos problemas, é divertido aprender novas combinações
    Mas ter que recriptografar e reconstruir o site inteiro sempre que alguém segue ou deixa de seguir é trabalhoso demais
    Além disso, uma estrutura em que você não vê comentários de quem não segue limita bastante a escalabilidade
    Ainda assim, é atraente como mistura de RSS, ActivityPub e site estático
    A tentativa de implementar controle de acesso dinâmico à lista de amigos com site estático é contraditória, mas interessante
    No fim, é uma estrutura que desperta amor e ódio ao mesmo tempo. Ainda assim, fico feliz e grato por ver esse tipo de tentativa