نعم، يمكن لـ Discourse القيام بشيء مشابه باستخدام أداة تضمين التعليقات الخاصة به. من بين أمور أخرى، قد يساعد ذلك في تقليل الإحراج الذي يشعر به بعض الأشخاص عند بدء منتدى به عدد قليل فقط من المستخدمين النشطين: AI sockpuppet accounts to jumpstart my community?. يمكن لمواقع Discourse الجديدة استخدام منشورات المدونة للترويج لمنتدياتها وزرعها. هذا ممكن الآن إلى حد ما، ولكن السماح للمستخدمين بالتعليق مباشرة من أداة التضمين سيجعل العملية أكثر سلاسة.
3 إعجابات
نموذج تعليق بسيط متصل بـ Discourse على جانب Wordpress، حتى لا يضطر الزوار إلى الذهاب أولاً إلى Discourse وإنشاء حساب هناك، قبل نشر تعليق، سيساعد في تقليل الاحتكاك وبناء المشاركة، على الأقل بالنسبة لـ الناشرين مثلي.
بالنسبة لحالتي، سيكون من المثالي أن يتمكن المعلق من ترك تعليقه ببساطة باستخدام الاسم وعنوان البريد الإلكتروني. يمكن بعد ذلك استخدام هذا لإنشاء مستخدم مرحلي في Discourse ودعوته للانضمام بالكامل لمواصلة المحادثة، دون منعه من ترك تعليقه.
نجد أن الاحتكاك الإضافي لإنشاء حساب لترك تعليق على مقال منشور يجعل من الصعب بناء المشاركة وفي النهاية تنمية المجتمع في منتدانا. على سبيل المثال، عند السؤال عن قسم التعليقات لدينا (باستخدام التكامل الحالي بين Discourse و Wordpress)، قدم لنا أحد المؤلفين الملاحظات التالية:
بخصوص منطقة المحادثة: الآن بعد أن ذكرتها… أتذكر رؤيتها. وفي ذلك الوقت، اعتقدت أنني سأنسى الأمر في الوقت الحالي لأنه بدا مستهلكًا للوقت للتسجيل. هذا دليل قوي على شعور معظم الناس بالاضطرار إلى المرور بهذه العملية. أنا عادةً مهووس إلى حد ما برؤية التعليقات على كتاباتي. أتذكر أنني ضحكت على نفسي وقلت: “أعتقد أنني لست مهووسًا بما يكفي للتعامل مع هذا الآن”. من الناحية المثالية، ستترك التعليقات مفتوحة للجميع دون عملية تسجيل. ولكن أي مستوى من التبسيط/السهولة سيحسن المشاركة هناك. التعليقات مثل هذه عادة ما تكون حركة اندفاعية. إذا تم إعاقة الأشخاص بأي شكل من الأشكال، فسوف يميلون إلى المضي قدمًا ولن يأخذوا الوقت الكافي.
3 إعجابات
كنت أفكر في هذا في اليوم الآخر. من الغريب أنني افتقدت تعليقات ووردبريس على منشورات مدونتي لأنها بدت سريعة جدًا للأشخاص لبدء الاستخدام، وحاجز دخول منخفض جدًا.
على الرغم من وجود عملية تسجيل بسيطة جدًا، إلا أنه في الوقت الحالي إذا أراد شخص ما التعليق على المنشور، فيجب عليه زيارة صفحة جديدة. أعتقد أن عبور هذا العتبة قد يبدو مرهقًا للغاية. يشبه الأمر تقريبًا أنني أريد التعليق على أ، ولكن يجب علي زيارة ب للتعليق على أ ثم العودة إلى أ لرؤية التعليق. سيكون من الطبيعي أكثر التعليق على أ مباشرة تحت أ.
أحب فكرة تنظيم المستخدمين. يمكنني التفكير في اختراق هذا الأمر عن طريق جعل نموذج تعليق ووردبريس يرسل بريدًا إلكترونيًا إلى منتدى Discourse ثم تنظيم مستخدم بهذه الطريقة، على الرغم من أنني أتخيل أنه قد يصبح أكثر تعقيدًا للتكامل بالكامل بهذه الطريقة.
3 إعجابات
أعتقد أن هذا كان ممكناً في السابق، ولكني متأكد تماماً من أن Discourse الآن يقارن “رأس البريد الإلكتروني من” بمسار الإرجاع الخاص به. إذا لم يتطابقا، يتم رفض البريد الإلكتروني. (إذا لم يكن Discourse يتحقق من مسار الإرجاع، فيمكن إساءة استخدام نظام التعليقات بسهولة - يمكن إدخال أي عنوان بريد إلكتروني في النموذج.)
هناك عدة طرق يمكن من خلالها معالجة مشكلة Discourse كنظام تعليقات. أعتقد أن أفضل نهج هو أن يقوم Discourse بتحسين إطار التعليقات المضمن الخاص به حتى يتمكن المستخدمون من التفاعل معه كمستخدمي Discourse مصادق عليهم. إذا لم يكن ذلك ممكناً، يمكن تطوير تطبيق ويب للتعليقات المضمنة في Discourse. سيكون هذا مشروعاً مثيراً للاهتمام، ولكني أرغب في التأكد من أن Discourse لن يوفر وظائف مماثلة عبر إطار التعليقات المضمن الخاص به قبل المضي قدماً فيه.
هناك أيضاً بعض الحلول الممكنة الخاصة بـ WordPress. أبسطها هو تمكين تعليقات WordPress بالإضافة إلى إضافة WP Discourse. الخطر هو أن هذا سيقلل من النشاط في منتدى Discourse. أعتقد أنه ستكون هناك طرق للمساعدة في ذلك في واجهة مستخدم WordPress - على سبيل المثال، الربط بالمحادثات ذات الصلة التي كانت تجري على Discourse.
سيكون من الممكن أيضاً تطوير شيء خاص بمواقع WordPress التي تعمل كموفر SSO لـ Discourse. كتبت عن ذلك في مشاركات سابقة في هذا الموضوع. للقيام بعمل جيد قد يتطلب ذلك تغييرات كبيرة في إضافة WP Discourse. ما لم (أنا أفكر بصوت عالٍ هنا):
ما أحاول الإشارة إليه باللقطة الشاشة أعلاه هو أنه بالنسبة لحالة موقع WordPress الذي هو موفر SSO لـ Discourse، يمكن عرض التعليقات باستخدام إطار التعليقات المضمن في Discourse. يمكن إنشاء التعليقات من خلال نموذج ينشر إلى واجهة برمجة تطبيقات Discourse. قد يتطلب هذا بعض التغييرات في إطار التعليقات المضمن في Discourse لضمان تحديثه عند إضافة تعليق جديد، ولكنه لن يتطلب من المستخدمين التفاعل معه كمستخدمي Discourse مصادق عليهم.
4 إعجابات
إذن، إذا فهمت بشكل صحيح، فإن الفكرة ستكون أن المسجل يسجل على جانب ووردبريس، ثم يترك تعليقًا عبر إطار Discourse المضمن، والذي سينشر في الموضوع على Discourse، ثم يقوم بتحديث العرض مرة أخرى على ووردبريس، بحيث يظهر على الفور.
سألت عملية التسجيل في ووردبريس عن صحة البريد الإلكتروني، على ما أعتقد. ولكن هذا سيتطلب أيضًا التبديل إلى ووردبريس كموفر Discourse SSO - وهو أمر ممكن، ولكنه مؤسف بطريقة ما، لأنه ينقل الاحتكاك إلى الجانب الآخر للأشخاص الذين قد يرغبون فقط في التسجيل في المنتدى.
أميل إلى الاتفاق مع ما قلته هنا:
إذا كان من الممكن حتى التسجيل مباشرة في الإطار، أو على الأقل أن يتم تجهيزه، بحيث يمكن للمرء المتابعة بالتعليق (والذي قد يتم نشره فقط بمجرد التحقق من صحة البريد الإلكتروني)، فسيكون ذلك حلاً يوازن بين سهولة الاستخدام والأمان.
إعجابَين (2)
نعم، لقد فهمت الأمر. إذا كان ووردبريس هو مزود SSO، فإن مشكلة السماح للمستخدمين بالتعليق على مواضيع Discourse ليست صعبة الحل. الجزء الصعب، فيما يتعلق بالعمل مع الحالة الحالية لمكون WP Discourse الإضافي، هو معرفة كيفية عرض التعليقات على ووردبريس - حاليًا، قسم تعليقات WP Discourse لا يعكس ردود موضوع Discourse. بدلاً من ذلك، يتم عرض مجموعة مختارة من أفضل التعليقات.
سيكون من الممكن تحديث مكون WP Discourse الإضافي للتعامل مع حالة الاستخدام هذه، ولكن للقيام بذلك بشكل صحيح سيتطلب إعادة كتابة كاملة للطريقة التي يتعامل بها مع تعليقات Discourse. ليس قراري، ولكني أعتقد أن بذل الجهد في تحسين إطار التعليقات الخاص بـ Discourse سيكون استخدامًا أفضل للوقت.
5 إعجابات
أردت فقط أن أضيف صوتي للمطالبة بهذه الميزة.
سيكون من الجيد جدًا للمستخدمين على WP التسجيل/تسجيل الدخول والتعليق مباشرة تحت منشور على WP دون الحاجة إلى الانتقال إلى المنتدى، بحيث يشعر كل شيء بنظام تعليقات. سيظهر تعليقهم تحت المنشور وفي سلسلة المناقشة التي تم إنشاؤها. ولديهم دائمًا خيار النشر إما في discourse أو wordpress أو كليهما - بسلاسة. ليس لدي أي فكرة عن كيفية تحقيق ذلك، ولكن هذه ستكون طريقة سلسة حقًا لدمج تعليقات WP مع Discourse تبدو أقل تعقيدًا ومن شأنها بلا شك أن تحسن بشكل كبير عدد التعليقات مما نحصل عليه حاليًا مع المكون الإضافي الحالي.
3 إعجابات
ربما هذا:
لكنها تستولي تمامًا على تسجيل الدخول الخاص بـ Discourse على حد علمي.
هل سيتيح ذلك للمستخدمين نشر تعليقات مباشرة تحت منشور ووردبريس وملء هذا المنشور تلقائيًا في سلسلة مناقشة ووردبريس المقابلة؟
أنا أعمل على هذا الآن. الإصدار الأول مخصص لموقع ووردبريس بدون رأس (headless WordPress) يستخدم إطار عمل Remix للواجهة الأمامية. بمجرد الانتهاء من ذلك، سأقوم بإنشاء إصدار لمواقع ووردبريس العادية. من المحتمل أن يكون إضافة (plugin) توسع إضافة WP Discourse. آمل أن يتم نقل معظم ما أقوم به على موقع ووردبريس بدون رأس إلى مواقع ووردبريس العادية، ولكن قد يتطلب ذلك بعض التنازلات.
السماح للمستخدمين بالتعليق مباشرة من موقع خارجي أمر سهل التنفيذ. الشرط الرئيسي هو أن يكون للموقع الخارجي إمكانية الوصول إلى بيانات اعتماد المستخدم في Discourse. يمكن تحقيق ذلك إما باستخدام الموقع الخارجي كموفر DiscourseConnect لـ Discourse أو عن طريق تكوين Discourse كموفر DiscourseConnect للموقع الخارجي.
في السيناريو الثاني - حيث لا يكون الموقع الخارجي هو موفر DiscourseConnect لـ Discourse - في المرة الأولى التي يرغب فيها المستخدم في التعليق من الموقع الخارجي، سيحتاج إلى النقر فوق رابط لربط حسابه على الموقع الخارجي بحسابه في Discourse (أو للتسجيل في Discourse إذا لم يكن قد فعل ذلك بعد). يمكن أن يكون هذا سلسًا جدًا من وجهة نظر المستخدم.
ومع ذلك، فإن التغيير المذكور أعلاه لا يجعل كل شيء يبدو وكأنه نظام تعليقات عادي. التوقع الطبيعي لنظام التعليقات هو أنه يمكنك قراءة جميع التعليقات والتفاعل معها. تعرض إضافة WP Discourse فقط مجموعة مختارة من التعليقات التي يتم سحبها من مسار خاص توفره Discourse. لا توفر أي وظائف للتفاعل مع التعليقات.
الأجزاء الصعبة من المشكلة هي:
- ترقيم الصفحات عبر جميع تعليقات الموضوع على ووردبريس، مع الأخذ في الاعتبار أنه قد يكون هناك الآلاف منها.
- توفير واجهة مستخدم تمنح المستخدم ملاحظات حول مكانه في قائمة طويلة من التعليقات.
- معرفة كيفية عرض التعليقات التي هي ردود مباشرة على تعليقات أخرى. (اتفاقية Discourse لهذا تختلف عن كيفية تعامل معظم أنظمة التعليقات مع الردود.)
- السماح للمستخدمين بالرد مباشرة على تعليق، أو الإعجاب بتعليق، أو تعديل تعليقاتهم الخاصة، وما إلى ذلك.
- التعامل مع التعليقات التي تم إنشاؤها على Discourse والتي قد تحتوي على محتوى أو ترميز لا يمكن عرضه أو التفاعل معه بسهولة على الموقع الخارجي. على سبيل المثال، oneboxes، استطلاعات الرأي…
- توفير طريقة لتصفية التعليقات حسب الأحدث، الأقدم، الأفضل، إلخ…
يجب تحقيق كل هذا دون وضع عبء مفرط على خادم الموقع الخارجي، أو إجراء الكثير من طلبات API إلى Discourse، أو استهلاك الكثير من الذاكرة على جهاز المستخدم (الهدف هو إنشاء نظام تعليقات خفيف الوزن). هذا قابل للتحقيق، ولكنه ليس شيئًا يمكن إدراجه ببساطة في كود WP Discourse الحالي دون إجراء تغييرات كبيرة عليه.
4 إعجابات
يسعدني سماع أنك بدأت في هذا!
مجرد فكرة: بما أن جزءًا من الفكرة هو تقليل صعوبة تشجيع الأشخاص على التعليق في المقام الأول، فقد يكون من الجيد التركيز على سلاسة هذا التعليق الأول. كما ذكرنا أعلاه، يبدو أن الكثير من الناس يريدون ببساطة التعليق باستخدام عنوان بريدهم الإلكتروني؛ المشكلة بعد ذلك هي التحقق وتسجيل الدخول، أو إنشاء حساب (اعتمادًا، على ما أعتقد، على كيفية تكوين DiscourseConnect).
بمجرد دخول المستخدم، أتوقع أن يكون أكثر ميلًا لزيارة موضوع المنتدى المقابل للحصول على جميع وظائف المناقشة المستندة إلى Discourse. آمل فقط ألا تعيق كل تلك الأجزاء الصعبة من المشكلة حل مشكلة “التعليق الأول”. وجود آلاف التعليقات التي يتعين علينا إيجاد طريقة لتقسيم الصفحات لها سيكون حينئذٍ “مشكلة جيدة لحلها”. 
4 إعجابات
هذا يكفي بالنسبة لي لأن المستخدمين الجدد والقدامى سيشاركون ويتفاعلون مع بعضهم البعض. لا يمثل الأمر مشكلة كبيرة بالنسبة لي خارجيًا
نعم، هذا قلق حقيقي. الخطوة الأولى هي إطلاق موقع تجريبي. وجود موقع مباشر لاختبار الأشياء سيجعل نقاط الاحتكاك واضحة.
قد يكون من الممكن تقنيًا السماح للمستخدمين المجهولين بالتعليق على المنشورات. الطريقة الوحيدة غير الملتوية التي يمكنني التفكير فيها هي نشر التعليقات نيابة عن المستخدم المجهول بواسطة مستخدم حقيقي. هذا يبدو غريبًا بعض الشيء.
أعلم أن ووردبريس لديه إعداد للسماح للمستخدمين “الضيوف” بإنشاء تعليقات. يأتي مع قيد مفاده أن تعليق “الضيف” لن يرتبط بمستخدم حقيقي إذا سجل المستخدم الذي أنشأ تعليق الضيف في الموقع بعد إنشاء التعليق. يجب أن يعمل النشر “نيابة عن” مستخدم بطريقة مماثلة - لن تكون هناك طريقة لمعرفة أن المستخدم الذي أنشأ التعليق المجهول هو مالك عنوان البريد الإلكتروني الذي قدمه مع التعليق.
من الناحية المثالية، سيتم مصادقة المستخدمين إما على الموقع الخارجي أو على Discourse قبل إنشاء تعليق.
من وجهة نظر المستخدم، فإن أقل قدر ممكن من الاحتكاك سيكون في حالة أن الموقع الخارجي هو مزود تسجيل الدخول الموحد (SSO) لـ Discourse. هذا سيجعل من الممكن لهم التعليق على مواضيع Discourse دون الحاجة إلى زيارة موقع Discourse.
من وجهة نظر مالك الموقع، فإن أسهل طريقة تقنيًا لمصادقة المستخدمين هي أن يعمل Discourse كموفر للمصادقة للموقع الخارجي. هذا هو التكوين الذي أستخدمه حاليًا على موقع الاختبار المحلي الخاص بي. الموقع الخارجي (Remix) لا يحتوي حتى على جدول للمستخدمين. إنه ببساطة ينشئ جلسة مستخدم بناءً على الاستجابة من مسار /session/sso_provider الخاص بـ Discourse.
العيب في استخدام Discourse كموفر للمصادقة للموقع الخارجي هو أنه يجبر المستخدمين على المرور بعملية التسجيل/تسجيل الدخول في Discourse. لا يوجد خطأ في هذه العملية، باستثناء أنها تبدو وكأنها تجبر المستخدمين على تنزيل جميع أصول Discourse عندما قد يرغبون فقط في ترك تعليق على الموقع الخارجي. لذلك فهي بطيئة نوعًا ما. سأبحث أكثر…
سيكون كذلك ربما قلل ذلك إلى المئات لسيناريو أكثر واقعية. النقطة التي أحاول طرحها هي أن المشكلة تصبح معقدة بمجرد تجاوز صفحة واحدة من المنشورات (20 منشورًا).
تعديل: قد يكون من الممكن استخدام دعوات Discourse لتبسيط العملية - إذا أراد مستخدم مجهول التعليق على منشور، فسيتم عرض حقل بريد إلكتروني مع نموذج التعليق. سيؤدي إرسال التعليق إلى تشغيل Discourse لإرسال دعوة إلى عنوان البريد الإلكتروني. سيتم الاحتفاظ بالتعليق في قائمة انتظار حتى يتم قبول الدعوة. سيتيح هذا للمستخدمين إنشاء التعليق عندما يشعرون بالإلهام ويمنحهم ردود فعل فورية حول حالة تعليقهم.
4 إعجابات
أتطلع لرؤية حل @simon هنا.
أردت فقط أن أشير إلى أن الحل الذي يتطور على مسار مختلف في هذا الصدد هو استخدام ActivityPub. في أحدث إصدار له، أضاف المكون الإضافي الرسمي لـ ActivityPub الخاص بـ Wordpress دعمًا للمكون الإضافي ActivityPub الخاص بـ Discourse.
هذا يعني أنه إذا كان لديك المكون الإضافي ActivityPub الخاص بـ Wordpress مثبتًا والمكون الإضافي ActivityPub الخاص بـ Discourse مثبتًا، فكل ما عليك فعله هو إعداد فئة لـ “متابعة” ممثل Wordpress الذي ينشر (أو موقع Wordpress بأكمله) وستظهر منشورات Wordpress الخاصة بك كمواضيع جديدة في تلك الفئة في Discourse.
(لاحظ أن المكون الإضافي لـ Wordpress لديه تأخير في النشر، وهذا هو سبب استغراق ظهوره في Discourse في الفيديو دقيقة واحدة؛ تخطى إلى 1:40 لرؤيته يظهر).
يدعم المكون الإضافي ActivityPub الخاص بـ Wordpress أيضًا استيعاب النشاط، وهو مُعد بالفعل لمعالجة الأنشطة الواردة ردًا على منشور كـ “تعليق” على هذا المنشور، ومع ذلك، فإن هذا الجزء بالذات لا يعمل حاليًا مع الأنشطة التي يرسلها المكون الإضافي Discourse (أعتقد أن المكون الإضافي لـ Wordpress لا يدعم الملاحظات المعلنة بعد). ولكن يجب أن يعمل ذلك قريبًا أيضًا.
انظر المزيد
6 إعجابات
لاحظ أن ماتياس، القائم على صيانة إضافة Wordpress، قد جعل هذا يعمل، لذلك يجب أن يكون هناك دعم لمشاركة المنشورات والتعليقات الأصلية ثنائية الاتجاه بين Discourse و Wordpress (عبر ActivityPub) قريبًا.
https://socialhub.activitypub.rocks/t/this-is-a-test-federation/4164/2
https://pfefferle.org/this-is-a-test-federation/#comment-148
3 إعجابات
بدأت هذه المناقشة بفكرة أن نظام تعليقات مدعوم من Discourse يمكن أن يوفر وظائف مشابهة لـ Coral، مع فائدة إضافية تتمثل في السماح لتعليقات موقع الويب بالانفصال إلى مواضيع Discourse عادية. يوفر Discourse القدرة على الإشراف على تعليقات موقع الويب والسماح بإجراء مناقشات متعلقة بالتعليقات على المنتدى.
لا أعتقد أن الحاجة إلى الإشراف تحتاج إلى جدال.
قد تكون الحاجة إلى السماح للتعليقات بالانفصال إلى مواضيع Discourse فعلية أقل وضوحًا. أعمل من افتراض أن إجراء أي نوع من المحادثات عبر الإنترنت أمر صعب - فالمحادثات الشخصية توفر جميع أنواع الإشارات الدقيقة التي لا توجد عبر الإنترنت. إجراء محادثات هادفة عبر الإنترنت مع أكثر من عدد قليل من الأشخاص يكاد يكون مستحيلاً. هذا هو المكان الذي يأتي فيه Discourse. توفر وظيفة المجموعات في Discourse القدرة على تحديد من يمكنه المشاركة في موضوع ما. يمكن السماح لمجموعات المعلقين بالمشاركة في مواضيع Discourse المغلقة. هذا هو عكس طريقة عمل الـ fediverse.
ومع ذلك، أنا مهتم بكيفية عمل تكامل Discourse/WordPress للـ fediverse. على سبيل المثال، إذا علقت سالي على منشور Bob في WordPress، فما الذي يُتوقع أن يحدث لتعليق سالي إذا كان لديها حساب Discourse؟ ماذا يمكن أن يحدث لتعليق سالي إذا لم يكن لديها حساب Discourse؟ هل هناك أي طريقة يمكن لسالي من خلالها إلغاء الاشتراك في نشر تعليقها على الـ fediverse؟
خارج الموضوع، ولكن مع أنواع مختلفة من مشاريع القوانين المتعلقة بالأضرار عبر الإنترنت التي يتم تنفيذها أو اقتراحها في الدول الغربية، إذا تم اعتبار تعليق سالي مسيئًا، فمن المسؤول عن نشره؟ أفترض أن هذا سؤال لا يمكن الإجابة عليه في هذه المرحلة.
3 إعجابات
مثير للاهتمام!
الطريقة التي أقترح بها التفكير في كيفية عمل ActivityPub مع كل من الاعتدال والتجميع (وغيرها من مبادئ الاتصال عبر الإنترنت) هي أنه معيار اتصال في المقام الأول. يوفر بعض الآليات للتعامل مع هذه الأسئلة، ولكنه يتركها إلى حد كبير للعملاء المختلفين في النظام.
البريد الإلكتروني كمعيار اتصال هو قياس غير مثالي، ولكنه ربما يكون مفيدًا. “البريد الإلكتروني” هو مجموعة من معايير الاتصال التي تسمح لك بتبادل الرسائل مع أي شخص على الإنترنت. لديه “مشاكل مراقبة جودة” مختلفة، على سبيل المثال، البريد العشوائي. هناك بعض الجوانب في مجموعة المعايير التي نسميها “البريد الإلكتروني” التي تساعد في التعامل مع هذه المشكلات (على سبيل المثال، DMARC، DKIM، SPF إلخ)، ومع ذلك، ربما تكون الطريقة الأساسية التي تتم بها مراقبة الجودة في عملاء البريد الإلكتروني أنفسهم. أصبح Gmail عميل بريد إلكتروني شائعًا جزئيًا لأنه تعامل بشكل جيد مع البريد العشوائي (ومشاكل مراقبة الجودة المماثلة).
باتباع القياس، سيكون Discourse هو “Gmail” الخاص بـ ActivityPub. لا تزال جميع أدوات الاعتدال وتجميع المستخدمين والميزات الأخرى التي تجعل Discourse منصة مناقشة رائعة متاحة (تقريبًا) في سياق ActivityPub. سأقوم بتوضيح ذلك من خلال البدء في الإجابة على أسئلتك.
سأبدأ بوصف ما يحدث ثم يمكننا ربما الانتقال إلى الأسئلة الأكثر دقة. سأتجاوز الكثير من الأشياء هنا، بهدف الإجابة على الأساسيات:
- يتم نشر تعليق سالي ككائن ActivityPub من ووردبريس.
- يتم استيعاب الكائن في Discourse وتحويله إلى منشور.
- إذا كان “ممثل” سالي مرتبطًا بحساب مستخدم في Discourse، فسيتم ربط المنشور بهذا الحساب. إذا لم يكن ممثلها مرتبطًا بالفعل بحساب مستخدم، فسيتم إنشاء مستخدم مرحلي من ممثل سالي وسيكونون مالكين للمنشور.
يمكنك رؤية ما سبق أثناء العمل في هذا الموضوع: - فئة Discourse WordPress - SocialHub تتابع Matthias’ Wordpress.
- نشر ماتياس مقالًا جديدًا على مدونته باستخدام حسابه العادي في ووردبريس.
- ظهر ذلك في Discourse كموضوع جديد، مع ربط المنشور بمستخدم مرحلي مرتبط بممثل ماتياس.
- طريقة عمل التعليقات هي نفسها تمامًا.
فقط لتغطية السؤال الأكثر وضوحًا ربما: هل يمكن لماتياس التوفيق بين المستخدم “المرحلي” الذي تم إنشاؤه من ممثل ووردبريس الخاص به وحسابه العادي في Discourse على هذا الخادم؟
الإجابة على المدى القصير هي أن إضافة Discourse تحتوي على مجموعة ميزات “تفويض” تسمح لك حاليًا بالمطالبة بملكية ممثلين من خوادم Discourse أخرى أو خوادم Mastodon، مما يدمج أي مستخدمين مرحلين في حسابك (مما يعني أنك الآن مالك المنشورات في حساب Discourse الرئيسي الخاص بك). يمكن توسيع مجموعة الميزات هذه إلى ووردبريس. أقدر أن هذا الكلام طويل بعض الشيء، وقد يكون من الأسهل فهم ما أعنيه بهذا العرض التوضيحي:
Preferences - angus - Discourse - 1 May 2024 | Loom
الإجابة على المدى الطويل هي أنه قد يتم تضمين إثباتات الهوية في أنشطة ActivityPub في مرحلة ما، مما قد يزيل الحاجة إلى التفويض الذي يقوده المستخدم، مما يعني أن “التوفيق” يمكن أن يكون تلقائيًا (أكثر).
ربما يكون السؤال الآخر هو ما إذا كان “التوفيق” ضروريًا، نظرًا لأن ماتياس لا يزال يتحكم في سمات هوية مستخدمه المرحلي عبر ممثل ActivityPub الخاص به (والذي يمكن تحريره على ووردبريس، وتنتقل التعديلات منه إلى المستخدم المرحلي في Discourse).
أقول معظم هذا كشكل من أشكال التمهيد، حتى نتمكن من الانتقال إلى أسئلتك الأكثر دقة، والأهم. آمل أن أكون منطقيًا حتى الآن.
إعجابَين (2)
هذا منطقي.
فيما يتعلق بقضية الإشراف، أنا أتحدث عن استخدام Discourse للإشراف على تعليقات WordPress. هذه هي الوظيفة التي ستسمح باستخدام Discourse بطريقة مشابهة لـ Coral. هذا سهل التحقيق إذا كانت تعليقات WordPress هي في الواقع تعليقات Discourse التي يتم نشرها من WordPress إلى Discourse عبر واجهة برمجة التطبيقات (API). إنها تعمل ببساطة خارج الصندوق. هذا يسمح بأشياء مثل استخدام أي أدوات إشراف مدعومة بالذكاء الاصطناعي توفرها Discourse. أتساءل عما إذا كان يمكن تحقيق شيء مماثل من خلال تكامل ActivityPub بين WordPress و Discourse.
ما هو إثبات الهوية للمستخدم المرحلي؟ هل يتم تمرير عنوان بريدهم الإلكتروني من الخادم الأصلي؟
بالنسبة لقلقي (الشخصي) بشأن عدم رغبتي في نشر المحتوى على شبكة fediverse بأكملها، يبدو أنه من الممكن تقنيًا إعداد علاقة ActivityPub واحد لواحد بين موقع Discourse وموقع WordPress، ولكني أتساءل عما إذا كان هذا النوع من الترتيب يهزم الغرض من بروتوكول ActivityPub.
تعديل: قد يكون من الجدير إضافة أن الهدف هو إنشاء علاقة مربحة للجانبين بين موقع ويب ومنتدى Discourse مرتبط به. تهدف أدوات الإشراف في Discourse إلى توفير الطمأنينة بأن نظام التعليقات الخاص بالموقع يتم الإشراف عليه بشكل جيد. القسم المخصص للتعليقات في الموقع مخصص لاستخدامه لزرع المواضيع والمستخدمين في موقع Discourse.
إعجابَين (2)
يتم تطبيق معظم* وظائف المعالجة المسبقة والمعالجة اللاحقة على المنشور الذي تم تحويله من كائن ActivityPub كما هو الحال مع المنشور الذي تم إنشاؤه عبر واجهة برمجة التطبيقات (API). نقطة الدخول مختلفة (أي وحدة تحكم ActivityPub بدلاً من وحدة تحكم المنشورات)، ولكن طريقة إنشاء المنشورات متشابهة إلى حد كبير.
*بمصطلحات أكثر تقنية، إذا قمت بإنشاء منشور عبر واجهة برمجة التطبيقات (API)، فإن المعالجة الفعلية تتم عبر NewPostManager، والذي يقوم بعد ذلك بتسليم معظم العمل إلى PostCreator. الشيء الرئيسي الذي يتعامل معه NewPostManager (لأغراضنا هنا) هو قائمة انتظار المراجعة. يتم التعامل مع كل شيء آخر في PostCreator.
حاليًا، يتجاوز المكون الإضافي ActivityPub NewPostManager ويسلمه إلى PostCreator في PostHandler الخاص به (أي المكون الإضافي). لقد فعلت ذلك بشكل أساسي لتقليل التعقيد في التنفيذ الأولي. لا يوجد سبب جوهري يمنع PostHandler الخاص بالمكون الإضافي من تسليم المنشور إلى NewPostManager والاستفادة من فحوصات قائمة انتظار المراجعة.
باختصار، لا يوجد فرق جوهري بين المنشورات التي تم إنشاؤها عبر المكون الإضافي ActivityPub وعبر واجهة برمجة التطبيقات (API) العادية.
هناك بضع طبقات لهذا.
-
أولاً، يتم توقيع طلب POST من المصدر إلى خادمك باستخدام توقيعات HTTP لضمان أن الطلب يأتي بالفعل من المصدر.
-
ثانيًا، لكل ممثل (أي مستخدم) على هذا المصدر معرف UUID، أي معرف مرتبط بنطاقه، فريد في fediverse. يبدو شيئًا كهذا:
https://angus.ngrok.io/ap/actor/f4b517bf6f81dbddfad3e44a45c9619d
لا يتم استخدام رسائل البريد الإلكتروني في ActivityPub.
-
كل نشاط (على سبيل المثال، إنشاء كائن يشبه المنشور) تتلقاه مرتبط بمعرف الممثل. ويمكن حل كل معرف ممثل إلى سمات الممثل.
-
لذلك، بحلول الوقت الذي تتلقى فيه “نشاطًا”، على سبيل المثال، إنشاء كائن جديد يشبه المنشور، على خادمك، فأنت تعرف، وفقًا للنطاق الذي تلقيت منه النشاط، سمات الممثل الذي يقوم بالنشاط. أنت تثق بالنطاق المرسل هنا، ولكن هذا هو الحال دائمًا إلى الحد الذي، على سبيل المثال، يثق فيه Discourse بمثيلات Wordpress مع المكون الإضافي WP Discourse لإرسال سمات المستخدم الصحيحة المرتبطة أيضًا.
لذلك لا يحتاج المستخدم المرحلي نفسه إلى إثبات هوية بحد ذاته، بنفس الطريقة التي لا يحتاج بها المستخدم المرحلي من البريد الإلكتروني إلى إثبات هوية.
تنشأ الحاجة إلى إثبات الهوية عندما يرغب الشخص الحقيقي المرتبط بممثل ActivityPub، وحساب Discourse آخر، مثل المثال مع Matthias أعلاه، في توحيد (أو “تسوية”) هويته. قد لا يحبون أن يكون لديهم فعليًا مستخدمان “على” Discourse واحد. أود أن أشير إلى أنه بدون مثل هذه التسوية، يمكنهم التحكم في
-
سمات هوية ممثل ActivityPub / المستخدم المرحلي عبر النطاق المصدر، على سبيل المثال، عن طريق تحديث ملف تعريف Wordpress الخاص بهم، ويتم نشر هذه التحديثات ويطبق Discourse نفس الشيء)؛ و
-
المحتوى المرتبط بممثل ActivityPub / المستخدم المرحلي عبر النطاق المصدر، على سبيل المثال، عن طريق تحرير تعليق Wordpress الخاص بهم، ويتم إرسال نشاط تحديث ثم معالجته بواسطة Discourse.
ولكن، مع ذلك، قد يشعرون أنه “فوضوي” أن يكون لديهم فعليًا مستخدمان على Discourse. لهذا السبب يحتوي المكون الإضافي على مجموعة ميزات “التفويض” الخاصة به، للسماح لك بإظهار أن مستخدم Discourse العادي الخاص بك مرتبط بممثل ActivityPub مع مستخدمه المرحلي. يتم ذلك حاليًا عبر آليات التفويض الخاصة بالمنصة:
-
بالنسبة لـ Mastodon، يتم ذلك عبر واجهة برمجة تطبيقات OAuth الخاصة بـ Mastodon. يتطلب منك المصادقة على حسابك على Mastodon لإثبات أنك تتحكم في الممثل ذي الصلة.
-
بالنسبة لـ Discourse، يتم ذلك عبر واجهة برمجة تطبيقات المستخدم. هذا هو ما هو موضح في الفيديو في منشوري السابق.
-
هناك عدد قليل من الطرق التي يمكن بها القيام بنفس الشيء لـ Wordpress، على سبيل المثال، DiscourseConnect عبر المكون الإضافي WP Discourse. لم يتم تنفيذ هذا بعد.
بمجرد إثبات أنك تمتلك الممثل المرتبط بالمستخدم المرحلي، يتم دمج المستخدم المرحلي مع المستخدم العادي الخاص بك، وتصبح منشوراته ملكك، وتصبح أي أنشطة جديدة مرتبطة بهذا الممثل ملكك تلقائيًا. ولكن مجموعة الميزات هذه هي في الواقع لتحسين تجربة المستخدم وليست ضرورية بشكل صارم. الشخص الحقيقي وراء هؤلاء المستخدمين المختلفين يتحكم في كل من سمات المستخدم ومحتواها منذ البداية.
نعم، من الممكن توجيه هدف المنشورات الصادرة، وتقييد مصدر المنشورات الواردة. ما إذا كان هذا يهزم الغرض من ActivityPub أمر قابل للنقاش. بشكل صارم، ActivityPub هو مجرد معيار. أود أن أجادل بأنه لا يوجد سبب لعدم استخدام المعيار بهذه الطريقة. تاريخيًا، ارتبط ActivityPub بالشبكات الاجتماعية اللامركزية، وخاصة Mastodon، وهذا قد يكون سبب شعورك بأن هذا النوع من النهج يهزم الغرض من ActivityPub. لكنني سأفرق بين معيار ActivityPub نفسه وتنفيذاته الحالية هنا.
علاوة على ذلك، في هذا السياق، أود أن أشير إلى أنه مثل البريد الإلكتروني، ما نسميه “ActivityPub” هو في الواقع مجموعة من المعايير. يجب قراءة وثيقة المعايير بعنوان “ActivityPub” جنبًا إلى جنب مع وثيقة معايير أخرى تسمى “ActivityStreams”، والتي تصف الكائنات الرئيسية قيد اللعب هنا. معيار ActivityStreams هو “محايد للخدمة” أكثر من ActivityPub نفسه (أي أقل ارتباطًا بالشبكات الاجتماعية اللامركزية).
لاستخدام (مثال آخر) تشبيه، فإن البلوك تشين كتكنولوجيا هي ببساطة دفتر أستاذ لامركزي، المرة الأولى التي تم شرحها لي جعلتني أفكر في نظام تورينز لتسجيل الأراضي، الذي تم اختراعه في القرن التاسع عشر (في أستراليا) لنفس الأسباب تقريبًا التي تم بها اختراع البلوك تشين (أي لمنع الاحتيال في معاملات الممتلكات). لكن التنفيذ الأكثر شيوعًا للبلوك تشين هو البيتكوين، الذي له استخدام محدد (مختلف)، وقيم ثقافية معينة. التشبيه ليس الأفضل، ولكن إحدى الطرق للتفكير في الأمر هي أن Mastodon والشبكات الاجتماعية اللامركزية هي لـ ActivityPub ما هو البيتكوين للبلوك تشين.
في الواقع، أحد الأسباب التي ساعدتني في إنشاء مجموعة عمل جديدة لـ W3C ActivityPub للمنتديات مع NodeBB و Flarum وآخرين هو محاولة تحويل تركيز تكامل ActivityPub من التنفيذات الحالية (مثل Mastodon) إلى اهتمامات المنتديات، مثل تلك المتعلقة بالإشراف التي تثيرها. لدينا بالفعل اجتماعنا القادم اليوم. إذا كان لديك وقت، أود أن يكون لدي “Discourser” زميل (هل هذا مصطلح؟) هناك
4 إعجابات
أنا أتحدث عن استخدام أدوات الإشراف الخاصة بـ Discourse للإشراف على التعليقات التي تظهر على WordPress. من الناحية الفنية، يمكن القيام بذلك باستخدام طلب واجهة برمجة تطبيقات Discourse أو Webhook - بعد حدوث إجراء إشراف في Discourse، يمكن تقديم طلب لتغيير حالة التعليق على WordPress.
بافتراض تغيير الأمور بحيث يتم التعامل مع منشورات ActivityPub بواسطة قائمة المراجعة، سيظل هناك مشكلة في التأخير الزمني بين وقت نشر التعليق الأولي على WordPress ووقت ظهوره في Discourse. أعتقد أن هذا يستغرق بضع دقائق؟
لهذه الحالة بالذات، فإن أحد نقاط البيع الرئيسية هو “استخدام Discourse للإشراف على تعليقات موقعك”. يستمر في سرد ميزات الإشراف الخاصة بـ Discourse، ونظام مستوى الثقة، وقائمة المراجعة، وأدوات الإشراف المدعومة بالذكاء الاصطناعي، وما إلى ذلك. هذه أدوات قد تكون مفيدة للمدونات الصغيرة، ولكنها ضرورية لمواقع الأخبار الرئيسية. أعتقد أن أفضل طريقة لتحقيق ذلك هي استخدام Discourse كمصدر وحيد للحقيقة للتعليقات، بدلاً من وجود تعليقات في قاعدتي بيانات (أو أكثر).
هذا رائع! بدون وقت للتفكير مليًا، لا أعتقد أنني سأكون ممثلاً جيدًا لـ Discourse.
لدي بعض المخاوف العامة حول فكرة التعامل مع المواضيع والمشاركات والمستخدمين كبيانات مجردة. يجب أن تكون هناك طريقة للتأكد من عدم فقدان سياق مكان حدوث المناقشة.
على مستوى أكثر عملية، ازدهر بروتوكول ActivityPub قبل تقديم مشاريع القوانين المتعلقة بالأضرار عبر الإنترنت التي يتم تقديمها في بلدان مختلفة. يجب أن يكون هناك بعض التأكيد على أن الخوادم التي تستهلك البيانات من مصدر ما ستحترم طلبات الحذف. وإلا، فإن المستخدمين الذين ينشئون محتوى على خادم المصدر يخاطرون بتداعيات قانونية إذا تم اعتبار محتواهم لاحقًا ضارًا في بلدهم.
3 إعجابات