NIP-67 добавляет подсказку auth в EOSE

NIP-67 добавляет к сообщению EOSE необязательный третий элемент: массив строк-подсказок, описывающих набор сохранённых событий, который клиент только что дочитал. С момента слияния в июне в нём было определено две подсказки. Pull request #2371, открытый fiatjaf 6 июня и слитый 1 сентября 2026 года, добавляет третью.

На бумаге изменение небольшое, 12 добавленных строк и 16 удалённых в двух файлах, и оно затрагивает как NIP-67, так и NIP-42.

Третья подсказка

Две существующие подсказки отвечают на вопрос о хранилище релея. "finish" означает, что релей отправил все сохранённые события, подходящие под фильтры подписки, и клиенту следует прекратить пагинацию. "more" означает, что релей придерживает подходящие сохранённые события, которые не отправил, и клиенту следует запросить их пагинацией.

Новое значение отвечает уже на вопрос о клиенте:

"auth": у релея могут быть ещё сохранённые события, подходящие под фильтры подписки, если пользователь выполнит AUTH (NIP-42).

Это неполнота другого рода. "more" описывает результат, урезанный собственными лимитами релея, которые пагинация рано или поздно исчерпает. "auth" описывает результат, урезанный тем, кем является клиент, и пагинация этого не исправит никогда. До появления этой подсказки со стороны клиента оба случая были неразличимы: неаутентифицированная подписка, вернувшая частичную выборку данных релея, завершалась тем же EOSE, что и подписка, вернувшая всё.

Требование к порядку

Остальная часть фразы и есть нормативная часть. Релеи MUST гарантировать, что сообщение AUTH с challenge отправлено до EOSE, несущего подсказку "auth".

Это следует из того, как NIP-42 работает уже сейчас. Клиент не может аутентифицироваться по собственной инициативе: он подписывает challenge, выбранный релеем. NIP-42 прямо формулирует это требование для своих существующих сценариев: у клиента должен быть сохранённый challenge, связанный с этим релеем, чтобы отреагировать на сигнал аутентификации. Релей, отправивший подсказку без challenge, потребовал бы от клиента действия, которое тот выполнить не может.

В NIP-42 появляется соответствующий раздел, auth hint in EOSE, который повторяет то же правило со стороны аутентификации и отсылает за определением к NIP-67. Релеи MAY использовать подсказку; если используют, challenge AUTH идёт первым.

Место среди существующих сигналов

У NIP-42 уже было два способа потребовать аутентификацию, и оба что-то завершают. auth-required в сообщении CLOSED закрывает подписку и не возвращает событий. auth-required в сообщении OK отклоняет запись.

Подсказка "auth" покрывает случай, которого не было ни у одного из них: ничего не сломалось. Релей принял подписку, отдал то, что неаутентифицированному клиенту полагалось видеть, и штатно завершил фазу сохранённых событий. Подсказка это пометка на успешном ответе, сообщающая, что выборка была частичной по причинам, на которые клиент может повлиять. Доставка событий в реальном времени по этой подписке продолжается по обычным правилам NIP-01, как и для всех прочих подсказок NIP-67, которые относятся только к сохранённым событиям.

Подсказки также сочетаются. Добавленный в спецификацию пример заканчивается строкой ["EOSE", "sub4", ["auth", "finish"]], оба значения сразу. Вместе они говорят, что релей отправил всё, что отправит при текущем уровне аутентификации клиента, и что более высокий уровень может открыть больше. Таким образом, "finish" относится к запрашивающему, а не является абсолютным утверждением о хранилище релея.

Убранные примеры

Pull request также удалил два примера из спецификации, оба показывали релеи без поддержки NIP-67, возвращающие EOSE из двух элементов, и заменил их случаем с аутентификацией. Текст, описывающий это устаревшее поведение, остался в теле спецификации, так что ничего нормативного вместе с ними не пропало.

Деталь для тех, кто будет копировать новый пример: в его строке REQ стоит идентификатор подписки sub2b, как в примере выше, тогда как строки EVENT и EOSE используют sub4.

Больше в NIP-67 ничего не изменилось. Он остаётся draft и optional, релеи с его поддержкой по-прежнему объявляют 67 в своём документе NIP-11, а клиенты без поддержки по-прежнему игнорируют третий элемент как замыкающий элемент массива, который они никогда не читают.