El NIP-66 gana medidas defensivas

Qué cambió

La PR, abierta por alltheseas, añade seis líneas a la especificación. Según la descripción de la PR, surge de una discusión sobre los "aprendizajes de benchmarks" del NIP-66 en un issue de nostrability/outbox, donde varios desarrolladores plantearon inquietudes sobre los caminos problemáticos de la especificación y las implicaciones de depender de los datos de un monitor.

La nueva sección dice:

• Los clientes NO DEBEN requerir eventos 30166 para funcionar. La ausencia de datos de monitoreo NO DEBE impedir una conexión a un relay.
• Un monitor puede publicar eventos 30166 erróneos, ya sea por una mala configuración o con intención maliciosa.
• Los clientes NO DEBERÍAN confiar en una sola fuente. Las defensas sugeridas incluyen filtrado por web of trust, consultar a varios monitores y descartar los resultados de filtrado de un monitor si aplicarlos eliminara una proporción irrazonable de relays.

Por qué importa

El NIP-66 trata sobre el descubrimiento de relays, así que el riesgo aquí no es que un monitor ataque directamente a un relay. Se trata de qué hace un cliente con los datos que le entrega un monitor. Un evento 30166 es simplemente otro evento de Nostr: cualquiera puede publicar uno, correcto o no. Antes de este cambio, la especificación no decía qué debía hacer un cliente si los datos de un monitor resultaban ser incorrectos, ya fuera por error o a propósito.

Las tres adiciones cierran esa brecha desde el lado del cliente. La primera regla mantiene el monitoreo como una mejora opcional en lugar de una dependencia, de modo que un cliente que no pueda alcanzar ningún monitor, o que no reciba respuesta, siga pudiendo conectarse a los relays con normalidad. La segunda regla nombra la amenaza sin rodeos: un monitor puede estar equivocado, por accidente o deliberadamente. La tercera regla da a los clientes formas concretas de responder: contrastar monitores entre sí, ponderarlos según el web of trust y tratar un filtro que excluiría una proporción irrazonable de relays como una señal de que el problema es el filtro, no los relays.

En conjunto, los cambios describen un cliente que trata los datos de un monitor de relays como una entrada más entre varias, no como una verdad absoluta. Esto encaja con el resto del diseño de Nostr, donde ningún publicador de un tipo de evento es la autoridad única y se espera que los clientes corroboren la información.

Cómo lucen los eventos del NIP-66

Un evento 30166 lleva una etiqueta d con la URL normalizada del relay, además de etiquetas adicionales como rtt-open, rtt-read y rtt-write para los tiempos de ida y vuelta, N para los NIPs soportados y R para las banderas de requisitos del NIP-11 como auth o payment. El content del evento puede incluir el documento NIP-11 del relay tal como lo reportó el monitor. Nada de eso cambia con esta PR. Lo que cambia es la orientación sobre cuánto debería apoyarse un cliente en esos datos.

El cambio afectó solo a 66.md, con seis líneas añadidas y ninguna eliminada.