Nostr è un protocollo per social network che non ha un'azienda dietro e non ha un server centrale. È nato da una costatazione semplice: i social network hanno un problema strutturale, e non si risolve aggiungendo funzioni.
Il problema è questo: l'account non è tuo. Il contenuto è tuo, ma la capacità di pubblicarlo dipende da un'azienda che può chiudere l'account, censurare il contenuto, vendere i dati o semplicemente fallire. Nessuna impostazione nei menu cambia la struttura.
Nostr sposta il controllo. Ma — e questa è la parte che quasi tutti gli articoli su Nostr omettono — il controllo che sposta è sui tuoi dati, non sulla tua identità. La privacy che promette è reale, e ha limiti precisi che vanno detti prima di usarli.
Che cos'è, in una frase
Ogni utente ha una coppia di chiavi. Firma eventi con la chiave privata, li pubblica su più relay indipendenti, e li firma in modo che non si possa fingere di essere lui.
Tre parole da definire, e le altre derivano da queste.
Chiavi. Come RSA, una coppia pubblica e privata. La pubblica identifica l'utente, la privata dimostra che è lui. La differenza con una piattaforma è che la chiave privata non esce mai dal tuo dispositivo: nessun amministratore la vede, perché non ce l'ha.
Eventi. L'unico oggetto che esiste in Nostr. Letteralmente: la
specifica NIP-01 dice che esiste un solo tipo di oggetto, event.
Questa è la parte più elegante e più importante del protocollo.
{
"id": <32 byte, sha256 dei dati serializzati, hex>,
"pubkey": <32 byte, chiave pubblica dell'autore, hex>,
"created_at": <timestamp unix in secondi>,
"kind": <intero da 0 a 65535>,
"tags": [ [<stringa>...], ... ],
"content": <stringa arbitraria>,
"sig": <64 byte, firma Schnorr secp256k1, hex>
}
Sette campi. Non c'è un campo username, non c'è un campo email, non
c'è un id_utente numerico progressivo. L'identità è la chiave pubblica.
Relay. Sono i server. Ma non sono "il server": sono relay indipendenti e intercambiabili, e tu ti connetti a quanti ne vuoi, in parallelo. Il protocollo prescrive che il client tenga una connessione WebSocket per relay e la usi per tutte le sottoscrizioni.
Il punto è che se un relay chiude, gli altri continuano. Non è resilienza, è struttura: non esiste un punto unico di fallimento perché non esiste un punto unico.
I tipi di evento, che è dove sta la semplicità
I kind sono interi, e le fasce hanno un significato che la specifica
definisce con precisione. È la parte che rende il protocollo estensibile
senza essere progettato prima.
| Fascia | Comportamento del relay |
|---|---|
1, 4-44, 1000-9999 | regolari: il relay li conserva tutti |
0, 3, 10000-19999 | sostituibili: per ogni pubkey+kind tiene l'ultimo |
20000-29999 | effimeri: non li conserva, servono al tempo reale |
30000-39999 | indirizzabili: per kind+pubkey+tag d tiene l'ultimo |
Le fasce non sono una decorazione: sono un meccanismo di riduzione dello spazio di archiviazione. In un social normale non si può scrivere "questa è la mia bio" senza creare un record nuovo; in Nostr pubblichi un kind 0 e il relay butta via il precedente. Il risultato è che un utente attivo occupa poco, e il relay non deve crescere all'infinito.
Il tipo più usato è il kind 1, la nota di testo, definito in NIP-10
invece che in NIP-01. Il kind 0 è l'unico definito nella specifica
base: contiene un JSON con name, about e picture.
I tag sono array di stringhe e sono il meccanismo dei riferimenti. Ce
ne sono tre standard: e punta a un altro evento, p a un altro utente,
a a un evento sostituibile. Tutte le lettere sono indicizzabili, e solo
il primo valore di ciascun tag lo è.
["REQ", <id_sovscrizione>,
{ "kinds": [1], "authors": ["<pubkey>"], "limit": 20 }]
Questa è una richiesta di sottoscrizione: mandami le note di quell'utente,
al massimo 20, e tienimi aggiornato. Il client comunica con il relay in
trei messaggi soltanto: EVENT per pubblicare, REQ per chiedere e
sottoscriversi, CLOSE per chiudere.
Perché è importante, e dove sbaglia
Fin qui sembra tutto meglio. Il punto onesto è un altro, e lo pongo prima dei benefici perché senza questo l'articolo è propaganda.
Nostr non nasconde chi sei. La chiave pubblica è pubblica per definizione, e ogni evento che pubblichi è firmato. Chiunque legga un tuo evento può sapere quale account lo ha scritto, in modo verificabile e permanente.
Quindi Nostr non è anonymity. Se pubblichi che cosa pensi, e poi ti
trovi un contatto che sa dove abiti, l'indirizzo IP del tuo router
riconosce la connessione con quel tuo pubkey. Non serve un software
particolare: serve l'abitudine di correlare.
La privacy che Nostr offre è di un altro tipo, ed è comunque reale:
nessun account può essere chiuso dal fornitore, perché non c'è un fornitore che lo possiede;
nessuna profilazione centralizzata, perché nessuno ha il quadro completo: ogni relay vede un pezzo, e i pezzi sono di utenti diversi;
la cancellazione la decidi tu, con un kind 5 che chiede la rimozione ai relay. Non è automatica e non è garantita: è una richiesta;
il tuo contenuto è tuo, indipendentemente dal fatto che ci sia qualcuno che lo ospita.
E c'è una proprietà che le piattaforme non possono replicare per costituzione:
la portabilità. Il tuo pubkey e i tuoi eventi sono tuoi ovunque.
Nessuna piattaforma può chiederti di ricominciare da zero perché hai cambiato
servizio. È la stessa proprietà che vale per il
repository Git,
e per la stessa ragione.
I tre modi in cui si compromette
Li scrivo esplicitamente perché sono il punto debole reale, e chiunque te li venda come un protocollo "che non può violare la privacy" sta ignorandoli.
1. Il relay che vede tutto. Un singolo relay che è fedele e ha molto traffico vede tutti gli eventi che gli passano, con gli IP dei client collegati. È il caso peggiore, ed è la ragione per cui usare un solo relay è un errore. Va bene conoscerne tre o quattro fidati, non uno solo.
2. Il modello del client. Qui la privacy è quanto bene è scritto il client che usi. Lo schema è privato-by-design, ma un client può fare cose che lo rendono meno privato: salvare in locale tutto quello che vede, mandare telemetria, mostrare pubblicità. La privacy è una proprietà dell'implementazione, non del protocollo. È il punto più importante di tutti.
3. Il danno è permanente. Un evento cancellato resta nella cronologia di tutti i relay che l'hanno ricevuto. Non c'è rollback, non c'è transazione, non c'è "stiamo ripristinando il backup": c'è una registrazione append-only replicata su server indipendenti. Questo è il prezzo dell'immutabilità, ed è il motivo per cui non si scrive su Nostr la stessa cosa che non scriveresti su un canale Telegram.
Un po' di storia
Il contesto. Nostr nasce dalla frustrazione di uno sviluppatore brasiliano noto solo come fiatjaf, che nel 2020 descrive il problema in modo netto: i social network sono incentrati su account che possono essere revocati, e chiunque può essere bandito senza appello. La proposta era di non avere utenti: solo chiavi ed eventi.
Il precedente esisteva ed era stato provato: ActivityPub, il protocollo di Mastodon, e Secure Scuttlebutt. Entrambi risolvevano il problema della censura, ma fiatjaf li considerava sbagliati per motivi tecnici e culturali. ActivityPub è complesso da federare e lascia il controllo ai singoli amministratori di server; Secure Scuttlebutt è pesante da gestire. La sua scelta progettuale è stata la semplicità radicale: chiavi, eventi, relay.
Il nome. Nostr sta per Notes and Other Stuff Transmitted by Relays — note e altro trasmesso dai relay. È l'acronimo che compare sulla documentazione ufficiale.
2020-2022: la specifica. La prima versione del protocollo viene pubblicata e prende il nome che conosciamo. NIP-01 è il documento fondativo e resta quello che definisce il funzionamento di base: se vuoi capire Nostr, le sue centottanta righe sono il punto di partenza, e sono un documento corto.
Il 2023: l'adozione. È l'anno in cui il protocollo esce dal gruppo ristretto e arriva nel pubblico largo. Il progetto assume la forma che ha adesso: la specifica vive in un repository pubblico di proposte di miglioramento, ognuna numerata, chiamate NIP.
Il repository come fonte di verità. È una scelta che vale la pena notare: non c'è un'azienda che pubblica le regole, c'è un repository con proposte aperte che chiunque può leggere e proporre di cambiare. Chi progetta software libero conosce il modello, ed è la ragione per cui l'articolo su Open source: perché conviene al software a pagamento si applica anche qui.
Le firme Schnorr. La specifica usa le firme Schnorr sulla curva secp256k1, lo stesso standard di BIP-340 di Bitcoin. La scelta non è casuale: Schnorr produce firme più piccole e verificabili in modo più efficiente, e su una rete in cui ogni relay verifica ogni evento la differenza di costo si sente.
La viralità del 2023. Il caso che porta Nostr fuori dal gruppo ristretto è legato a un account ad altissimo profilo che entra nel protocollo, e il motivo per cui resta nella storia è che non può essere bandito: non c'è il pulsante. Questo è l'argomento che ha fatto conoscere il protocollo, ed è anche il suo limite. Il caso d'uso dimostrato è "pubblicare senza poter essere censurato", non "comunicare in privato".
2024 in poi. I NIP cominciano ad avere sottospegniature, come NIP-05 per gli identificatori leggibili e NIP-09 per le richieste di cancellazione. È il segnale che il protocollo è entrato nella fase in cui servono gli standard, non le idee.
Cosa significa per chi lavora in sicurezza
Qui il discorso cambia, e vale la pena renderlo esplicito.
La firma è la parte solida. Un evento firmato è non negoziabile e verificabile: nessuno, relay compreso, può mostrare un tuo evento con una firma falsa. È una garanzia più forte di quella che dà qualsiasi social commerciale, dove il badge "verificato" è un'etichetta del fornitore.
La tracciabilità è il punto debole. Un attaccante che si connette a un
relay e vede gli eventi firmati da un certo pubkey ha costruito un
profilo di quell'identità. Non può impersonarlo, ma può sapere quando
è attivo e di che cosa si occupa. È il rovescio diretto dell'anonimato,
ed è il motivo per cui il protocollo è adatto a chi ha paura della censura
e inadatto a chi ha bisogno di sparire.
L'assenza di moderazione è un problema di sicurezza, non una libertà. In un protocollo senza autorità non esiste un canale per segnalare contenuti illeciti, e non esiste nessuno che ti obblighi a toglierli. Per una piattaforma è una scelta di design; per un'azienda che espone dati personali a terzi è un problema normativo, prima che tecnico.
Le implicazioni sono valide solo dopo aver verificato l'implementazione. Il punto su cui la maggior parte dei commenti sbaglia è questo: dire "uso Nostr, quindi sono privato" senza aver letto il codice del client è una dichiarazione di fiducia, non una garanzia.
La regola che usiamo noi
Il ragionamento di CYBER ONIONS su Nostr è breve, e non è approvazione:
Un protocollo che ti restituisce il controllo dei dati è un buon protocollo. Un protocollo che ti restituisce il controllo anche dell'identità, non lo è — e non è che sia tecnicamente impossibile: è che ogni vantaggio di Nostr si trasforma nel suo costo.
Detto altrimenti, con le regole che seguiamo quando lo usiamo:
più relay, mai uno solo: un relay fedele che vede tutto basta a ricostruire ciò che gli altri insieme tengono frammentato;
- client con codice leggibile, verificato prima di fidarci dei dati;
niente dati personali negli eventi: la firma rende l'evento permanente, e la cancellazione è una richiesta che può non essere onorata;
Nostr per l'identità verificabile, non per l'anonimato: se devi sparire, non è lo strumento giusto.
Se di tutto questo resta una cosa sola: controlla il client, non solo il protocollo. Il protocollo è una specifica pubblica e non può cambiare sotto di te; il client è un programma che qualcuno ha scritto, e quello sì può cambiare — o può essere buggy — senza che tu lo sappia.