NIPs e Evolução do Protocolo

Conceito

NIP = Nostr Implementation Possibilities. São os documentos que descrevem o que clientes e relays podem implementar. Vivem num repositório no GitHub: nostr-protocol/nips.

O nome já é a tese. Não é Nostr Improvement Proposal, não é Specification, não é Standard. É Possibilities — possibilidades. E o próprio README abre deixando isso explícito:

"NIPs listados aqui não são um checklist de protocolo. Nada obriga nenhum software a implementar nenhum NIP. Cada app escolhe o subconjunto relevante para o seu caso de uso."

Hoje são 95 NIPs listados, dos quais 13 estão marcados como unrecommended — desaconselhados, mas não apagados. O catálogo completo está em 6. Catálogo de NIPs.

Apenas o NIP-01 é obrigatório

Essa é a arquitetura de governança do Nostr numa frase. O NIP-01 define o mínimo indivisível: o formato do evento assinado, o formato do filtro, e as mensagens WebSocket entre cliente e relay. Se você implementa o NIP-01, você está no Nostr.

Todo o resto é opt-in. Um cliente de podcast implementa o NIP-F4 e ignora os outros 90. Um relay minimalista implementa só o 01. Ambos são Nostr válido, e conseguem coexistir.

Os 5 critérios de aceitação

O repositório lista os critérios para um NIP ser aceito, e cada um vale como lição de design de protocolo:

O critério 1 é o mais importante e o mais raro em comitês de padronização: o padrão documenta a prática, não a antecipa. O caminho normal é alguém fazer algo, outros copiarem, e só então virar NIP. Isso é o oposto do modelo W3C/ISO, e é o que explica a velocidade — e também a bagunça.

O critério 3 é o que permite os outros 94 NIPs existirem sem explodir o protocolo: incompatibilidade tem que degradar graciosamente. Um cliente que não entende kind: 30023 (artigo longo) simplesmente não mostra o evento; não trava.

Como um NIP nasce

Duas rotas, e o README admite as duas:

1. De baixo para cima — alguém começa a fazer algo, outros copiam, vira NIP depois. É a rota preferida na prática.
2. De cima para baixo — alguém escreve a ideia, submete um PR, a comunidade discute, e se houver concordância razoável vira NIP.

Não há votação formal, não há fundação, não há BDFL declarado. Há um repositório com um dono e um conjunto de devs com acesso de commit.

A numeração é hexadecimal

Detalhe que confunde quem chega agora: os NIPs vão de 01 a 99 e depois continuam em 5A, 7D, A0, A3, A4, B0, B7, BE, C0, C7, CC, EE, F4.

O identificador é dois dígitos hexadecimais (00–FF), não um número decimal. Então não existem "255 NIPs faltando" — existe um espaço de 256 endereços, e os NIPs novos ocupam faixas altas para evitar colisão com os PRs abertos na faixa baixa.

Deprecação: riscar, não apagar

O padrão do repositório é manter o NIP desaconselhado visível e riscado, com o motivo escrito. Exemplos reais:

Isso importa porque o dado antigo continua existindo nos relays. Um cliente ainda precisa ler kind: 4 para mostrar DMs de 2023, mesmo escrevendo só kind: 14. Deprecar um NIP não apaga os eventos que ele gerou — só desaconselha produzir mais.

Trade-offs

O trade-off central de governança:

Evolução rápida e sem porteiro, paga com fragmentação.

O que se ganha:

• Um NIP novo não precisa de aprovação de ninguém para existir na prática — basta dois clientes implementarem
• Não há versão do protocolo, não há hard fork, não há migração coordenada
• O protocolo cresce por acréscimo de vocabulário (kinds e tags novos), nunca por mudança de gramática

O que se perde:

• "Suporta Nostr" não significa nada. Dois clientes podem não enxergar as mesmas features. O usuário descobre isso na cara dura: publica um artigo longo (kind: 30023) e o amigo, em outro app, não vê nada.
• O critério 4 ("uma única forma de fazer cada coisa") é uma intenção, não uma garantia. NIPs sobrepostos aconteceram — 28 vs 29, 72 vs 29, 96 vs B7 — e a resolução foi depreciar depois do estrago.
• O repositório é, na prática, um ponto de centralização do protocolo descentralizado.

O README encara essa última crítica de frente, e a resposta é boa: o índice central pode ser contestado e forkado a qualquer momento, e se ele deixar de servir a comunidade, ela migra. A centralização é de coordenação, não de poder — ninguém precisa de permissão do repositório para rodar um relay ou publicar um evento.

Exemplo prático

Como o NIP-17 substituiu o NIP-04 sem quebrar ninguém.

O NIP-04 fazia DMs criptografadas com kind: 4. Problema: o conteúdo era cifrado, mas a tag p (destinatário) era pública. Qualquer relay via quem falava com quem, quando e com que frequência — o grafo social inteiro, que costuma ser mais revelador que o texto.

A correção veio em camadas, cada uma um NIP separado:

Resultado: o relay vê um kind: 1059 (gift wrap) assinado por uma chave aleatória de uso único. Não sabe quem mandou, para quem, nem o quê.

Repare no padrão de engenharia, que é o mais reaproveitável desta nota: a solução foi decomposta em três NIPs com responsabilidades separadas, em vez de um "NIP-04 v2" monolítico. Isso permitiu que o NIP-44 (cifra) fosse reusado por outras features sem arrastar junto a semântica de DM. É separação de responsabilidades aplicada a protocolo — o mesmo princípio de 2. Single Responsibility Principle.

E a migração não teve data marcada, nem flag, nem versão: os clientes passaram a escrever kind: 14 e continuaram lendo kind: 4. Retrocompatibilidade pelo critério 3.

Relacionado

• 6. Catálogo de NIPs
• 7. Kinds de Eventos e Mensagens
• 2. Eventos e Chaves
• 1. Nostr
• 5. Limites do Nostr

---

Parte de MOC Nostr · nostr-protocol/nips