Nostr

Conceito

Nostr = Notes and Other Stuff Transmitted by Relays. Protocolo aberto criado pelo fiatjaf (pseudônimo) por volta de 2020, com tração a partir de 2022–2023.

A tese é quase provocadora de tão simples:

Para publicar informação de forma resistente à censura, você não precisa de consenso — precisa de assinatura.

Todo o resto do protocolo é consequência disso. Não há blockchain, não há token, não há consenso, não há estado global. Há duas peças, e só.

Peça 1 — identidade é um par de chaves

Não existe cadastro. Não existe senha. Não existe servidor que "tem" a sua conta, porque não existe conta. Existe uma chave secp256k1 (a mesma curva do Bitcoin):

Consequência imediata e enorme: sua identidade não contém nome de servidor. Compare com federação, onde você é @user@servidor.social — ver 2. Nostr vs ActivityPub.

Peça 2 — tudo é um evento assinado

Post, perfil, lista de seguidos, reação, mensagem privada: tudo é o mesmo objeto JSON, mudando o campo kind. Ver 2. Eventos e Chaves para o detalhe.

E o servidor?

O servidor se chama relay e faz exatamente três coisas: aceita evento, guarda evento, entrega evento por filtro. Nada mais. Relays não conversam entre si e não decidem o que é verdade — quem faz o trabalho de espalhar e juntar é o cliente. Ver 3. Relays e Fan-out.

O truque arquitetural

O que o Nostr fez, resumido em uma frase:

Manteve a infraestrutura cliente-servidor (que funciona, atravessa NAT, é barata de hospedar) e tirou a identidade de dentro do servidor, movendo-a para a chave.

Isso torna o relay descartável e intercambiável. Se um relay te bane, some ou vira lixo, você continua existindo nos outros — mesma chave, mesmos seguidores, mesmo histórico. Não há "migração de servidor", porque nunca houve nada preso ao servidor.

Esse é um padrão de projeto reaproveitável muito além do Nostr: quando um problema é difícil demais, às vezes a saída é mover a fronteira do sistema em vez de resolver o problema. Migração de instância não foi resolvida — foi deixada de existir.

Trade-offs

O que se ganha:

• Resistência à censura sem consenso — barato, rápido, sem token, sem mineração
• Portabilidade total da identidade — a chave é sua, o relay é detalhe de infraestrutura
• Simplicidade brutal — o protocolo básico (NIP-01) cabe em poucas páginas; dá para escrever um relay funcional num fim de semana
• Interoperabilidade real — como tudo é evento assinado, qualquer cliente lê os dados de qualquer outro

O que se perde — e aqui é onde o estudo fica interessante:

• Não há deleção — só pedido educado de deleção
• Não há ordem global — o created_at é auto-declarado pelo autor
• Não há contagem confiável — "quantos seguidores?" não tem resposta, só estimativa
• Não há recuperação de conta — vazou a nsec, acabou
• Disponibilidade do dado é responsabilidade sua — seus posts vivem só nos relays que resolveram guardá-los

Ver 5. Limites do Nostr para o detalhe de cada um. Nenhum desses é bug a ser corrigido em versão futura: todos são o preço estrutural de não ter consenso nem operador.

Exemplo prático

Como se parece uma sessão real, do zero:

1. Você gera um par de chaves localmente. Não avisa ninguém. Já existe.
2. Publica um evento kind: 0 (perfil: nome, foto, bio) em 5 relays.
3. Publica um evento kind: 1 (um post) nesses mesmos 5 relays.
4. Alguém abre um cliente, pede aos relays dele os eventos kind: 1 dos autores que segue, e o seu post aparece — desde que ao menos um relay em comum tenha guardado.

Repare no que não aconteceu: nenhum cadastro, nenhuma confirmação de e-mail, nenhuma aprovação, nenhuma transação paga, nenhuma espera por bloco.

E repare no ponto frágil, que é o mesmo passo 4: se você e a pessoa não têm nenhum relay em comum, vocês são invisíveis um para o outro apesar de ambos estarem "no Nostr". A descoberta é o problema difícil do protocolo — e a resposta parcial é o outbox model (NIP-65), descrito em 3. Relays e Fan-out.

Relacionado

• 2. Eventos e Chaves
• 3. Relays e Fan-out
• 4. NIPs e Evolução do Protocolo
• 5. Limites do Nostr
• 1. Nostr vs Blockchain
• 2. Tipos de Sistemas Distribuídos

---

Parte de MOC Nostr · nostr-protocol/nips