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]