المشكلة الشائعة التي يواجهها العديد من مستخدمي Discourse هي عدم القدرة على عرض تجميع لجميع مجموعات الاهتمام التي اشتركوا فيها. لا توجد طريقة سهلة لاستهلاك المحتوى من عدة نماذج Discourse في شكل تغذية مستخدم مركزية واجتماعية. تتغلب المنصات المركزية مثل Reddit على هذه المشكلة من خلال توفير تسجيل دخول واحد لجميع المجتمعات، وتغذية مجمعة لكل المجتمعات تظهر في تدفق واحد على صفحة الهبوط في reddit.com. هذه الميزة الأخيرة هي ما نود تكراره في Discourse من خلال بروتوكول ActivityPub.
على سبيل المثال، يزور الشخص أ عدة نماذج Discourse: واحدة للسياسة، اثنتان للهوايات، واحدة لمنتدى الحي المحلي، لكنه لا يملك طريقة لاستهلاك كل المحتوى ذي الصلة في تغذية واحدة. بالمقارنة، إذا انضممت إلى عدة مجموعات على Facebook أو عدة قنوات فرعية على Reddit، فإن المنشورات الأكثر صلة تظهر بالفعل في تغذيتك.
المواصفات (الإصدار 1)
يمكننا تصميم نموذج أولي لمنتج الحد الأدنى (MVP) من خلال تمكين الميزات التالية عبر إضافة Discourse:
إنشاء تغذية ActivityPub عند الطلب (لكل صفحة تحتوي بالفعل على تغذية RSS)
مشابهة لإضافة .rss إلى عنوان URL، وهذا سيسمح بجلب المحتوى باستخدام بروتوكول AP عند طلب نقطة النهاية الصحيحة.
قد نكون قادرين حتى على تمكين هذا للمحتوى الخاص عن طريق إرفاق مفاتيح واجهة برمجة التطبيقات الخاصة بالمستخدمين بعنوان URL.
السماح لمسؤولي المنتدى بتمكين ActivityPub (صادر) على أساس كل فئة أو جعله مفعّلًا افتراضيًا؟ (أعتقد أن @Falco كان لديه بعض الأفكار هنا)
إيجاد طريقة لاستهلاك هذا المحتوى على منتدى Discourse / تغذية Mastodon (وارد)
الخطوات التالية
نحن بحاجة بالتأكيد إلى البدء بشكل صغير، لذا في البداية، نحتاج إلى اتخاذ قرار بشأن مجموعة صغيرة وقابلة للتنفيذ من الميزات التي ستدخل في الإصدار الأول. لقد كنت أراجع بروتوكول ActivityPub لكنني لست على دراية كافية بآليات عمله الداخلية بعد. لذلك، أدعو الآخرين الذين أظهروا اهتمامًا كبيرًا بهذا الموضوع للمشاركة في النقاش (@Falco، @hellekin، @merefield) لمساعدتنا في بناء مواصفات قابلة للتنفيذ للإصدار الأول وتقديم توصيات بتغييرات على المواصفات أعلاه.
أود أن أبدأ بالقول: ألا ينبغي لنا التركيز على “ماذا” وليس “كيف” في البداية؟ هل تأتي هندسة التقنية لاحقًا؟ والسبب في قولي ذلك هو أن اختيارها مبكرًا قد يحد من الوظائف.
أود جدًا أن أرى في الإصدار الأول قوائم “اكتشاف الاكتشافات”، بدءًا من:
قائمة “الأحدث” التي تعرض معاينة لكل موضوع حديث من المصادر المضمنة (اتحاد بسيط لـ “الأحدث” من جميع المصادر).
قائمة “المتابعة”، التي تعرض معاينة لكل موضوع لديه نشاط اخترت أن تُعلم به. (هذا يستمد سوابقه من تطبيق الهاتف المحمول الحالي - حيث يقوم بتفجير إشعارات النشاط الجديد في المواضيع المتابعة إلى معاينات المواضيع الأساسية نفسها).
يجب أن أقول إن الاقتراح الأصلي الذي يتضمن تشبيه فيسبوك يتجاوز فهمي: ليس لدي أدنى فكرة عن ما يفعله فيسبوك، ولا أفهم كيف يرتبط بـ Discourse بأي شكل من الأشكال.
فهمي لدعم ActivityPub في Discourse هو أنه يمكن أن يساعد في توحيد المواضيع، أو حتى مشاركة فئة بين نسخ Discourse. على سبيل المثال، يمكن توحيد موضوع إعلان واحد على discourse.joinmastodon.org إلى socialhub.activitypub.rocks في فئة #software:mastodon ذات الصلة: هناك، يمكن للمستخدمين المحليين الإعجاب والرد والاقتباس، وما إلى ذلك، كما لو كان موضوعًا محليًا، باستثناء أن الموضوع الأصلي سيعيش على مثيل joinmastodon.
جانب آخر منه هو أنه إذا كان لدى شخص ما حساب على كلا المثيلين، فيجب أن تكون هناك طريقة لربط هذين الحسابين معًا، أي استخدام مثيل Discourse محدد كمزود هوية رئيسي. أفهم أن هذا ليس محور الجولة الأولى، لكن من الجيد وضعه في الاعتبار، نظرًا لأننا قد ننتهي بامتلاك “تسجيل الدخول باستخدام [ضع تنفيذ ActivityPub المفضل لديك هنا]”.
ما أفهمه من الاقتراحات أعلاه هو تكرار تطبيق Discourse على Android، حيث يكون لديك قائمة بالمثيلات، وتصلك إشعارات من جميعها. يبدو أنه من الخطير بعض الشيء دمج الردود غير ذات الصلة من مصادر عديدة، خاصةً عندما تفقد سياقها.
هل فهمت بشكل صحيح، وهل سيجعل فهمي خطوة جيدة ثانية لرؤيتك في دمج ActivityPub مع Discourse؟
جميع تطبيقات ActivityPub الحالية تتوقع أن تُنشر المنشورات بواسطة “فاعلين” (Actors) مستقرين، لذا قد تحتاج إلى أحد الخيارات التالية:
حساب نظام ينشر جميع المنشورات
حساب واحد لكل تغذية قابلة للمتابعة
حساب واحد لكل تغذية قابلة للمتابعة، يقوم بإجراء إعلانات (Announce) للمنشورات التي يُفترض أنها كُتبت بواسطة حساب لكل مستخدم في Discourse
الخيار الأول هو الأسهل على الأرجح في التنفيذ؛ بينما يحقق الخيار الثالث أفضل توافق بين نماذج البيانات.
هناك أيضًا خيار نشر محتوى الموضوع بالكامل، أو منشورات الموضوع الأولى فقط، أو شيء مشابه لتغذيات تويتر الخاصة بـ StackExchange حيث يتم إنشاء منشورات منفصلة للترويج للمنشورات من صفحة /top. أو ربما يكون هذا هو كيفية عمل تغذية “أفضل المنشورات” فقط، بينما تنشر التغذيات الأخرى كل شيء…
على المستوى التقني، لا ينبغي أن يتغير عنوان URL: فجميع الخوادم ستُرسل Accept: application/activity+json أو بدائلها.
تطبيق قارئ يدمج تغذيات من مصادر مختلفة في أوقات مختلفة في ActivityPub - وإعادة إنشاء “الجدول الزمني الخوارزمي” كخيار اختياري - هو شيء أرغب فيه منذ فترة، ولا يبدو أنه موجود اليوم.
@hellekin: أعتقد أن الكتابة عبر النطاقات لديها فرصة عالية لتجاوز العديد من حمايةات مكافحة البريد العشوائي التي يوفرها Discourse بشكل قاتل. إن القراءة أكثر أهمية في التنفيذ: فبعد كل شيء، القراءة أساسية!
لا أعتقد ذلك: لا يزال بإمكان المستخدمين عن بُعد أن يُوضعوا في قائمة الانتظار، ما لم يربطوا حسابهم عن بُعد بحساب محلي، وفي هذه الحالة سيطبق نظام مكافحة البريد العشوائي على ذلك الحساب.
أعترف أنني لم ألقِ سوى نظرة سريعة على التعليقات. أقترح أن تكون كل فئة ككيان مستقل (بنوع “مجموعة”). عندئذٍ يمكن للأشخاص من الخارج الاشتراك ببساطة في فئات محددة. ويمكن تنفيذ المنشورات في هذه الفئات من خلال إعلان حساب “المجموعة” لرسائل المستخدم. وبهذه الطريقة نمتلك كلاً من الفئة والمؤلف. وهذا هو الأسلوب الذي نستخدمه في برمجياتنا الخاصة. وعند استخدام توقيعات JSON-LD، سيكون ذلك آمناً حتى للفئات غير العامة.
السؤال هو: ما الذي يجب فعله بشأن التعليقات الواردة من الخارج؟ أقترح أن تُعرَّف حسابات المجموعات على أنها تتطلب “موافقة يدوية”. عندئذٍ يمكن إضافة عملية تحقق لتجنب البريد العشوائي العشوائي. وبعد ذلك، سيكون بإمكان هذه الحسابات المُتحقَّق منها التعليق على هذه المنشورات.
سيؤدي ذلك فوراً إلى تمكين الأشخاص من (تقريباً) كل الفيدفيوزي من الاتصال والتفاعل مع أنظمة ديسكورد.
يمكن لكل مجموعة فئات (Category Group) أن يكون لها مالك يمتلك صلاحية إدارة الفئة: التحكم في أذونات النشر، وحظر المستخدمين أو إزالتهم، وتحديد مدى الظهور (عام أو خاص)…
يقوم المستخدمون المحليون بإنشاء فئات على مثيلتهم (instance)، بشرط موافقة طاقم المثيل على إنشاء الفئات.
إذا لم يكن مالك الفئة مناسبًا لمنصبه، فيمكن لطاقم الموقع تغييره.
هذه هي الطريقة التي تعمل بها العديد من المنتديات والمجتمعات المركزية. ما يجب تحسينه هو جعلها موزعة (federated).
ومع ذلك، لا تزال هناك مشكلات:
هل يجب أن تكون معرفات الـ actor قابلة للتغيير؟ يمكن تعيين أسماء المستخدمين في Discourse لتكون قابلة للتعديل في إعدادات الموقع. ومع ذلك، أشك في قدرة برمجيات ActivityPub الأخرى على التعامل مع ذلك. Is Object's `id` immutable? - ActivityPub - SocialHub
(سيتم ذكر المزيد لاحقًا)
نأمل أن نناقش تنفيذ ActivityPub في Discourse خلال جلسة Birds of a Feather يوم الأحد القادم خلال APConf2020. راجع الموضوع المخصص على SocialHub:
@rishabh سيكون رائعًا أن نكون معك، على الأقل في الموضوع إذا لم تتمكن من الحضور يوم الأحد. لا نعرف الساعة الدقيقة بعد، لكنها ستكون صباح يوم الأحد. سأقوم بتحديث هذا المنشور عندما أعرف التفاصيل.
آسف لأنني لم أستطع الحضور. يجب أن أبلغك بأننا لم نتقدم بطلب للحصول على تمويل NGI0، ولا يعمل أي شخص على هذا حاليًا. كما أنني لست الشخص الأنسب لقيادة هذا الأمر لأنني غير ملم بالبروتوكول، لكنني سأخاطب @Falco هنا فقط لأرى ما إذا كان لديه أي أفكار أو اهتمام بالمضي قدمًا في هذا.
حسنًا، في ذلك الوقت، قدم أحد أعضاء فريقك الطلب — حتى لو لم يعد عضوًا في الفريق — وقد تم اختياركم، لذا كان لا بد من موافقة شخص ما. لذا لا أعرف إلى من تشير بكلمة “نحن”. على أي حال، أتطلع إلى مناقشة الأمر مع @Falco. سيكون نوع من الدعم لبروتوكول ActivityPub مفيدًا جدًا لمجتمع ActivityPub، خاصةً أنه سيسهل العمل عبر مثيلات Discourse ويحسن التكامل مع Fediverse.
أدرك مشكلة مكافحة البريد المزعج، لكن أعتقد أنه يمكن التخفيف منها من خلال اعتبار مستخدمي Fediverse في مرحلة تجريبية، مثل مستخدمي البريد الإلكتروني غير المسجلين، حتى يسجلوا فعليًا حسابًا محليًا.
نعم، لقد تقدمنا بطلب للحصول على التمويل في الماضي، لكننا تحدثنا مع فريق NLnet في وقت سابق من هذا العام لإغلاق المشروع وتحرير التمويل الذي كان محجوزًا لنا. حتى لو تم اختيارنا آنذاك، فإن التعاون مع NGI0 ملغى لوقت مؤقت. بالطبع، نحن أحرار في تقديم مقترحات في المستقبل.
sl007
(Sebastian Lasse | @sl007@mastodon.social)
20
مثير للاهتمام.
تم تمويل هذا المشروع من خلال صندوق NGI0 Discovery، وهو صندوق أنشأته NLnet بدعم مالي من برنامج الجيل التالي للإنترنت التابع للمفوضية الأوروبية، تحت إشراف المديرية العامة لشبكات الاتصالات والمحتوى والتكنولوجيا بموجب اتفاقية المنحة رقم 825322.
إذن: هل يتحدثون عن “Discourse” آخر؟
أسأل فقط بسبب “الموقع الرسمي للمشروع: https://discourse.org” …
على أي حال، أتطلع إلى مناقشة الأمر مع