Lightning Address

आना अपने पॉडकास्ट के लिए योगदान लेना चाहती हैं। हर श्रोता को नया लंबा इनवॉइस भेजने के बजाय वह एक Lightning Address प्रकाशित करती हैं। उदाहरण anna@example.com याद रखना आसान है: @ से पहले वाला भाग सेवा में प्राप्तकर्ता को पहचानता है और उसके बाद वाला डोमेन वॉलेट को उत्तर देता है। ईमेल से यह समानता जानबूझकर रखी गई है, लेकिन पैसे ईमेल से नहीं भेजे जाते। कोई मौजूदा ईमेल अपने आप Lightning Address नहीं बन जाता और नाम भर से मालिक की पहचान साबित नहीं होती। इसलिए जिस रचनाकार को सहयोग देना है, उसी से पता सत्यापित करें। [1] [6]

श्रोता संगत वॉलेट में नाम डालता है। वॉलेट सेवा से भुगतान का विवरण और स्वीकार्य राशि की सीमा लेता है। उपयोगकर्ता डोमेन, विवरण और चुनी हुई राशि जाँचता है; उसके बाद वॉलेट विशिष्ट BOLT 11 इनवॉइस माँगता है और भुगतान से पहले उसकी राशि की जाँच करता है। इनवॉइस मिलना अभी भुगतान होना नहीं है। यह प्रक्रिया LNURL-pay कहलाती है। सेवा callback यानी इनवॉइस माँगने का पता, विवरण वाली metadata और minSendable व maxSendable सीमाएँ लौटाती है। amount को msat में भेजा जाता है, जो satoshi का हज़ारवाँ हिस्सा है: 1000 msat = 1 sat। इनवॉइस pr फ़ील्ड में मिलता है। [2] [3]

आना ऐसी सेवा इस्तेमाल कर सकती हैं जो उनका वॉलेट सँभालती हो, या नाम को अपने Lightning नोड से जोड़ सकती हैं—यानी भुगतान संभालने वाले अपने सॉफ़्टवेयर से। पते का रूप यह अंतर नहीं बताता। वेब endpoint, जहाँ सर्वर वॉलेट को उत्तर देता है, किसी बीच के सर्वर के जरिए उनके नोड से इनवॉइस माँग सकता है। यह मध्यस्थ ज़रूरी नहीं कि पैसे भी रखता हो; यह व्यवस्था और दी गई अनुमतियों पर निर्भर है। फिर भी सर्वर के उत्तरों का नियंत्रण अहम है: जो उन्हें बदल सके, वह भुगतान करने वाले को दूसरा इनवॉइस दिखा सकता है। अपना डोमेन होने से self-custody, यानी अपनी कुंजियों पर खुद का नियंत्रण, अपने आप सुनिश्चित नहीं होता। [3] [4]

वॉलेट Lightning Address पर भेजने की सुविधा दे सकता है, बिना उपयोगकर्ता को प्राप्त करने का अपना पता दिए। प्राप्त करने के लिए उपलब्ध वेब सेवा, इनवॉइस बनाने की सुविधा और Lightning Network पर वास्तव में भुगतान ले पाने की क्षमता भी चाहिए। भुगतान चैनलों से होकर पहुँचता है। चैनल प्रतिभागियों के बीच ऐसे कनेक्शन हैं जिनमें भुगतान के साथ दोनों पक्षों के हिस्से की राशि बदलती है। इसमें Inbound Liquidity शामिल है: चैनलों के दूसरे सिरे पर मौजूद वे धनराशियाँ जो भुगतान के दौरान प्राप्तकर्ता की ओर आ सकती हैं। याद रहने वाला नाम यह आने वाली तरलता पैदा नहीं करता। पता खुल जाए लेकिन भुगतान विफल हो, तो समस्या नाम में ही हो यह ज़रूरी नहीं। वेबसाइट का उत्तर, मिला हुआ इनवॉइस और पैसे मिलने की पुष्टि अलग-अलग चरण हैं। [3] [5]

अपने डोमेन पर आप भुगतान संभालने वाला सर्वर बदलकर भी श्रोताओं को बताया नाम रख सकते हैं। BTCPay दस्तावेज़ HTTP 301 से endpoint को दूसरी जगह भेजने का उदाहरण देते हैं: वेब अनुरोध का गंतव्य बदलता है, बिटकॉइन स्थानांतरित नहीं होते। दूसरे के डोमेन वाले नाम पर यह नियंत्रण शायद न मिले। Seed Phrase, यानी वॉलेट बहाल करने के शब्द, अपने आप सेवा के खाते तक पहुँच बहाल होने की गारंटी नहीं देते। वे डोमेन के प्रबंधन का अधिकार या DNS की सेटिंग भी सुरक्षित नहीं रखते। DNS वह प्रणाली है जो तय करती है कि डोमेन किस जगह ले जाए। बदलाव के बाद केवल पता खुलना न देखें; सही इनवॉइस और परीक्षण भुगतान का वास्तविक आगमन भी जाँचें। पुराने संपर्कों को नया नाम अपने आप पता नहीं चलता। [5] [3]

LUD-16 बताता है कि नाम से GET वेब अनुरोध, यानी डेटा माँगने का अनुरोध, कैसे बनता है। वॉलेट डोमेन पर /.well-known/lnurlp/username पथ खोलता है और username की जगह उपयोगकर्ता का नाम रखता है। सामान्य वेब पर HTTPS और onion डोमेन पर HTTP इस्तेमाल होता है। payRequest उत्तर मिलने पर प्रक्रिया LUD-06 के अनुसार आगे बढ़ती है। HTTPS रास्ते में छेड़छाड़ से कनेक्शन को बचाता है, लेकिन सेवा की ईमानदारी साबित नहीं करता। सेवा अनुरोध सँभालती है और जानती है कि इनवॉइस किस प्राप्तकर्ता के लिए है। इसलिए पढ़ने योग्य नाम अपने आप गुमनामी नहीं देता। [1] [2]

LUD-16 उपयोगकर्ता नाम में छोटे अक्षर a-z, अंक 0-9 और -_. की अनुमति देता है; सामान्य ईमेल में अधिक चिह्न हो सकते हैं। वैकल्पिक संक्षिप्त रूप @domain, /.well-known/lnurlp/_ पथ पर डिफ़ॉल्ट प्राप्तकर्ता _@domain को दर्शाता है, लेकिन वॉलेट या सेवा इसे न भी माने। +tag जोड़ना भी सर्वव्यापी सुविधा नहीं है। इसे मानने वाली सेवा योगदान का उद्देश्य अलग कर सकती है और text/tag में दिखा सकती है। यह कोई नई निजी कुंजी या निजता की गारंटी नहीं है। रोज़मर्रा में प्राप्तकर्ता द्वारा प्रकाशित ठीक वही नाम कॉपी करना बेहतर है। [1]

मेटाडेटा अतिरिक्त जानकारी है जिसे वॉलेट और सेवा व्यवस्थित JSON प्रारूप में भेजते हैं। LNURL-pay में text/plain होता है, जो भुगतान का छोटा विवरण है। LUD-16 नाम से संबंध के लिए text/identifier जोड़ता है, या नाम वास्तविक ईमेल हो तो text/email। इससे वॉलेट दिखा सकता है कि भुगतान किससे जुड़ा है। यह फिर भी सेवा की दी जानकारी है, आना की वास्तविक पहचान का स्वतंत्र सत्यापन नहीं। इसलिए शुरू में मिले पते, डोमेन और राशि की जाँच सावधानी से भुगतान करने का हिस्सा बनी रहती है। [1] [2]