Nostr

يتضمن الحدث pubkey وcreated_at وkind وtags وcontent وid وsig. يشتق NIP-01 قيمة id بواسطة SHA-256 من تسلسل محدد بدقة، ويستخدم BIP340 على secp256k1. يتحقق العميل من السلامة والتفويض بالمفتاح. يضع المؤلف created_at؛ فهو ليس ختمًا زمنيًا مستقلًا أو دليلًا على صدق المحتوى. [Nostr — NIP-01: Basic protocol] [fiatjaf — Original Nostr description]

ينشر العميل EVENT ويشترك بواسطة REQ عبر WebSocket. يبلّغ OK بقبول ذلك الخادم أو رفضه. ينهي EOSE قائمة الأحداث المحفوظة، لا الاشتراك في الأحداث الجديدة بالضرورة. لا تؤكد هذه الرسائل وصول المحتوى للمستلم أو نسخه في الشبكة كلها أو حفظه الدائم. [Nostr — NIP-01: Basic protocol]

داخل المرشح الواحد يجب أن تتحقق جميع الشروط: المؤلف والنوع يعنيان AND. تُجمع المرشحات المتعددة في REQ بواسطة OR؛ يكفي تحقق أحدها. يحد limit القائمة الأولية، لا عدد الأحداث المقبلة. قد تعني النتيجة الغائبة أن تاريخ الخادم محدود، لا أن الحدث غير موجود. [Nostr — NIP-01: Basic protocol]

تُقارن الأحداث القابلة للاستبدال وفق pubkey وkind، والقابلة للعنونة أيضًا وفق الوسم d. قد تحل نسخة أحدث محل القديمة؛ وعند تساوي الوقت يُختار id الأقل معجميًا. لا يُتوقع حفظ الأحداث العابرة. هذه قواعد لسلوك الخوادم، لا أرشيف عالمي ثابت؛ وقد تختلف التطبيقات. [Nostr — NIP-01: Basic protocol]

يستخدم NIP-19 ترميز Bech32 للعرض: يدل npub على المفتاح العام وnsec على الخاص. الترميز ليس تشفيرًا. لذا فإن مشاركة nsec تسلّم المفتاح السري، لا مجرد رابط ملف شخصي. تستخدم أحداث ومرشحات NIP-01 المفاتيح العامة بالصيغة السداسية عشرة، لا عرض npub. [Nostr — NIP-19: Encoded entities]

يربط NIP-05 اسمًا شبيهًا بالبريد الإلكتروني بمفتاح عام بحسب رد النطاق. يثبت ذلك الارتباط، لا الهوية الحقيقية أو الأمانة. ينبغي أن يتابع العميل المفتاح الأصلي: إذا غيّر النطاق ربط الاسم إلى مفتاح آخر، فلا يستبدل به تلقائيًا الملف الذي سبق اتباعه. [Nostr — NIP-05: Internet identifiers]

يعرّف NIP-09 طلب المؤلف إزالة أحداثه. قبل الإخفاء ينبغي للعميل التحقق من تطابق المفتاح العام للحدث الأصلي والطلب. يمكن للخوادم والعملاء معالجته، لكن البروتوكول لا يزيل كل نسخة نُزّلت أو حُفظت. الحذف في واجهة واحدة ليس دليلًا على محو عالمي. [Nostr — NIP-09: Deletion requests]

يعرّف NIP-44 حمولة payload مشفرة، لا نظام مراسلة خاصة كاملًا؛ ويضيف NIP-17 الأغلفة وقواعد التسليم. لا يوفر NIP-44 وحده forward secrecy عند تسرب المفتاح لاحقًا. تظل عناوين الشبكة والتوقيت وسلوك العميل مهمة حتى مع التشفير. يجب تمييز دعم كل NIP بحسب التطبيق. [Nostr — NIP-44: Encrypted payloads] [Nostr — NIP-17: Private messages]