NIPs do Nostr explicados: os documentos de especificação do protocolo

A evolução do Nostr acontece através de NIPs, documentos de especificação curtos que qualquer um pode propor. Se você quer entender como novos recursos como zaps ou DMs criptografadas chegam ao protocolo, NIPs são a resposta.

Este guia cobre o que são NIPs, como funcionam como mecanismo de governança e quais delas ler se você está entrando em detalhes técnicos.

NIPs são documentos markdown curtos no GitHub que propõem como implementar recursos do Nostr. Desenvolvedores de clientes escolhem quais suportar. Uma NIP se torna "real" quando implementadores suficientes a adotam. O conjunto principal de NIPs amplamente usadas é cerca de 30; a lista completa fica mais próxima de 100.

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

O que uma NIP realmente é

Uma NIP é um arquivo markdown no repositório github.com/nostr-protocol/nips. Cada arquivo descreve um recurso, formato ou convenção específica: como assinar events, qual é a aparência de um event de metadados de perfil, como enviar uma mensagem direta, qual formato as requisições de zap Lightning usam.

O tamanho varia. As NIPs mais curtas têm menos de uma página; as mais longas têm vários milhares de palavras. A maioria fica entre 500 e 2000 palavras. Elas são escritas para serem implementáveis apenas a partir da especificação, então incluem formatos de mensagem, campos obrigatórios e events de exemplo.

A convenção de nomenclatura é NIP-XX onde XX é um número. Números são atribuídos quando a NIP é mesclada; eles não refletem prioridade ou importância. NIP-05 é sobre identificadores verificados; NIP-04 é o padrão DM mais antigo; NIP-01 é o protocolo principal. Os números rastreiam a ordem de proposta, não a significância do recurso.

Por que "Implementation Possibilities"

O nome é uma escolha deliberada. Compare com outras tradições de especificação.

• RFCs (Requests for Comments) em protocolos de internet frequentemente acabam sendo obrigatórias para interoperabilidade.
• EIPs (Ethereum Improvement Proposals) frequentemente se tornam obrigatórias via atualização de rede.
• NIPs são permanentemente opcionais. Um cliente que implementa 40 NIPs e um cliente que implementa 10 são ambos clientes Nostr válidos; eles apenas fazem diferentes subconjuntos de coisas.

Isso significa que NIPs nunca "quebram" implementações existentes. Uma nova NIP para algum recurso não força clientes mais antigos a mudar. O protocolo cresce nas bordas enquanto o núcleo permanece estável.

O ciclo de vida da NIP

Como uma nova NIP chega à existência:

1. Alguém nota uma lacuna ou necessidade. "Não temos uma forma padrão de fazer X." Pode ser um desenvolvedor de cliente, um operador de relay ou um usuário frustrado com um problema específico.
2. Eles escrevem um rascunho. O formato segue as NIPs existentes: título, propósito, especificação, exemplos.
3. Eles submetem um pull request para o repositório de NIPs.
4. Revisão da comunidade. Desenvolvedores, operadores de relay e usuários interessados comentam. O rascunho é revisado com base no feedback.
5. Mesclado ou abandonado. NIPs mescladas recebem um número e se tornam parte do repositório. Rascunhos abandonados ficam no histórico de pull requests.
6. A implementação segue (ou não). Algumas NIPs são implementadas em semanas. Algumas esperam anos. Algumas nunca são implementadas amplamente.

O processo é leve. Sem votações de comitê, sem aprovação formal. Se o pull request recebe feedback amplamente positivo e aborda uma necessidade óbvia, é mesclado.

NIPs que importam se você é um usuário

A maioria das NIPs é invisível para usuários. Um punhado afeta sua experiência diária:

• NIP-01: Protocolo principal. Como events são estruturados e assinados. Você nunca vê, mas tudo mais depende disso.
• NIP-05: Identificadores verificados. Lhe dá nomes legíveis como você@domínio.com. Nosso guia NIP-05 cobre isso.
• NIP-07: Assinatura de extensão do navegador. Permite que clientes web assinem sem ver sua chave privada.
• NIP-19: Codificação Bech32. Por que sua chave pública parece npub1... em vez de hex bruto.
• NIP-23: Artigos de longa forma. Permite posts no estilo blog no Nostr.
• NIP-44: DMs criptografadas. O padrão moderno de mensagens diretas (melhor que a NIP-04 mais antiga).
• NIP-57: Zaps. Dicas Lightning com recibos públicos.
• NIP-98: Autenticação HTTP. Permite que identidades Nostr autentiquem em sites comuns.

Como usuário você se beneficia de todas essas sem interagir com elas. Os clientes lidam com os detalhes do protocolo.

NIPs que importam se você é um desenvolvedor

Se você está escrevendo ou mantendo um cliente Nostr, as NIPs que vale a pena ler crescem para dezenas:

• NIP-01 a NIP-10 (mecânicas principais).
• NIP-11 (documentos de informações de relay).
• NIP-13 (prova de trabalho, para resistência a spam).
• NIP-17 (DMs embrulhados em presente para ocultamento de metadados).
• NIP-22 (expiração de events).
• NIP-27 (referências de notas de texto).
• NIP-30 (emoji personalizado).
• NIP-31 (tipos de events).
• NIP-33 (events substituíveis parametrizados).
• NIP-42 (autenticação de conexões com relays).
• NIP-47 (Nostr Wallet Connect).
• NIP-50 (capacidade de busca).
• NIP-65 (metadados da lista de relays).
• NIP-78 (dados de aplicativo personalizado arbitrário).

Essas são as que a maioria dos clientes convencionais implementa. Um cliente que suporta este conjunto mais as NIPs voltadas para usuário acima cobre 95% do uso típico.

Lendo uma NIP

Se você quer ler uma diretamente, o repositório está em github.com/nostr-protocol/nips. A estrutura da maioria das NIPs:

• Título e descrição. O que a NIP propõe.
• Motivação. Por que o recurso é necessário.
• Especificação. Formato de mensagem exato, campos obrigatórios, regras de validação.
• Events de exemplo. JSON concreto mostrando qual é a aparência de um event em conformidade.
• Comportamento de cliente/relay. Como implementações devem lidar com os events.

NIPs são escritas para serem legíveis por desenvolvedores que as implementam. A seção de especificação é a importante; é onde o protocolo real vive.

NIPs com adoção parcial

Algumas NIPs existem mas são inconsistentemente implementadas em clientes. Isso cria casos extremos onde sua experiência varia por cliente.

NIP-44 (DMs criptografadas). Adotada por Damus, Primal, Amethyst e maioria dos clientes principais em 2024-2025. Alguns clientes mais antigos apenas suportam NIP-04. Se você DM alguém cujo cliente suporta apenas NIP-04, suas mensagens NIP-44 para eles falham silenciosamente. A resposta prática: use um cliente moderno e espere que sua correspondente também use.

NIP-17 (DMs embrulhados em presente). DMs que ocultam metadados. A adoção em 2026 está crescendo mas não é universal. O recurso é ótimo onde os clientes de ambas as partes suportam; caso contrário, recai silenciosamente para DMs menos privadas.

NIP-46 (signatários remotos). Permite que um assinador de hardware ou aplicativo bunker assine events em nome de um cliente. Suportado em Amethyst, parcial em outro lugar.

NIP-65 (lista de relays do usuário). Permite que usuários publiquem seus relays preferidos para que clientes roteiem automaticamente para os lugares certos. A adoção está melhorando; clientes mais antigos a ignoram.

NIP-50 (busca). Permite que clientes consultem relays para correspondências de texto. Alguns relays suportam; muitos não. A qualidade da busca é inconsistente como resultado.

Verificar quais NIPs um determinado cliente suporta é um diagnóstico útil quando algo não funciona como esperado. A maioria dos clientes publica sua matriz de suporte NIP em sua documentação.

Como o processo de NIP mantém o protocolo coerente

Sem autoridade central, então a coerência vem da dinâmica social. Algumas observações:

NIPs ruins não se propagam. Uma proposta que duplica uma NIP existente ou resolve o problema errado recebe adoção mínima e morre silenciosamente. A comunidade não é formal, mas é opinionada.

Boas NIPs são implementadas independentemente. Múltiplos desenvolvedores de clientes leem propostas e decidem independentemente. Boas ideias acumulam adotadores; más ideias não.

NIPs concorrentes às vezes emergem. Duas propostas diferentes para o mesmo recurso podem coexistir por um tempo. Geralmente uma vence na prática porque mais clientes a implementam; às vezes elas se mesclam.

Evolução compatível com fork. Porque NIPs são opcionais, um cliente pode implementar NIP-X-v1 e depois atualizar para NIP-X-v2 sem quebrar qualquer um que apenas suporte v1. O protocolo não se divide.

Isso é confuso mas funcional. O protocolo evoluiu significativamente em cinco anos sem um corpo de governança central porque o mecanismo social de "implementadores leem, implementadores decidem, implementadores codificam" tem alinhamento suficiente para produzir coerência.

Propondo sua própria NIP

Se você tem uma ideia para um novo recurso Nostr:

1. Verifique primeiro o repositório de NIPs. Alguém pode já ter proposto.
2. Se não, abra um problema no GitHub descrevendo o problema que você está resolvendo.
3. Com base no feedback, rascunhe uma NIP completa seguindo o formato existente.
4. Submeta um pull request.
5. Participe da discussão. Esteja disposto a revisar.
6. Se for mesclado, ótimo. Se não for, o problema pode ter uma solução melhor; considere por quê.

Nem toda boa ideia se torna uma NIP. Nem toda NIP se torna um recurso. O ecossistema tem mais propostas do que qualquer desenvolvedor único poderia acompanhar, e o filtro é "implementadores suficientes da comunidade a implementam." Esse filtro é o núcleo de como o Nostr permanece coerente sem ser de cima para baixo.