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 إعادة توجيه endpoint باستخدام HTTP 301: يُرسل طلب الويب إلى مكان آخر، من دون نقل أي عملات. وقد لا تملك هذا التحكم في اسم تابع لنطاق شخص آخر. لا تضمن Seed Phrase، أي كلمات استعادة المحفظة، وحدها استعادة الوصول إلى حساب الخدمة. وهي لا تحفظ أيضًا صلاحيات إدارة النطاق أو إعدادات DNS، وهو النظام الذي يحدد الوجهة التي يقود إليها النطاق. بعد التغيير، تحقّق من الفاتورة الصحيحة ومن استلام دفعة تجريبية بالفعل، لا من فتح العنوان فقط. ولن يعرف أصحاب بيانات الاتصال القديمة اسمك الجديد تلقائيًا. [5] [3]

يشرح LUD-16 تحويل الاسم إلى طلب ويب GET، أي طلب للحصول على بيانات. تتصل المحفظة بالنطاق عند المسار /.well-known/lnurlp/username، مع استبدال username باسم المستخدم. تستخدم HTTPS على الويب المعتاد وHTTP لنطاق onion. ثم تستكمل استجابة payRequest المسار وفق LUD-06. يحمي HTTPS الاتصال من التلاعب أثناء النقل، لكنه لا يثبت أمانة الخدمة نفسها. فهي تعالج الاستعلامات وتعرف المستلم الذي تصدر له الفاتورة، ولذلك لا يضيف الاسم المقروء إخفاءً للهوية بحد ذاته. [1] [2]

يسمح LUD-16 في اسم المستخدم بالحروف الصغيرة a-z والأرقام 0-9 والرموز -_.؛ أما البريد المعتاد فيسمح بمجموعة أوسع. يشير الاختصار الاختياري @domain إلى المستلم الافتراضي _@domain عند المسار /.well-known/lnurlp/_، لكن المحفظة أو الخدمة قد لا تدعمه. والإضافة +tag ليست عامة أيضًا. إذا دعمتها الخدمة، يمكنها تمييز غرض المساهمة وإدراجه في text/tag. ليست الإضافة مفتاحًا خاصًا جديدًا ولا ضمانًا للخصوصية. في الاستخدام اليومي، الأفضل نسخ الاسم الدقيق الذي نشره المستلم. [1]

البيانات الوصفية معلومات إضافية تتبادلها المحفظة والخدمة بصيغة JSON المنظمة. وهي تتضمن في LNURL-pay الحقل text/plain، أي وصفًا قصيرًا للدفع. ويضيف LUD-16 الحقل text/identifier لربط الدفع بالاسم، أو text/email إذا كان الاسم يقابل بريدًا إلكترونيًا حقيقيًا. يساعد ذلك المحفظة على عرض ما تتعلق به الدفعة. لكنها تظل معلومات تقدمها الخدمة، وليست تحققًا مستقلًا من هوية آنا المدنية. لذلك تظل مراجعة العنوان الأصلي والنطاق والمبلغ جزءًا من الدفع بعناية. [1] [2]