Il NIP-66 guadagna misure difensive

Cosa è cambiato

La PR, aperta da alltheseas, aggiunge sei righe alla specifica. Secondo la descrizione della PR, nasce da una discussione sugli "insegnamenti dei benchmark" del NIP-66 in una issue di nostrability/outbox, dove diversi sviluppatori avevano sollevato dubbi sui percorsi problematici della specifica e sulle implicazioni di affidarsi ai dati di un monitor.

La nuova sezione recita:

• I client NON DEVONO richiedere eventi 30166 per funzionare. L'assenza di dati di monitoraggio NON DEVE impedire una connessione al relay.
• Un monitor può pubblicare eventi 30166 errati, sia per configurazione sbagliata sia per intenti malevoli.
• I client NON DOVREBBERO fidarsi di un'unica fonte. Le difese suggerite includono il filtraggio tramite web of trust, l'interrogazione di più monitor e lo scarto dei risultati di filtraggio di un monitor se applicarli rimuoverebbe una proporzione irragionevole di relay.

Perché è importante

Il NIP-66 riguarda la scoperta dei relay, quindi il rischio qui non è che un monitor attacchi direttamente un relay. Riguarda cosa fa un client con i dati che un monitor gli fornisce. Un evento 30166 è semplicemente un altro evento Nostr: chiunque può pubblicarne uno, corretto o meno. Prima di questa modifica, la specifica non diceva cosa dovesse fare un client se i dati di un monitor si fossero rivelati errati, per sbaglio o intenzionalmente.

Le tre aggiunte colmano questo vuoto dal lato client. La prima regola mantiene il monitoraggio come miglioramento opzionale anziché come dipendenza, così un client che non riesce a raggiungere alcun monitor, o non riceve risposta, deve comunque potersi connettere ai relay normalmente. La seconda regola nomina la minaccia senza mezzi termini: un monitor può sbagliare, per caso o deliberatamente. La terza regola offre ai client modi concreti per reagire: confrontare i monitor tra loro, ponderarli tramite web of trust e trattare un filtro che escluderebbe una proporzione irragionevole di relay come un segnale che il problema è il filtro stesso, non i relay.

Nel loro insieme, le modifiche descrivono un client che tratta i dati di un relay monitor come uno degli input possibili, non come una verità assoluta. Questo si allinea al resto del design di Nostr, dove nessun singolo pubblicatore di un tipo di evento è autorevole e ai client si chiede di verificare incrociando le fonti.

Come sono fatti gli eventi del NIP-66

Un evento 30166 porta un tag d con l'URL normalizzato del relay, oltre a tag aggiuntivi come rtt-open, rtt-read e rtt-write per i tempi di round-trip, N per i NIP supportati e R per i flag dei requisiti NIP-11 come auth o payment. Il campo content dell'evento può includere il documento NIP-11 del relay come riportato dal monitor. Nulla di tutto ciò cambia con questa PR. A cambiare è l'indicazione su quanto un client dovrebbe fare affidamento su questi dati.

La modifica ha toccato solo 66.md, con sei righe aggiunte e nessuna rimossa.