Nostr Wallet Connect (NWC) to wspólne zasady opisane w dokumencie NIP-47. Pozwalają aplikacji wysyłać żądania do portfela Lightning przez Nostr. Serwer pośredniczący, zwany relayem, przenosi zaszyfrowane polecenia i odpowiedzi, a nie same bitcoiny. Uprawnieniami i realizacją płatności zarządza usługa portfela.
Anna słucha podcastu i chce przesłać jego autorowi niewielką kwotę przez Lightning Network. Dzięki NWC odtwarzacz może bezpośrednio poprosić jej portfel o zapłatę. Usługa portfela najpierw sprawdza uprawnienia połączenia, a potem wykonuje dozwolone żądanie. NWC nie określa, kto przechowuje klucze do bitcoinów: po drugiej stronie może być własny węzeł Anny albo usługa przechowująca środki za nią. Ten sam przycisk „Połącz portfel” może więc oznaczać zupełnie inny zakres kontroli nad pieniędzmi. Zależnie od przyznanych praw aplikacja może też działać bez osobnego potwierdzania każdej płatności. [1] [2]
Portfel zwykle udostępnia kod QR lub tekst połączenia, technicznie URI. Zawiera on klucz publiczny usługi, adres relaya oraz secret, czyli klucz prywatny tego połączenia klienckiego. Nie jest to seed, czyli początkowa tajna wartość portfela, ani jego Seed Phrase, słowa służące do odzyskiwania. Nie jest jednak również nieszkodliwym publicznym linkiem: osoba z działającą kopią może korzystać z tych samych uprawnień. Możliwa szkoda zależy od dozwolonych funkcji i limitów. Osobne połączenia dla różnych aplikacji pozwalają je rozróżniać i niezależnie odwoływać, a także ograniczają możliwość powiązania ich ze sobą. [1]
Aplikacja może potrzebować tylko odczytu salda albo także wysyłania pieniędzy. To różne uprawnienia. Publiczne zdarzenie info ogłasza możliwości usługi; get_info zwraca metody dostępne danemu połączeniu. Metoda to nazwane polecenie: pay_invoice zleca zapłatę, make_invoice tworzy żądanie płatności, lookup_invoice sprawdza jego stan, a get_balance odczytuje saldo. Samo get_info również należy do podstawowego zestawu. Historia, keysend — płatność bez wcześniej utworzonej faktury — oraz powiadomienia są opcjonalnymi rozszerzeniami. Obsługa polecenia przez serwer nie oznacza zgody na jego użycie przez każdą połączoną aplikację. [1] [3] [5]
Anna może chcieć przyznać odtwarzaczowi tylko ograniczony budżet. Jeśli usługa oferuje limity wydatków, metod lub czasu ważności, sama musi je egzekwować. Kwota widoczna wyłącznie w odtwarzaczu nie chroni przed aplikacją wysyłającą inne żądanie. Sprawdź też, czy budżet jest jednorazowy, czy odnawiany, i jak wliczane są opłaty. Gdy Anna przestaje używać aplikacji, powinna odwołać jej uprawnienia po stronie portfela. Usunięcie aplikacji lub jej lokalnego połączenia nie dowodzi cofnięcia dostępu. Odwołanie blokuje przyszłe żądania, ale nie cofa zakończonej płatności. [1]
Faktura Lightning jest żądaniem płatności, na przykład w formacie BOLT11, a nie dowodem zapłaty. NIP-47 wyraża kwoty i opłaty w msat, tysięcznych częściach satoshi: 1000 msat = 1 sat. Pomylenie jednostek zmienia więc kwotę tysiąckrotnie. make_invoice tylko tworzy żądanie. Udane pay_invoice zwraca preimage. Oblicza się z niej hash, czyli krótki skrót kontrolny. Musi on odpowiadać hashowi płatności na fakturze; zwrócona preimage stanowi więc dowód ukończenia płatności. Odpowiedź błędu używa error. Stan można odczytać przez lookup_invoice. Aplikacja musi rozpatrzyć rzeczywisty wynik, nie ogłaszać sukcesu po samym wysłaniu wiadomości. [1]
Anna naciska Zapłać, lecz aplikacja nie dostaje odpowiedzi. Timeout, czyli upływ czasu oczekiwania, nie mówi jeszcze, co stało się z pieniędzmi. NWC używa ulotnych zdarzeń dla żądań i odpowiedzi; odłączony relay albo niedostępna usługa mogą spowodować utratę wiadomości. Mogła jednak zaginąć wyłącznie odpowiedź po zakończonej już płatności. Najpierw sprawdź stan przez lookup_invoice lub bezpośrednio w portfelu. Cisza nie potwierdza niepowodzenia. Nowego żądania nie można automatycznie uznać za bezpieczne powtórzenie poprzedniej czynności; najpierw trzeba ustalić jej wynik. [1]
Aplikacja i portfel wymieniają zaszyfrowane wiadomości. Obecne uzgadnianie wybiera w pierwszej kolejności nip44_v2; przestarzałe nip04 pozostaje dla zgodności. Brak znacznika encryption oznacza starszy tryb. NIP-44 nie zapewnia jednak forward secrecy, ochrony wcześniejszej komunikacji przy późniejszym wycieku długoterminowego klucza. Relay może ponadto widzieć rodzaje zdarzeń, znaczniki, klucze publiczne połączeń i czas komunikacji. Do NWC nie należy więc używać głównego klucza tożsamości, którym publikuje się w Nostr. Oddzielne klucze ograniczają łączenie płatności z publicznym profilem, ale nie gwarantują pełnej anonimowości. [1] [4]
Do zwykłego korzystania nie trzeba znać numerów wiadomości, lecz są ważne przy tworzeniu integracji. Info używa kind 13194, żądania 23194, a odpowiedzi 23195. kind oznacza rodzaj zdarzenia. Znacznik p wskazuje drugą stronę, a e w odpowiedzi odsyła do pierwotnego żądania. Klient sprawdza podpis, oczekiwany klucz usługi, to powiązanie oraz result_type, nazwę polecenia, którego dotyczy wynik. Nie może uznać dowolnej wiadomości z relaya za potwierdzenie. Inaczej cudza odpowiedź lub odpowiedź dotycząca innej czynności mogłaby uchodzić za wynik tej płatności. [1]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Nostr, Lightning Network, BOLT 11, Portfel, Private Key, Satoshi. Do tego hasła prowadzą również odsyłacze z Nostr, BOLT 11.