ما الذي يجعل Nostr منصة اجتماعية مختلفة – مجلة Bitcoin
نالت Nostr الكثير من الاهتمام والحيوية منذ إضافتها مؤخرًا إلى قائمة المنصات الاجتماعية البديلة المحظور الترويج لها على Twitter. كما أنه يكتسب زخمًا حيث أصبح من الواضح أن شراء Twitter بواسطة Elon Musk لم يغير بشكل أساسي أي شيء يتعلق بحرية التعبير على المنصة – لا يزال المستخدمون ممنوعون لأسباب غير متسقة وتعسفية ، ويبحث الناس عن بديل لامركزي ليس شيئًا مثل Mastodon ، حيث لا يزال مشغل الخادم لديه القدرة على التحكم في هويتك.
على الرغم من الاهتمام الأخير ، تم إنشاء بروتوكول Nostr وتطبيق خادم الترحيل الأول في نهاية عام 2020 بواسطة المطور fiatjaf. قبل الاندفاع الكبير في الاهتمام ، كان مجرد بروتوكول هادئ ومناسب يحاول ببساطة أن يكون حلاً خفيف الوزن لمشاكل Twitter و Mastodon. في كلا النظامين ، هويتك / اسم المستخدم الخاص بك هو ببساطة شيء يتحكم فيه أي شخص يقوم بتشغيل الخادم. كون Mastodon نظامًا متحدًا به عدة خوادم مختلفة تتحدث جميعها مع بعضها البعض لا يغير هذا الواقع بشكل أساسي. أيا كان الخادم الذي تستخدمه لاستضافة حساب فهو يتحكم بشكل كامل فيما إذا كان يمكنك استخدامه أم لا. حتى تشغيل الخادم الخاص بك ، يمكن لمشغلي الخوادم الآخرين وضع قائمة سوداء أو بيضاء للخوادم التي سيسمح لها بالتحدث إلى خوادمهم. وقد أدى هذا إلى الكثير من التقسيم في “Fediverse” لخوادم Mastodon المختلفة وجعل فكرة تشغيلك فقط بلا معنى. لا يزال بإمكانك في النهاية أن تخضع للرقابة من قبل مشغلي الخوادم الآخرين ، مما يمنع مستخدميهم من رؤية المحتوى الخاص بك في خلاصتهم.
الفارق الأساسي بين Nostr وشيء مثل Mastodon هو أنه بدلاً من استخدام اسم مستخدم مملوك من قبل مشغل الخادم ، يستخدم كل مستخدم زوج مفاتيح عام / خاص للتعامل مع هذه الوظيفة بدلاً من ذلك. هذا شيء لا يمكن لمشغل الخادم الاستيلاء عليه منك أو منعك منه. هذا هو أحد اللبنات الأساسية التي تم بناء بروتوكول Nostr العام على رأسها.
التالي هو “الأحداث”. هذا هو نوع الكائن / البيانات الأساسي الذي يستخدمه العملاء وخوادم الترحيل التي يتصل بها العملاء لإرسال الرسائل واستردادها. الفكرة العامة للبروتوكول هي أن العملاء يرسلون الأحداث إلى خوادم الترحيل ، والتي بدورها تقوم بتخزينها وفهرستها ، ويمكن للعملاء الآخرين التواصل مع خوادم الترحيل لطلب الأحداث التي تلقوها وتخزينها. في NIP 01 الأصلي ، تم تحديد ثلاثة أنواع مختلفة من الأحداث:
- 0: إرسال البيانات الوصفية حول المستخدم ، مثل اسم المستخدم والصورة والسيرة الذاتية وما إلى ذلك.
- 1: يرسل الرسائل النصية والمحتوى الأساسي
- 2: يوصي بخوادم الترحيل للأشخاص الذين يتابعون منشئ الحدث للاتصال بهم
يتم تنظيم جميع الأحداث بطريقة محددة على وجه التحديد. وهي تشمل المفتاح العام للمنشئ والطابع الزمني لتاريخ إنشائها ونوعها (أو نوعها في المواصفات) وحمولة المحتوى والتوقيع من منشئ الحدث. يمكن أن تحتوي أيضًا على علامات تشير إلى أحداث أو مستخدمين آخرين ، ولها قيمة معرّف وهي عبارة عن تجزئة لكل شيء باستثناء توقيع المنشئ (على غرار TXID لمعاملات Bitcoin). يتيح لك هذا ضمان إنشاء رسالة بالفعل بواسطة مالك المفتاح العام بداخلها من خلال التحقق من التوقيع (والشخص الذي يمتلك هذا المفتاح إذا لم يتم اختراقه) ، وضمان عدم تغيير الرسالة بعد وقعوا عليه. تمامًا كما لا يمكنك تغيير معاملة Bitcoin بعد توقيعها دون إبطالها ، لا يمكنك تغيير حدث Nostr بعد أن قام المنشئ بتوقيعه دون أن يكون احتيالًا واضحًا.
تم توسيع نظام نوع الحدث بشكل كبير من ذلك NIP الأصلي. يوجد نوع حدث للرسائل المباشرة المشفرة ، إنشاء مفتاح مشترك من خلال الجمع بين المفتاح الخاص للمرسل والمفتاح العام للمستقبل ، مما ينتج عنه نفس المفتاح الذي ستحصل عليه من خلال دمج المفتاح العام للمرسل مع المفتاح الخاص للمستلم (هذه هي الطريقة BIP 47 والمدفوعات الصامتة تعمل). هناك أيضًا أنواع للأحداث القابلة للاستبدال والأحداث المؤقتة. في حالة حدث قابل للاستبدال (من الواضح) ، فهي مصممة بحيث يمكن لمنشئ الحدث الأصلي التوقيع على حدث جديد ليحل محل الحدث القديم. ستقوم خوادم الترحيل التي تتبع المواصفات بإسقاط الحدث الأقدم تلقائيًا من مساحة التخزين الخاصة بها والبدء في تقديم الإصدارات الأحدث للعملاء عند الاستلام. تم تصميم الأحداث المؤقتة بحيث يتم بثها إلى أي شخص يشترك في منشئها عند إرسالها إلى جهاز الترحيل ، ولكن ليس من المفترض أن تقوم خوادم الترحيل بتخزينها. هذا يخلق إمكانية رؤية الرسائل فقط من قبل الأشخاص عندما يكونون متصلين أثناء بثها. يوجد حتى نوع حدث للإشارة إلى رد فعل (مثل إبداءات الإعجاب أو الرموز التعبيرية) لأحداث أشخاص آخرين.
عند الحديث عن ذلك الحدث الأخير ، يمكن أن تحتوي الأحداث أيضًا على علامات. توجد حاليًا أنواع علامات للأحداث (للإشارة إلى حدث Nostr دقيق) ، ومفاتيح عامة (للإشارة إلى مستخدمين آخرين أو الإشارة إليهم) وموضوعات (لمحاكاة الوظائف ، مثل موضوعات البريد الإلكتروني). يمكن أن تتضمن كل هذه المؤشرات إلى خوادم ترحيل محددة يمكن من خلالها جلب البيانات بحيث يمكن للمستخدمين التفاعل فعليًا عبر الخوادم ، على سبيل المثال ، يمكن للمستخدم الذي ينشر محتواه على خادم ترحيل واحد التفاعل مع المحتوى الذي تم إنشاؤه بواسطة مستخدم آخر والإشارة إليه. خادم ترحيل مختلف بطريقة تسمح لأي مستخدم بجلب سلسلة التفاعلات بالكامل بالترتيب الصحيح وبدون تعقيد هائل في معرفة مكان العثور على البيانات ذات الصلة.
داخل NIP الأصلي ، يتم تقديم مواصفات لكيفية تفاعل العملاء مع خوادم الترحيل من خلال بنية رسالة / بيانات اشتراك تتضمن عوامل تصفية للأحداث التي يهتم العميل بتلقيها. يمكن لهذه المرشحات تحديد المفاتيح العامة للمستخدمين ، والأحداث الدقيقة ، وأنواع الأحداث وحتى الأطر الزمنية المحددة التي يرغبون فيها بناءً على المعايير السابقة. يمكنك حتى إرسال بادئات المفاتيح العامة أو معرّفات الأحداث ، مثل “1xjisj….” وتلقي أي حدث أو أحداث من مفتاح عام يبدأ بتلك السلسلة القصيرة (يمكن أن يكون هذا مفيدًا للإخفاء من خادم الترحيل الذي تريد عرضه بالفعل).
بشكل عام ، يعد البروتوكول نظامًا معممًا للغاية لتمرير الرسائل بين المستخدمين الذي يغطي الأشياء المهمة ، مثل ضمان سلامة الرسائل ومن أرسلها باستخدام هويات المفاتيح العامة ، مع تسهيل البنية التحتية على الواجهة الخلفية أيضًا خوادم الترحيل التي يمكن أن تكون مركزية للغاية أو تسمح للمستخدم بتشغيل خادم الترحيل الشخصي الخاص به ، كل ذلك أثناء التفاعل بسلاسة مع بعضها البعض وعدم التسبب في فوضى هائلة في حالة حظر المستخدم من خادم ترحيل واحد. يمكنهم الانتقال إلى واحد آخر أو تشغيل نظامهم الخاص ولا يفقد إلغاء النظام الأساسي الخاص بهم من الخادم السابق هويتهم الرقمية أو أتباعهم لأنهم ما زالوا يحتفظون بالسيطرة على مفتاحهم الخاص ويمكن للمستخدمين المصادقة على ذلك عند العثور عليهم في مكان آخر.
يمكن أن تعمل خوادم الترحيل كما تشاء أيضًا. يمكن أن تعمل مجانًا ، ويمكنها تحصيل مدفوعات صغيرة لنشر الرسائل أو تنزيلها ، وهناك أيضًا NIP لطلب إثبات عمل بأسلوب التجزئة لإرسال رسالة. يمكن أن تكون خادم ترحيل فردي لاستضافة منشوراتك وتقديمها فقط للمستخدمين الآخرين ، أو يمكن أن تكون خادمًا يعمل على نطاق واسع مثل Twitter أو Reddit (يمكن للعملاء عرض المعلومات وتنظيمها كما يريدون ، مما يسمح بمحاكاة أي مواقع اجتماعية بشكل أساسي منصة إعلامية موجودة اليوم). كل هذا يمكن أن يتفاعل بسلاسة ودون أن يكون قادرًا على حجب المستخدم. يمكنك منعهم من نشر المحتوى على خادم الترحيل الخاص بك ، ولكن في النهاية لا يمكنك منعهم من عرض المحتوى الذي تستضيفه على خادم الترحيل أو منع المستخدمين الآخرين من العثور على المحتوى الخاص بهم على خوادم أخرى.
إنه بروتوكول مبسط للغاية مع مساحة تصميم كبيرة ومفتوحة للأشخاص ليبنيها ، مما يضمن للمستخدمين إمكانية التفاعل دائمًا مع بعضهم البعض بغض النظر عما يختاره مشغلو خادم الترحيل الفردي لاستضافته أو عدم استضافته. هذا هو أعظم قوتها وأكبر ضعف في نفس الوقت. بينما يضمن للمطورين حرية الإنشاء بدون قيود صارمة بواسطة بروتوكول معقد ، هناك أيضًا العديد من المشكلات التي ستواجهها بطبيعتها ولا يتم التعامل معها بواسطة البروتوكول نفسه.
في الجزء التالي الذي أكتبه ، سوف أتطرق إلى بعض المشكلات التي أراها تحدث وحلولًا محتملة ، لكن في الوقت الحالي ، سأقول ذلك فقط من حيث بساطة التصميم والإمكانيات التي يفتحها للناس build ، قام Nostr بعمل جيد للغاية ، معتبراً أنه من بنات أفكار شخص واحد وقد ساهم عدد قليل فقط من الأشخاص في مواصفات البروتوكول نفسه حتى الآن.
هذا منشور ضيف بواسطة Shinobi. الآراء المعبر عنها خاصة بها تمامًا ولا تعكس بالضرورة آراء BTC Inc أو Bitcoin Magazine.
