بروتوكول Nostr، شرح بسيط

البروتوكول هو مجموعة من القواعد التي تحدد كيفية تحدث البرامج مع بعضها البعض. المنصة هي شركة تشغل هذه البرامج نيابة عنك. Twitter منصة. البريد الإلكتروني بروتوكول. Nostr بروتوكول.

التمييز مهم لأن البروتوكولات والمنصات لها أنماط فشل مختلفة وهياكل تكاليف مختلفة ومستقبليات مختلفة. يشرح هذا الدليل ما الذي يجعل Nostr بروتوكولاً بالتحديد، ما الذي يعنيه عملياً، ولماذا يبقى التصميم صغيراً بقصد.

ملخص سريع. Nostr هو بروتوكول مراسلة pub/sub مع توقيعات تشفيرية. يحدد تنسيق حدث صغير وطريقة بسيطة للعملاء لإرسال واستقبال تلك الأحداث عبر relays. لا تمتلكه أي شركة. يمكن لأي شخص كتابة عميل أو تشغيل relay أو اقتراح إضافات. المواصفات الأساسية تناسب بضع صفحات.

عندما تكون جاهزًا، احصل على عنوان @nostr.blog →

ما هو البروتوكول بالفعل

البريد الإلكتروني هو مقارنة جيدة. عند إرسال بريد إلكتروني من Gmail إلى Outlook، لا يحتاج Gmail إلى إذن Outlook. كلا الخدمتين تتحدثان SMTP (بروتوكول البريد الإلكتروني)، و SMTP يحدد كل شيء مطلوب لخادم بريد واحد لتسليم رسالة إلى آخر. الخوادم شركات مختلفة. البروتوكول هو اتفاق محايد.

يعمل Nostr بنفس الطريقة. حدث Nostr (منشور، إعجاب، متابعة) هو كائن JSON له شكل معين محدد في البروتوكول. relay هو أي خادم يوافق على قبول وتخزين وإعادة توجيه الأحداث التي تتوافق مع هذا الشكل. أي عميلين يتحدثان Nostr يمكنهما التفاعل عبر أي relay يتحدث Nostr، بغض النظر عمن صنع أي من الثلاثة.

البروتوكول هو اتفاق محايد. التطبيقات مجانية لتكون أي شيء.

مواصفات Nostr، في أقل الجمل

ثلاث قواعد تغطي معظمها.

1. الحدث هو كائن JSON مع id و pubkey و created_at و kind و tags و content و sig. id هو hash للحقول الأخرى؛ sig هو توقيع Schnorr على المعرف باستخدام نظيره الخاص من pubkey.
2. relay يقبل الأحداث الصحيحة عبر WebSocket ويخدم الاشتراكات التي تفلتر الأحداث حسب المؤلف أو النوع أو الوسم أو الوقت.
3. العميل يوقع الأحداث وينشرها على relays؛ يقرأ الأحداث بالاشتراك في relays مع المرشحات.

هذا هو البروتوكول الأساسي. كل ميزة متقدمة (المقالات الطويلة، zaps، DMs، المجتمعات، القوائم) هي ملحق يناسب هذا الإطار دون تغييره.

لماذا يبقى البروتوكول صغيراً

معظم البروتوكولات تنمو بالتراكم. كل حالة استخدام تضيف إلى المواصفات؛ كل عقد المواصفات أكبر من العقد السابق. HTTP الآن مئات من الصفحات. نما البريد الإلكتروني من حفنة من RFCs إلى شبكة معقدة. تجنب Nostr هذا بقصد.

الآلية هي NIPs (Nostr Implementation Possibilities). لا تُضاف الميزات الجديدة إلى المواصفات الأساسية؛ يتم اقتراحها كـ NIPs اختيارية. يطبق العملاء النماذج التي يهمهم بها. يتجاهل العملاء الآخرون النماذج الأخرى. يصبح NIP الشهير جزءاً من البروتوكول العملي لأن عدد التطبيقات الكافية تتحدثه؛ يتلاشى NIP غير الشهير دون احتفالية.

هذا يعني أن النواة صغيرة دائماً (الثوابت المهمة: الأحداث الموقعة، relays مفتوحة، الهوية المحمولة) والحواف مرنة دائماً (تتطور الميزات الجديدة دون كسر العملاء الموجودين). عميل Nostr من 2022 لا يزال يعمل في 2026 لأن النواة لم تتغير؛ إنه فقط يفعل أشياء أقل من العملاء الأحدث.

البروتوكول مقابل المنصة، بشكل ملموس

خمسة فروقات عملية يمكنك الشعور بها كمستخدم.

الهوية. على منصة، حسابك مملوك للشركة. على بروتوكول، حسابك هوية تشفيرية تمتلكها أنت. لا أحد يمكنه أن يأخذها منك.

البيانات. على منصة، منشوراتك تعيش في قاعدة البيانات الخاصة بهم. على بروتوكول، منشوراتك تعيش على عدة relays مستقلة. إذا اختفى أحدها، الآخرون لا يزالون يملكونها.

سرعة الميزات. على منصة، تُطلق الميزات عندما تقرر الشركة. على بروتوكول، تُطلق الميزات عندما يكتبها أي منفذ. هذا أبطأ بطرق معينة (لا توجد خريطة طريق مركزية) وأسرع بطرق أخرى (تجارب متوازية عديدة).

النقود. على منصة، تلتقط الشركة كل النقود. على بروتوكول، النقود هي ما يتفق عليه المستخدمون والمطبقون. Nostr لديه zaps (نصائح من نظير إلى نظير عبر Lightning) لأن ذلك يناسب الثقافة؛ قد تصل مجتمعات بروتوكول مختلفة إلى معايير مختلفة.

نمط الفشل. يمكن للمنصة أن تختفي تماماً. بروتوكول لا يمكنه؛ طالما أن منفذ واحد يبقى نشطاً، البروتوكول يعيش. صُمم Nostr بحيث أنه حتى إذا اختفى fiatjaf (المؤلف الأصلي) غداً، ستبقى الشبكة تعمل بدون تغيير.

ما لا يفعله البروتوكول بوضوح

خمسة أشياء تم استبعادها من المواصفات بقصد.

التعديل. لا يحدد البروتوكول ما المحتوى المقبول. لكل relay قواعده الخاصة؛ لكل عميل مرشحاته الخاصة؛ لكل مستخدم قائمة كتم صوته الخاصة. يحدث التعديل في الحواف، وليس النواة.

البحث. لا يوجد بحث محدد بالبروتوكول. بعض relays تفهرس النص؛ آخرون لا يفعلون. العملاء الذين يريدون البحث إما يعتمدون على relays قادرة على البحث أو يشغلون فهرسة خاصة بهم. الغياب متعمد؛ يبقي البروتوكول محايداً على ما يتم العثور عليه.

الترتيب. لا يوجد تغذية "لك". لا توجد أوزان للمشاركة. يعرض العملاء الأحداث حسب الطابع الزمني بشكل افتراضي؛ أي ترتيب آخر هو قرار على مستوى العميل، وليس قرار البروتوكول.

الاكتشاف. لا يوجد محرك توصيات. العثور على حسابات جديدة للمتابعة هو ميزة عميل، وليس ميزة بروتوكول. بعض العملاء يستثمرون بكثافة في هذا (Primal)؛ آخرون يتركونها للمستخدمين (Damus).

الاسترجاع. لا يوجد إعادة تعيين الحساب. فقدان المفتاح الخاص، فقدان الحساب. يمكن للبروتوكول أن يتضمن تدوير المفتاح لكنه لا يفعل، لأن المقايضات حقيقية والمجتمع لم يتفق على آلية معينة بعد. هذا مجال جارٍ (مسودات NIP-26 و NIP-41).

كل حذف هو اختيار. تبقى البروتوكولات صغيرة برفضها حل كل مشكلة على مستوى البروتوكول.

من يقرر ما يصبح Nostr

لا أحد والجميع.

لا توجد مؤسسة Nostr. لا توجد مجموعة عمل شركات. لا يوجد لجنة إشراف. أكثر السلطات تركيزاً في أي مكان في النظام البيئي هي مستودع GitHub الخاص بـ fiatjaf حيث يتم اقتراح NIPs، وحتى ذلك هو مجرد نقطة تنسيق، وليس حارس بوابة.

يتم قراءة النماذج المقترحة بواسطة مطوري العملاء. يتم تطبيق الشهيرة. NIP الذي يطبقه ثلاثة عملاء رئيسيين يصبح فعلياً جزءاً من البروتوكول؛ NIP الذي كتبه مطور واحد لكن لا أحد آخر يهتم به هو مجرد وثيقة على GitHub.

هذه العملية فوضوية. هناك مشاكل تنسيق واقتراحات مكررة وسياسة عرضية. إنها أيضاً مرنة بطريقة معينة: لا يمكن لطرف واحد أن يفسدها بقرار سيء، لأن القرارات السيئة لا تحصل على التبني. يتطور البروتوكول في اتجاهات تقريبية بوزن اختيارات المطورين، وليس بالمرسوم.

متى يفوز نموذج البروتوكول

تفوز البروتوكولات على المنصات في ظروف معينة:

• عندما تأهل الملكية أكثر من الصقل. البروتوكولات عادة ما تكون أقل صقلاً من المنصات. إنها تفوز عندما تهتم بما لا يمكن للصقل أن يعطيك إياه (هوية دائمة، مقاومة الرقابة، التشغيل البيني المفتوح).
• عندما تكون تأثيرات الشبكة هي الميزة. تنمو قيمة البروتوكول مع التبني من قبل المطبقين، وليس فقط المستخدمين. يجعل المزيد من العملاء والـ relays الشبكة أقوى بطرق لا تستطيع المنصة نسخها.
• عندما يأهل الأفق الطويل. يتم شراء المنصات وبيعها وإغلاقها أو تحويلها. تتجاوز البروتوكولات أي منفذ واحد. البريد الإلكتروني أقدم من معظم الشركات؛ يراهن Nostr على نفس الديناميكية.

إذا كانت حالة الاستخدام الخاصة بك لا تطابق أي من هذه، فعادة ما تكون المنصة أسرع وأسهل. هذا صادق. Nostr ليست أفضل عالمياً من Twitter لكل حالة استخدام ممكنة. إنها أفضل بالطرق المحددة التي يفوز بها البروتوكول على منصة.

قراءة المواصفات الفعلية

إذا أثار هذا الدليل فضولك لقراءة البروتوكول مباشرة، مستودع NIPs لديه القائمة الكاملة. NIP-01 هو النواة؛ النماذج المرقمة بعده هي الملحقات. لا تحتاج إلى فهم أي منها لاستخدام Nostr، لكن قراءة NIP-01 تستغرق حوالي عشر دقائق وتوضح الكثير.