Проверяйте NIP-05, не приравнивая домен к доверию

NIP-05 упрощает обмен длинным публичным ключом Nostr, связывая его с интернет-идентификатором вроде alice@example.com. Это помогает находить профиль, но слово «проверенный» часто обещает больше, чем доказывает протокол.

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

Начните с подписанного профиля

Прямой поток начинается с самого нового действительного события kind 0 для публичного ключа. Его JSON может содержать поле nip05:

json

{
  "name": "Alice",
  "nip05": "alice@example.com"
}

Разделите локальную часть и домен. В локальной части допустимы только строчные a-z, цифры и -_.. Затем запросите:

text

https://example.com/.well-known/nostr.json?name=alice

Ответ должен содержать объект names, где точная запись alice равна тому же публичному ключу из события kind 0: 64 шестнадцатеричных символа в нижнем регистре. Формат npub предназначен для отображения и в этом ответе недопустим.

Сравнение двустороннее. Подписанный профиль говорит: «этот ключ заявляет этот идентификатор». Ответ HTTPS говорит: «этот домен сейчас назначает это имя этому ключу». Показывайте идентификатор только при совпадении обеих сторон.

Обратному поиску тоже нужна вторая сторона

Поиск может начинаться с alice@example.com, но не должен заканчиваться ключом из ответа домена. Клиенту следует получить самое новое действительное событие kind 0 этого ключа и подтвердить, что его поле nip05 содержит тот же идентификатор.

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

Особую локальную часть _ можно показывать как один домен. _@example.com может отображаться как example.com, но сетевой запрос все равно использует name=_.

Следуйте за публичным ключом, а не за адресом

NIP-05 не является изменяемым указателем контакта. Если пользователь подписался на ключ, найденный по alice@example.com, список контактов должен хранить этот публичный ключ. Нельзя хранить идентификатор как команду заменить ключ в будущем.

Предположим, сегодня домен связывает alice с ключом A, а через месяц с ключом B. Клиент должен перестать показывать NIP-05 у ключа A, когда связь больше не совпадает. Он не должен незаметно переносить подписку с A на B. Передача домена, взлом сервера, ошибка настройки или переназначение иначе смогут переписать социальный граф пользователя.

Это важно и для расчетов Web of Trust. Ребра принадлежат публичным ключам. Текущее сопоставление с доменом может быть доказательством рядом с ключом, но не заменяет узел и не должно наследовать оценку доверия ключа после изменения.

Считайте сетевые правила правилами безопасности

У well-known endpoint есть строгие требования:

Используйте HTTPS и точный домен из идентификатора.
Игнорируйте редиректы. NIP-05 запрещает endpoint возвращать их, а клиенту следовать им.
Требуйте шестнадцатеричные ключи и имена в нижнем регистре.
В браузерном клиенте отличайте неверную связь от неопределенного сетевого сбоя. Отсутствие Access-Control-Allow-Origin: * может скрыть от JavaScript действительный endpoint.
Читайте только запрошенное имя из names; не принимайте похожее написание или предполагаемую нормализацию.

Эти правила не дают удобному идентификатору превратиться в открытый механизм редиректов или нормализации. Интерфейс должен различать «связь не совпадает» и «проверку выполнить не удалось».

Подсказки релеев помогают поиску, а не идентичности

Ответ может содержать рекомендуемый объект relays, индексированный по публичному ключу. Эти URL помогают найти событие kind 0 и другие события человека. Они не усиливают доказательство между именем и ключом и не гарантируют, что событие существует, принято или останется сохраненным.

Используйте подсказки как ограниченный источник для обнаружения. Они не должны стирать настройки релеев пользователя или заменять более свежие сведения о маршрутизации без явной политики.

Кэшируйте результат, время и причину

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

Храните как минимум идентификатор, публичный ключ, результат, время проверки и класс ошибки. Периодически перепроверяйте совпадения, а сетевые сбои повторяйте раньше подтвержденных расхождений. При изменении поля nip05 в kind 0 немедленно аннулируйте старый результат.

Практичная модель включает четыре состояния:

совпадает: обе стороны согласны сейчас;
расходится: endpoint ответил, но имя или ключ отличаются;
недоступно: DNS, TLS, HTTP или CORS не позволили сделать вывод;
недействительно: идентификатор, JSON или ключ нарушают NIP-05.

Безопасный список проверок

Перед отображением NIP-05:

Проверьте подпись самого нового действительного события kind 0.
Проверьте синтаксис и нижний регистр локальной части.
Запросите точный well-known URL без перехода по редиректам.
Сравните точное имя с точным шестнадцатеричным ключом в нижнем регистре.
При обратном поиске получите kind 0 и подтвердите в нем тот же идентификатор.
Привязывайте подписки, ребра доверия и ссылки на аккаунт к публичному ключу.
Записывайте время проверки и отдельно объясняйте неопределенные сбои.

NIP-05 полезен тем, что добавляет читаемый поиск, не меняя криптографический якорь идентичности Nostr. Самый безопасный интерфейс точно сообщает проверенный факт: этот домен и этот подписанный ключ сейчас согласны относительно этого имени.