Используйте списки релеев NIP-65, не теряя посты и…

Клиент Nostr не должен считать, что все релеи выполняют одну и ту же роль. Пользователь может публиковать свои события в одном наборе релеев, а другой использовать для событий, в которых его упоминают. NIP-65 позволяет объявить это разделение подписанным заменяемым событием kind 10002.

Направление легко перепутать. Write-релеи пользователя показывают, где искать созданные им события. Его read-релеи показывают другим авторам, куда доставлять события с его тегом. Ошибка может выглядеть как пропавшие посты или упоминания, хотя сами релеи исправны.

Read и write описывают поведение владельца списка

Событие kind 10002 хранит URL в тегах r. Необязательное третье значение равно read или write:

json

{
  "kind": 10002,
  "tags": [
    ["r", "wss://posts.example", "write"],
    ["r", "wss://mentions.example", "read"],
    ["r", "wss://both.example"]
  ],
  "content": ""
}

Релей без маркера относится к обеим группам. Метки читаются с точки зрения владельца. write означает «здесь я обычно публикую события», а read означает «здесь я обычно читаю упоминания». Это не разрешения и не обещание, что релей примет соединение, сохранит событие или будет хранить его всегда.

Kind 10002 входит в заменяемый диапазон NIP-01, поэтому самое новое событие для публичного ключа вытесняет старые версии. При редактировании клиент должен публиковать полный список, а не частичное изменение. Если метки времени совпадают, NIP-01 выбирает событие с лексикографически меньшим ID.

Посты пользователя ищут в его write-релеях

Чтобы загрузить события от пользователя, NIP-65 советует обращаться к его write-релеям. Там следует искать обычные заметки и другие созданные им события.

Это кажется обратным, если воспринимать write как команду текущему клиенту. Но маркер сообщает, где пишет владелец списка, а значит, где остальные должны читать его публикации.

Если профиль выглядит пустым, сначала проверьте событие 10002. Клиент может знать публичный ключ, но искать только в собственных релеях по умолчанию. Добавление write-релеев автора в план запроса способно вернуть публикации без изменения постоянных настроек пользователя.

Упоминание доставляют в read-релеи получателя

При публикации клиент должен отправить событие в write-релеи автора. Если событие тегирует другого пользователя, его нужно отправить и в read-релеи этого пользователя. Так маршрут объединяет хранение у автора и доставку получателю.

Если Алиса пишет в Relay A, а упоминания читает в Relay B, клиент Боба должен опубликовать ответ в write-релеях Боба и в Relay B Алисы. Relay A поможет найти посты Алисы, но не соответствует объявленному ею входящему маршруту.

Доставка не гарантирована. Релей может требовать аутентификацию, оплату или соблюдение другой политики. Получатель может изменить список, а клиенты могут по-разному поддерживать NIP-65. Список задаёт маршрут, но не является квитанцией.

Список должен быть небольшим и доступным

NIP-65 рекомендует по два-четыре релея в каждой категории. Длинный список увеличивает число соединений, дубликатов и операций публикации. Дополнительные релеи дают резервирование, но требуют ресурсов и могут раскрывать больше информации о поведении пользователя.

Само событие списка тоже нужно обнаружить. NIP-65 предлагает широко распространять его, в том числе через известные публичные индексаторы, к которым клиенты обращаются за списками. Событие также следует отправлять на выбранные релеи вместе с публикациями. Иначе правильный список останется невидимым.

Практическая последовательность проверки

Если посты или упоминания отсутствуют:

Найдите новейшее действительное событие 10002 для публичного ключа.
Считайте немаркированные теги r одновременно read и write.
Ищите события автора в его write-релеях.
Отправляйте тегированные события в read-релеи получателя и write-релеи автора.
Отдельно фиксируйте выбор маршрута и подтверждение приёма каждым релеем.
Осторожно используйте значения по умолчанию, если список не найден: его отсутствие не доказывает правильность конкретного релея.

NIP-65 не создаёт единый глобальный набор релеев. Он позволяет каждому пользователю опубликовать направления для двух разных потоков. Их соблюдение упрощает диагностику и помогает не принять ошибку маршрутизации за потерю данных.