كيف يعمل نوستر فعلاً: البروتوكول، بدون مصطلحات معقدة

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

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

الملخص السريع. نوستر هو pub/sub عبر WebSockets مع التوقيعات التشفيرية. ينشر العملاء كائنات JSON موقعة (أحداث) إلى الريليهات (خوادم صغيرة)، والعملاء الآخرون يشتركون في الريليهات بمرشحات تطابق الأحداث التي يريدونها. التوقيعات تمنع التزوير؛ الريليهات المتعددة تمنع نقاط الفشل المركزية. هذا هو البروتوكول بأكمله؛ كل شيء آخر عبارة عن اتفاقيات تنسيق لأنواع مختلفة من المحتوى.

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

كتلة البناء الأساسية: الحدث

كل شيء على نوستر هو حدث. المنشور هو حدث. التفاعل هو حدث. تحديث الملف الشخصي هو حدث. الرسالة المباشرة هي حدث. إيصال zap هو حدث.

الحدث هو كائن JSON بهذا الشكل بالضبط:

{
  "id": "abc123...",
  "pubkey": "0a4f7b1a3d9a1529a3080c3ae5ee553e0af0a01d86d01677c0bb270592923f88",
  "created_at": 1776329035,
  "kind": 1,
  "tags": [
    ["t", "nostr"],
    ["p", "3bf0c63f..."]
  ],
  "content": "hello nostr",
  "sig": "def456..."
}

ستة حقول تؤدي عملاً مهماً. id هو hash لمحتوى الحدث الخاص به؛ يحدده بشكل فريد. pubkey هو المؤلف (مفتاح عام بصيغة hex من 64 حرف). created_at هو Unix timestamp. kind هو عدد صحيح يصف ما يمثله الحدث (المزيد عن هذا أدناه). tags هي قائمة من التعليقات المنظمة مثل hashtags (t)، الإشارات (p للمفتاح العام، e للحدث)، والعشرات من الأخرى. content هي الحمولة الحرة الشكل، عادة نص.

sig هو توقيع Schnorr، مصنوع بمفتاحك الخاص، على الـ hash في id. هذا هو الحقل الذي يمنع التزوير: أي شخص يمكنه حساب الـ hash، لكن فقط صاحب المفتاح الخاص يمكنه إنتاج توقيع صحيح عليه.

ما هو "kind"

يخبر الحقل kind العملاء كيفية تفسير الحدث. الرقم هو نوع الدلالة بالكامل.

عدد قليل من الأنواع قيد الاستخدام النشط:

يتم اقتراح الأنواع الجديدة وتقنينها عبر NIPs (Nostr Implementation Possibilities). أي شخص يمكنه أن يقترح واحداً. الأنواع التي يتم اعتمادها على نطاق واسع تصبح أجزاء فعلية من البروتوكول؛ الأنواع التي لا تحظى بالاعتماد ببساطة تبقى متخصصة دون أن تكسر أي شيء.

كيف يتم نشر الحدث

عندما تضغط على "نشر" في عميل نوستر، يتم هذا التسلسل:

1. يجمع العميل JSON. يملأ pubkey، created_at، kind، tags، content.
2. يحسب العميل الـ id. ينفذ SHA-256 على تسلسل قانوني لتلك الحقول. هذا هو الـ hash الذي يغطيه التوقيع.
3. يوقع العميل الـ id بالمفتاح الخاص. توقيع Schnorr عبر secp256k1، نفس المنحنى الذي يستخدمه بيتكوين. التوقيع بـ 64 بايت يصبح حقل sig.
4. يفتح العميل اتصالات WebSocket لكل ريليه مكون. أو يعيد استخدام الموجودة إذا كانت نشطة.
5. يرسل العميل الحدث كرسالة. تنسيق الأسلاك هو مصفوفة JSON: ["EVENT", {...event...}].
6. يتحقق كل ريليه من التوقيع. يرفض الحدث إذا لم يتحقق التوقيع مقابل المفتاح العام المزعوم. يقبل ويخزن وإلا.
7. يدفع كل ريليه الحدث للمشتركين. أي عميل لديه اشتراك مفتوح يطابق مرشحه هذا الحدث يحصل على الحدث المسلم في الوقت الفعلي.

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

كيف يجلب العميل المنشورات

القراءة هي مرآة النشر.

يفتح عميلك اتصالات WebSocket على قائمة من الريليهات. لكل واحد، يرسل رسالة اشتراك:

["REQ", "sub_id_1", { "authors": ["pubkey1", "pubkey2", ...], "kinds": [1, 6], "limit": 50 }]

يطلب من الريليه ما يصل إلى 50 حدث من المؤلفين في القائمة، من النوع 1 (ملاحظة قصيرة) أو النوع 6 (إعادة نشر). يقوم الريليه بـ:

1. الاستعلام في قاعدة بياناته المحلية عن الأحداث المطابقة، وإرسالها (الأقدم إلى الأحدث افتراضياً، حتى الحد) كرسائل EVENT مرة أخرى للعميل.
2. إرسال رسالة EOSE (نهاية الأحداث المخزنة) بحيث يعرف العميل أن التفريغ التاريخي كامل.
3. يبقي الاشتراك مفتوحاً. أي حدث جديد يطابق المرشح (منشور من قبل شخص آخر لاحقاً) يتم دفعه للعميل في الوقت الفعلي.

هذا هو كيف يصبح تغذيتك حية. أنت لا تقوم باستطلاع؛ الريليه يقوم بالبث.

يفعل عميلك هذا بشكل متوازي عبر كل ريليه مكون. اتحاد الردود هو خطك الزمني. الأحداث المكررة عبر الريليهات يتم إلغاء تكرارها بـ id.

كيف تمنع التوقيعات التزوير فعلاً

هذا هو الجزء الذي تتجاهله معظم الشروحات.

عندما يستقبل العميل حدثاً، فإنه يعيد حساب الـ hash على التسلسل القانوني (بنفس الطريقة التي قام بها الناشر) وينفذ التحقق من Schnorr: بالنظر إلى pubkey، و id، و sig، هل التوقيع يفحص تشفيرياً؟

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

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

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

ما الذي تفعله الريليهات فعلاً

الريليه هو أنبوب حمقاء وسريعة مع ثلاث مهام:

1. قبول الأحداث والتحقق من التوقيعات. رفض أي شيء لا يتحقق أو يفشل فحوصات السياسة (مرشحات البريد المزعج، حدود الحجم، المفاتيح العامة المحظورة).
2. تخزين الأحداث. عادة في قاعدة بيانات SQLite أو PostgreSQL مفهرسة بـ id، pubkey، kind، وقيم الـ tags.
3. خدمة الاشتراكات. مطابقة مرشحات REQ الواردة مقابل قاعدة البيانات (للتاريخي) والأحداث المباشرة (للوقت الفعلي).

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

غياب تلك المهام الأخرى هو السبب في أن الريليهات يمكنها أن تكون صغيرة. VPS واحد بـ 5 دولارات شهرياً يمكنه تشغيل ريليه يخدم مئات المستخدمين النشطين. نفس الوظيفة في مقياس تويتر تكلف مليارات لأن تويتر تفعل كل تلك الأشياء الأخرى.

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

مثال كامل: شخص ما يضع إعجابة على منشورك

ربط كل هذا معاً، إليك ما يحدث من البداية إلى النهاية عندما تضع أليس إعجابة على منشور كتبه بوب.

1. ينشر بوب. عميل بوب يبني حدث kind:1 مع محتوى "hello world"، يوقعه، يرسله إلى خمسة ريليهات مكونة لبوب. كل ريليه يقبل ويخزن.
2. تشترك أليس. لعميل أليس اشتراك مفتوح على اثنين من تلك الريليهات مع مرشح يتضمن المفتاح العام لبوب في authors. الريليهات تدفع حدث بوب لأسفل الاشتراك. عميل أليس يعرض المنشور في خطها الزمني.
3. تضع أليس إعجابة. عميل أليس يبني حدث kind:7 مع محتوى "+" (اتفاقية نوستر "الإعجابة")، يضع علامة على المنشور الذي يتفاعل معه ([\"e\", \"bob_post_id\"]) والمؤلف ([\"p\", \"bob_pubkey\"]). يوقع وينشر إلى خمسة ريليهات مكونة لأليس.
4. ينتشر التفاعل. أي ريليه لديه اشتراك نشط يطابق المرشح { \"#e\": [\"bob_post_id\"], \"kinds\": [7] } (وهذا ما يستخدمه عميل بوب لمراقبة التفاعلات على منشوراته الخاصة) يدفع التفاعل إلى بوب. عميل بوب يجمع الإعجابات ويعرض العدد تحت المنشور.

لاحظ ما لم يحدث. لم يتم ping على أي خدمة "زر الإعجابة" المركزية. لم يقرر أي backend ما إذا كانت الإعجابات تُحسب. الإعجابة هي مجرد حدث موقع، معلن على نفس القنوات التي يتم الإعلان عن المنشور نفسه من خلالها.

ما لا يفعله نوستر بشكل صريح

خمسة أشياء تم استبعادها من البروتوكول الأساسي عن قصد، لأنها تنتمي إلى العميل أو الريليه، وليس تنسيق الأسلاك المشترك.

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

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

لماذا يعمل التصميم على الإطلاق

يعتمد التصميم على خاصية بسيطة واحدة: التوقيعات رخيصة للتحقق منها، التزوير مستحيل بدون المفتاح الخاص، والريليهات حرة للاستبدال.

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

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

إذا كنت تريد أن ترى التدفق الكامل من جانب المستخدم (زوج مفاتيح، هوية NIP-05، قائمة ريليهات، محفظة، جاهز للنشر)، فإن signup على nostr.blog يطوي تلك الخطوات في صفحة واحدة. الآليات الموضحة هنا هي ما يعمل فعلاً تحت ذلك التدفق.