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]