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

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

مع ظهور ونمو منصات جديدة، غالبًا ما يأتي اختيار الشبكات الاجتماعية البديلة مع اعتبارات سياسية. مواقع مثل Getr، وParler، وGab، وTruth Social كلها تلبي احتياجات اليمين من خلال الترويج لنفسها كبدائل حرية التعبير لتويتر.

ما سنناقشه اليوم هو Nostr-دامس، وهو بروتوكول جديد لوسائل التواصل الاجتماعي حظي بالكثير من الاهتمام مؤخرًا وهو مبتكر إلى حد ما. وتشمل هذه المبادئ التقنية لشركة Nostr، وقضايا الإدارة الرئيسية التي يتعين حلها، وكيفية تحفيز المرحل لمواصلة العمل.

نظرة عامة على نستر

بدأت في 2020، نوستر هو بروتوكول لا مركزي يسمح للمستخدمين بامتلاك هوياتهم والتحقق من المنشورات باستخدام التوقيعات الرقمية باستخدام تشفير المفتاح العام والخاص. يتم بعد ذلك نشر هذه المنشورات إلى شبكة من الخوادم المترابطة. لا يستخدم البروتوكول blockchain، والذي وجد في التجارب المبكرة أنه بطيء جدًا بالنسبة للشبكات الاجتماعية. ولكن هناك أوجه تشابه هيكلية، وقد وجدت شركة Nostr مكانًا مبكرًا في حشد العملات المشفرة بروحها التحررية ومفتوحة المصدر.

مستودون ضد نوستر

تم إنشاء بروتوكول Nostr وأول خادم ترحيل من قبل المطور fiatjaf في أواخر عام 2020. قبل أن يحظى باهتمام واسع النطاق، كان Nostr بروتوكولًا متخصصًا هادئًا يهدف إلى أن يكون حلاً خفيف الوزن لمشاكل Twitter وMastodon.

Mastodon، وهي شبكة مفتوحة المصدر تأسست عام 2016، تسمح لأي شخص بإعداد خادم. غالبًا ما يوصف التصميم بأنه "موحد" وقد يقع أو لا يقع ضمن الخط غير الواضح لـ "Web3"، اعتمادًا على كيفية تعريف ذلك. يسمح Mastodon للمستخدمين بالانضمام إلى المجتمعات المنسقة باستخدام قواعد مخصصة للإشراف على المحتوى. وفي الوقت الحاضر، وصل عدد المستخدمين المسجلين إلى 200+، وأصبح ملاذاً آمناً لليبراليين والصحفيين والعلماء.

In تويتر و المستودون حيوان بائد شبيه بالفيل يتم التحكم في الأنظمة والهويات/أسماء المستخدمين من قبل من يقوم بتشغيل الخادم.

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

الحدث/الفعالية: هذا هو نوع الكائن/البيانات الأساسي الذي يستخدمه العملاء وخوادم الترحيل التي يتصلون بها لإرسال الرسائل واستردادها. الفكرة العامة للبروتوكول هي أن العملاء يرسلون الأحداث إلى خادم الترحيل، الذي يقوم بعد ذلك بتخزينها وفهرستها، ويمكن للعملاء الآخرين التواصل مع خادم الترحيل لطلب الأحداث التي قاموا باستلامها وتخزينها. في الأصل نيب 01، تم تحديد ثلاثة أنواع مختلفة من الأحداث:

• إرسال البيانات الوصفية عن المستخدم، مثل اسم المستخدم والصورة والسيرة الذاتية وما إلى ذلك.
• إرسال الرسائل القصيرة والمحتوى الأساسي
• أوصي بخادم الترحيل للأشخاص الذين يتابعون منشئ الحدث للاتصال

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

يتيح ذلك للمستخدمين التحقق من التوقيع (ومن يملك المفتاح، إذا لم يتم اختراقه) لضمان أن الرسالة قد تم إنشاؤها بالفعل بواسطة مالك المفتاح العام الموجود فيها وأن الرسالة لم يتم تغييرها منذ التوقيع هو - هي.

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

تم توسيع نظام نوع الحدث بشكل كبير عن النظام الأصلي خطة التنفيذ الوطنية. يوجد نوع حدث للرسائل المشفرة المباشرة التي تبني سرًا مشتركًا من خلال دمج المفتاح الخاص للمرسل مع المفتاح العام للمستلم، وتكون نتيجته نفس ما تحصل عليه من خلال دمج المفتاح العام للمرسل مع المفتاح الخاص للمستلم المفاتيح هي نفسها (هذه هي الطريقة التي تعمل بها BIP 47 والمدفوعات الصامتة).

هناك أيضًا أنواع أحداث قابلة للاستبدال وأحداث سريعة الزوال. في حالة الأحداث القابلة للاستبدال (من الواضح)، فهي مصممة بحيث يتمكن المنشئ الأصلي للحدث من التوقيع على حدث جديد ليحل محل الحدث القديم. ستقوم خوادم الترحيل التي تتبع هذه المواصفات بحذف الأحداث القديمة تلقائيًا من مخازنها والبدء في تقديم الإصدارات الأحدث للعملاء عند الاستلام.

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

عند الحديث عن السؤال الأخير، يمكن أن تحتوي الأحداث أيضًا على علامات. حاليًا، هناك أنواع من العلامات لـ الحدث/الفعالية (في اشارة الى حدث Nostr بالضبط)، المفتاح العمومي (للإشارة إلى مستخدم آخر أو الإشارة إليه)، و الموضوع (لتقليد الوظيفة، مثل موضوع البريد الإلكتروني).

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

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

يمكن للمستخدمين أيضًا إرسال المفاتيح العامة أو بادئات معرفات الأحداث، مثل "1xjisj..." وتلقي أي حدث أو أكثر من مفتاح عام بدءًا من تلك السلسلة القصيرة (وهذا مفيد لإخفاء ما تريد رؤيته بالفعل من خوادم الترحيل) .

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

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

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

يمكن أن تكون بمثابة خادم ترحيل واحد يستضيف المنشورات ويجعلها متاحة فقط للمستخدمين الآخرين أو خادم يعمل على نطاق واسع، مثل Twitter أو Reddit (يمكن للعملاء عرض المعلومات وتنظيمها حسب الرغبة، مما يسمح بمحاكاة أي وسائط اجتماعية). كل هذه العناصر تعمل بسلاسة دون حظر المستخدمين.

قضايا الإدارة الرئيسية التي يتعين معالجتها بواسطة Nostr

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

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

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

يتطلب Nostr نظام تشفير فعليًا يربط دوران مفتاح بآخر. اقترح المطور fiatjaf حلاً أساسيًا قد يحل هذه المشكلة. الفكرة الأساسية هي أخذ قائمة طويلة من العناوين المستمدة من بذرة رئيسية واحدة وإنشاء مجموعة من المفاتيح "المعدلة"، على غرار كيفية التزام أشجار Taproot بمفاتيح Bitcoin.

يأخذ Taproot جذر Merkle لشجرة Taproot و"يضيفه" إلى المفتاح العام لإنشاء مفتاح عام جديد. يمكن تكرار ذلك عن طريق إضافة جذر Merkle إلى المفتاح الخاص للحصول على مفتاح خاص يطابق المفتاح العام الجديد. تتمثل فكرة فياتجاف في ربط الالتزامات بشكل عكسي من النهاية إلى البداية بحيث يحتوي كل مفتاح معدَّل فعليًا على دليل على أن المفتاح المعدل التالي قد تم استخدامه لإنشائه.

لذا، تخيل أنك تبدأ بالمفتاح Z، وهو الأخير في السلسلة. يمكنك تعديله بشيء ما، ثم الرجوع وإنشاء نسخة معدلة من المفتاح Y باستخدام المفتاح المعدل Z (Z' + Y = Y'). من هنا، يمكنك أخذ Y' واستخدامه لضبط X (Y' + X = X'). يمكنك القيام بذلك طوال الطريق للعودة إلى المفتاح A، والحصول على A، واستخدام هذا المفتاح من هناك. عندما يتم كسره، يمكن للمستخدم بث حدث يحتوي على المفتاح غير المعدل A والمفتاح المعدل B'.

سيحتوي هذا على جميع البيانات اللازمة لإظهار أن B' تم استخدامه لإنشاء A'، ويمكن للمستخدم التوقف فورًا عن متابعة A' ومتابعة B' بدلاً من ذلك. سيعرفون بشكل لا لبس فيه أن B' هو المفتاح التالي لذلك المستخدم ويتبعون هذا المفتاح بدلاً من ذلك.

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

يعد أي من المسارين ممكنًا ولكنه يتطلب في النهاية الحفاظ على مفتاح الجذر أو مادة المفاتيح آمنة وكشف مفاتيح التشغيل السريع الفردية (مفاتيح التشغيل السريعة) لعملاء Nostr فقط.

ومع ذلك، فإن هذا النظام لا يحمي المستخدمين ولا يوفر آليات لاستعادة الهوية في حالة فقدان مادة مفتاح الجذر أو تعرضها للخطر.

لإجراء بعض المناقشات حول الحلول المحتملة هنا، هناك طريقة أخرى للتفكير في الأمر وهي ضبط مفتاح على مفتاح بارد رئيسي والذي يجب استخدامه أيضًا لتوقيع الأحداث من مفتاح إلى دوران آخر. لديك المفتاح A'، والذي يتم اشتقاقه عن طريق إضافة A وM (المفتاح الرئيسي)؛ سيكون حدث التناوب هو A وM وB' (يتم إنشاؤه عن طريق إضافة B وM) وتوقيع M. يمكن أن يكون M مفتاح عتبة متعدد التوقيع - ثلثين، ثلاثة أخماس، وما إلى ذلك.

قد يضيف هذا التكرار مقابل الخسارة ويوفر آلية آمنة لتدوير المفاتيح. ويفتح هذا أيضًا الباب لاستخدام الخدمات للمساعدة في عملية الاسترداد أو لنشر بعض هذه المفاتيح على الأصدقاء الموثوقين. إنه يوفر نفس المرونة التي توفرها multisig في Bitcoin نفسها.

PIN26 هو أيضًا اقتراح قد يكون مفيدًا جدًا في التعامل مع هذه المشكلة. يحدد هذا امتداد بروتوكول للأحداث التي تسمح بالتوقيع من مفتاح واحد لتخويل مفتاح آخر لنشر الأحداث نيابة عنه. سيتم بعد ذلك تضمين "الرمز المميز" أو إثبات التوقيع المفوض في جميع الأحداث التي ينشرها المفتاح العام الثاني نيابة عن الأول. ويمكن أن يكون محدودًا بفترة زمنية، لذا تنتهي صلاحية رموز التفويض تلقائيًا ويجب تجديدها.

تعد مسألة إدارة المفاتيح والأمن مشكلة كبيرة جدًا مع مساحة تصميم كبيرة جدًا مليئة بالمقايضات ونقاط الضعف. ومع ذلك، إذا لم تتمكن Nostr من حماية والحفاظ على سلامة هذه الهويات للمستخدمين، فلن يتم اعتماد بروتوكول يعتمد بالكامل على أزواج المفاتيح العامة/الخاصة المستخدمة كهويات على نطاق واسع.

التوسع الذي يواجه Nostr

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

أعلن هنا

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

المدفوعات المصغرة

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

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

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

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

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

والسؤال الأخير هو المفتاح: التوقعات الاقتصادية. لقد اعتاد الناس على دفع رسوم عندما يتم الإعلان عن وظيفة ما في مكان ما أو دفع رسوم لمشغل السوق عندما يطلبون شيئًا ما عبر الإنترنت ولكنهم لا يقدمون أشياء يعتقدون أنها يجب أن تكون مجانية - Google وTwitter. يمكن أن يوفر هذا وسيلة للمرسلين لإنشاء ركيزة دخل قوية من مستخدميهم دون خلق الكثير من الاحتكاك أو الإخلال بتوقعات المستخدم المحتمل العادي.

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

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

وفي الختام

مشاريع Web3 الاجتماعية، بالإضافة إلى ما سبق ذكره نوستر و المستودون حيوان بائد شبيه بالفيل، وتشمل أيضًا مشاريع مثل فاركستر و العدساتوالتي لن تحل محل منصات التواصل الاجتماعي الحالية بسرعة. وبحسب الإحصائيات فإن تويتر يضم مئات الملايين من المستخدمين النشطين، فيسبوك لديها مليارات، ولكن المستودون حيوان بائد شبيه بالفيل لديه فقط 2.5 مليون مستخدمو نوستر لديه فقط حوالي 220,000 هوية مستخدم فريدة. تواجه العديد من مشاريع Web3 الاجتماعية عقبات تتعلق بسهولة الاستخدام والتي تؤدي إلى إبطاء التبني الجماعي.

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

تنصل: يتم توفير المعلومات الواردة في هذا الموقع كتعليق عام على السوق ولا تشكل نصيحة استثمارية. نحن نشجعك على إجراء البحث الخاص بك قبل الاستثمار.

انضم إلينا لتتبع الأخبار: https://linktr.ee/coincu

هارولد

كوينكو الأخبار