Kinds de Eventos e Mensagens

Conceito

As 4 faixas de kind — e por que elas existem

Este é o detalhe mais elegante do NIP-01: o número do kind não é só um rótulo, é uma instrução de armazenamento para o relay. A faixa em que ele cai determina o comportamento, sem precisar de campo extra nem de configuração.

Repare no que isso resolve:

• Replaceable é como o perfil (kind: 0) e a lista de seguidos (kind: 3) funcionam sem acumular lixo. Você não "edita" o perfil — publica um novo, e o relay descarta o anterior. É estado por sobrescrita, não por mutação.
• Addressable adiciona uma chave secundária (a tag d), permitindo vários documentos editáveis do mesmo tipo. É como um artigo (kind: 30023) tem um endereço estável (naddr) e continua editável.
• Ephemeral é fire-and-forget: usado por autenticação (kind: 22242) e por RPC entre apps (kind: 24133), onde persistir seria vazamento, não feature.

Empate de timestamp em replaceable? Regra do NIP-01: fica o de id menor em ordem lexicográfica. Determinístico, sem coordenação — todo relay chega ao mesmo resultado sozinho.

Kinds mais usados

A tabela oficial tem mais de 150 entradas e não é exaustiva — o registro legível por máquina fica em registry-of-kinds. Ou seja: o espaço de kind é aberto, e a colisão é evitada por convenção social, não por autoridade.

Mensagens Cliente → Relay

Mensagens Relay → Cliente

O EOSE é a peça de design mais interessante do conjunto. Uma única inscrição serve histórico e tempo real no mesmo canal, e o EOSE é apenas o marcador entre os dois. Não há "endpoint de histórico" e "websocket de updates" — há um só fluxo, com uma fronteira anunciada.

Motivos padronizados de OK e CLOSED

O terceiro campo do OK e o do CLOSED começam com um prefixo legível por máquina, seguido de texto livre:

duplicate · pow · blocked · rate-limited · invalid · restricted · mute · error

["OK", "b1a649eb...", false, "rate-limited: slow down, 10 events/min"]
["CLOSED", "sub1", "auth-required: precisa autenticar para ler DMs"]

O padrão — prefixo para a máquina, resto para o humano — é o mesmo dos status codes HTTP com corpo de erro, e resolve o mesmo problema: dar ao cliente algo para decidir programaticamente sem perder a mensagem diagnóstica.

Trade-offs

A faixa do kind codificar semântica de armazenamento é econômico e irreversível. Economia: zero campos extras, zero configuração, e um relay implementa as quatro políticas com um if na faixa. Irreversibilidade: um kind publicado na faixa errada não pode ser reclassificado depois sem quebrar quem já o armazena.

O custo maior é a numeração como espaço compartilhado global. Não há registro autoritativo — dois projetos podem escolher o mesmo kind para coisas diferentes, e o conflito só aparece quando os dados se cruzam num relay. A defesa é convenção e o registro comunitário, o que é frágil por construção. É o preço de não ter autoridade, coerente com o resto do desenho.

Exemplo prático

Uma sessão completa, do primeiro byte:

→ ["REQ","feed",{"kinds":[1],"authors":["3bf0c63f..."],"limit":20}]
← ["EVENT","feed",{...}]        # 20 eventos do histórico
← ["EOSE","feed"]               # acabou o passado
← ["EVENT","feed",{...}]        # 10 min depois: post novo, ao vivo

→ ["EVENT",{"kind":1,"content":"oi","sig":"..."}]
← ["OK","a1b2c3...",true,""]

→ ["EVENT",{"kind":1,"content":"oi","sig":"..."}]     # mandei de novo
← ["OK","a1b2c3...",true,"duplicate: already have this event"]

Repare na última linha: reenviar o mesmo evento devolve true, não erro. E é correto — o id é o hash do conteúdo, então "já tenho" e "acabei de guardar" levam ao mesmo estado final.

Ou seja: publicar no Nostr é idempotente por construção, e de graça. Não precisou de chave de idempotência como no exemplo de 1. O que é um Sistema Distribuído, porque o identificador é o conteúdo. É a mesma propriedade que faz o retry seguro funcionar — obtida por endereçamento por conteúdo em vez de por protocolo.

Relacionado

• 2. Eventos e Chaves
• 3. Relays e Fan-out
• 6. Catálogo de NIPs
• Idempotent Operations

---

Parte de MOC Nostr · NIP-01