Lightning Address

LUD-16 używa username i domeny, lecz ogranicza nazwę do małych a-z, cyfr 0-9 i znaków -_.; plus jest możliwy tylko przy obsłudze tagów przez usługę. Zwykła składnia e-maila jest szersza. Skrzynka nie gwarantuje więc Lightning Address, a ta sama nazwa nie uwierzytelnia osoby odbiorcy. [Lightning Address — LUD-16] [Lightning Address — Project overview]

Portfel pobiera przez GET ścieżkę /.well-known/lnurlp/username w danej domenie, przez HTTPS lub HTTP dla usługi onion. Odpowiedź ma postać payRequest według LUD-06. Znaczenie mają rzeczywista domena i jej usługa; tekst przed małpą nie jest kluczem publicznym węzła. [Lightning Address — LUD-16]

Odpowiedź podaje callback, metadata oraz granice minSendable/maxSendable. Płacący wybiera amount w msat; 1000 msat to jeden satoshi. Callback zwraca fakturę w pr, a portfel przed zapłatą sprawdza zgodność kwoty. Wyszukanie adresu ani otrzymanie faktury nie oznacza rozliczenia. [LNURL — LUD-06 payRequest] [Lightning Address — Implementation guide]

Nowszy LUD-16 dopuszcza opcjonalny zapis @domena jako skrót _@domena ze ścieżką kończącą się /_. Ani usługa, ani portfel nie muszą go obsługiwać. Obsługiwany +tag jest przesyłany w ścieżce; usługa może użyć go jako metadanych text/tag. Tag nie jest nowym kluczem Bitcoin ani automatyczną ochroną prywatności. [Lightning Address — LUD-16]

LUD-16 wymaga text/identifier lub text/email w metadata; text/email dotyczy rzeczywistego adresu e-mail. Nadal wymagane jest też text/plain z LNURL-pay. Porównuj wyświetlaną nazwę i opis z domeną oraz zamierzonym odbiorcą. Twierdzenie usługi nie jest niezależną weryfikacją tożsamości człowieka. [Lightning Address — LUD-16] [LNURL — LUD-06 payRequest]

Usługa może wystawiać faktury swojego portfela albo używać serwera mostu połączonego z węzłem. Sam format nie oznacza więc ani powierniczego przechowywania, ani samodzielnej kontroli. Most potrzebuje uprawnień do swojej funkcji, a nie automatycznie nieograniczonej kontroli portfela. Osoba kontrolująca endpoint może wpływać na fakturę otrzymywaną przez płacącego. [Lightning Address — Implementation guide] [Lightning Address — Bridge server]

Portfel może płacić na Lightning Address bez udostępniania użytkownikom własnej nazwy. Odbiór wymaga działającej usługi internetowej, wystawienia faktury i możliwości przyjęcia płatności. Czytelny adres sam nie tworzy płynności przychodzącej. Powtarzane zapytania mogą ujawnić dostawcy odbiorcę i czas działań. [Lightning Address — Implementation guide]

Własna domena pozwala przekierować endpoint na inny serwer; BTCPay opisuje na przykład HTTP 301. W cudzej domenie zachowanie nazwy zależy od dostawcy. Seed nie przywraca kontroli DNS, certyfikatów ani powiązań kont. Po zmianie usługi ponownie sprawdź wyszukanie, fakturę docelową i odbiór; nie zakładaj automatycznej aktualizacji starych kontaktów. [BTCPay Server — Address redirection] [Lightning Address — Implementation guide]