NIP-17: الرسائل الخاصة المباشرة - دليل شامل

NIP-17 يمثل ترقية أمنية كبيرة في كيفية عمل الرسائل الخاصة في Nostr. يشرح هذا الدليل لماذا يجب أن تهتم بهذا التحسين في البروتوكول، وكيفية الترحيل من معيار NIP-04 القديم، والخطوات العملية لتأمين اتصالاتك.

ما هو NIP-17؟

NIP-17 هو مواصفة بروتوكول Nostr التي تحدد الرسائل الخاصة المباشرة باستخدام نظام تشفير مزدوج الطبقات يسمى “seal + gift wrap”. تم إنشاؤه لمعالجة عيوب الأمان الأساسية في طريقة تشفير NIP-04 السابقة.

على عكس NIP-04، الذي استخدم طبقة واحدة من تشفير AES-256-CBC، يستخدم NIP-17:

1. Seal (نوع الحدث 13): الطبقة الداخلية الموقّعة بمفتاحك الحقيقي، حتى يتأكد من تكاتبه أن الرسالة صادرة منك فعلًا
2. Gift wrap (نوع الحدث 1059): المظروف الخارجي الموقّع بمفتاح مؤقّت يُرمى بعد الاستخدام. يخفي الـ seal بداخله، فلا تظهر هويتك الحقيقية أبدًا على الحدث الذي تخزّنه الـ relays

وهذا التقسيم إلى طبقتين يعني:

• بقاء محتوى الرسالة خاصًا
• لا تستطيع الـ relays معرفة من أرسل الرسالة: الـ gift wrap موقَّع بمفتاح عشوائي يُستخدم مرة واحدة، وليس بمفتاحك أنت
• الطوابع الزمنية عشوائية، مما يجعل ربط توقيت الرسائل ببعضها أصعب

لماذا يهم NIP-17: مشكلة أمان NIP-04

كان NIP-04 هو بروتوكول الرسائل المباشرة الأصلي لـ Nostr، لكنه يحتوي على العديد من مشاكل الأمان الحرجة التي تجعله غير مناسب للاتصال الخاص الحقيقي.

المقارنة: NIP-04 مقابل NIP-17

المشكلة الأساسية في NIP-04

تكشف رسائل NIP-04 عن من يتحدث مع من لكل relay يخزّنها. (لا يوجد في Nostr أي بلوكتشين؛ الأحداث تبقى ببساطة على الـ relays، ويستطيع أي شخص القراءة من أي relay.) وبينما يكون جسم الرسالة مشفرًا، يحتوي المظروف على:

# بنية حدث NIP-04 (مبسطة)
{
  "pubkey": "<sender_public_key>",      # يمكن لأي شخص رؤية من أرسل هذا
  "tags": [["p", "<recipient_pubkey>"]], # يمكن لأي شخص رؤية من استلمه
  "content": "<encrypted_content>"       # فقط المحتوى مخفي
}

وهذا يعني أن مشغلي الـ relay، ومراقبي الشبكة، وجامعي البيانات يمكنهم:

• بناء رسوم اجتماعية تُظهر من يتواصل مع من
• تتبع أنماط وترددات الاتصال
• استنتاج العلاقات من توقيت الرسائل

يسدّ NIP-17 معظم هذه الثغرة بتغليف الرسالة كاملةً في مظروف خارجي موقَّع بمفتاح مؤقّت، فلا يعرف الـ relay من أرسلها. لكن أمرًا واحدًا يبقى مكشوفًا بحكم التصميم: المفتاح العام للمستلم يسافر على المظروف في وسم غير مشفّر، لأن الـ relay لا بدّ أن يعرف إلى أين يسلّم الرسالة. أي أن NIP-17 يخفي المرسِل، لا المستلِم.

كيف يعمل NIP-17: Seal + Gift Wrap

فهم التنفيذ التقني يساعد على تقدير تحسينات الأمان.

طبقة Gift Wrap (الخارجية)

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

• مفتاحًا عامًا عشوائيًا يُستخدم مرة واحدة، ولا شيء فيه يعود إليك
• المفتاح العام للمستلم، في وسم غير مشفّر يقرأه الـ relay
• طابعًا زمنيًا معشّى
• الرسالة الداخلية المختومة (sealed)

طبقة Seal (الداخلية)

داخل الـ gift wrap يوجد الـ seal. هنا تسكن نسبة الرسالة إلى صاحبها، ولا يرى الـ relay هذه الطبقة أبدًا. هذه الطبقة:

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

Gift wrap (الطبقة الخارجية)

مفتاح عام عشوائي، تلميح المستلم، هذا كل ما يراه الـ relay

Seal (الطبقة الداخلية)

موقَّعة بمفتاح المرسل الحقيقي، ولا يقرأها إلا المستلم

محتوى الرسالة الفعلي

المرسل: المفتاح العام الحقيقي · الطابع الزمني: 1234567890

الفوائد الرئيسية

1. خصوصية المرسِل: لا يستطيع أحد غير المستلم تحديد من أرسل الرسالة. أما المستلم نفسه فيظهر اسمه في وسم p غير مشفّر لا بدّ أن تقرأه الـ relays.
2. عدم القابلية للربط: كل رسالة موقَّعة بمفتاح جديد يُستخدم مرة واحدة، فلا يبدو للمراقب أن الرسائل الصادرة من المرسل نفسه تنتمي إلى بعضها.
3. لا توجد Forward Secrecy: يشتقّ NIP-44 مفتاح المحادثة من مفتاحين ثابتين، لذا فإن مهاجمًا يحصل لاحقًا على مفتاح nsec الخاص بك يستطيع فك تشفير كل رسالة كان قد حفظها. المفاتيح ذات الاستخدام الواحد تخفي من أرسل الرسالة، لكنها لا تحمي الرسائل السابقة. احذف المحادثات القديمة إن كان هذا يهمّك.

التسليم: قائمة relays الرسائل المباشرة (النوع 10050)

يصف الـ seal والـ gift wrap كيفية تغليف الرسالة. وتبقى قطعة ثالثة تصف إلى أين تُسلَّم: حدث من النوع 10050. وهي قائمة صغيرة وعامة بالـ relays التي تقبل رسائلك الخاصة.

المواصفة صارمة في هذا: يجب على المرسلين نشر الـ gift wraps فقط إلى الـ relays المدرجة في قائمة النوع 10050 الخاصة بالمستلم. وإذا لم تنشر واحدة قط، تعاملك المواصفة على أنك «غير جاهز لاستقبال الرسائل» ولا ينبغي للعملاء حتى المحاولة. فتسقط الرسائل المباشرة الموجهة إليك بصمت ولا تُسلَّم أبدًا، دون أي خطأ في أيٍّ من الطرفين.

قاعدتان عمليتان:

• انشر قائمتك قبل أن تتوقع أي رسائل NIP-17 (انظر الخطوة 3 من دليل الترحيل أدناه)
• أبقِها صغيرة: توصي المواصفة بـ 1-3 relays، وكل relay تدرجه في القائمة يرى من يراسلك

دليل الترحيل: الانتقال من NIP-04 إلى NIP-17

الترحيل إلى NIP-17 سهل مع عملاء Nostr الحديثين. إليك كيفية إجراء التبديل.

الخطوة 1: التحقق من دعم العميل

لا ينفعك NIP-17 إلا إذا كان العميل على طرفَي المحادثة يتحدث به. هؤلاء الأربعة يصرّحون بذلك في توثيقهم أو في شفرتهم المصدرية:

Damus يستحق تحذيرًا خاصًا به. حتى سبتمبر 2026، لا تزال قائمة المواصفات التي ينشرها Damus خالية من NIP-17، وفيها NIP-04 القديم وحده. وللأمر نتيجتان، كلتاهما مهمة. الرسالة المغلَّفة التي ترسلها لن تظهر لمن يستخدم Damus أصلًا. وما يرسله هو إليك يخرج كحدث من النوع 4 عاديّ، يحمل مفتاحيكما العامّين على ظاهره، حيث يقرأهما كل relay يخزّنه. فإن كانت المحادثة حساسة، انقلها إلى أحد العملاء أعلاه.

أما Primal و Iris و Nos فتقع في منطقة رمادية. لا يقول Primal شيئًا في العلن، فعامله على أن حاله غير معروف. ويشفّر Iris محادثاته الخاصة بمخطط double ratchet خاص به بدل NIP-17 المجرّد، وهذا جيد داخل Iris ولا يضمن شيئًا خارجه. ولا يدرج Nos لا NIP-17 ولا المواصفتين المبنيّ عليهما، والمشروع ساكن منذ أوائل 2025.

قوائم ميزات العملاء تتغير أسرع من الأدلة. فإن لم يُذكر عميلك هنا، فاختبار الخطوة 5 يحسم الأمر أسرع من تتبّع سجلات التغييرات.

الخطوة 2: غالبًا لا يوجد ما تشغّله

هذه الخطوة أقصر مما تتوقع. لا يوثّق أيّ من العملاء أعلاه مفتاح تشغيل لـ NIP-17، لأنه ببساطة غير موجود. هم يستخدمون الـ gift wraps تلقائيًا بمجرد أن يصبح الطرف الآخر قادرًا على استقبالها.

فتخطَّ إلى الخطوة 3، وهي الجزء الذي يحتاج إليك فعلًا. محادثات NIP-04 القديمة تبقى مكانها وتبقى مقروءة، ولا شيء يحوّلها.

الخطوة 3: انشر قائمة relays الرسائل المباشرة (النوع 10050)

لا يسلّم مرسلو NIP-17 إلا إلى الـ relays التي تدرجها في حدث النوع 10050 الخاص بك. وبدونه تسقط الرسائل الموجهة إليك بصمت (انظر قسم «التسليم: قائمة relays الرسائل المباشرة» أعلاه).

1. ابحث في عميلك عن إعداد relays الرسائل المباشرة أو الرسائل الخاصة
2. أضف من relay واحد إلى ثلاثة relays تقبل الـ gift wraps (النوع 1059)، فبعض الـ relays ترفضها
3. احفظ، وسينشر عميلك قائمة النوع 10050 نيابة عنك

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

الخطوة 4: التواصل مع جهات الاتصال

يعمل NIP-17 فقط إذا كان الطرفان يدعمان NIP-17. أرسل ملاحظة إلى جهات الاتصال المتكررة:

"مرحباً! أنا أقوم بالترقية إلى NIP-17 للحصول على خصوصية أفضل في رسائلنا المباشرة.
يرجى تحديث عميل Nostr إذا لم تكن قد فعلت ذلك بالفعل.
ستكون رسائلنا المستقبلية أكثر أماناً!"

الخطوة 5: تأكّد أنه يعمل فعلًا

الفحص المهم هنا لا يتطلب أي مهارة تقنية. اطلب من شخص يستخدم أحد عملاء الخطوة 1 أن يراسلك، ثم ردّ عليه. فإن وصل الاتجاهان، فقائمتك من النوع 10050 منشورة والـ gift wraps تصلك. وإن اختفت رسالتك دون أن يرى أيّ منكما خطأ، فتلك هي العلامة الكلاسيكية لغياب قائمة الـ relays، والخطوة 3 هي المكان الذي تعود إليه.

ويمكنك إجراء الاختبار نفسه وحدك: سجّل الدخول إلى حسابك من عميل ثانٍ، أو راسل نفسك إن كان عميلك يسمح بذلك.

وإن أردت أن ترى ما يُرسَل حقًا، فعارض أحداث Nostr مثل njump.me يعرض لك الأحداث الخام. الـ gift wrap السليم يبدو تقريبًا هكذا:

// مثال حدث NIP-17 (مبسط)
{
  "kind": 1059, // حدث gift wrap
  "pubkey": "<random_ephemeral_key>", // ليس المرسل الحقيقي!
  "tags": [["p", "<recipient_pubkey>"]],
  "content": "<encrypted_seal_content>"
}

شيئان يستحقان القراءة هناك. الـ pubkey مفتاح لمرة واحدة لن تتعرّف عليه، وهذا هو إخفاء المرسِل، أي بالضبط ما تريده. أما وسم p فيُظهر مفتاح المستلم الحقيقي. وليس هذا خللًا في إعدادك؛ الـ relay يحتاج إليه ليعرف إلى أين تذهب الرسالة.

أفضل ممارسات الأمان

حقق أقصى قدر من خصوصيتك عند استخدام NIP-17:

1. تحقق من دعم العميل قبل الاتصال الحساس

تحقق دائمًا من أن جهة اتصالك تستخدم عميلًا يدعم NIP-17 قبل أن تشارك أي شيء حسّاس. الـ gift wrap المُرسَل إلى شخص لا يتحدث عميله سوى NIP-04 لا يصل مشوّهًا، بل لا يصل إطلاقًا: عميله لا يبحث أصلًا عن أحداث النوع 1059، ولا يظهر لأيٍّ منكما أي خطأ.

2. اعتبر العودة إلى NIP-04 قرارًا حقيقيًا

بعض العملاء يسمحون لك بمواصلة محادثة NIP-04 قديمة. قد يكون هذا الخيار العملي أحيانًا، لكن اعرف ثمنه: رسالة NIP-04 تضع مفتاحيكما العامّين، مكشوفَين، على حدث يخزّنه كل relay. أبقِ ذلك للدردشة التي لا يضيرك أن تُنسب إليك علنًا، وابدأ أي شيء حسّاس كمحادثة NIP-17 جديدة.

3. استخدم مفاتيح جديدة للمحادثات عالية الأمان

للحصول على أقصى قدر من الأمان:

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

4. كن على دراية بالبيانات الوصفية في أنواع الأحداث الأخرى

يحمي NIP-17 فقط الرسائل المباشرة. لا تزال أنواع الأحداث الأخرى (ملاحظات، تفاعلات، متابعات) تكشف عن بيانات الرسم الاجتماعي. استخدم هويات متعددة للتجزئة.

5. اختر Relays تركز على الخصوصية

حتى مع NIP-17، أنماط حركة المرور الخاصة بك مرئية للـ relays. استخدم:

• Tor أو VPN للخصوصية الإضافية على مستوى الشبكة
• Relays التي لا تسجل أو تحتفظ ببيانات الرسائل الوصفية
• Relays متعددة لتوزيع حركة المرور الخاصة بك

6. فهم القيود

NIP-17 تحسّن حقيقي، لكنه لا يجعلك خفيًّا:

• لا تزال الـ relays ترى عنوان IP الخاص بك (استخدم VPN أو Tor)
• لا يزال تحليل التوقيت قادرًا على كشف أنماط الاتصال
• مفتاح المستلم على المظروف بنص مكشوف، بحكم التصميم
• هاتف أو عميل مخترَق يسرّب كل شيء، مهما فعل البروتوكول

استكشاف الأخطاء وإصلاحها

«رسائلي لا تصل أبدًا»: تحقّق أولًا من قائمة relays الرسائل الخاصة

هذا أكثر أعطال NIP-17 شيوعًا، ونادرًا جدًا ما تكون المشكلة في التشفير.

لا يسلّم مرسلو NIP-17 إلى الـ relays المعتادة لديك. هم يبحثون عن حدث من النوع 10050، أي قائمتك المنشورة بالـ relays التي تقبل رسائلك المباشرة، ثم يرسلون الـ gift wrap إليها وحدها. وإذا لم تنشر هذه القائمة قط، فلن يجد عميل المُرسِل جهة للتسليم وتُسقَط الرسالة بصمت، دون أن يظهر شيء في أيٍّ من الواجهتين.

الحل: في عميل يدعم NIP-17، ابحث عن إعداد relays الرسائل الخاصة واحفظ relay واحدًا على الأقل؛ هذا ينشر قائمتك من النوع 10050. واختر relay يقبل فعلًا الـ gift wraps، فبعضها يرفض النوع 1059. (هذه هي الخطوة 3 من دليل الترحيل. إذا كنت قد تخطيتها فابدأ من هناك.)

أبقِ القائمة قصيرة: كل relay تضيفه هو relay يرى من يراسلك.

«جهة اتصال واحدة بعينها لا يصلها شيء مما أرسله»

إن كان الجميع يسمعون منك ولا يسمع منك شخص واحد، فالمشكلة عنده لا في تشفيرك. عميله على الأرجح بلا دعم لـ NIP-17، فلا يشترك أبدًا في الـ gift wraps ولا يرى رسالتك. ولا يظهر شيء «هراءً» لأنه لا يظهر شيء أصلًا.

الحل: اطلب منه الانتقال إلى أحد عملاء الخطوة 1. وإن تعذّر ذلك ولم يبقَ أمامكما سوى رسائل NIP-04 القديمة، فاقرأ التحذير في «أفضل ممارسات الأمان» أولًا: NIP-04 يسلّم مفتاحيكما العامّين لكل relay بنص مكشوف.

”لا يمكن رؤية ما إذا كان شخص ما قرأ رسالتي NIP-17”

السبب: إيصالات القراءة غير موحدة لـ NIP-17 بعد الحل: هذا السلوك المتوقع. يعطي NIP-17 الأولوية للخصوصية على تأكيد التسليم.

”تظهر الرسائل بترتيب غير صحيح”

السبب: اختلاف الساعة بين الأجهزة الحل: تأكد من أن وقت جهازك متزامن (شغل المزامنة التلقائية للوقت)

“يرفض Relay أحداث NIP-17”

السبب: الـ relay يشغّل برنامجًا قديمًا، أو أنه ببساطة يرفض تخزين أحداث النوع 1059 الحل: استبدله بآخر في قائمة relays رسائلك المباشرة. بعض العملاء يعرضون ما يدعمه الـ relay في شاشة الـ relays؛ وإن لم يفعل عميلك، فتجريب relay آخر ومراقبة وصول الرسائل أسرع من التحقيق في الأمر. وإبلاغ المشغّل يستحق دقيقة أيضًا.

«يعرض عليّ عميلي الاختيار بين نوعَي الرسائل»

السلوك المتوقع: بعض العملاء لا يزالون يقرأون الصيغتين ويكتبونهما ريثما تكمل الشبكة انتقالها، ويتركون لك الاختيار لكل محادثة. اختر NIP-17 كلما كان متاحًا.

مستقبل الرسائل الخاصة في Nostr

NIP-17 هو المعيار الحالي للرسائل الخاصة الثنائية في Nostr، وهو ما ينبغي أن تستخدمه اليوم. لكنه ليس نهاية الطريق، وثغرتاه الحقيقيتان هما ما يعمل الناس عليه: لا forward secrecy، ولا دردشة جماعية بالمعنى الصحيح.

وأجدّ الأجوبة حتى الآن هو بروتوكول Marmot، الذي يضع MLS (معيار الرسائل الجماعية الذي تقوم عليه دردشات المجموعات على طريقة Signal) فوق Nostr، مع إبقاء مفاتيح Nostr كهوية. يذكر مستودع Marmot نفسه أن المواصفة معتمَدة، وتطبيق White Noise هو تطبيق الدردشة المبني عليها. وهذا النهج يوفّر فعلًا الـ forward secrecy ويتعامل مع المجموعات، أي بالضبط ما يتركه NIP-17 ناقصًا.

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

الخلاصة

NIP-17 تحسّن حقيقي على NIP-04، وهو ما ينبغي أن تستخدمه. لكن كن واضحًا بشأن ما تحصل عليه. كلامك مشفّر، ولا يستطيع الـ relay أن يعرف من أرسل الرسالة. لكنه لا يزال يرى إلى أي حساب هي موجّهة، ولا يزال بإمكان من يراقب الطرفين أن يستنتج الكثير من التوقيت. عامله كبريد مغلَق، لا كرسالة لا يمكن تعقّبها.

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

المهام العملية:

1. ✅ استخدم عميلًا يدعم NIP-17 (‏Amethyst أو 0xchat أو Coracle أو Snort)
2. ✅ انشر قائمة relays الرسائل المباشرة (النوع 10050)، فبدونها لن يصلك شيء
3. ✅ أرسل رسالة اختبار في الاتجاهين مع جهة اتصال، لتعرف أن التسليم يعمل
4. ✅ قبل أي شيء حسّاس، تحقق من العميل الذي يستخدمه الطرف الآخر

والخصوصية في النهاية عادة تُمارَس. يمنحك NIP-17 الأدوات، ويبقى حسن استخدامها مسؤوليتك.

---

اختبر معرفتك بـ NIP-17

جاهز للتحقق من فهمك للمراسلة الآمنة؟

اختبار الرسائل الخاصة

غرض NIP-17

السؤال 1 من 5

0/5 تمت الإجابة

ما هو NIP-17؟

نوع جديد من الـ Relays

معيار تشفير محسّن للرسائل الخاصة يحل محل NIP-04

تكامل مع محفظة بيتكوين

---

آخر تحديث: 2 سبتمبر 2026

لديك أسئلة؟ انضم إلى النقاش على Nostr أو افتح issue في مستودع التوثيق هذا.

---

تابع القراءة

• الخصوصية والأمان على Nostr: نموذج التهديد الأوسع الذي تقع هذه الرسائل داخله
• مفاتيحك، هويتك: ضياع المفتاح يعني ضياع المحادثة، بلا رجعة