NIP-A3 добавляет цели платежей payto: в репозиторий NIP

Событие

NIP-A3 определяет kind:10133 и помечает его как заменяемое. Это следует из NIP-01, где любой kind n при 10000 <= n < 20000 является заменяемым: для каждой комбинации pubkey и kind реле обязано хранить только последнее событие и может отбросить прежние версии. Таким образом, у пользователя одновременно есть только один список целей платежей, и публикация нового списка замещает предыдущий.

Поле content остаётся пустым. Всё содержится в тегах:

["payto", "<type>", "<authority>", "<optional_extra_1>", "<optional_extra_2>", ...]

Первый элемент это буквальная строка payto. Второй это тип платежа, например bitcoin или lightning. Третий это полномочие: адрес или имя пользователя, формат которого зависит от платёжной системы. Всё, что идёт дальше, зарезервировано для будущих возможностей RFC-8905.

Правило прямой совместимости прописано явно: клиенты обязаны понимать элементы с 0 по 2 и могут игнорировать любые дополнительные элементы.

Валидация

type ограничен строчными латинскими буквами, цифрами и дефисами. Типы нечувствительны к регистру, и спецификация предписывает приводить их к нижнему регистру. authority должен быть безопасным для URL, а специальные символы следует кодировать. Помимо этого, клиенты могут применять валидацию, специфичную для платёжной системы, к тем типам, которые они распознают.

Со стороны записи спецификация предписывает клиентам принимать неизвестные им типы. Шаг 3 её списка реализации говорит, что клиент может предупредить пользователя о нераспознанном типе, но всё равно должен разрешить отправку. Пример события в спецификации содержит тег с типом unknowntype рядом с bitcoin и nano.

Отображение

Для каждого тега payto клиенту следует собрать URI payto://<type>/<authority> и показать его как кнопку или ссылку. Именно эта форма URI и является целью NIP. RFC-8905 уже стандартизирует payto: как схему URI для вызова целей платежей, поэтому NIP-A3 не изобретает новую схему; он несёт части, нужные для её сборки.

Распознанные типы отображаются со значком и оформлением. NIP-A3 включает таблицу из восьми рекомендуемых типов, у каждого из которых есть длинное название, короткое название, символ и ссылка на фирменные материалы самой платёжной системы. Эти восемь: bitcoin, cashme для Cash App, ethereum, lightning, monero, nano, revolut и venmo.

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

Связь с zap

Заметки по реализации разбирают пересечение с NIP-57. У платежей через Lightning уже есть путь в nostr: поле lud16 в метаданных профиля kind 0, декодируемое как запрос на оплату lnurl. NIP-A3 говорит, что клиенты могут использовать тег payto типа lightning как альтернативу lud16 или как дополнение к нему, указав в поле полномочия адрес lightning или LNURL.

Разобранный пример показывает оба варианта вместе: событие kind 0 с lud16 и событие kind 10133 с целью lightning с тем же адресом плюс целью bitcoin. Ни одно не заменяет другое. Ничто в диффе не объявляет lud16 устаревшим и не меняет NIP-57.

Для разработчиков

Реле не требуется ничего нового. Kind 10133 попадает в заменяемый диапазон, который они уже обрабатывают, а payto это обычный тег.

Для клиентов сторона чтения невелика: подписаться на kind 10133 для видимых на экране pubkey, разобрать теги, собрать URI и показать результат. Сторона записи требует формы с полем типа и полем полномочия, двух правил валидации выше и заменяемой публикации.

NIP-A3 помечен как optional и содержит строку author:atxmj. Пометки draft у него нет. Ничто не обязывает клиент его реализовывать, о чём README репозитория NIP говорит применительно ко всему списку.