NIP-78 закрывает данные приложений за AUTH

Новый раздел

Всё добавленное умещается в три предложения под новым заголовком ## AUTH:

Because this data is private to the user, relays SHOULD require clients to perform the NIP-42 AUTH flow before accepting or serving kind 78 and kind 30078 events, and SHOULD only serve these events to the authenticated owner, i.e. the client must authenticate with the same pubkey as the event author.

В этой фразе два требования, и это не одно и то же, сказанное дважды. Первое про дверь: выполнить процедуру аутентификации, прежде чем реле примет одно из таких событий или выдаст его. Второе про совпадение: пройдя аутентификацию, клиент получает только те события, которые сам и записал. Реле, которое требовало бы AUTH, а затем отдавало настройки всех пользователей любому, кто потрудился представиться, выполнило бы первое и провалило второе.

Сравнение pubkey идёт с автором события. Это стоит отметить, потому что ближайший существующий прецедент опирается на другое. В NIP-17 давно есть похожая строка про приватные личные сообщения:

Relays SHOULD protect message metadata by only serving kind:1059 events to users p-tagged on the event (enforced using NIP-42 AUTH).

Там получатель указан в теге, потому что gift wrap подписан одноразовым ключом и его поле автора ничего полезного не сообщает. События NIP-78 подписывает сам пользователь, поэтому поле автора и есть владелец, и никакой тег для их поиска не нужен.

Оба kind, а не один

Пул-реквест озаглавлен "require AUTH for kind 30078", и в его описании упомянут только этот kind. Влитый текст охватывает и kind 78. Здесь стоит следовать файлу, а не заголовку: нормативная фраза называет оба.

Различие существенно, потому что это разные типы событий. 30078 адресуемое, ключом служит тег d, и реле хранит по одному на каждого автора и значение d. 78 обычное событие, добавленное в спецификацию в мае 2026 года, для приложений, которым нужно хранить и запрашивать много записей одного типа, а не единственный блок. Реализация, закрывшая только адресуемый kind, оставила бы открытым случай с множеством записей, а именно он с большей вероятностью накопит заметный объём пользовательских данных.

Абзац про обмен

Вторая половина изменения это абзац, вставленный ближе к началу, перед определениями событий:

These kinds are not meant to be used as a generic interchange format for data that should be public or exchanged between different applications. Applications that need such interoperability should use dedicated kinds instead.

Это рекомендация, а не нормативное правило, без единого MUST или SHOULD, но именно у неё появляются практические последствия, как только реле начнут применять раздел ниже. Данные, записанные в 30078 в расчёте на то, что их прочитают другие приложения, перестают быть для них читаемыми в тот момент, когда реле переходит на выдачу только владельцу. Спецификация заранее фиксирует, что такое применение в её задачи не входило.

Теперь это NIP про реле

Строка ключевых слов в заголовке изменилась с draft optional на draft optional relay. Раньше NIP-78 описывал только то, что клиенты кладут внутрь события; теперь он предписывает реле, как с ним обращаться, и это ровно то, что помечает данное ключевое слово. Сейчас его несут девятнадцать файлов спецификации, включая NIP-78, рядом с NIP-01, NIP-42, NIP-17 и прочими документами о поведении реле.

Что видят клиенты

NIP-42 уже определяет, что реле отправляет при отсутствии аутентификации. Запрос, который нельзя обслужить, даёт CLOSED с префиксом auth-required: , а отклонённая запись даёт OK со значением false и тем же префиксом. Клиенту, который уже обрабатывает эти два случая для шифрованных личных сообщений, не нужен новый механизм для данных приложений, достаточно распространить ту же обработку ещё на пару kind.

Есть и более мягкий сигнал. NIP-42 указывает на подсказку auth в EOSE, добавленную в NIP-67 первого сентября, которая позволяет реле ответить на запрос, штатно его закрыть и сообщить, что аутентификация вернула бы больше. Реле, выбравшее этот путь, на неаутентифицированный запрос 30078 вернуло бы пустой результат, а не ошибку.

Больше в NIP-78 ничего не сдвинулось. Он по-прежнему draft и optional, kind и соглашения об их теге d не изменились, а перечисленные в конце сценарии использования остались теми же тремя.