Le NIP-66 gagne des mesures défensives

Ce qui a changé

La PR, ouverte par alltheseas, ajoute six lignes à la spécification. Selon la description de la PR, elle fait suite à une discussion sur les "enseignements des benchmarks" du NIP-66 dans une issue de nostrability/outbox, où plusieurs développeurs avaient soulevé des inquiétudes sur les scénarios problématiques de la spécification et les implications de s'appuyer sur les données d'un moniteur.

La nouvelle section indique :

• Les clients NE DOIVENT PAS exiger d'événements 30166 pour fonctionner. L'absence de données de surveillance NE DOIT PAS empêcher une connexion à un relais.
• Un moniteur peut publier des événements 30166 erronés, que ce soit par mauvaise configuration ou intention malveillante.
• Les clients NE DEVRAIENT PAS faire confiance à une seule source. Les défenses suggérées incluent le filtrage par web of trust, l'interrogation de plusieurs moniteurs et le rejet des résultats de filtrage d'un moniteur si leur application supprimerait une proportion déraisonnable de relais.

Pourquoi c'est important

Le NIP-66 concerne la découverte de relais, donc le risque ici n'est pas qu'un moniteur attaque directement un relais. Il s'agit de ce qu'un client fait des données qu'un moniteur lui fournit. Un événement 30166 n'est jamais qu'un événement Nostr comme un autre : n'importe qui peut en publier un, correct ou non. Avant ce changement, la spécification ne précisait pas ce qu'un client devait faire si les données d'un moniteur s'avéraient fausses, que ce soit par erreur ou intentionnellement.

Les trois ajouts comblent cette lacune du côté client. La première règle maintient la surveillance comme une amélioration optionnelle plutôt qu'une dépendance, de sorte qu'un client incapable de joindre un moniteur, ou qui n'obtient pas de réponse, doit quand même pouvoir se connecter normalement aux relais. La deuxième règle nomme la menace sans détour : un moniteur peut se tromper, par accident ou délibérément. La troisième règle donne aux clients des moyens concrets de réagir, en recoupant les moniteurs entre eux, en les pondérant via le web of trust, et en traitant un filtre qui exclurait une proportion déraisonnable de relais comme un signal que le problème vient du filtre lui-même, pas des relais.

Pris ensemble, ces changements décrivent un client qui traite les données d'un moniteur de relais comme une entrée parmi d'autres, et non comme une vérité absolue. Cela correspond au reste de la conception de Nostr, où aucun publicateur unique d'un type d'événement ne fait autorité et où les clients sont censés recouper les informations.

À quoi ressemblent les événements du NIP-66

Un événement 30166 porte un tag d avec l'URL normalisée du relais, ainsi que des tags supplémentaires comme rtt-open, rtt-read et rtt-write pour les temps d'aller-retour, N pour les NIP pris en charge, et R pour les indicateurs d'exigences NIP-11 comme auth ou payment. Le champ content de l'événement peut inclure le document NIP-11 du relais tel que rapporté par le moniteur. Rien de tout cela ne change avec cette PR. Ce qui change, c'est la recommandation sur le degré de confiance qu'un client devrait accorder à ces données.

Le changement n'a touché que 66.md, avec six lignes ajoutées et aucune supprimée.