NIP-66 получает меры защиты

Что изменилось

PR, открытый пользователем alltheseas, добавляет в спецификацию шесть строк. Согласно описанию PR, он появился после обсуждения "выводов из бенчмарков" NIP-66 в issue проекта nostrability/outbox, где несколько разработчиков высказали опасения по поводу нештатных сценариев спецификации и последствий доверия данным монитора.

Новый раздел гласит:

• Клиенты НЕ ДОЛЖНЫ требовать события 30166 для своей работы. Отсутствие данных мониторинга НЕ ДОЛЖНО препятствовать подключению к релею.
• Монитор может публиковать ошибочные события 30166 -- как из-за неправильной настройки, так и со злым умыслом.
• Клиентам НЕ СЛЕДУЕТ доверять единственному источнику. Среди предложенных мер защиты: фильтрация через web of trust, опрос нескольких мониторов и отбрасывание результатов фильтрации одного монитора, если их применение убрало бы неоправданно большую долю релеев.

Почему это важно

NIP-66 касается обнаружения релеев, поэтому риск здесь не в том, что монитор атакует релей напрямую. Дело в том, что клиент делает с данными, которые ему передаёт монитор. Событие 30166 -- это просто ещё одно событие Nostr: опубликовать его может кто угодно, правильное оно или нет. До этого изменения спецификация не говорила, что должен делать клиент, если данные монитора окажутся неверными -- по ошибке или намеренно.

Три добавления закрывают этот пробел со стороны клиента. Первое правило оставляет мониторинг необязательным дополнением, а не зависимостью: клиент, который не может достучаться ни до одного монитора или не получает ответа, всё равно должен подключаться к релеям в обычном режиме. Второе правило прямо называет угрозу: монитор может ошибаться, случайно или намеренно. Третье правило даёт клиентам конкретные способы реагирования -- сверять данные разных мониторов между собой, взвешивать их через web of trust и рассматривать фильтр, который отсёк бы неоправданно большую долю релеев, как сигнал того, что проблема в самом фильтре, а не в релеях.

Вместе эти изменения описывают клиента, который относится к данным монитора релеев как к одному из нескольких источников, а не как к абсолютной истине. Это согласуется с остальной архитектурой Nostr, где ни один издатель определённого типа события не является единственным авторитетом, и от клиентов ожидается перепроверка данных.

Как выглядят события NIP-66

Событие 30166 содержит тег d с нормализованным URL релея, а также дополнительные теги: rtt-open, rtt-read и rtt-write для времени отклика, N для поддерживаемых NIP и R для флагов требований по NIP-11, таких как auth или payment. Поле content события может включать документ NIP-11 релея, зафиксированный монитором. Ничего из этого этот PR не меняет. Меняется только рекомендация о том, насколько клиенту стоит полагаться на эти данные.

Изменение затронуло только 66.md: шесть добавленных строк и ни одной удалённой.