Como Nostr realmente funciona: o protocolo, sem jargão

A maioria das explicações de Nostr para em "é um protocolo social descentralizado" e deixa a parte interessante por dizer. A parte interessante é que todo o protocolo cabe em um documento curto. Nenhum truque esperto, nenhuma complexidade escondida. Apenas alguns primitivos que funcionam juntos.

Este guia passa por esses primitivos na ordem em que surgem quando você realmente usa Nostr: como um evento é construído, como é assinado, como chega aos relays, como os clientes se subscrevem, e qual é o fluxo quando você gosta de um post, recebe uma resposta ou recebe um zap. Nenhuma comparação com blockchain, nenhuma narrativa grandiosa. Apenas a mecânica.

TL;DR. Nostr é pub/sub sobre WebSockets com assinaturas criptográficas. Clientes publicam objetos JSON assinados (eventos) para relays (pequenos servidores), e outros clientes se subscrevem aos relays com filtros que correspondem aos eventos que querem. As assinaturas impedem falsificação; múltiplos relays impedem pontos únicos de falha. Esse é todo o protocolo; todo o resto é convenções de formatação para diferentes tipos de conteúdo.

Quando estiver pronto, pegue seu endereço @nostr.blog →

O bloco de construção: um evento

Tudo em Nostr é um evento. Um post é um evento. Uma reação é um evento. Uma atualização de perfil é um evento. Uma mensagem direta é um evento. Um recibo de zap é um evento.

Um evento é um objeto JSON com exatamente esta forma:

{
  "id": "abc123...",
  "pubkey": "0a4f7b1a3d9a1529a3080c3ae5ee553e0af0a01d86d01677c0bb270592923f88",
  "created_at": 1776329035,
  "kind": 1,
  "tags": [
    ["t", "nostr"],
    ["p", "3bf0c63f..."]
  ],
  "content": "hello nostr",
  "sig": "def456..."
}

Seis campos fazem trabalho significativo. id é um hash do próprio conteúdo do evento; identifica unicamente o evento. pubkey é o autor (uma chave pública de 64 caracteres em hexadecimal). created_at é um timestamp Unix. kind é um inteiro descrevendo o que o evento representa (mais sobre isso abaixo). tags é uma lista de anotações estruturadas como hashtags (t), menções (p para pubkey, e para evento), e dezenas de outras. content é a carga útil de forma livre, geralmente texto.

sig é a assinatura de Schnorr, feita com a chave privada do autor, sobre o hash em id. Este é o campo que impede falsificação: qualquer um pode computar o hash, mas apenas o detentor da chave privada pode produzir uma assinatura válida sobre ele.

O que é um "kind"

O campo kind diz aos clientes como interpretar o evento. O número é o tipo semântico completo.

Um punhado de kinds em uso ativo:

Novos kinds são propostos e padronizados via NIPs (Nostr Implementation Possibilities). Qualquer um pode propor um. Os que ganham adoção ampla se tornam partes de facto do protocolo; os que não ganham simplesmente permanecem nicho sem quebrar nada.

Como um evento é publicado

Quando você toca "postar" em um cliente Nostr, esta sequência é executada:

1. Cliente monta o JSON. Preenche pubkey, created_at, kind, tags, content.
2. Cliente computa o id. Executa SHA-256 sobre uma serialização canônica desses campos. Este é o hash que a assinatura cobre.
3. Cliente assina o id com a chave privada. Assinatura de Schnorr sobre secp256k1, a mesma curva que Bitcoin usa. A assinatura de 64 bytes se torna o campo sig.
4. Cliente abre conexões WebSocket para cada relay configurado. Ou reutiliza as existentes abertas se estão ativas.
5. Cliente envia o evento como uma mensagem. O formato transmitido é um array JSON: ["EVENT", {...event...}].
6. Cada relay valida a assinatura. Rejeita o evento se a assinatura não verificar contra a pubkey reivindicada. Aceita e armazena caso contrário.
7. Cada relay empurra o evento para subscribers. Qualquer cliente com uma subscrição aberta cujo filtro corresponde a este evento recebe o evento entregue em tempo real.

A volta completa leva 50 a 300 milissegundos dependendo das localizações dos relays. Se algum relay é lento ou está offline, os outros relays ainda publicam o evento. Você só precisa de um relay para aceitá-lo para que o evento exista na rede.

Como um cliente busca posts

A leitura é o espelho da publicação.

Seu cliente abre conexões WebSocket para uma lista de relays. Para cada um, envia uma mensagem de subscrição:

["REQ", "sub_id_1", { "authors": ["pubkey1", "pubkey2", ...], "kinds": [1, 6], "limit": 50 }]

Isso pede ao relay até 50 eventos dos autores na lista, de kind 1 (nota curta) ou kind 6 (repostagem). O relay:

1. Consulta seu banco de dados local para eventos correspondentes, envia-os (do mais antigo para o mais novo por padrão, até o limite) como mensagens EVENT de volta ao cliente.
2. Envia uma mensagem EOSE (end of stored events) para que o cliente saiba que o despejo histórico está completo.
3. Mantém a subscrição aberta. Qualquer novo evento que corresponda ao filtro (publicado por alguém mais depois) é empurrado ao cliente em tempo real.

É assim que seu feed se torna ao vivo. Você não está consultando; o relay está transmitindo.

Seu cliente faz isso em paralelo em cada relay configurado. A união de respostas é seu timeline. Eventos duplicados entre relays são desduplicados por id.

Como assinaturas realmente impedem falsificação

Esta é a parte que a maioria das explicações ignora.

Quando um cliente recebe um evento, ele recomputa o hash sobre a serialização canônica (da mesma forma que o publicador fez) e executa verificação de Schnorr: dada a pubkey, o id e a sig, a assinatura se verifica criptograficamente?

Se sim, o evento é autêntico. O autor deste evento era o detentor dessa pubkey no momento da assinatura. Cada cliente executa esta verificação em cada evento. Um relay que envia um evento forjado com uma assinatura inválida só consegue ver o evento descartado silenciosamente por cada cliente que o vê.

Isso importa porque significa que relays não são confiáveis. Um relay malicioso não pode colocar palavras em sua boca. Pode recusar servir seus posts, pode injetar posts legítimos de outra pessoa em seu feed, mas não pode produzir um post válido assinado por você sem sua chave privada, e não pode modificar um de seus posts existentes sem quebrar a assinatura.

O custo desta propriedade é exatamente uma verificação de Schnorr por evento, o que é rápido o suficiente para que até clientes móveis lidem com dezenas de milhares de eventos por segundo.

O que relays realmente fazem

Um relay é um tubo burro e rápido com três trabalhos:

1. Aceitar eventos e validar assinaturas. Rejeitar qualquer coisa que não verifique ou falhe verificações de política (filtros de spam, limites de tamanho, pubkeys bloqueadas).
2. Armazenar eventos. Geralmente em um banco de dados SQLite ou PostgreSQL indexado por id, pubkey, kind e valores de tag.
3. Servir subscrições. Corresponder filtros de REQ entrantes contra o banco de dados (para histórico) e contra eventos ao vivo (para tempo real).

Pronto. Um relay não classifica, não recomenda, não cura, não monetiza, não mostra anúncios, não aplica um algoritmo, ou não faz nada que uma plataforma faria. Ele encaminha bytes assinados.

A ausência desses outros trabalhos é porque relays podem ser minúsculos. Um único VPS de $5 por mês pode executar um relay servindo centenas de usuários ativos. A mesma função na escala do Twitter custa bilhões porque Twitter faz todas essas outras coisas.

As políticas de relay diferem. Alguns são sem permissão e servem qualquer evento assinado. Alguns exigem pagamento (o modelo "relay pago"), outros se restringem a uma comunidade específica (funcionários de uma empresa, membros de um servidor Discord), e ainda outros são agressivos sobre filtragem de spam. Você escolhe quais relays usar; sua escolha afeta quais posts você vê e quais chegam aos seus seguidores.

Um exemplo completo: alguém gosta do seu post

Juntando tudo, aqui está o que acontece de ponta a ponta quando Alice gosta de um post que Bob escreveu.

1. Bob publica. O cliente de Bob constrói um evento kind:1 com conteúdo "hello world", o assina, envia para cinco relays configurados de Bob. Cada relay aceita e armazena.
2. Alice se subscreve. O cliente de Alice tem uma subscrição aberta em dois desses relays com um filtro que inclui a pubkey de Bob em authors. Os relays empurram o post de Bob para a subscrição. O cliente de Alice mostra o post em seu timeline.
3. Alice toca like. O cliente de Alice constrói um evento kind:7 com conteúdo "+" (a convenção Nostr de "like"), marca o post que reage (["e", "bob_post_id"]) e o autor (["p", "bob_pubkey"]). Assina e publica para cinco relays configurados de Alice.
4. A reação se propaga. Qualquer relay que tenha uma subscrição ativa correspondendo ao filtro { "#e": ["bob_post_id"], "kinds": [7] } (que é o que o cliente de Bob usa para observar reações aos seus próprios posts) empurra a reação para Bob. O cliente de Bob agrega os likes e mostra a contagem sob o post.

Observe o que não aconteceu. Nenhum serviço centralizado de "botão de like" foi acionado. Nenhum backend decidiu se a contagem funciona. O like é apenas um evento assinado, anunciado nos mesmos canais que o post em si.

O que Nostr explicitamente não faz

Cinco coisas deixadas fora do protocolo central de propósito, porque pertencem ao cliente ou ao relay, não ao formato de fio compartilhado.

• Verificação de identidade. Nostr apenas prova "esta pubkey assinou este post". Se a pubkey pertence a um ser humano específico é uma questão separada respondida por NIP-05 e contexto fora da cadeia.
• Moderação de conteúdo. O protocolo não decide o que é visível. Clientes filtram, relays filtram, usuários filtram. Cada camada independentemente.
• Busca. Não há ponto final de busca global. Alguns relays suportam busca de texto sobre seu pool de eventos local; não há garantia de protocolo de que qualquer relay possa encontrar qualquer post.
• Classificação algorítmica. Nenhum feed "para você" no protocolo. A classificação acontece no cliente se acontecer.
• Recuperação de conta. Nenhuma redefinição de email, nenhuma redefinição de telefone, nenhum sistema central de disputa. Perd a chave privada, perde a identidade. Este é um tradeoff, não um bug.

Essas ausências são o que torna o protocolo pequeno. Também são o que torna construir uma experiência de usuário polida por cima mais difícil do que construir uma em uma plataforma centralizada, que é o custo honesto.

Por que o design funciona em tudo

O design se baseia em uma propriedade simples: assinaturas são baratas de verificar, falsificação é impossível sem a chave privada, e relays são livres para substituir.

Esses três fatos se combinam. Verificação barata significa que cada cliente pode verificar cada evento. Falsificação impossível significa que relays não precisam ser confiáveis. Substituição livre significa que nenhum relay tem poder sobre ninguém.

Juntos, você obtém uma rede social onde a camada de plataforma é intercambiável e a camada de identidade é possuída pelo usuário. Que é o que "descentralizado" realmente significa na prática, em vez de como o marketing geralmente usa a palavra.

Se você quer ver todo o fluxo do lado do usuário (um par de chaves, uma identidade NIP-05, uma lista de relay, uma carteira, pronto para postar), o signup de nostr.blog reduz essas etapas em uma página. A mecânica descrita aqui é o que realmente está rodando sob esse fluxo.