NIPs في Nostr موضحة: وثائق مواصفات البروتوكول

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

يغطي هذا الدليل ماهية NIPs، وكيف تعمل كآلية حوكمة، وأي منها يجب قراءته إذا كنت تدخل عالم التقنية.

NIPs هي وثائق markdown قصيرة على GitHub تقترح كيفية تنفيذ ميزات Nostr. يختار مطورو العملاء أيها يدعمون. تصبح NIP "حقيقية" عندما يعتمدها عدد كافٍ من المنفذين. مجموعة NIPs المستخدمة على نطاق واسع حوالي 30؛ القائمة الكاملة أقرب إلى 100.

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

ما هي NIP فعلياً

NIP هي ملف markdown في مستودع github.com/nostr-protocol/nips. كل ملف يصف ميزة أو صيغة أو اتفاقية محددة: كيفية توقيع الأحداث، وكيف يبدو حدث بيانات الملف الشخصي، وكيفية إرسال رسالة مباشرة، وما هي صيغة طلبات Lightning zap.

يختلف الحجم. أقصر NIPs تقل عن صفحة واحدة؛ الأطول عدة آلاف من الكلمات. يجلس معظمها حوالي 500 إلى 2000 كلمة. تتم كتابتها لتكون قابلة للتنفيذ من المواصفات وحدها، لذا تتضمن صيغ الرسائل والحقول المطلوبة والأحداث كمثال.

اتفاقية الأسماء هي NIP-XX حيث XX هو رقم. يتم تعيين الأرقام عند دمج NIP؛ لا تعكس الأولوية أو الأهمية. NIP-05 يتعلق بالمعرفات المتحققة؛ NIP-04 هو معيار الرسائل المباشرة الأقدم؛ NIP-01 هو البروتوكول الأساسي. تتبع الأرقام ترتيب الاقتراح وليس أهمية الميزة.

لماذا "إمكانيات التنفيذ"

الاسم خيار مقصود. قارن مع تقاليس المواصفات الأخرى.

• RFCs (طلبات التعليقات) في بروتوكولات الإنترنت غالباً ما تصبح إلزامية للتفاعل.
• EIPs (اقتراحات تحسين Ethereum) غالباً ما تصبح إلزامية عبر ترقية الشبكة.
• NIPs اختيارية دائماً. عميل ينفذ 40 NIP وعميل ينفذ 10 هما كلاهما عميلا Nostr صحيح؛ إنهما يفعلان مجرد مجموعات مختلفة من الأشياء.

هذا يعني أن NIPs لا "تكسر" أبداً التطبيقات الموجودة. NIP جديدة لميزة ما لا تفرض على العملاء الأقدم التغيير. ينمو البروتوكول على الحواف بينما يبقى الأساس مستقراً.

دورة حياة NIP

كيفية ظهور NIP جديدة:

1. يلاحظ شخص ما فجوة أو احتياجاً. "ليس لدينا طريقة قياسية للقيام بـ X." قد يكون مطور عميل أو مشغل relay أو مستخدم محبط من مشكلة محددة.
2. يكتبون مسودة. الصيغة تتابع NIPs الموجودة: العنوان والغرض والمواصفات والأمثلة.
3. يقدمون طلب سحب إلى مستودع NIPs.
4. يراجع المجتمع. يعلق المطورون ومشغلو relay والمستخدمون المهتمون. يتم مراجعة المسودة بناءً على التعليقات.
5. دمج أو التخلي. يحصل دمج NIPs على رقم ويصبح جزءاً من المستودع. تبقى المسودات المهجورة في سجل طلبات السحب.
6. يتبع التنفيذ (أم لا). يتم تنفيذ بعض NIPs في غضون أسابيع. يانتظر البعض سنوات. لا يتم تنفيذ البعض على نطاق واسع.

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

NIPs التي تهم إذا كنت مستخدماً

معظم NIPs غير مرئية للمستخدمين. حفنة قليلة تؤثر على تجربتك اليومية:

• NIP-01: البروتوكول الأساسي. كيف يتم هيكلة الأحداث وتوقيعها. لا ترى هذا أبداً، لكن كل شيء آخر يعتمد عليه.
• NIP-05: المعرفات المتحققة. يعطيك أسماء قابلة للقراءة you@domain.com. دليل NIP-05 الخاص بنا يغطيها.
• NIP-07: توقيع امتداد المتصفح. يتيح لعملاء الويب التوقيع دون رؤية مفتاحك الخاص.
• NIP-19: ترميز Bech32. لماذا يبدو مفتاحك العام مثل npub1... بدلاً من hex الخام.
• NIP-23: مقالات طويلة. تفعل منشورات بأسلوب المدونة على Nostr.
• NIP-44: الرسائل المباشرة المشفرة. معيار المراسلة المباشرة الحديث (أفضل من NIP-04 الأقدم).
• NIP-57: Zaps. نصائح Lightning مع إيصالات عامة.
• NIP-98: المصادقة عبر HTTP. يتيح لهويات Nostr المصادقة للمواقع العادية.

كمستخدم تستفيد من كل هذه دون التفاعل معها. تتعامل العملاء مع تفاصيل البروتوكول.

NIPs التي تهم إذا كنت مطوراً

إذا كنت تكتب أو تحتفظ بعميل Nostr، فإن NIPs التي تستحق القراءة تنمو إلى عشرات:

• NIP-01 إلى NIP-10 (الميكانيكا الأساسية).
• NIP-11 (وثائق معلومات relay).
• NIP-13 (إثبات العمل، لمقاومة الرسائل المزعجة).
• NIP-17 (الرسائل المباشرة المغلفة للهدايا لإخفاء البيانات الوصفية).
• NIP-22 (انتهاء صلاحية الحدث).
• NIP-27 (مراجع ملاحظات النص).
• NIP-30 (emoji مخصص).
• NIP-31 (نوع الأحداث).
• NIP-33 (الأحداث القابلة للاستبدال المعاملة كمعامل).
• NIP-42 (المصادقة على الاتصالات بـ relays).
• NIP-47 (Nostr Wallet Connect).
• NIP-50 (قدرة البحث).
• NIP-65 (بيانات قائمة relay الوصفية).
• NIP-78 (بيانات تطبيق مخصص عشوائي).

هذه هي التي ينفذها معظم العملاء الرئيسيين. عميل يدعم هذه المجموعة بالإضافة إلى NIPs التي يواجهها المستخدم أعلاه يغطي 95% من الاستخدام النموذجي.

قراءة NIP

إذا كنت تريد قراءة واحدة مباشرة، فإن المستودع في github.com/nostr-protocol/nips. هيكل معظم NIPs:

• العنوان والوصف. ما تقترحه NIP.
• الدافع. لماذا تكون الميزة مطلوبة.
• المواصفات. صيغة الرسالة الدقيقة والحقول المطلوبة وقواعد التحقق.
• أحداث مثال. JSON ملموس يوضح كيف يبدو حدث متوافق.
• سلوك العميل/relay. كيف يجب على التطبيقات التعامل مع الأحداث.

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

NIPs مع الاعتماد الجزئي

بعض NIPs موجودة لكن يتم تنفيذها بشكل غير متسق عبر العملاء. هذا ينشئ حالات حدية حيث تختلف تجربتك حسب العميل.

NIP-44 (الرسائل المباشرة المشفرة). تم الاعتماد من قبل Damus وPrimal وAmethyst ومعظم العملاء الرئيسيين في 2024-2025. بعض العملاء الأقدم لا يزالون يدعمون NIP-04 فقط. إذا أرسلت رسالة مباشرة إلى شخص ما عميله يدعم فقط NIP-04، فإن رسائل NIP-44 الخاصة بك له تفشل بصمت. الإجابة العملية: استخدم عميلاً حديثاً وآمل أن يفعل منافسك أيضاً.

NIP-17 (الرسائل المباشرة المغلفة للهدايا). الرسائل المباشرة المخفية للبيانات الوصفية. الاعتماد في 2026 ينمو لكن ليس شاملاً. الميزة رائعة حيث يدعم كلا الطرفين عملاء لها؛ خلاف ذلك يسقط بصمت إلى رسائل مباشرة أقل خصوصية.

NIP-46 (الموقعون البعيدون). يتيح لمدقق أجهزة أو تطبيق bunker التوقيع على الأحداث نيابة عن عميل. مدعوم في Amethyst وجزئياً في مكان آخر.

NIP-65 (قائمة relay المستخدم). يتيح للمستخدمين نشر relays المفضلة لديهم بحيث يمكن للعملاء التوجيه تلقائياً إلى الأماكن الصحيحة. الاعتماد يتحسن؛ العملاء الأقدم يتجاهلونها.

NIP-50 (البحث). يسمح للعملاء بالاستعلام عن relays لمطابقات النصوص. بعض relays تدعمها؛ الكثير لا تفعل. جودة البحث غير متسقة نتيجة لذلك.

التحقق من أي NIPs يدعمها عميل معين مفيد عند حدوث خلل. ينشر معظم العملاء مصفوفة دعم NIP الخاصة بهم في الوثائق.

كيف تحافظ عملية NIP على تماسك البروتوكول

لا سلطة مركزية، لذا ينبع التماسك من الديناميكا الاجتماعية. بعض الملاحظات:

NIPs السيئة لا تنتشر. يحصل مقترح يكرر NIP موجودة أو يحل المشكلة الخاطئة على اعتماد ضئيل ويموت بهدوء. المجتمع ليس رسمياً لكنه بآراء قوية.

NIPs الجيدة يتم تنفيذها بشكل مستقل. يقرأ مطورو عملاء متعددون المقترحات ويقررون بشكل مستقل. تتراكم الأفكار الجيدة المتبنيين؛ الأفكار السيئة لا تفعل.

قد تظهر NIPs متنافسة أحياناً. يمكن لاقتراحين مختلفين لنفس الميزة أن يتعايشا لفترة. عادة واحدة تفوز عملياً لأن المزيد من العملاء ينفذونها؛ أحياناً يندمجان.

تطور متوافق مع الـ fork. لأن NIPs اختيارية، يمكن للعميل تنفيذ NIP-X-v1 وفي وقت لاحق الترقية إلى NIP-X-v2 دون كسر أي شخص يدعم فقط v1. البروتوكول لا ينقسم.

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

اقتراح NIP الخاص بك

إذا كان لديك فكرة لميزة Nostr جديدة:

1. تحقق أولاً من مستودع NIPs. قد يكون شخص ما اقترحها بالفعل.
2. إن لم تكن، افتح مشكلة GitHub تصف المشكلة التي تحلها.
3. بناءً على التعليقات، قم بصياغة NIP كاملة بعد صيغة NIPs الموجودة.
4. قدم طلب سحب.
5. تفاعل في النقاش. كن مستعداً للمراجعة.
6. إذا تم دمجها، عظيم. إذا لم تكن، قد تكون للمشكلة حل أفضل؛ فكر لماذا.

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