Nostr

منصة · هذا التحليل المعمّق مبني على الصفحات الرسمية صفحات المنصة نفسها والأدوات المساعدة.

انظر أيضاً: كيف تقرأ البطاقات и عن المصادر والمنهج.

نظرة عامة

Nostr ليس منصة بل بروتوكول. والاسم اختصار لعبارة Notes and Other Stuff Transmitted by Relays، أي «ملاحظات وأشياء أخرى تُنقل عبر المرحّلات». ويصفه موقع nostr.com بأنه «شبكة حرة ومفتوحة لا يملكها أحد ولا يتحكم بها أحد».

البنية بسيطة، وعليها يقوم كل ما عداها. هناك المرحّلات (relays) — خوادم تخزّن الرسائل وتوزّعها. وهناك العملاء (clients) — تطبيقات يقرأ الناس ويكتبون من خلالها. وهناك المفاتيح: المفتاح العام يعمل عمل اسم المستخدم، والمفتاح الخاص عمل كلمة المرور؛ والمفاتيح هي التي تمنحك الحق في هويتك، لا الشركة. ولأن الهوية ملك للمفتاح لا للتطبيق، يمكنك الانتقال بين العملاء مع الاحتفاظ بملفك الشخصي ومشتركيك ومنشوراتك.

تقنياً يعود الأمر كله إلى نوع واحد من الكائنات. تنص الوثيقة الأساسية للبروتوكول على أن النوع الوحيد الموجود هو «الحدث» (event)، وأن التواقيع والمفاتيح تستخدم مخطط شنور على منحنى secp256k1، وأن المرحّل يعرض نقطة websocket يرسل إليها العميل ثلاثة أنواع من الرسائل: EVENT للنشر، وREQ للاشتراك في استعلام، وCLOSE لإغلاقه.

وهذا يعني بالنسبة إلى هذا الدليل ما يلي: ليس لـ Nostr مالك، ولا جمهور واحد، ولا لوحة إعلانات، ولا قواعد إشراف، ولا برنامج مدفوعات. وفيما يلي بيان ما هو موجود بدلاً من ذلك.

من يوجد هنا

لا وجود لرقم يمثّل جمهور Nostr — ولا يمكن أن يوجد بالشكل المعتاد. فليس ثمة خادم مركزي يحصي المستخدمين: هناك عدد كبير من المرحّلات المستقلة، كل واحد منها لا يرى سوى مستخدميه.

ولا يمكن الحكم إلا بشكل غير مباشر ومن خلال مرحّلات بعينها. فالعميل على nostr.com يتصل افتراضياً بستة مرحّلات ويعرض قائمتها في الواجهة مباشرة: relay.nostr.com، relay.damus.io، nos.lol، nostr.bitcoiner.social، nostr.mom و relay.snort.social. ويوصي المشروع بالاطلاع على دليل المرحّلات لدى أداة خارجية هي Nostr.watch، وعلى دليل العملاء في nostrapps.com (صفحة المرحّلات، صفحة العملاء).

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

كيف تبدأ

لا يوجد تسجيل بالمعنى المعتاد: الحساب هو زوج من المفاتيح يولّده التطبيق. لا تأكيد بريد إلكتروني، ولا رقم هاتف، ولا مراجعة لطلب.

ومن هنا ينشأ الخطر الرئيسي الذي يحذّر منه المشروع نفسه: المفتاح الخاص يمنح وصولاً كاملاً إلى الحساب — فبه يمكن النشر باسمك وتغيير الملف الشخصي وإرسال الرسائل؛ وإذا ضاع المفتاح ولم تكن لديك نسخة، فلا وجود لزر «نسيت كلمة المرور». ونصيحة المشروع العملية: لا تُدخل مفتاحك الخاص في كل تطبيق يصادفك — فامتداد المتصفح الموقّع أو الموقّع البعيد أكثر أماناً.

ويمكن الحصول على اسم قابل للتحقق يشبه «علامة التوثيق»: إذ تصف وثيقة منفصلة من البروتوكول ربط المفتاح بنطاق. فالعميل يأخذ من الملف الشخصي عنواناً على هيئة الاسم@النطاق، ويطلب https://النطاق/.well-known/nostr.json?name=الاسم ويقارن المفتاح العام الذي يتلقاه بمفتاح صاحب المنشور. وهذه بالنسبة إلى الشركة هي طريقة تأكيد أن الحساب يخصها فعلاً: فالتأكيد يأتي من التحكم بالنطاق، لا من قرار مشرف.

ولا يوجد حساب أعمال منفصل — كما لا يوجد حساب عادي أصلاً. فحضور الشركة في Nostr هو مفتاح مربوط بنطاقها، ومرحّل خاص بها إن أرادت.

ما الذي يمكن نشره

تُحدَّد الصيغ بـ«أنواع» الأحداث، والأنواع موصوفة في وثائق منفصلة — NIP (Nostr Implementation Possibilities). وتُحفظ قائمتها في مستودع مفتوح وتشمل، من بين أمور أخرى: الملاحظات القصيرة وسلاسل النقاش، والمواد الطويلة، والصور والفيديو، والبث المباشر و«المساحات»، واستطلاعات الرأي، وأحداث التقويم، والويكي، والتورنت، والقوائم، والإشارات المرجعية، والاقتباسات (قائمة NIP).

وليس في البروتوكول حدود للطول أو الحجم — بل هي لدى المرحّل، وعلى المرحّل أن يعلنها. وتصف وثيقة معلومات المرحّل هذه الحقول: max_message_length — الحجم الأقصى لـ JSON الوارد بالبايت (وهو عملياً يحدّ حجم الحدث أيضاً)، وmax_content_length — العدد الأقصى للمحارف في حقل المحتوى، وmax_event_tags — العدد الأقصى للوسوم، وmax_subscriptions — عدد الاشتراكات المتزامنة على اتصال واحد، وmax_limit — سقف عدد الأحداث في الرد على طلب واحد.

وهكذا يبدو الأمر عملياً. يعلن المرحّل relay.damus.io في تاريخ التحقق حداً للرسالة قدره 1 000 000 بايت، و200 اشتراك، وسقف استعلام قدره 500 حدث؛ والمرحّل nos.lol — 131 072 بايت، و20 اشتراكاً، والـ 500 حدث ذاتها؛ والمرحّل relay.nostr.com — 131 072 بايت، و200 اشتراك، و500 حدث. وهذه الأرقام تخص كل مرحّل على حدة، وستكون مختلفة على مرحّل آخر.

وليس في البروتوكول حظر على المحتوى. بل ثمة ترميز تقني: وثيقة تصف وسم المحتوى الحساس، وأخرى تصف البلاغات عن الأحداث، وثالثة تصف طلب الحذف. وانتبه إلى كلمة «طلب»: فالحذف في Nostr رجاء موجّه إلى المرحّلات، لا ضمانة. أما ما يُقبل ويُخزَّن فيقرره مالك المرحّل.

كيف تنمو

لا وجود لتغذية خوارزمية في البروتوكول. فما يُعرض على المستخدم يقرره العميل، وأي الأحداث تُسلَّم يقرره المرحّل. والعميل على nostr.com يُظهر ذلك بوضوح: في واجهته خيارات للتغذية هي «الاشتراكات» و«العالمية» و«الخاصة»، وتحتها قائمة المرحّلات المتصلة.

ومن هنا نتيجة عملية يشرحها المشروع بنفسه: إذا بدا Nostr بطيئاً أو فارغاً، فقد يكون السبب في المرحّلات؛ فبعض المرحّلات سريع وموثوق، وبعضها يتوقف ولا يستجيب، وإضافة عدد من المرحّلات الجيدة تغيّر الكثير. والنمو في Nostr هو أولاً وقبل كل شيء النشر في المرحّلات التي يوجد فيها قراء فعلاً.

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

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

طريق تحقيق الدخل

لا توجد منصة — ومن ثم لا توجد مدفوعات من منصة. لكن توجد مدفوعات مباشرة بين الناس، وهي موصوفة في البروتوكول نفسه.

وتسمى الآلية «الزاب» (zap) — دفعة عبر شبكة Lightning. وتُدخل وثيقة البروتوكول نوعين من الأحداث: 9734 — طلب الزاب، أي توجّه الدافع إلى محفظة المستلم طلباً للفاتورة، و9735 — الإيصال، أي تأكيد محفظة المستلم أن الفاتورة دُفعت. والمسار كالتالي: العميل يأخذ من ملف المستلم عنوان نقطة الدفع الخاصة به، ويتحقق من أنها تدعم Nostr، ويرسل إليها طلباً موقّعاً ويتلقى فاتورة؛ وبعد الدفع تنشر المحفظة إيصالاً. ومعنى الإيصال مشروح في الموضع نفسه: فهو يتيح للعملاء عرض المدفوعات في التغذية مباشرة — للمتعة أو كوسيلة لمكافحة السخام.

ولا توجد عمولة منصة في هذا المخطط — فالمال ينتقل من محفظة إلى محفظة. لكن لا توجد ضمانات منصة كذلك: فتسليم الدفعة مسؤولية شبكة Lightning ومزوّد المحفظة الذي تختاره.

وإلى جانب الزابات تتضمن قائمة البروتوكول آليات مالية أخرى: أهداف الجمع (zap goals)، والشارات، ومحافظ Cashu و«النَتزابات»، والربط البعيد للمحفظة، وأحداث الطلبات بين الناس. وكل واحدة منها ينفّذها العميل إن شاء.

الأدوات والأتمتة

لا توجد لدى Nostr «واجهة برمجية رسمية» للسبب نفسه الذي لا يوجد له مالك: البروتوكول نفسه هو الواجهة. فأي برنامج يستطيع فتح websocket نحو مرحّل والعمل معه مباشرة (الوثيقة الأساسية). ولا وجود لمفاتيح المطورين ولا لطلبات الوصول ولا لمراجعة التطبيقات.

وقبل بناء أي أداة يجدر بك قراءة التحذير الوارد في القائمة نفسها: «NIP هنا ليست قائمة تحقق للبروتوكول. لا شيء يُجبر أي برنامج على تنفيذ أي NIP. وكل تطبيق يختار المجموعة الجزئية التي يحتاجها لمهمته». ومعنى ذلك أنه لا يمكن التعويل على ميزة لمجرد أنها موصوفة: بل عليك التحقق من أن مرحّلاً بعينه يدعمها. وثمة طريقة للتحقق: فالمرحّل يقدّم عبر HTTP وثيقة تتضمن قائمة الـ NIP التي يدعمها، واسم البرنامج، ونسخته، وجهات الاتصال ورابطاً إلى شروط خدمته. والمرحّلات الثلاثة المذكورة أعلاه تعلن المجموعة ذاتها: ثلاثتها تعمل ببرنامج strfry وتدعم NIP 1 و2 و4 و9 و11 و28 و40 و45 و70 و77.

ومن الأدوات الجاهزة يذكر المشروع امتدادات المتصفح للتوقيع والموقّعات البعيدة، وكذلك موقّعه الخاص Pomegranate. أما أدلة العملاء والمرحّلات فتُحفظ خارج البروتوكول — في nostrapps.com و Nostr.watch (صفحة العملاء، صفحة المرحّلات).

القيود والقواعد

• لا توجد قواعد موحدة. فلا وجود لأي وثيقة تمنع شيئاً على جميع المشاركين في الشبكة. والقواعد يضعها مالك المرحّل؛ والبروتوكول لا ينص إلا على رابط إلى شروط الخدمة ضمن معلومات المرحّل.
• الحدود يضعها المرحّل ويعلنها بنفسه: حجم الرسالة، وطول المحتوى، وعدد الوسوم، وعدد الاشتراكات، وسقف الاستعلام.
• يجوز للمرحّل أن يطلب تسجيل الدخول وفق بروتوكول المصادقة أو إثبات العمل للأحداث الجديدة.
• الحذف غير مضمون: فالوثيقة تصف تحديداً «طلب الحذف»، وتنفيذه من عدمه يقرره كل مرحّل.
• فقدان المفتاح لا رجعة فيه. ولا توجد استعادة للوصول.
• لا إطار قانوني للشبكة. فالمسؤولية يتحملها مالك المرحّل والمؤلف؛ ولا يوجد لدى البروتوكول كيان قانوني يمكن إبرام عقد معه. وقائمة NIP ذاتها تُنشر في مستودع من دون ترخيص معلن.

لمن يناسب

يناسب المشاريع التي يهمها الاستقلال عن مالك المنصة: فالهوية ملك للمفتاح لا للشركة، ولا يمكن حظر الحساب مركزياً، وعند عدم الرضا عن مرحّل يكفي تغيير المرحّل. ويناسب المطورين: فالاتصال بالشبكة لا يتطلب مفتاح تطبيق ولا موافقة.

ويناسب المشاريع المرتبطة بالبيتكوين وLightning: فالمدفوعات مدمجة في البروتوكول على هيئة زابات، وهذا أكثر أجزاء آليته المالية تطوراً.

ولا يناسب إن كنت تحتاج إلى وصول متوقع وتقارير: فلا شيء هنا يُقاس — لا منصة ولا إحصاءات ولا لوحة إعلانات. ولا يناسب الإرسال الجماعي و«الترويج»: فللمرحّل أن يطلب رسماً أو تسجيل دخول أو إثبات عمل وأن يقطع الاتصال بك من دون تفسير. ولا يناسب إن كانت مؤسستك تشترط عقداً مع مزوّد خدمة: فليس لدى البروتوكول طرف كهذا.

حقائق محقَّقة من قاعدة البيانات

بيانات محقَّقة موجزة يستند إليها هذا التحليل المعمّق.

عن المنصة

تصف المنصة نفسها هكذا: «Nostr is a free and open-source protocol for social media and other things - controlled by users, not platforms.»

وصف ذاتي: هذا تصريح من المنصة عن نفسها، وليس تقييماً مستقلاً

المصدر, تم التحقق 2026-07-28

Nostr (Notes and Other Stuff Transmitted by Relays) موصوف بأنه شبكة حرة ومفتوحة لا يملكها أحد ولا يتحكم بها أحد؛ الترحيلات تخزّن الرسائل وتوزّعها، والعملاء يتيحون قراءتها وكتابتها

هذا بروتوكول لا منصة: ليس له مالك ولا لوحة إعلانات ولا برنامج مدفوعات

المصدر, تم التحقق 2026-07-28

النوع الوحيد من الكائنات هو الحدث (event)؛ والتواقيع والمفاتيح تستخدم مخطط شنور على منحنى secp256k1؛ والترحيل يعرض نقطة websocket، ويرسل العميل EVENT للنشر وREQ للاشتراك وCLOSE لإغلاقه

الوثيقة الأساسية للبروتوكول NIP-01

المصدر, تم التحقق 2026-07-28

من أين تبدأ

ليس لعتبة الدخول إلى nostr مالك واحد للقواعد: «Nostr (Notes and Other Stuff Transmitted by Relays) is a free and open network that nobody owns or controls»؛ ومجموعة مقترحات البروتوكول تقول الشيء نفسه عن نفسها: «NIPs listed here are not a protocol checklist. Nothing forces any software to implement any NIP»

الاقتباسان حرفيان، ولغة المصدر الإنجليزية. والثاني من ملف README لمجموعة NIP: https://raw.githubusercontent.com/nostr-protocol/nips/master/README.md. والخلاصة العملية للقارئ: لا وجود لشروط دخول موحّدة ملزمة للشبكة كلها؛ فالشروط يضعها كل مُرحِّل وكل تطبيق على حدة، وهي مختلفة

المصدر, تم التحقق 2026-08-07

للمُرحِّل أن يغلق الكتابة أو يشترط الدخول بتوقيع أو يطلب إثبات عمل: ففي قائمة قيود NIP-11 ذُكر «auth_required» و«restricted_writes» و«min_pow_difficulty» و«payment_required»؛ «Your client should expect that requests exceed these practical limitations are rejected or fail immediately»

الاقتباسات حرفية، ولغة المصدر الإنجليزية، مع الإبقاء على إملاء المصدر. ولا وجود على مستوى البروتوكول لطلبات ولا دعوات ولا إشراف تحريري؛ فكل ما ذُكر خصائص لمُرحِّل مفرد، ويمكن معرفتها بطلب وثيقة بياناته منه

المصدر, تم التحقق 2026-08-07

الحساب والوصول

الحساب زوج مفاتيح لا سجل لدى مالك منصّة: «Every account has Nostr keys. Your public key is like your username and can be shared with anyone. Your private key is like your password and must be kept safe. These keys give you ownership of your identity, rather than a company owning it for you»

الاقتباس حرفي، ولغة المصدر الإنجليزية. ولا يلزم للحصول على المفاتيح تسجيل ولا إثبات هوية ولا موافقة: فزوج المفاتيح يُولَّد على الجهاز. أما الاسم القابل للتحقق من نوع اسم@نطاق فاختياري وموصوف في NIP-05 المستقل

المصدر, تم التحقق 2026-08-07

للحساب زوج مفاتيح: العام يعمل كاسم مستخدم، والخاص ككلمة مرور؛ والهوية تعود للمفتاح لا للتطبيق، ولذلك يمكن تبديل العميل مع الاحتفاظ بالملف الشخصي والمتابعين

لا يوجد تسجيل ولا تأكيد بريد ولا مراجعة طلب

المصدر, تم التحقق 2026-07-28

عند فقدان المفتاح الخاص بلا نسخة احتياطية لا سبيل لاستعادة الوصول: لا وجود لزر «забыли пароль»

ينصح المشروع بعدم إدخال المفتاح الخاص في كل تطبيق، بل باستخدام إضافة موقِّعة أو موقِّع بعيد

المصدر, تم التحقق 2026-07-28

اسم قابل للتحقق بصيغة اسم@نطاق: يطلب العميل https://نطاق/.well-known/nostr.json?name=اسم ويطابق المفتاح العام المستلَم مع مفتاح صاحب المنشور

بالنسبة إلى الشركة هذه وسيلة لتأكيد الحساب عبر السيطرة على النطاق، لا بقرار مشرف

المصدر, تم التحقق 2026-07-28

ما الذي يمكن نشره

قائمة NIP تصف من جملة ما تصف: الملاحظات القصيرة والسلاسل، والمواد الطويلة، والصور والفيديو، والبث المباشر والمساحات الصوتية، والاستطلاعات، وأحداث التقويم، والويكي، والتورنتات، والقوائم، والمحفوظات والاقتباسات

قائمة NIP ليست التزامات: لا شيء يُجبر برنامجًا على تنفيذ أي NIP

المصدر, تم التحقق 2026-07-28

كيف تُدفع الأموال هنا

من يُقبل. لا عتبة للمدفوعات بالمشتركين أو المشاهدات أو عدد المنشورات: فالزابّات تنتقل من شخص إلى شخص مباشرة عبر شبكة Lightning، والشرط الوحيد هو أن يملك المتلقّي محفظة بعنوان lnurl — «Client calculates a recipient's lnurl pay request url from the zap tag on the event being zapped, or by decoding their lud16 field on their profile»

الاقتباس حرفي، ولغة المصدر الإنجليزية. عتبة الصفر: لا يشترط NIP-57 عدد مشتركين ولا ساعات مشاهدة ولا عمرًا للحساب. أما المبالغ الحدّية فتحدّدها محفظة المتلقّي بحقلَي «minSendable» و«maxSendable»، لا الشبكة

المصدر, تم التحقق 2026-08-07

لا عمولة للشبكة ولا من يأخذها: فالمال يمرّ خارج البروتوكول، عبر محفظة المتلقّي، وnostr ليس طرفًا في الحساب — إذ يصف NIP-57 نوعين من الأحداث فقط، سجل الطلب وسجل الإيصال: «9734 is a zap request… 9735 is a zap receipt, representing the confirmation by the recipient's lightning wallet that the invoice issued in response to a zap request has been paid»

الاقتباس حرفي، ولغة المصدر الإنجليزية. وقد تأخذ المحفظة أو عقدة شبكة Lightning عمولتها — وهذا لم يعد nostr، ومقدارها غير محدّد في NIP-57. ولا عمولة ولا حصة ولا عتبة دفع لدى الشبكة، لأنه لا وجود لوسيط يحتفظ بالمال

المصدر, تم التحقق 2026-08-07

المدفوعات بين الأشخاص موصوفة في البروتوكول بأنها «запы» عبر شبكة Lightning: الحدث 9734 هو طلب زاب، والحدث 9735 هو إيصال محفظة المستلم بسداد الفاتورة

لا عمولة للمنصة في المخطط: المال ينتقل من محفظة إلى محفظة؛ ومسؤولية التسليم على شبكة Lightning ومزوّد المحفظة

المصدر, تم التحقق 2026-07-28

قائمة NIP تتضمن أيضًا أهداف الجمع (zap goals) والشارات ومحافظ Cashu والنات-زابات، والاتصال البعيد بالمحفظة، وأحداث الطلبات بين الأشخاص

كل آلية ينفّذها العميل باختياره

المصدر, تم التحقق 2026-07-28

الأسعار

لا يأخذ البروتوكول مالًا، لكن المُرحِّل المفرد قد يأخذ: فـNIP-11 ينصّ على حقول للرسوم — «Relays that require payments may want to expose their fee schedules»: «fees»: «admission» (رسم القبول)، «subscription» (اشتراك مع حقل «period»)، «publication» (رسم النشر، مع بيان أنواع الأحداث)؛ وفي قائمة قيود المُرحِّل سمة «payment_required»

الاقتباسات حرفية، ولغة المصدر الإنجليزية. والأرقام يحدّدها كل مُرحِّل بنفسه، ولذلك ليس للشبكة سعر دخول موحّد. والمثال الوارد في NIP-11 نفسه بوصفه نموذجًا لاستجابة المُرحِّل nostr.wine: «fees»: «admission»: ({«amount»: 18888000, «unit»: «msats»}) — وهذا تصريح مُرحِّل في مثال الوثيقة، لا حسابنا نحن ولا وعدًا بالسعر الجاري

المصدر, تم التحقق 2026-08-07

القيود والحدود

يعلن الترحيل قيوده في وثيقة المعلومات: max_message_length (حجم JSON الوارد)، وmax_content_length (المحارف في حقل المحتوى)، وmax_event_tags، وmax_subscriptions، وmax_limit؛ وقد يشترط التوثيق وإثبات العمل

وثيقة NIP-11؛ وليس للبروتوكول قيود طول وحجم خاصة به

المصدر, تم التحقق 2026-07-28

الترحيل relay.damus.io يعلن في تاريخ الفحص حدًا للرسالة قدره 1 000 000 بايت، و200 اشتراك متزامن، وسقف استخراج 500 حدث؛ والبرنامج strfry

الرقم يخص هذا الترحيل، وهو مختلف على غيره

المصدر, تم التحقق 2026-07-28

الترحيل nos.lol يعلن حدًا للرسالة قدره 131 072 بايت، و20 اشتراكًا، وسقف استخراج 500 حدث

قيس بطلب وثيقة المعلومات عن الترحيل

المصدر, تم التحقق 2026-07-28

الترحيل relay.nostr.com يعلن حدًا للرسالة قدره 131 072 بايت، و200 اشتراك، وسقف استخراج 500 حدث؛ وNIP المعلنة هي 1 و2 و4 و9 و11 و28 و40 و45 و70 و77

المجموعة نفسها من NIP يعلنها damus.io وnos.lol

المصدر, تم التحقق 2026-07-28

القيود

لا توجد قواعد موحّدة: مالك الترحيل هو من يقرر ما يقبله ويخزّنه؛ والبروتوكول ينص فقط على رابط لشروط الخدمة في معلومات الترحيل

الحذف موصوف بأنه «запрос на удаление»، وتنفيذه غير مضمون

المصدر, تم التحقق 2026-07-28

وسائل مكافحة الرسائل المزعجة: يمكن للترحيل أن يشترط إثبات عمل بصعوبة محددة أو توثيقًا؛ وبعض الترحيلات مدفوعة، وهو ما يقلّل الإزعاج بحسب شرح المشروع

يوصي المشروع بـ Nostr.watch كدليل للترحيلات، وnostrapps.com كدليل للعملاء

المصدر, تم التحقق 2026-07-28

ملف الروبوتات في nostr.com يسمح بزحف الموقع لجميع الوكلاء

جرى التحقق منه على حدة

المصدر, تم التحقق 2026-07-28

الجانب القانوني

مستودع قائمة NIP منشور دون ترخيص محدد

ليس للبروتوكول كيان قانوني يمكن التعاقد معه

المصدر, تم التحقق 2026-07-28

الوصول البرمجي

العميل على nostr.com يتصل افتراضيًا بستة ترحيلات: relay.nostr.com وrelay.damus.io وnos.lol وnostr.bitcoiner.social وnostr.mom وrelay.snort.social

القائمة ظاهرة في الواجهة مباشرة

المصدر, تم التحقق 2026-07-28

لا وجود لـ «официального API» منفصل: الواجهة هي البروتوكول نفسه، وأي برنامج يستطيع فتح websocket إلى ترحيل؛ ولا وجود لمفاتيح مطوّرين ولا لمراجعة التطبيقات

التحقق من دعم إمكانات بعينها يجري عبر وثيقة المعلومات عن الترحيل

المصدر, تم التحقق 2026-07-28

اللغات

لغة واجهة الصفحة الرئيسية: en

اللغة مأخوذة من سمة الترميز، والنسخ من hreflang

المصدر, تم التحقق 2026-07-28

قسم الدليل: كل ما يشبهها انظر أيضاً: فهرس الدليل · مقارنة أدوات الجدولة · الاختيار حسب الحالة · قيود المنصات