Nostr WoT
NostrNIP-02Web of TrustСписки подписок

Список подписок Nostr является полным снимком

Событие kind 3 не добавляет одну подписку. Оно заменяет предыдущий список автора, поэтому безопасная последовательность состоит из чтения, изменения, подписи и проверки.

Nostr WoT Newsroom

Статья4 мин чтения

Материал подготовлен редакцией Nostr WoT на основе указанных первоисточников и опубликован автоматически, без индивидуальной проверки человеком.

Список подписок Nostr является полным снимком

Подписка на человека в интерфейсе Nostr выглядит как добавление: нажать Follow и добавить один профиль. Но событие, отправляемое на релеи, не является командой добавить один ключ. NIP-02 определяет kind 3 как полный список подписок автора и говорит, что каждый новый список перезаписывает предыдущие.

Поэтому обновление списка состоит из чтения, изменения, подписи и публикации. Клиент должен взять список, который собирается заменить, изменить весь этот набор и подписать новое событие со всеми записями, которые должны остаться. Публикация только нового тега p не является небольшим обновлением. Это замена списка одной записью.

Каждый p-тег содержит больше, чем ключ

Массив тегов содержит один тег p для каждого отслеживаемого или известного профиля. Первое значение содержит 32-байтовый публичный ключ в шестнадцатеричном виде. Две необязательные позиции могут содержать рекомендуемый URL релея и локальный petname:

json
["p", "<32-byte-hex-pubkey>", "wss://relay.example", "alice"]

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

Значение relay подсказывает, где могут находиться события профиля. Оно не предписывает публиковать там и не доказывает, что релей по-прежнему обслуживает этот ключ. Petname является локальным контекстом, выбранным автором списка. Это не глобальное имя пользователя и не подтверждённая личность.

Kind 3 заменяется по автору и kind

NIP-01 относит kind 3 к заменяемым событиям. Для каждой комбинации pubkey и kind релей обязан хранить самое новое событие и может удалить старые версии. Если у двух кандидатов одинаковый timestamp created_at, побеждает событие с меньшим ID в лексикографическом порядке.

Это правило определяет один текущий снимок, но не описывает слияние снимков. Если телефон подписывается на Alice из списка со 100 записями, а ноутбук подписывается на Bob из старого списка с 90, ноутбук может позже опубликовать 91 запись и заменить версию телефона. Alice исчезнет, хотя на ноутбуке никто не нажимал Unfollow.

Объединение всех старых событий также не является безопасным восстановлением. Старая версия может содержать людей, которых автор намеренно удалил. Клиент, объединяющий все увиденные списки, может вернуть эти подписки и их подсказки релеев. Детерминированным победителем является текущее заменяемое событие, а не самый большой список.

Несколько релеев могут временно расходиться

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

Клиент при восстановлении списка должен опросить выбранные релеи, проверить подписи и сравнить кандидатов по правилам порядка заменяемых событий. Нельзя считать первый ответ релея глобально актуальной версией. После публикации повторное чтение с нескольких релеев помогает подтвердить, что выбранный снимок доступен там, где ожидалось.

У удаления есть похожее ограничение. NIP-02 говорит, что релеи и клиенты должны удалять старые списки после получения нового. Эта рекомендация не доказывает, что каждый релей удалил каждую старую копию. Новое событие определяет текущий список, но не является криптографическим подтверждением удаления.

Более безопасная последовательность обновления

Перед изменением списка получите победившее событие kind 3 с релеев аккаунта. Сохраните каждый нужный тег p и его необязательные значения. Примените изменение подписки, релея или petname ко всему набору. Используйте новый timestamp, подпишите один раз и опубликуйте одно и то же событие на выбранных релеях.

Затем получите его снова и проверьте ID события, автора и количество тегов. Если список может редактировать другое устройство, сравните ID исходного события перед публикацией. Несовпадение означает, что базовый снимок изменился и правку нужно повторить поверх более нового списка.

Этот процесс не превращает подписки в оценки доверия. Он защищает входные данные, которые используют многие инструменты Web of Trust. Главное свойство просто: событие kind 3 содержит весь текущий список. Отношение к нему как к операции добавления может стереть связи; отношение как к версионированному снимку делает конфликт видимым до подписанной замены.

Источники

Каждое утверждение в этом материале ссылается на первоисточник.

  1. NIP-02: Follow List в коммите b82211e — nostr-protocol/nips (20 сентября 2026 г.)
  2. NIP-01: базовый поток протокола в коммите b82211e — nostr-protocol/nips (4 сентября 2026 г.)

Будьте в курсе

Получайте новости о выпущенных версиях Nostr WoT, новых функциях и интеграциях.

Вы будете получать рассылку на русском языке.

Мы сохраняем ваш адрес электронной почты и предпочитаемый язык для отправки рассылки.

Рассылки