Il protocollo Nostr, spiegato in parole semplici

Un protocollo è un insieme di regole per come i programmi comunicano tra loro. Una piattaforma è un'azienda che esegue quei programmi per conto tuo. Twitter è una piattaforma. La posta elettronica è un protocollo. Nostr è un protocollo.

La distinzione è importante perché protocolli e piattaforme hanno diverse modalità di guasto, diverse strutture di costo e diversi futuri. Questa guida spiega cosa rende Nostr un protocollo specificamente, cosa significa in pratica, e perché il design rimane intenzionalmente piccolo.

TL;DR. Nostr è un protocollo di messaggistica pub/sub con firme crittografiche. Definisce un piccolo formato di evento e un modo semplice per i client di inviare e ricevere quegli eventi tramite relay. Nessuna azienda lo possiede. Chiunque può scrivere un client, eseguire un relay, o proporre estensioni. La specifica principale si adatta a poche pagine.

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

Cosa un protocollo effettivamente è

La posta elettronica è un buon paragone. Quando invii un'email da Gmail a Outlook, Gmail non ha bisogno del permesso di Outlook. Entrambi i servizi parlano SMTP (il protocollo email), e SMTP definisce tutto ciò che è necessario affinché un server di posta consegni un messaggio a un altro. I server sono aziende diverse. Il protocollo è un accordo neutrale.

Nostr funziona allo stesso modo. Un evento Nostr (un post, un like, un follow) è un oggetto JSON con una forma specifica definita nel protocollo. Un relay è qualsiasi server che accetta, memorizza e invia avanti eventi conformi a quella forma. Due client qualsiasi che parlano Nostr possono interagire tramite qualsiasi relay che parla Nostr, indipendentemente da chi ha creato uno qualsiasi dei tre.

Il protocollo è un accordo neutrale. Le implementazioni sono libere di essere qualsiasi cosa.

La specifica Nostr, nelle fewest sentences possibili

Tre regole coprono quasi tutto.

1. Un evento è un oggetto JSON con id, pubkey, created_at, kind, tags, content, sig. L'id è un hash dei campi rimanenti; il sig è una firma Schnorr sull'id usando la controparte privata del pubkey.
2. Un relay accetta eventi validi tramite WebSocket e serve sottoscrizioni che filtrano gli eventi per autore, kind, tag o tempo.
3. Un client firma gli eventi e li pubblica ai relay; legge gli eventi sottoscrivendosi ai relay con filtri.

Questo è il protocollo principale. Ogni funzionalità avanzata (articoli lunghi, zap, DM, comunità, liste) è un'estensione che si adatta a questo modello senza cambiarlo.

Perché il protocollo rimane piccolo

La maggior parte dei protocolli crescono per accrezione. Ogni caso d'uso si aggiunge alla specifica; ogni decennio la specifica è più grande di quella del decennio precedente. HTTP ora è centinaia di pagine. La posta elettronica è cresciuta da una manciata di RFC a un intrico. Nostr ha evitato questo per scelta consapevole.

Il meccanismo è i NIP (Nostr Implementation Possibilities). Nuove funzionalità non vengono aggiunte alla specifica principale; vengono proposte come NIP opzionali. I client implementano i NIP che interessano loro. Altri client li ignorano. Un NIP popolare diventa parte del protocollo pratico perché abbastanza implementazioni lo parlano; un NIP impopolare scompare senza cerimonia.

Questo significa che il core rimane per sempre piccolo (gli invarianti importanti: eventi firmati, relay aperti, identità portabile) e i bordi rimangono per sempre flessibili (nuove funzionalità evolvono senza rompere i client esistenti). Un client Nostr del 2022 funziona ancora nel 2026 perché il core non è cambiato; fa semplicemente meno cose rispetto ai client più nuovi.

Protocollo vs piattaforma, concretamente

Cinque differenze pratiche che puoi sentire come utente.

Identità. Su una piattaforma, il tuo account è di proprietà dell'azienda. Su un protocollo, il tuo account è un'identità crittografica che possiedi. Nessuno può portarlo via.

Dati. Su una piattaforma, i tuoi post vivono nel loro database. Su un protocollo, i tuoi post vivono su più relay indipendenti. Se uno scompare, gli altri li hanno ancora.

Velocità delle funzionalità. Su una piattaforma, le funzionalità vengono rilasciate quando l'azienda decide. Su un protocollo, le funzionalità vengono rilasciate quando qualsiasi implementatore le scrive. Questo è più lento in alcuni modi (nessun roadmap centrale) e più veloce in altri (molti esperimenti in parallelo).

Monetizzazione. Su una piattaforma, l'azienda cattura tutta la monetizzazione. Su un protocollo, la monetizzazione è quello che gli utenti e gli implementatori concordano. Nostr ha zap (mance peer-to-peer su Lightning) perché si adatta alla cultura; una diversa comunità di protocolli potrebbe arrivare a norme diverse.

Modalità di guasto. Una piattaforma può scomparire completamente. Un protocollo no; finché un implementatore rimane attivo, il protocollo vive. Nostr è progettato in modo che anche se fiatjaf (l'autore originale) scomparisse domani, la rete continuerebbe a funzionare senza cambiamenti.

Cosa il protocollo esplicitamente non fa

Cinque cose omesse dalla specifica intenzionalmente.

Moderazione. Il protocollo non decide quale contenuto è accettabile. Ogni relay ha le sue regole; ogni client ha i suoi filtri; ogni utente ha la sua lista di silenziati. La moderazione avviene ai bordi, non nel core.

Ricerca. Non c'è ricerca definita dal protocollo. Alcuni relay indicizzano il testo; altri no. I client che vogliono la ricerca si affidano ai relay con capacità di ricerca o eseguono il proprio indicizzazione. L'assenza è deliberata; mantiene il protocollo neutrale su cosa viene trovato.

Ranking. Nessun feed "For You". Nessun ponderazione dell'engagement. I client visualizzano gli eventi per timestamp per impostazione predefinita; qualsiasi altro ordinamento è una decisione a livello di client, non di protocollo.

Scoperta. Nessun motore di raccomandazione. Trovare nuovi account da seguire è una funzionalità di client, non una funzionalità di protocollo. Alcuni client investono molto in questo (Primal); altri lo lasciano agli utenti (Damus).

Recupero. Nessuna reimpostazione di account. Perdi la chiave privata, perdi l'account. Il protocollo potrebbe includere la rotazione delle chiavi ma non lo fa, perché i compromessi sono reali e la comunità non ha concordato su un meccanismo specifico ancora. Questa è un'area in corso (progetti NIP-26, NIP-41).

Ogni omissione è una scelta. I protocolli rimangono piccoli rifiutandosi di risolvere ogni problema a livello di protocollo.

Chi decide cosa diventa Nostr

Nessuno e tutti.

Non c'è una Nostr Foundation. Nessun gruppo di lavoro aziendale. Nessun comitato di governo. L'autorità più concentrata ovunque nell'ecosistema è il repository GitHub di fiatjaf dove vengono proposti i NIP, e anche questo è solo un punto di coordinamento, non un gatekeeper.

I NIP proposti vengono letti dagli sviluppatori di client. Quelli popolari vengono implementati. Un NIP che tre client principali implementano è effettivamente parte del protocollo; un NIP che uno sviluppatore ha scritto ma nessun altro se ne importa è solo un documento su GitHub.

Questo processo è disordinato. Ci sono problemi di coordinamento, proposte duplicate e occasionali politiche. È anche resiliente in un modo specifico: nessuna singola parte può rovinarla prendendo una brutta decisione, perché le brutte decisioni semplicemente non vengono adottate. Il protocollo evolve in direzioni approssimative dal peso delle scelte degli sviluppatori, non per decreto.

Quando il modello di protocollo vince

I protocolli battono le piattaforme in condizioni specifiche:

• Quando la proprietà è più importante della raffinatezza. I protocolli sono solitamente meno raffinati delle piattaforme. Vincono quando ti importa di ciò che la raffinatezza non può darti (identità permanente, resistenza alla censura, interoperabilità aperta).
• Quando l'effetto di rete è la funzionalità. Il valore di un protocollo cresce con l'adozione da parte degli implementatori, non solo degli utenti. Più client e relay rendono la rete più forte in modi che una piattaforma non può copiare.
• Quando l'orizzonte a lungo termine è importante. Le piattaforme vengono acquistate, vendute, chiuse o cambiate. I protocolli sopravvivono a qualsiasi implementatore singolo. La posta elettronica è più vecchia della maggior parte delle aziende; Nostr sta scommettendo sulla stessa dinamica.

Se il tuo caso d'uso non corrisponde a nessuno di questi, una piattaforma è solitamente più veloce e facile. Questo è onesto. Nostr non è universalmente migliore di Twitter per ogni possibile utilizzo. È migliore nei modi specifici in cui un protocollo batte una piattaforma.

Leggere la specifica effettiva

Se questa guida ti ha fatto venire voglia di leggere il protocollo direttamente, il repository dei NIP ha l'elenco completo. NIP-01 è il core; i NIP numerati dopo di esso sono estensioni. Non hai bisogno di capire nulla di tutto questo per usare Nostr, ma leggere NIP-01 richiede circa dieci minuti e chiarisce molto.