حالة التنمية البيئية Nostr والمشاكل

في الأسبوع الماضي، اقترح عضو مجتمع CKB Retric بروتوكول Nostr Binding.

يتم استخدام بروتوكول ربط Nostr لإنشاء تعيين واحد لواحد بين Nostr Event وCKB Cell. يمكن للمستخدمين العاديينإنشاء وتوزيع الأصول الأصلية في شبكة Nostr الاجتماعية استنادًا إلى هذا البروتوكول، من خلال RGB++، ويمكن أيضًا التحكم في هذه الأصول الموجودة على Nostr بواسطة عناوين Bitcoin. يمكن لمطوري العملاء إنشاء منتجات عليه، على عكس ETH dApp، الذي ينقسم إلى نظامين (أحدهما خادم خارج السلسلة والآخر عبارة عن عقد ذكي متصل بالسلسلة)، يجلب بروتوكول ربط Nostr تطورًا جديدًا إلى dApp. النموذج،الذي يستخدم نظامًا متسقًا بمستويات بيانات مختلفة لإنشاء التطبيقات اللامركزية. يُذكر أنه يمكن دمج بروتوكول ربط Nostr بسلاسة في شبكة CKB Lightning Network في المستقبل لحل مشكلات الدفع الأصلية في الشبكات الاجتماعية.

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

في 9 مارس من هذا العام، في مؤتمر Bitcoin الأول في سنغافورة الذي شاركت في تنظيمه مؤسسة Nervos وABCDE، قدم ريتريك "الوضع الحالي للتنمية البيئية والمشاكل" مشاركة الموضوع؟

فيما يلي المحتوى الذي تم تجميعه بناءً على مشاركة Retric، والذي يمكن أن يساعد الجميع على فهم بروتوكول Nostr بشكل أفضل:

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

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

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

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

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

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

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

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

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

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

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

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

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

إذن ما هو تطور Nostr؟ إليك بعض البيانات التي وجدتها في شهر مارس. نظرًا لأن هذه شبكة موزعة، فليس من السهل في الواقع حساب بياناتها. هذه هي البيانات التي حصلت عليها من موقع nostr.band قد يصل إجمالي عدد مستخدمي Nostr إلى حوالي 370.000، وقد يكون عدد المستخدمين النشطين يوميًا. 12000 فقط. قد يكون إجمالي عدد المرحلات والمرحلات التي ظهرت وعدد الأشخاص الذين مروا عبر هذه العقدة أكثر من 2000. ولكن عدد هذه العقد الموجودة دائمًا على الإنترنت ربما يكون أقل من 200. من المحتمل أن يكون هذا هو الحال، لذلك لا يزال هناك عدد قليل نسبيًا من المستخدمين.

للمقارنة، انظر إليها باستخدام بروتوكول BlueSky. كان ينبغي على Bluesky أن يقول في نهاية العام الماضي أنهم وصلوا إلى 2 مليون مستخدم. البيانات الموجودة على اليمين هي المكان الذي قام فيه شخص ما بإحصاء المستخدمين الذين غادروا تويتر وأين ذهبوا. يمكنك أيضًا أن ترى أن Mastodon يحتل المرتبة الأولى، وMastodon هو علامة تجارية قديمة نسبيًا بعد ذلك، ذهب بعض الأشخاص إلى OST News، وذهب بعض الأشخاص إلى BlueSky ينتمي في الواقع إلى المستوى الخامس، وهو جزء صغير نسبيًا.

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

دعني ألخص ذلك، نشعر الآن أنمعظم المستخدمين هم في الواقع مطورون أو صانعون. إنهم مهتمون بالبروتوكول نفسه ويريدون تطوير الأشياء عليه، أو أنا شخص يريد القيام بشيء ما وسأعمل على البروتوكول الخاص بك، وقد يكون هناك عدد أقل من المستخدمين العاديين.

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

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

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

وينقسم إلى وضعين أكثر تفصيلاً، أحدهما يسمى Inbox والآخر يسمى Outbox. على سبيل المثال، مثل Inbox، فهو يسمح للمستخدمين بتحديد Relays التي سأقرأ منها بعض الأخبار عني. إذا كنت تريد @me على Twitter أو القيام بأشياء أخرى، فيمكنك إرسال هذه الرسالة إلى Inbox Relay هذا. والآخر هو Outbox Relay، والذي يحدد أنني سأرسل بعض رسائلي إلى العديد من Relays A وB وC وD. وربما يعني ذلك أنني سأرسل بعض رسائل Relay التي غالبًا ما أنشرها على Relay أولاً.

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

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

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

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

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

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

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

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

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

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