Nostr

تجد آنا في Nostr كتّابًا تريد متابعتهم. ثم تكتشف لاحقًا أن التطبيق لم يعد يناسبها. إذا استخدمت المفتاح الخاص نفسه أو جهاز توقيع متصلًا بطريقة آمنة في تطبيق آخر، يمكنها الاحتفاظ بهويتها. يساعد المفتاح العام الآخرين على التعرّف إليها والتحقق من التوقيعات، بينما يتيح المفتاح الخاص التوقيع باسمها. لهذا يختلف npub عن nsec اختلافًا جوهريًا. وفق NIP-19، يمثلان المفتاح العام والخاص بترميز Bech32. NIP وثائق مرقّمة تصف قواعد Nostr وإضافاته. الترميز ليس تشفيرًا: nsec ليس رابط ملف شخصي عاديًا يمكن مشاركته مع أي شخص. والاحتفاظ بالهوية لا يضمن أن يجد التطبيق الجديد كل المنشورات القديمة أو أن ينقل جميع الإعدادات. [2] [7]

يوقّع التطبيق، الذي يسمى العميل، المنشور ويرسله إلى خوادم الترحيل المختارة. خادم الترحيل يستقبل الرسائل ويحفظها أو يمررها بحسب قواعده. يتصل تطبيق بيتر بهذه الخوادم ويطلب المنشورات التي تهمه. لا يوجد خادم مركزي وحيد، ولا التزام بأن ينسخ كل خادم كل شيء. تقنيًا، يتواصل العميل والخادم عبر WebSocket، وهو اتصال يبقى مفتوحًا لتبادل الرسائل: ينقل EVENT الرسالة، ويبدأ REQ الاشتراك، ويبلغ OK عن القبول أو الرفض. حتى الرد الإيجابي OK لا يؤكد وصول المنشور إلى بيتر أو حفظه إلى الأبد. يشير EOSE إلى انتهاء إرسال النتائج المخزنة لذلك الطلب، ويمكن للاشتراك بعده مواصلة استقبال رسائل جديدة. [1] [7]

عندما يستقبل بيتر رسالة، يتحقق تطبيقه من مطابقة التوقيع للمفتاح العام المذكور ومن أن البيانات الموقّعة لم تتغير. هذا لا يثبت صحة مضمون الرسالة أو هوية صاحبها المدنية. كما يحدد الكاتب وقت الإنشاء، لذا فهو ليس ختمًا زمنيًا مستقلًا. ولمن يريد التفاصيل التقنية: يحتوي السجل المسمى event على pubkey وcreated_at وkind وtags وcontent، أي المفتاح والوقت والنوع والوسوم والمحتوى. تنتج SHA-256 من تمثيل هذه البيانات بصيغة محددة بدقة قيمة تحقق قصيرة تسمى id. وهي تتيح اكتشاف تغيير البيانات الموقّعة. ويحتوي الحقل sig على Schnorr Signature، أي توقيع شنور وفق BIP340 على المنحنى secp256k1. معناه أن صاحب المفتاح المقابل وقّع هذه البيانات، وليس أن الادعاء الوارد فيها يستحق الثقة. [1]

يصعب تذكّر مفتاح عام طويل. يتيح NIP-05 ربطه بمعرّف يشبه عنوان البريد الإلكتروني. يسأل التطبيق النطاق المعني عن المفتاح المرتبط بالاسم، ثم يقارن الإجابة بمفتاح الملف الشخصي. إنه يتحقق من ارتباط محدد بالنطاق، لا من الاسم الحقيقي أو السمعة أو الموثوقية تلقائيًا. ويمكن لمشغّل النطاق تغيير هذا الارتباط لاحقًا. إذا كانت آنا تتابع شخصًا بالفعل، فينبغي أن يظل المفتاح العام الأصلي هو المرجع؛ لا ينبغي أن يغيّر إسناد الاسم نفسه إلى مفتاح جديد الشخصَ الذي تتابعه من دون علمها. استخدام اسم مستعار يعني التعريف بنفسك بمعرّف ثابت بدل الاسم المدني، وليس ضمان إخفاء الهوية. [3]

لا يحتاج بيتر إلى تنزيل جميع الرسائل. يمكنه إرسال مرشح، كطلب منشورات كتّاب محددين من نوع معين. تُجمع الشروط المختلفة داخل المرشح الواحد بمنطق AND، أي يجب تحققها جميعًا. أما القيم المتعددة المسموح بها لشرط واحد فهي بدائل OR، وكذلك المرشحات المتعددة داخل طلب REQ واحد؛ يكفي أن يطابق المنشور أحدها. يحد limit عدد النتائج المخزنة في الدفعة الأولى، لا الرسائل المستقبلية في الاشتراك تلقائيًا. يستخدم NIP-01 مفاتيح مكتوبة بالنظام الست عشري داخل الأحداث والمرشحات، لا صيغة npub المخصصة للمستخدم. وقد يكون غياب النتائج بسبب المرشح أو الخادم المختار أو سجله، وليس دليلًا على أن المنشور غير موجود في أي مكان. [1]

تغيّر آنا وصف ملفها وتريد أن يرى الآخرون الوصف الجديد. لذلك يميز Nostr بين أنواع السجلات التي ينبغي للخوادم الاحتفاظ بها. في الأحداث القابلة للاستبدال، يُختار أحدث سجل للزوج نفسه من pubkey وkind. وتضيف الأحداث القابلة للعنونة قيمة الوسم d لتمييز مستندات الكاتب نفسه، مثلًا. إذا تساوت أوقات السجلات القابلة للاستبدال، فالتوصية هي الاحتفاظ بأصغر id بحسب الترتيب المعجمي، أي الأسبق عند ترتيب صيغته المكتوبة. أما الأحداث المؤقتة، المسماة ephemeral، فلا يُتوقع أصلًا تخزينها. هذه أعراف وقد يختلف سلوك الخوادم. لذا ليس Nostr دفترًا تتفق فيه الشبكة كلها على تاريخ واحد ثابت لا يتغير. [1]

تلاحظ آنا أنها نشرت شيئًا كانت تريد إبقاءه خاصًا. يسمح NIP-09 بإرسال طلب حذف موقّع. قبل تنفيذه، يجب على العميل التحقق من أن الطلب والمنشور الأصلي يعودان إلى المفتاح العام نفسه؛ فلا يحق لشخص غريب حذف منشور آنا بمجرد الإشارة إليه. يمكن للخوادم والتطبيقات المتعاونة إزالة المحتوى أو التوقف عن عرضه. لكن الطلب لا يزيل كل النسخ أو لقطات الشاشة أو الأرشيفات المستقلة. وإخفاء منشور في تطبيق لا يعني أن خادمًا آخر توقف عن إتاحته. لذلك ما تنشره أهم من مجرد وجود زر للحذف. [4]

يمكن لأي شخص يحصل على منشور عام أن يقرأه؛ فالتوقيع وحده لا يخفي المحتوى. تحتاج الرسائل الخاصة إلى قواعد إضافية. يصف NIP-44 تشفير المحتوى، بينما يتناول NIP-17 تغليف الرسائل وإيصالها مع طبقات حماية إضافية. هذا لا يمنح إخفاء هوية تلقائيًا: قد تظل عناوين الشبكة والتوقيت وسلوك التطبيق كاشفة للمعلومات. ولا يوفر هذا التشفير أيضًا forward secrecy، أي حماية المحادثات الماضية إذا انكشف المفتاح طويل الأجل لاحقًا. فمن يحصل على المفتاح الخاص المطلوب ورسائل مشفّرة سُجلت سابقًا قد يقرأ المراسلات القديمة أيضًا. تحقق من الإضافات التي يدعمها التطبيق فعلًا؛ فكلمة «Nostr» وحدها لا تصف مستوى خصوصيته. [5] [6]