Nostr NIP spiegati: i documenti di specifica del protocollo

L'evoluzione di Nostr avviene attraverso i NIP, brevi documenti di specifica che chiunque può proporre. Se vuoi capire come nuove funzionalità come gli zap o i DM crittografati entrano nel protocollo, i NIP sono la risposta.

Questa guida copre cosa sono i NIP, come funzionano come meccanismo di governance, e quali leggere se vuoi approfondire tecnicamente.

I NIP sono brevi documenti markdown su GitHub che propongono come implementare funzionalità Nostr. Gli sviluppatori di client scelgono quali supportare. Un NIP diventa "reale" quando abbastanza implementatori lo adottano. Il set principale di NIP ampiamente utilizzati è circa 30; l'elenco completo è più vicino a 100.

Quando sei pronto, prendi il tuo indirizzo @nostr.blog →

Cosa è effettivamente un NIP

Un NIP è un file markdown nel repository github.com/nostr-protocol/nips. Ogni file descrive una funzionalità, un formato, o una convenzione specifica: come firmare gli event, come appare un event di metadati del profilo, come inviare un messaggio diretto, quale formato utilizzano le richieste di zap Lightning.

La dimensione varia. I NIP più brevi sono meno di una pagina; i più lunghi sono diverse migliaia di parole. La maggior parte si aggira intorno a 500-2000 parole. Sono scritti per essere implementabili dalla sola specifica, quindi includono formati di messaggi, campi obbligatori, e event di esempio.

La convenzione di denominazione è NIP-XX dove XX è un numero. I numeri vengono assegnati quando il NIP viene incorporato; non riflettono priorità o importanza. NIP-05 riguarda gli identificatori verificati; NIP-04 è lo standard DM più vecchio; NIP-01 è il protocollo core. I numeri tengono traccia dell'ordine delle proposte, non della significatività delle funzionalità.

Perché "Implementation Possibilities"

Il nome è una scelta deliberata. Confronta con altre tradizioni di specifica.

• RFC (Requests for Comments) nei protocolli internet spesso diventano obbligatori per l'interoperabilità.
• EIP (Ethereum Improvement Proposals) spesso diventano obbligatori attraverso un aggiornamento di rete.
• NIP sono permanentemente opzionali. Un client che implementa 40 NIP e un client che ne implementa 10 sono entrambi validi client Nostr; fanno semplicemente diversi sottoinsiemi di cose.

Ciò significa che i NIP non "rompono" mai implementazioni esistenti. Un nuovo NIP per una funzionalità non forza i client più vecchi a cambiare. Il protocollo cresce ai margini mentre il core rimane stabile.

Il ciclo di vita del NIP

Come nasce un nuovo NIP:

1. Qualcuno nota un divario o un'esigenza. "Non abbiamo un modo standard per fare X." Potrebbe essere uno sviluppatore di client, un operatore di relay, o un utente frustrato da un problema specifico.
2. Scrivono una bozza. Il formato segue i NIP esistenti: titolo, scopo, specifica, esempi.
3. Inviano una pull request al repository dei NIP.
4. La comunità esamina. Sviluppatori, operatori di relay, e utenti interessati commentano. La bozza viene rivista in base al feedback.
5. Incorporamento o abbandono. I NIP incorporati ricevono un numero e diventano parte del repository. Le bozze abbandonate rimangono nella cronologia delle pull request.
6. L'implementazione segue (o meno). Alcuni NIP vengono implementati entro settimane. Alcuni aspettano anni. Alcuni non vengono mai ampiamente implementati.

Il processo è snello. Nessun voto di comitato, nessuna approvazione formale. Se la pull request riceve un ampio feedback positivo e affronta un'esigenza ovvia, viene incorporata.

I NIP che contano se sei un utente

La maggior parte dei NIP è invisibile agli utenti. Un'manciata influisce sulla tua esperienza quotidiana:

• NIP-01: Protocollo core. Come gli event sono strutturati e firmati. Non lo vedrai mai, ma tutto il resto dipende da esso.
• NIP-05: Identificatori verificati. Ti dà nomi leggibili tu@dominio.com. La nostra guida NIP-05 la copre.
• NIP-07: Firma dell'estensione del browser. Consente ai client web di firmare senza vedere la tua chiave privata.
• NIP-19: Codifica Bech32. Perché la tua chiave pubblica assomiglia a npub1... invece di hex grezzo.
• NIP-23: Articoli di lunga forma. Abilita i post in stile blog su Nostr.
• NIP-44: DM crittografati. Lo standard moderno dei messaggi diretti (migliore del vecchio NIP-04).
• NIP-57: Zap. Mance Lightning con ricevute pubbliche.
• NIP-98: Autenticazione HTTP. Consente alle identità Nostr di autenticarsi ai siti web regolari.

Come utente benefici di tutto ciò senza interagire con esso. I client gestiscono i dettagli del protocollo.

I NIP che contano se sei uno sviluppatore

Se stai scrivendo o mantenendo un client Nostr, i NIP che vale la pena leggere crescono in dozzine:

• NIP-01 attraverso NIP-10 (meccanica core).
• NIP-11 (documenti di informazioni sul relay).
• NIP-13 (proof of work, per resistenza allo spam).
• NIP-17 (DM avvolti come regalo per nascondere i metadati).
• NIP-22 (scadenza dell'event).
• NIP-27 (riferimenti a note di testo).
• NIP-30 (emoji personalizzato).
• NIP-31 (tipi di event).
• NIP-33 (event sostituibili parametrizzati).
• NIP-42 (autenticazione delle connessioni ai relay).
• NIP-47 (Nostr Wallet Connect).
• NIP-50 (capacità di ricerca).
• NIP-65 (metadati dell'elenco di relay).
• NIP-78 (dati personalizzati arbitrari dell'app).

Questi sono quelli che la maggior parte dei client mainstream implementa. Un client che supporta questo set più i NIP rivolti all'utente di cui sopra copre il 95% dell'uso tipico.

Leggere un NIP

Se vuoi leggerne uno direttamente, il repository è a github.com/nostr-protocol/nips. La struttura della maggior parte dei NIP:

• Titolo e descrizione. Cosa propone il NIP.
• Motivazione. Perché la funzionalità è necessaria.
• Specifica. Formato esatto del messaggio, campi obbligatori, regole di convalida.
• Event di esempio. JSON concreto che mostra come appare un event conforme.
• Comportamento del client/relay. Come le implementazioni dovrebbero gestire gli event.

I NIP sono scritti per essere leggibili dagli sviluppatori che li implementano. La sezione di specifica è quella importante; è dove vive il protocollo effettivo.

NIP con adozione parziale

Alcuni NIP esistono ma sono implementati in modo incoerente tra i client. Questo crea casi limite in cui la tua esperienza varia a seconda del client.

NIP-44 (DM crittografati). Adottato da Damus, Primal, Amethyst, e la maggior parte dei client principali nel 2024-2025. Alcuni client più vecchi supportano solo NIP-04. Se invii un DM a qualcuno il cui client supporta solo NIP-04, i tuoi messaggi NIP-44 a lui falliscono silenziosamente. La risposta pratica: usa un client moderno e spera che il tuo corrispondente faccia lo stesso.

NIP-17 (DM avvolti come regalo). DM che nascondono i metadati. L'adozione nel 2026 sta crescendo ma non è universale. La funzionalità è ottima dove entrambe le parti supportano i client; altrimenti ricade silenziosamente su DM meno privati.

NIP-46 (firmatari remoti). Consente a un firmatario hardware o a un'app bunker di firmare event per conto di un client. Supportato in Amethyst, parziale altrove.

NIP-65 (elenco dei relay dell'utente). Consente agli utenti di pubblicare i loro relay preferiti in modo che i client possano instradare automaticamente ai posti giusti. L'adozione sta migliorando; i client più vecchi lo ignorano.

NIP-50 (ricerca). Consente ai client di interrogare i relay per corrispondenze di testo. Alcuni relay lo supportano; molti no. La qualità della ricerca è incoerente di conseguenza.

Verificare quali NIP un determinato client supporta è una diagnostica utile quando qualcosa non funziona come previsto. La maggior parte dei client pubblica la loro matrice di supporto NIP nella loro documentazione.

Come il processo NIP mantiene il protocollo coerente

Nessuna autorità centrale, quindi la coerenza deriva dalla dinamica sociale. Alcuni appunti:

I cattivi NIP non si propagano. Una proposta che duplica un NIP esistente o risolve il problema sbagliato riceve un'adozione minima e muore silenziosamente. La comunità non è formale ma è opinabile.

I buoni NIP vengono implementati indipendentemente. Più sviluppatori di client leggono proposte e decidono indipendentemente. Le buone idee accumulano adottanti; le cattive idee no.

I NIP concorrenti emergono a volte. Due diverse proposte per la stessa funzionalità possono coesistere per un po'. Di solito uno vince nella pratica perché più client lo implementano; a volte si uniscono.

Evoluzione compatibile con il fork. Poiché i NIP sono opzionali, un client può implementare NIP-X-v1 e successivamente aggiornare a NIP-X-v2 senza rompere chiunque supporti solo v1. Il protocollo non si divide.

È disordinato ma funzionale. Il protocollo è evoluto significativamente in cinque anni senza un corpo di governance centrale perché il meccanismo sociale di "gli implementatori leggono, gli implementatori decidono, gli implementatori codificano" ha abbastanza allineamento da produrre coerenza.

Proporre il tuo NIP

Se hai un'idea per una nuova funzionalità Nostr:

1. Controlla prima il repository dei NIP. Qualcuno potrebbe averla già proposta.
2. Se no, apri un issue su GitHub descrivendo il problema che stai risolvendo.
3. In base al feedback, redigi un NIP completo seguendo il formato esistente.
4. Invia una pull request.
5. Partecipa alla discussione. Sii disposto a revisionare.
6. Se viene incorporato, fantastico. Se non lo è, il problema potrebbe avere una soluzione migliore; considera il perché.

Non ogni buona idea diventa un NIP. Non ogni NIP diventa una funzionalità. L'ecosistema ha più proposte di quante qualsiasi singolo sviluppatore potrebbe tracciare, e il filtro è "implementa abbastanza della comunità?" Quel filtro è il cuore di come Nostr rimane coerente senza essere top-down.