Sistemas Descentralizados/03 - Nostr7 min
Catálogo de NIPs
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Os 95 NIPs do repositório oficial, agrupados por tema em vez de por número. ⚠️ = marcado como unrecommended pelo repositório (13 no total). Para o processo de como um NIP nasce, morre e evolui, ver 4. NIPs e Evolução do Protocolo.
Conceito
O catálogo revela uma coisa que a lista numérica esconde: os NIPs se dividem em duas naturezas completamente diferentes.
- NIPs de mecânica (01, 09, 11, 42, 44, 45, 50, 59, 65, 77…) — mudam como o protocolo funciona. São poucos, densos, e todo cliente sério implementa.
- NIPs de vocabulário (34, 52, 54, 64, 88, CC, F4…) — só definem
kinds e tags novos para um domínio. Não mudam nada do protocolo; são "o Nostr também serve para xadrez / podcast / geocaching".
Essa separação é o que permite 95 NIPs sem caos: a esmagadora maioria é vocabulário, e vocabulário novo é sempre retrocompatível — quem não conhece a palavra ignora o evento.
Núcleo do protocolo
O que todo mundo precisa. Comece por aqui.
| NIP | Nome | O que resolve |
|---|---|---|
| 01 | Basic protocol flow | O único obrigatório. Evento, assinatura, id, filtros, mensagens WebSocket |
| 09 | Event Deletion Request | Pedido de deleção (kind: 5) — é pedido, não comando |
| 13 | Proof of Work | Custo computacional no id do evento como anti-spam |
| 40 | Expiration Timestamp | "Apague isso depois de X" — relays honestos obedecem |
| 62 | Request to Vanish | "Apague tudo meu deste relay" — o mais próximo de um direito ao esquecimento |
| 70 | Protected Events | Evento que só o próprio autor pode publicar no relay |
Relays — operação e descoberta
| NIP | Nome | O que resolve |
|---|---|---|
| 11 | Relay Information Document | Relay se descreve por HTTP: limites, políticas, NIPs suportados |
| 42 | Authentication of clients to relays | Login no relay via desafio assinado (AUTH) |
| 43 | Relay Access Metadata and Requests | Pedir entrada, convite e saída em relays fechados |
| 45 | Counting results | Mensagem COUNT — contar sem baixar tudo |
| 50 | Search Capability | Busca textual (search no filtro) |
| 65 | Relay List Metadata | Base do outbox model — onde encontrar cada autor |
| 66 | Relay Discovery and Liveness | Monitores publicam quais relays existem e estão vivos |
| 67 | EOSE Completeness Hint | O relay diz se o EOSE significa "acabou mesmo" ou "cansei" |
| 77 | Negentropy Syncing | Sincronizar dois relays comparando conjuntos com pouca banda |
| 86 | Relay Management API | API administrativa do relay (banir, listar, moderar) |
Identidade, chaves e assinatura
| NIP | Nome | O que resolve |
|---|---|---|
| 05 | Mapping keys to DNS identifiers | nome@dominio.com → pubkey via /.well-known/nostr.json |
| 07 | window.nostr |
Extensão de navegador assina — o app nunca vê a chave |
| 19 | bech32-encoded entities | npub, nsec, note, nprofile, nevent, naddr |
| 21 | nostr: URI scheme |
Links clicáveis que abrem no cliente instalado |
| 39 | Linking Profiles to Other Platforms | Provar que a npub é o mesmo dono do GitHub/Twitter |
| 46 | Nostr Remote Signing | Bunker: a chave fica num signer remoto, o app pede assinatura |
| 49 | Private Key Encryption | ncryptsec — chave privada cifrada com senha, portável |
| 55 | Android Signer Application | Mesmo papel do NIP-07, no Android |
| 98 | HTTP Auth | Usar a chave Nostr para autenticar em APIs HTTP comuns |
| ⚠️ 06 | Key derivation from mnemonic | Desaconselhado: "prefira uma única nsec" |
| ⚠️ 26 | Delegated Event Signing | Desaconselhado: "peso desnecessário para pouco ganho" |
Os NIPs 07, 46, 49 e 55 existem todos pelo mesmo motivo: manter a chave privada fora do aplicativo. É a resposta parcial do ecossistema ao problema descrito em 5. Limites do Nostr.
Privacidade e criptografia
| NIP | Nome | O que resolve |
|---|---|---|
| 44 | Encrypted Payloads (Versioned) | A cifra moderna, versionada — substitui a do NIP-04 |
| 59 | Gift Wrap | Embrulha evento em outro, com chave descartável — esconde metadados |
| 17 | Private Direct Messages | DM privada de verdade = 44 + 59 juntos |
| ⚠️ 04 | Encrypted Direct Message | Desaconselhado: cifra fraca e vazava quem-fala-com-quem |
| ⚠️ EE | E2EE via MLS | Desaconselhado: substituído pelo protocolo Marmot (fora do repo) |
Conteúdo social
| NIP | Nome | O que resolve |
|---|---|---|
| 02 | Follow List | kind: 3 — quem você segue, público |
| 10 | Text Notes and Threads | kind: 1 e as regras de resposta/thread (tags e e p) |
| 14 | Subject tag | Assunto em nota de texto |
| 18 | Reposts | Repost (kind: 6) e repost genérico (kind: 16) |
| 22 | Comment | Comentário genérico (kind: 1111) sobre qualquer coisa |
| 23 | Long-form Content | Artigos em Markdown (kind: 30023) — o "Medium do Nostr" |
| 24 | Extra metadata fields and tags | Campos extras de perfil sem inflar o NIP-01 |
| 25 | Reactions | Curtidas e emojis (kind: 7) |
| 27 | Text Note References | Menções embutidas no texto via nostr: (substitui o NIP-08) |
| 30 | Custom Emoji | Emoji personalizado por imagem |
| 37 | Draft Events | Rascunhos, cifrados, guardados nos relays |
| 38 | User Statuses | "ouvindo tal música", "ocupado" — status temporário |
| 51 | Lists | O NIP mais reaproveitado: mutes, pins, bookmarks, listas de tudo |
| 58 | Badges | Emblemas emitidos por terceiros e exibidos no perfil |
| 84 | Highlights | Trechos destacados de qualquer conteúdo |
| 88 | Polls | Enquetes e respostas |
| A4 | Public Messages | Mensagem pública endereçada (kind: 24) |
| B0 | Web Bookmarks | Favoritos de páginas web |
| ⚠️ 08 | Handling Mentions | Desaconselhado: substituído pelo NIP-27 |
| ⚠️ 31 | Dealing with Unknown Events | Desaconselhado: "desnecessariamente inchado" |
Mídia e arquivos
| NIP | Nome | O que resolve |
|---|---|---|
| 68 | Picture-first feeds | Feed de fotos (kind: 20) — o "Instagram do Nostr" |
| 71 | Video Events | Vídeo, inclusive vertical curto |
| 92 | Media Attachments (imeta) |
Metadados do anexo: dimensão, hash, blurhash, mime |
| 94 | File Metadata | Descreve um arquivo hospedado fora do relay |
| A0 | Voice Messages | Áudio curto e comentário em áudio |
| B7 | Blossom | Armazenamento de blobs endereçado por hash — substitui o NIP-96 |
| ⚠️ 96 | HTTP File Storage | Desaconselhado: substituído pelo Blossom |
Repare no padrão: relay não guarda arquivo. Relay guarda evento JSON; a mídia mora em outro lugar e o evento carrega o hash. Isso mantém o relay barato — e é a mesma separação de S3 vs. banco relacional.
Grupos, comunidades e tempo real
| NIP | Nome | O que resolve |
|---|---|---|
| 29 | Relay-based Groups | Grupos com moderação, ancorados num relay |
| 53 | Live Streaming and Spaces | Transmissão ao vivo, salas de áudio, chat ao vivo |
| 7D | Forum Threads | Threads estilo fórum (kind: 11) |
| C7 | Chats | Mensagem de chat (kind: 9) |
| ⚠️ 28 | Public Chat | Desaconselhado: use o NIP-29 |
| ⚠️ 72 | Moderated Communities | Desaconselhado: use o NIP-29 |
Três tentativas de "grupo" (28 → 72 → 29) é o exemplo mais claro do critério 4 dos NIPs — uma única forma de fazer cada coisa — sendo alcançado por depreciação, depois do estrago, e não por planejamento.
Moderação e confiança
| NIP | Nome | O que resolve |
|---|---|---|
| 32 | Labeling | Rotular pessoas/eventos — base de moderação distribuída |
| 36 | Sensitive Content | Marcar conteúdo sensível (content-warning) |
| 56 | Reporting | Denúncia publicada como evento assinado |
| 85 | Trusted Assertions | Afirmações de confiança sobre pessoas/eventos — web of trust |
Sem operador central, moderação não pode ser imposta — só publicada. Cada um denuncia e rotula; o cliente decide em quem confia. A moderação vira dado, não autoridade.
Dinheiro — Bitcoin, Lightning e Cashu
| NIP | Nome | O que resolve |
|---|---|---|
| 57 | Lightning Zaps | Gorjeta em Lightning com recibo publicado no Nostr |
| 47 | Nostr Wallet Connect | Cliente comanda uma carteira Lightning remota |
| 60 | Cashu Wallet | Carteira ecash guardada como eventos |
| 61 | Nutzaps | Zap pagando em ecash Cashu |
| 75 | Zap Goals | Meta de arrecadação |
| 87 | Cashu / Fedimint Discoverability | Anunciar mints disponíveis |
| A3 | payto: Payment Targets |
Destinos de pagamento genéricos (inclusive fiat) |
| 69 | Peer-to-peer Order events | Ordens P2P (base de exchanges sem custódia) |
| 99 | Classified Listings | Anúncios classificados |
| ⚠️ 15 | Nostr Marketplace | Desaconselhado: "complicado demais, use o 99" |
Aplicações — o "Other Stuff" do nome
| NIP | Nome | O que resolve |
|---|---|---|
| 34 | git stuff |
Repos, patches, issues e PRs sobre Nostr — GitHub sem GitHub |
| 35 | Torrents | Anúncio e comentário de torrents |
| 48 | Bridged Events | Marcar evento que veio de outra rede (ponte) |
| 52 | Calendar Events | Eventos de agenda e RSVP |
| 54 | Wiki | Artigos wiki com merge request |
| 64 | Chess (PGN) | Partidas de xadrez |
| 73 | External Content IDs | Referenciar ISBN, DOI, URL, podcast GUID |
| 78 | Application-specific Data | Um app guarda config arbitrária nos relays |
| 89 | Recommended Application Handlers | "Que app abre esse kind?" — tipo MIME types |
| 5A | Static Websites (nsites) | Hospedar site estático em relays + Blossom |
| C0 | Code Snippets | Trechos de código |
| CC | Geocaching | Caches geográficos, logs e provas |
| F4 | Podcasts | Podcast e episódios |
| ⚠️ 03 | OpenTimestamps | Desaconselhado: vulnerável a um ataque específico |
| ⚠️ 90 | Data Vending Machines | Desaconselhado: "isso saiu totalmente de controle" |
| ⚠️ BE | Nostr BLE | Desaconselhado: implementado uma vez só, incerto se funciona |
Trade-offs
Olhando o catálogo inteiro, três coisas ficam evidentes:
1. A cauda longa é enorme e barata. Xadrez, geocaching, torrent, podcast. Cada um custa um kind novo e zero mudança no protocolo. Esse é o retorno do design do NIP-01: um formato genérico de evento assinado é extensível de graça.
2. O que é caro está no núcleo. Deleção, ordenação, privacidade de metadados e descoberta — os quatro problemas difíceis — consumiram NIPs 09, 62, 44, 59, 17, 65, 66, 67, 77, e nenhum está resolvido, só mitigado. É onde vale estudar a fundo.
3. Nenhum NIP resolve disponibilidade nem consenso. Não existe NIP para "garantir que meu post existe amanhã" ou "concordar sobre a ordem". Não por esquecimento: é fora do escopo por construção. Ver 1. Nostr vs Blockchain.
Exemplo prático
Que subconjunto um cliente real precisa implementar?
Para um cliente de microblog utilizável, o mínimo honesto é:
| Para | NIPs |
|---|---|
| Existir | 01 |
| Ter identidade decente | 05, 07/46, 19, 21 |
| Ler e escrever posts | 10, 18, 22, 25, 27 |
| Achar as pessoas | 02, 51, 65 |
| Mandar DM sem vazar | 17, 44, 59 |
| Não afogar em spam | 42, 56, 32 |
| Mídia | 92, 94, B7 |
São ~18 dos 95 — e é por isso que "suporta Nostr" não diz nada sobre compatibilidade. Dois clientes com conjuntos diferentes funcionam, mas não enxergam as mesmas coisas.
Na prática o usuário descobre isso do pior jeito: publica um artigo longo (kind: 30023, NIP-23) e o amigo, noutro app, vê o perfil vazio. Nada quebrou — o app dele simplesmente não fala essa palavra.
Relacionado
- 4. NIPs e Evolução do Protocolo
- 7. Kinds de Eventos e Mensagens
- 2. Eventos e Chaves
- 3. Relays e Fan-out
- 5. Limites do Nostr
Parte de MOC Nostr · nostr-protocol/nips