Come funziona veramente Nostr: il protocollo, senza gergo

La maggior parte delle spiegazioni di Nostr si ferma a "è un protocollo social decentralizzato" e lascia la parte interessante non detta. La parte interessante è che l'intero protocollo rientra in un documento breve. Nessun trucco intelligente, nessuna complessità nascosta. Solo alcuni primitivi che funzionano insieme.

Questa guida percorre quei primitivi nell'ordine in cui si presentano quando effettivamente usi Nostr: come viene costruito un evento, come viene firmato, come raggiunge i relay, come i client si sottoscrivono, e quale sia il flusso quando metti un like a un post, ricevi una risposta, o ricevi uno zap. Nessun confronto con blockchain, nessuna grande narrazione. Solo i meccanismi.

TL;DR. Nostr è pub/sub su WebSocket con firme crittografiche. I client pubblicano oggetti JSON firmati (eventi) ai relay (piccoli server), e altri client si sottoscrivono ai relay con filtri che corrispondono agli eventi che vogliono. Le firme prevengono le contraffazioni; i relay multipli prevengono singoli punti di fallimento. Questo è l'intero protocollo; tutto il resto è convenzioni di formattazione per diversi tipi di contenuto.

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

Il blocco costitutivo: un evento

Tutto su Nostr è un evento. Un post è un evento. Una reazione è un evento. Un aggiornamento del profilo è un evento. Un messaggio diretto è un evento. Una ricevuta di zap è un evento.

Un evento è un oggetto JSON con esattamente questa forma:

{
  "id": "abc123...",
  "pubkey": "0a4f7b1a3d9a1529a3080c3ae5ee553e0af0a01d86d01677c0bb270592923f88",
  "created_at": 1776329035,
  "kind": 1,
  "tags": [
    ["t", "nostr"],
    ["p", "3bf0c63f..."]
  ],
  "content": "hello nostr",
  "sig": "def456..."
}

Sei campi svolgono un lavoro significativo. id è un hash del contenuto stesso dell'evento; lo identifica in modo univoco. pubkey è l'autore (una chiave pubblica esadecimale a 64 caratteri). created_at è un timestamp Unix. kind è un intero che descrive cosa rappresenta l'evento (vedi più avanti). tags è una lista di annotazioni strutturate come hashtag (t), menzioni (p per pubkey, e per evento), e dozzine di altri. content è il payload in formato libero, solitamente testo.

sig è la firma Schnorr, creata con la chiave privata dell'autore, sull'hash in id. Questo è il campo che previene le contraffazioni: chiunque può calcolare l'hash, ma solo il detentore della chiave privata può produrre una firma valida su di esso.

Cos'è un "kind"

Il campo kind dice ai client come interpretare l'evento. Il numero è l'intero tipo semantico.

Una manciata di kind in uso attivo:

I nuovi kind vengono proposti e standardizzati tramite NIP (Nostr Implementation Possibilities). Chiunque può proporne uno. Quelli che ottengono un'ampia adozione diventano de facto parti del protocollo; quelli che non lo fanno rimangono semplicemente di nicchia senza rompere nulla.

Come un evento viene pubblicato

Quando tocchi "post" in un client Nostr, questa sequenza viene eseguita:

1. Il client assembla il JSON. Riempie pubkey, created_at, kind, tags, content.
2. Il client calcola l'id. Esegue SHA-256 su una serializzazione canonica di questi campi. Questo è l'hash che la firma copre.
3. Il client firma l'id con la chiave privata. Firma Schnorr su secp256k1, la stessa curva che Bitcoin utilizza. La firma a 64 byte diventa il campo sig.
4. Il client apre connessioni WebSocket a ogni relay configurato. O ne riutilizza quelle esistenti se sono attive.
5. Il client invia l'evento come messaggio. Il formato on-wire è un array JSON: ["EVENT", {...event...}].
6. Ogni relay valida la firma. Rifiuta l'evento se la firma non si verifica rispetto al pubkey rivendicato. Accetta e archivia altrimenti.
7. Ogni relay spinge l'evento ai sottoscritti. Qualsiasi client con una sottoscrizione aperta il cui filtro corrisponde a questo evento riceve l'evento consegnato in tempo reale.

L'intero round-trip impiega 50-300 millisecondi a seconda delle posizioni dei relay. Se un relay è lento o offline, gli altri relay continuano comunque a pubblicare l'evento. Hai bisogno che solo un relay lo accetti perché l'evento esista sulla rete.

Come un client recupera i post

La lettura è lo specchio della pubblicazione.

Il tuo client apre connessioni WebSocket a una lista di relay. Per ciascuno, invia un messaggio di sottoscrizione:

["REQ", "sub_id_1", { "authors": ["pubkey1", "pubkey2", ...], "kinds": [1, 6], "limit": 50 }]

Questo chiede al relay fino a 50 eventi dagli autori nella lista, di kind 1 (nota breve) o kind 6 (repost). Il relay:

1. Interroga il suo database locale per gli eventi corrispondenti, li invia (dal più vecchio al più nuovo per impostazione predefinita, fino al limite) come messaggi EVENT al client.
2. Invia un messaggio EOSE (end of stored events) in modo che il client sappia che il dump storico è completo.
3. Mantiene la sottoscrizione aperta. Qualsiasi nuovo evento che corrisponde al filtro (pubblicato da qualcun altro successivamente) viene spinto al client in tempo reale.

Ecco come il tuo feed diventa live. Non stai eseguendo il polling; il relay sta trasmettendo.

Il tuo client fa questo in parallelo su ogni relay configurato. L'unione delle risposte è la tua timeline. Gli eventi duplicati tra relay vengono deduplicati per id.

Come le firme effettivamente prevengono le contraffazioni

Questa è la parte che la maggior parte delle spiegazioni sorvola.

Quando un client riceve un evento, ricalcola l'hash su la serializzazione canonica (allo stesso modo del publisher) ed esegue la verifica Schnorr: dato il pubkey, l'id e la sig, la firma si verifica crittograficamente?

Se sì, l'evento è autentico. L'autore di questo evento era il detentore di quel pubkey al momento della firma. Ogni client esegue questo controllo su ogni evento. Un relay che spedisce un evento contraffatto con una firma non valida viene semplicemente eliminato da ogni client che lo vede.

Questo è importante perché significa che i relay non sono attendibili. Un relay malevolo non può mettere parole nella tua bocca. Può rifiutarsi di servire i tuoi post, può iniettare post legittimi di qualcun altro nel tuo feed, ma non può produrre un post valido firmato da te senza la tua chiave privata, e non può modificare uno dei tuoi post esistenti senza rompere la firma.

Il costo di questa proprietà è esattamente una verifica Schnorr per evento, che è abbastanza veloce che anche i client mobile la gestiscono a decine di migliaia di eventi al secondo.

Cosa i relay effettivamente fanno

Un relay è un tubo stupido e veloce con tre compiti:

1. Accetta eventi e valida le firme. Rifiuta tutto ciò che non si verifica o fallisce i controlli di politica (filtri spam, limiti di dimensione, pubkey bloccati).
2. Archivia gli eventi. Solitamente in un database SQLite o PostgreSQL indicizzato per id, pubkey, kind e valori di tag.
3. Serve le sottoscrizioni. Abbina i filtri REQ in ingresso al database (per lo storico) e agli eventi live (per il real-time).

Questo è tutto. Un relay non classifica, non consiglia, non cura, non monetizza, non mostra annunci, non applica un algoritmo, e non fa nulla di quello che una piattaforma farebbe. Inoltra byte firmati.

L'assenza di questi altri compiti è il motivo per cui i relay possono essere minuscoli. Un singolo VPS da $5 al mese può eseguire un relay servendo centinaia di utenti attivi. La stessa funzione alla scala di Twitter costa miliardi perché Twitter fa tutti gli altri lavori.

Le politiche del relay differiscono. Alcuni sono senza permessi e servono qualsiasi evento firmato. Alcuni richiedono il pagamento (il modello "paid relay"), altri si limitano a una comunità specifica (dipendenti di un'azienda, membri di un server Discord), e ancora altri sono aggressivi nel filtraggio dello spam. Tu scegli quali relay usare; la tua scelta influenza quali post vedi e quali raggiungono i tuoi follower.

Un esempio completo: a qualcuno piace il tuo post

Mettendo tutto insieme, ecco cosa succede da capo a fondo quando Alice mette un like al post che Bob ha scritto.

1. Bob pubblica. Il client di Bob costruisce un evento kind:1 con contenuto "hello world," lo firma, lo invia ai cinque relay configurati di Bob. Ogni relay accetta e archivia.
2. Alice si sottoscrive. Il client di Alice ha una sottoscrizione aperta su due di quei relay con un filtro che include il pubkey di Bob in authors. I relay spingono l'evento di Bob giù per la sottoscrizione. Il client di Alice mostra il post nella sua timeline.
3. Alice tocca like. Il client di Alice costruisce un evento kind:7 con contenuto "+" (la convenzione "like" di Nostr), tagga il post a cui reagisce (["e", "bob_post_id"]) e l'autore (["p", "bob_pubkey"]). Lo firma e lo pubblica ai cinque relay configurati di Alice.
4. La reazione si propaga. Qualsiasi relay che ha una sottoscrizione attiva che corrisponde al filtro { "#e": ["bob_post_id"], "kinds": [7] } (che è quello che il client di Bob usa per guardare le reazioni ai suoi post) spinge la reazione a Bob. Il client di Bob aggrega i like e mostra il conteggio sotto il post.

Nota cosa non è accaduto. Nessun servizio centralizzato "pulsante mi piace" è stato contattato. Nessun backend ha deciso se contare il like. Il like è solo un evento firmato, annunciato sugli stessi canali del post stesso.

Cosa Nostr esplicitamente non fa

Cinque cose lasciate fuori dal protocollo principale appositamente, perché appartengono al client o al relay, non al formato wire condiviso.

• Verifica dell'identità. Nostr solo prova "questo pubkey ha firmato questo post." Se il pubkey appartiene a un essere umano specifico è una domanda separata risposta da NIP-05 e da contesto off-chain.
• Moderazione dei contenuti. Il protocollo non decide cosa è visibile. I client filtrano, i relay filtrano, gli utenti filtrano. Ogni livello indipendentemente.
• Ricerca. Non c'è un endpoint di ricerca globale. Alcuni relay supportano la ricerca di testo sul loro pool di eventi locale; non c'è alcuna garanzia di protocollo che un relay possa trovare qualsiasi post.
• Ranking algoritmico. Nessun feed "for you" nel protocollo. Il ranking avviene nel client se accade.
• Recupero dell'account. Nessun reset email, nessun reset telefono, nessun sistema centrale di controversie. Perdi la chiave privata, perdi l'identità. Questo è un compromesso, non un bug.

Queste assenze sono quello che rende il protocollo piccolo. Sono anche quello che rende la costruzione di un'esperienza utente raffinata in cima più difficile che costruirne una su una piattaforma centralizzata, che è il costo onesto.

Perché il design funziona affatto

Il design si basa su una semplice proprietà: le firme sono economiche da verificare, la contraffazione è impossibile senza la chiave privata, e i relay sono liberi di sostituire.

Questi tre fatti si compongono. La verifica economica significa che ogni client può verificare ogni evento. La contraffazione impossibile significa che i relay non devono essere attendibili. La sostituzione libera significa che nessun singolo relay ha potere su nessuno.

Mettendoli insieme, ottieni una rete social dove il livello della piattaforma è intercambiabile e il livello dell'identità è di proprietà dell'utente. Che è quello che "decentralizzato" effettivamente significa in pratica, in contrasto con come il marketing di solito usa la parola.

Se vuoi vedere l'intero flusso dal lato dell'utente (una coppia di chiavi, un'identità NIP-05, una lista di relay, un portafoglio, pronto a postare), il signup di nostr.blog collassa questi passaggi in una pagina. I meccanismi descritti qui sono quello che sta effettivamente girando sotto quel flusso.