Nostr Wallet Connect

Анна слухає подкаст і хоче надіслати автору невелику суму через Lightning Network. З NWC програвач може безпосередньо попросити її гаманець виконати платіж. Сервіс гаманця спочатку перевіряє права з’єднання, а потім виконує дозволений запит. NWC не визначає, хто зберігає ключі від біткоїнів: з іншого боку може бути власний вузол Анни або сервіс, який тримає кошти за неї. Однакова кнопка «Під’єднати гаманець» тому може означати різний рівень контролю над грошима. Залежно від наданих прав застосунок також може діяти без нового підтвердження кожного окремого платежу. [1] [2]

Гаманець зазвичай надає QR-код або текстовий рядок з’єднання, технічно URI. Він містить публічний ключ сервісу, адресу relay та secret — приватний ключ цього клієнтського з’єднання. Це не seed, початкове таємне значення гаманця, і не його Seed Phrase, слова відновлення. Але й не нешкідливе публічне посилання: власник придатної копії може користуватися тими самими дозволами. Можливі збитки залежать від доступних функцій та лімітів. Окремі з’єднання для різних застосунків дозволяють розрізняти їх і відкликати по одному, а також зменшують можливість пов’язати їх між собою. [1]

Застосунку може бути потрібне лише читання балансу або також надсилання грошей. Це різні права. Публічна подія info оголошує можливості сервісу; get_info повертає методи, доступні конкретному з’єднанню. Метод — команда з назвою: pay_invoice запитує оплату, make_invoice створює платіжний запит, lookup_invoice перевіряє його стан, get_balance читає баланс. Сам get_info також належить до основного набору. Історія, keysend — платіж без заздалегідь створеного рахунку — та сповіщення є необов’язковими розширеннями. Підтримка команди сервером не дозволяє кожному під’єднаному застосунку виконувати її. [1] [3] [5]

Анна може виділити програвачу лише обмежений бюджет. Якщо сервіс пропонує ліміти витрат, методів або строку дії, він сам має забезпечувати їх виконання. Число лише на екрані програвача не захищає від застосунку, який надішле інший запит. Перевірте також, чи бюджет одноразовий, чи поновлюваний і як враховуються комісії. Коли Анна перестає користуватися застосунком, слід відкликати його права в сервісі гаманця. Видалення застосунку або локального з’єднання не доводить, що доступ скасовано. Відкликання блокує майбутні запити, але не повертає вже завершений платіж. [1]

Рахунок Lightning є запитом на оплату, наприклад у форматі BOLT11, а не доказом платежу. NIP-47 виражає суми й комісії в msat, тисячних частках satoshi: 1000 msat = 1 sat. Плутанина в одиницях змінює суму в тисячу разів. make_invoice лише створює запит. Успішний pay_invoice повертає preimage. З цього значення обчислюють хеш — коротке контрольне значення. Він має відповідати платіжному хешу рахунку; повернена preimage слугує свідченням завершення платежу. Відповідь про помилку використовує error. Стан можна з’ясувати через lookup_invoice. Застосунок має опрацювати справжній результат, а не повідомляти про успіх відразу після надсилання повідомлення. [1]

Анна натискає «Сплатити», але відповіді немає. Timeout, завершення часу очікування, ще не пояснює, що сталося з грошима. NWC використовує для запитів і відповідей ефемерні події; від’єднаний relay або недоступний сервіс можуть спричинити втрату повідомлення. Проте загубитися могла лише відповідь після вже завершеного платежу. Спочатку перевірте стан через lookup_invoice або в самому гаманці. Мовчання не підтверджує невдачу. Новий запит не можна автоматично вважати безпечним повторенням попередньої дії; насамперед потрібно з’ясувати її результат. [1]

Застосунок і гаманець обмінюються зашифрованими повідомленнями. Поточне узгодження надає перевагу nip44_v2, а застаріле nip04 залишається для сумісності. Відсутність мітки encryption означає старіший режим. Водночас NIP-44 не забезпечує forward secrecy — захисту попередньої комунікації в разі пізнішого витоку довготривалого ключа. Relay також може бачити типи подій, мітки, публічні ключі з’єднань і час обміну. Тому для NWC не слід використовувати основний ключ ідентичності, яким людина публікує в Nostr. Окремі ключі допомагають зменшити зв’язування платежів із публічним профілем, але не гарантують повної анонімності. [1] [4]

Для звичайного користування не потрібно пам’ятати номери повідомлень, але вони важливі під час розроблення інтеграції. Info використовує kind 13194, запити — 23194, відповіді — 23195. kind визначає тип події. Мітка p указує іншу сторону, а e у відповіді посилається на початковий запит. Клієнт перевіряє підпис, очікуваний ключ сервісу, цей зв’язок і result_type — назву команди, до якої належить результат. Довільного повідомлення від relay недостатньо для підтвердження. Інакше чужу відповідь або відповідь на іншу дію можна помилково прийняти за результат цього платежу. [1]