Запросы NIP-09 не доказывают полное удаление

Удаление публикации в клиенте Nostr не отправляет команду, способную достичь каждого реле, кэша и устройства. Клиент публикует ещё одно подписанное событие. NIP-09 определяет его как kind 5, запрос на удаление, который указывает на одно или несколько событий тегами e или a.

Различие важно. Корректный запрос даёт сотрудничающим программам информацию, чтобы перестать отдавать или показывать событие. Он не делает указанные байты невосстановимыми и не доказывает, что каждый прежний получатель стёр свою копию.

Kind 5 указывает, что автор хочет убрать

Тег e называет конкретный ID события. Тег a адресует заменяемое событие по его виду, открытому ключу и идентификатору d. NIP-09 также говорит, что запросу следует содержать тег k для каждого указанного вида события. В поле content автор может объяснить причину удаления.

Для ссылки e запрос действителен только тогда, когда у указанного события и запроса kind 5 совпадают открытые ключи. Клиент обязан проверить это перед скрытием или удалением. Без такой проверки любой мог бы подписать запрос, чтобы публикация другого автора исчезла из совместимых интерфейсов.

Ссылка a имеет более широкий охват. Реле должны удалить все версии заменяемого события до метки created_at запроса. Более новые версии в него не входят, поэтому время является частью границы.

Реле получают просьбу, а не дистанционное управление

NIP-09 говорит, что реле следует удалить совпадающие события или перестать их публиковать. Он не утверждает, что реле можно заставить это сделать. Реле может не получить запрос, не хранить указанное событие или применять другую политику хранения.

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

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

Подпись доказывает авторство, а не глобальное удаление

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

Реле независимы, а клиенты могут получать события через несколько подписок. Снимок экрана, локальная база, экспорт или архивное реле могут сохраниться, даже если все обычные реле автора приняли запрос. Поэтому NIP-09 прямо разрешает предупреждать, что удаление невозможно гарантировать на всех реле и клиентах.

То же ограничение относится к зашифрованным событиям. Удаление шифротекста с сотрудничающих реле снижает будущую доступность, но не отзывает уже загруженные копии. Шифрование и удаление решают разные задачи.

Что клиент может проверить

Клиент может проверить подпись kind 5, убедиться, что каждое указанное через e событие принадлежит тому же автору, и записать, какие реле приняли запрос. Затем он может снова опросить эти реле и убедиться, что они больше не возвращают цель. Такие проверки дают полезное свидетельство для определённого набора реле.

Они не создают глобальную квитанцию об удалении. Ответ одного реле ничего не говорит о неопросенных серверах, клиентах вне сети или копиях за пределами сети реле.

Практическое правило состоит в том, чтобы считать публикацию Nostr долговечной. Используйте kind 5, когда материал нужно отозвать, передавайте запрос реле, получившим оригинал, и позволяйте клиентам скрывать корректные цели. Но не публикуйте секреты в расчёте, что будущий запрос вернёт каждую копию. NIP-09 координирует удаление. Он не превращает распределённую сеть в систему дистанционного стирания.