NIP-02 даёт petname разрешаемые пути

Каждый компонент ведёт к списку одного человека

Объединённый текст NIP-02 определяет разрешение по одному компоненту. Если список пользователя сопоставляет erin одному ключу, а список Erin сопоставляет charlie другому, клиент разрешает ~/erin/charlie: сначала ищет erin локально, получает последнее событие kind 3 от Erin и затем ищет в нём charlie.

Прежний текст показывал производные имена вроде frank.david.erin, но не задавал грамматику пути или порядок поиска. Новая версия описывает направление работы разрешателя: начать с корня, найти первое имя, затем использовать список этого профиля для следующего имени.

Форма ~ использует вошедшего пользователя как относительный корень. NIP-02 также приводит два абсолютных корня для случая без входа или когда текущий контекст не подходит:

~npub1.../erin/charlie
[email protected]/erin/charlie

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

Читаемый путь не доказывает доверие

Пути могут показывать социальный контекст без единого центра, который раздаёт все имена. В интерфейсе web of trust ~/erin/charlie может быть полезнее отдельного ключа, потому что описывает, как пользователь приходит к Charlie через Erin.

Такой путь не является криптографическим доказательством личности. Событие kind 3 подписано, поэтому клиент может проверить, кто опубликовал каждое сопоставление. Однако автор может выбрать вводящий в заблуждение petname, изменить его или указать другой ключ. NIP-02 также говорит, что новый список заменяет предыдущий. Разрешателю нужно последнее действительное событие на каждом шаге.

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

Детали разбора остаются открытыми

Merge меняет один файл: добавляет десять строк и удаляет двадцать. Он определяет относительные и абсолютные примеры, но не задаёт экранирование petname с /, пробелами или другими специальными символами. Эти случаи подняли в комментариях после merge, и текущий NIP пока их не решает.

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

Полезная граница ясна: NIP-02 описывает цепочку локально назначенных имён. Он не делает их глобально уникальными идентификаторами, не заменяет проверку публичных ключей и не устанавливает оценку доверия.