نالت Nostr الكثير من الاهتمام والدعم منذ إضافتها مؤخرًا إلى قائمة المنصات الاجتماعية البديلة التي تم حظر الترويج لها على Twitter. كما أنها تزداد شعبيتها ، حيث من الواضح أن استحواذ Elon Musk على Twitter لم يغير بشكل أساسي حرية التعبير على المنصة – لا يزال المستخدمون محظورون لأسباب غير متسقة وتعسفية ، يبحث الناس عن بديل لامركزي لذلك. على عكس Mastodon ، حيث لا يزال مشغلو الخادم لديهم القدرة على التحكم في هويتك.
![Nostr](https://bitcoinmagazine.com/.image/ar_16:9%2Cc_fill%2Ccs_srgb%2Cg_faces:center%2Cq_auto:good%2Cw_768/MTk0MjMxNzYxODMwNjE4NjI5/satoshi-guy-fawkes-coding.png)
على الرغم من الاهتمام الأخير
تم إنشاء بروتوكول Nostr وتطبيق خادم الترحيل الأول بالفعل بواسطة المطور fiatjaf في أواخر عام 2020. قبل أن يكتسب اهتمامًا واسع النطاق ، كان بروتوكولًا متخصصًا هادئًا أراد فقط أن يكون حلاً خفيفًا لمشاكل Twitter و Mastodon. في كلا النظامين ، هويتك / اسم المستخدم الخاص بك هو مجرد شيء يتحكم فيه من يدير الخادم. كون Mastodon نظامًا متحدًا به عدة خوادم مختلفة تتواصل جميعها مع بعضها البعض لا يغير هذا الواقع بشكل أساسي. بغض النظر عن الخادم الذي تستخدمه لاستضافة حسابك ، لديك سيطرة كاملة على ما إذا كان يمكنك استخدامه أم لا. حتى عند تشغيل الخوادم الخاصة بك ، يمكن لمشغلي الخوادم الآخرين وضع الخوادم في القائمة السوداء أو القائمة البيضاء التي يُسمح لها بالاتصال بخوادمهم. يؤدي هذا إلى عدد كبير من الأقسام في “Fediverse” لخوادم Mastodon المختلفة ، ويجعل فكرة تشغيل نفسها فقط موضع نقاش. قد يستمر الأمر في النهاية بالرقابة من قبل مشغلي الخوادم الآخرين ، مما يمنع مستخدميهم من رؤية المحتوى الخاص بك في خلاصاتهم.
يتمثل الاختلاف الأساسي بين Nostr وشيء مثل Mastodon في أن كل مستخدم يستخدم زوج مفاتيح عام / خاص للتعامل مع الوظيفة ، بدلاً من استخدام اسم مستخدم مملوك لمشغل الخادم. هذا شيء لا يمكن لمشغل الخادم أن يأخذه منك أو يمنعك منه. هذا هو أحد اللبنات الأساسية لبناء بروتوكول Nostr بأكمله.
التالي هو “الأحداث”
هذا هو نوع الكائن / البيانات الأساسي الذي يستخدمه العملاء وخوادم الترحيل التي يتصل بها العملاء لإرسال الرسائل واستردادها. الفكرة العامة للبروتوكول هي أن العملاء يرسلون الأحداث إلى خادم الترحيل ، والذي يقوم بدوره بتخزين هذه الأحداث وفهرستها ، ويمكن للعملاء الآخرين التواصل مع خادم الترحيل لطلب الأحداث التي يتلقونها وتخزينها. في NIP 01 الأصلي ، تم تحديد ثلاثة أنواع مختلفة من الأحداث:.
مُثير للإهتمام حقاً
يتم تنظيم جميع الأحداث بطريقة محددة ومحددة
وهي تشمل المفتاح العام للمنشئ والطابع الزمني للإنشاء والنوع (أو النوع في المواصفات) وحمولة المحتوى وتوقيع منشئ الحدث. يمكن أن تحتوي أيضًا على علامات تشير إلى أحداث أو مستخدمين آخرين ، ولها قيمة معرّف تمثل تجزئة لكل شيء باستثناء توقيع المنشئ (على غرار TXID لمعاملة Bitcoin). يسمح لك هذا بضمان أن الرسالة قد تم إنشاؤها بالفعل من قبل مالك المفتاح العام فيها من خلال التحقق من التوقيع (ومن يمتلك هذا المفتاح ، إذا لم يتم اختراقه) ، وأن الرسالة لم يتم تغييرها بعد وقعوا عليه. تمامًا كما لا يمكنك تغيير معاملة Bitcoin بعد توقيعها دون إبطالها ، لا يمكنك تغيير حدث Nostr بعد توقيعه من قبل المنشئ دون احتيال واضح.
تم توسيع نظام نوع الحدث بشكل كبير من NIP الأصلي
تحتوي الرسائل المباشرة المشفرة على نوع حدث ينشئ مفتاحًا مشتركًا من خلال دمج المفتاح الخاص للمرسل مع المفتاح العام للمستلم ، والذي ينتج عنه نفس المفتاح (هذه هي الطريقة التي يعمل بها BIP 47 والمدفوعات الصامتة). هناك أيضًا أنواع من الأحداث القابلة للاستبدال والأحداث المؤقتة. في حالة الأحداث القابلة للاستبدال (من الواضح) ، فهي مصممة بحيث يمكن لمنشئ الحدث الأصلي التوقيع على حدث جديد ليحل محل الحدث القديم. سيحذف خادم الترحيل الذي يتبع المواصفات الأحداث القديمة تلقائيًا من مساحة التخزين ويبدأ في تقديم الإصدارات الأحدث للعملاء عند الاستلام. تم تصميم الأحداث المؤقتة بحيث يتم بثها عند إرسالها إلى مرحل لأي شخص يشترك في منشئها ، ولكن يجب ألا يخزنها خادم الترحيل. هذا يخلق إمكانية أن يرى الرسالة فقط أولئك المتصلين أثناء البث. حتى أن هناك نوع حدث لتمثيل ردود الفعل على أحداث الآخرين (مثل الإعجابات أو الرموز التعبيرية).
عند الحديث عن الحدث الأخير
يمكن أن تحتوي الأحداث أيضًا على علامات. يوجد حاليًا أنواع علامات أحداث (للإشارة إلى حدث Nostr دقيق) ، ومفتاح عام (لوضع علامة أو الإشارة إلى مستخدم آخر) وموضوع (لمحاكاة الوظيفة ، مثل موضوع البريد الإلكتروني). يمكن أن تتضمن كل هذه المؤشرات إلى خوادم ترحيل محددة يمكن من خلالها جلب البيانات بحيث يمكن للمستخدمين التفاعل فعليًا عبر الخوادم ، أي يمكن ربط المستخدم الذي ينشر محتواه إلى خادم ترحيل واحد بمحتوى آخر أنشأه مستخدم يتفاعل ويشير إلى مرحل مختلف تسمح الخوادم لأي مستخدم بجلب سلسلة التفاعل بالكامل بالترتيب الصحيح وبدون قدر كبير من التعقيد في تحديد مكان العثور على البيانات ذات الصلة.
في NIP الأصلي
تم تقديم مواصفات لكيفية تفاعل العميل مع خادم الترحيل من خلال الاشتراك في بنية رسالة / بيانات تتضمن عوامل تصفية للأحداث التي يهتم العميل باستلامها. يمكن لهذه المرشحات تحديد المفتاح العام للمستخدم ، والحدث الدقيق ، ونوع الحدث ، أو حتى الإطار الزمني المحدد الذي يريدونه بناءً على المعايير السابقة. يمكنك حتى إرسال بادئة للمفتاح العام أو معرّف الحدث ، على سبيل المثال “1xjisj…. ” وتلقي أي حدث أو أحداث من مفتاحك العام بدءًا من تلك السلسلة القصيرة (مفيدة لإخفاء المحتوى الخاص بك من خوادم الترحيل التي تريد بالفعل رؤيتها ) ..
بشكل عام
يعد البروتوكول مخططًا عامًا بسيطًا جدًا لتمرير الرسائل بين المستخدمين ، ويغطي أشياء مهمة مثل ضمان تكامل الرسالة واستخدام هويات المفاتيح العامة لإرسال الرسائل ، مع تسهيل أيضًا أن تكون خوادم ترحيل البنية التحتية للواجهة الخلفية مركزية للغاية أو تسمح للمستخدمين بتشغيل خوادم الترحيل الشخصية الخاصة أثناء التفاعل بسلاسة مع بعضها البعض ودون التسبب في حدوث فوضى كبيرة في حالة منع المستخدمين من استخدام خادم ترحيل واحد. يمكنهم الانتقال إلى خادم آخر أو تشغيل خادمهم الخاص ، ولن يفقد نزع النظام الأساسي الخاص بهم من الخادم السابق هويتهم الرقمية أو أتباعهم ، حيث لا يزالون يحتفظون بالسيطرة على مفاتيحهم الخاصة ، ويمكن للمستخدمين المصادقة عندما يعثر عليهم المكان.
يمكن أيضًا تشغيل خوادم الترحيل كيفما تشاء
يمكن أن تعمل مجانًا ، ويمكن أن تتقاضى رسومًا صغيرة لنشر الرسائل أو تنزيلها ، وهناك أيضًا خطة تنفيذية تتطلب إثبات عمل بأسلوب التجزئة لإرسال الرسائل. يمكن أن تكون خادم ترحيل فردي يستضيف منشوراتك ويجعلها متاحة فقط للمستخدمين الآخرين ، أو يمكن أن تكون خادمًا يعمل على نطاق واسع ، مثل Twitter أو Reddit (يمكن للعملاء عرض المعلومات وتنظيمها حسب الرغبة ، مما يسمح بمحاكاة أي وسائل التواصل الاجتماعي) منصة وسائط موجودة اليوم). كل هذه تتفاعل بسلاسة دون قفل المستخدمين. يمكنك منعهم من نشر المحتوى على خادم الترحيل الخاص بك ، ولكن في النهاية لا يمكنك منعهم من عرض المحتوى الذي تستضيفه على خادم الترحيل الخاص بك أو من عثور المستخدمين الآخرين على المحتوى الخاص بهم على خوادم أخرى.
إنه بروتوكول بسيط للغاية به مساحة تصميم مفتوحة كبيرة للأشخاص للبناء عليها
مما يضمن أن المستخدمين يمكنهم دائمًا التفاعل مع بعضهم البعض ، بغض النظر عما إذا كان مشغلو خادم الترحيل الفردي يختارون استضافته أم لا. هذا هو أعظم قوتها وأكبر ضعف في نفس الوقت. بينما يضمن للمطورين حرية الإنشاء بدون قيود صارمة لبروتوكول معقد ، هناك أيضًا العديد من المشكلات المتأصلة التي لا يمكن للبروتوكول نفسه حلها.
في المقالة التالية التي أكتبها
سأستكشف بعض المشكلات التي أراها تحدث والحلول المحتملة ، لكن في الوقت الحالي ، سأقول ذلك فقط من حيث بساطة التصميم والإمكانيات التي يفتحها للناس ، اللغة في البناء ، قام Nostr بعمل جيد ، معتبراً أنه من بنات أفكار شخص واحد ، وحتى الآن لم يساهم سوى عدد قليل من الأشخاص في مواصفات البروتوكول نفسه.
هذا منشور ضيف بواسطة Shinobi
الآراء المعبر عنها خاصة بها تمامًا ولا تعكس بالضرورة آراء BTC Inc أو Bitcoin Magazine.
💡 الموارد والمراجع
“bitcoinmagazine.com” عبر: BITCOINERS تتدفق إلى NOSTR ، ولكن كيف تختلف عن Twitter؟ …