يتم إنشاء موضوع برابط في المنشور الأول - للبدء، اكتشاف إما رابط واحد في المنشور الأول، أو عنوان URL تم لصقه في العنوان.
اختياري: لتجنب البريد العشوائي التافه، انتظر الرد الأول أو قم بتمكين إعداد موقع.
فحص الصفحة لمعرفة ما إذا كان WebMention مدعومًا.
يتم إرسال تعليق WebMention بالنص “This page is being discussed on =SITE\u005fDOMAIN=: "=TITLE=" =TOPIC\u005fLINK= =CATEGORY_AND_TAGS=” (باستخدام لغة الموقع الافتراضية).
يستقبل الموقع WebMention (قد يفوض إلى fed.brid.gy، ويطبق مكافحة البريد العشوائي، وما إلى ذلك) ويعرضه في النهاية كتعليق.
سيأخذ الممثل (معلق “المؤلف”) إما شعار الموقع عالي الجودة أو صورة @system الرمزية، والاسم المختصر للمنتدى.
على الهامش: لم أذكر ذلك في المنشور ولكن البروتوكول يدعم إرسال الإعجابات وإعادة النشر كمواطنين من الدرجة الأولى مثل الردود، سيكون من الجيد لو نفذت ديسكورس ذلك أيضاً
قدمت Pavilion طلبًا إلى NLnet للحصول على 40,000 يورو لإضافة دعم الاتحاد إلى Discourse (انظر أدناه). تم رفضه وانتهى بنا الأمر بالتقدم بطلب (والحصول على قبول) في DAPSI بدلاً من ذلك.
تحديث هنا. يناقش كل من Pavilion و CDCK (Discourse.org) بناء إضافة ActivityPub لـ Discourse. بعد بعض المناقشة، توصلنا إلى المواصفات أدناه. نرحب بأي تعليقات أو اقتراحات قبل الانتهاء منها. لاحظ أن
دعم المحتوى الوارد (مثل المنشورات على Mastodon وما إلى ذلك التي يتم استيرادها إلى Discourse) مستبعد عن قصد. سيكون من الممكن إضافة هذا في إصدار لاحق.
دعم متابعة المستخدمين (على عكس الفئات) مستبعد أيضًا عن قصد. سيكون من الممكن أيضًا إضافة هذا في إصدار لاحق.
ستقوم Pavilion ببناء إضافة MVP (سأعمل عليها)، وستمتلكها CDCK وتستضيفها (أي ستكون إضافة CDCK، وليست إضافة Pavilion).
نظرة عامة
إضافة ActivityPub (AP) لـ Discourse.
الهدف من الإضافة هو تنفيذ MVP لمواصفات ActivityPub و ActivityVocab و ActivityStreams في Discourse مع تكامل واحد موضح لوظائف MVP لمنصة متوافقة مع AP، وهي Mastodon. قدر الإمكان، سيتم بناء التنفيذ لدعم المزيد من دعم البروتوكولات وأي امتدادات.
تتعلق هذه المواصفات بتمكين دعم AP على أساس كل فئة حيث يتم ربط المنشور الأول فقط في كل موضوع في فئة ممكّنة لـ AP (“المنشور الأول فقط”).
المستخدمون
سيتم توثيق استخدام الإضافة بشكل شامل على meta في موضوع إضافة.
مستخدم عادي
يشترك في (أو “يتابع”) فئة Discourse ممكّنة للاتحاد (FDC) على Mastodon (أو أي خدمة fediverse أخرى) باستخدام معرّف الفئة، على سبيل المثال @announcements@meta.discourse.org.
يرى مقتطفًا من المنشور الأول لجميع مواضيع FDC (المنشورة بعد اشتراكهم) في موجز Mastodon الخاص بهم، كل منها برابط يعود إلى الموضوع المرتبط، على سبيل المثال " ناقش على منتدانا ".
أي إجراء يتعلق بالمنشور في Mastodon لا يظهر في Discourse.
أي إجراء يتعلق بالمنشور في Discourse لا يظهر في Mastodon.
يمكن لمؤلف المنشور التحكم في مقتطفات المنشورات المربوطة باستخدام علامات مشابهة لتلك المستخدمة للتحكم في مقتطفات المواضيع، على سبيل المثال <div>{text}</div>
مسؤول
يمكّن الاتحاد على أساس كل فئة باستخدام إعداد فئة. لا يمكن تمكين الاتحاد إلا في الفئات المرئية لـ “الجميع” على المثيلات العامة.
يحدد اسم المستخدم المربوط للفئة عبر واجهة مستخدم إعدادات الفئة (لا يمكن تغييره).
يحدد قوائم السماح والرفض للنطاقات عبر إعدادات الموقع التي يتم قبول النشاط منها أو رفضه تلقائيًا.
يحدد “قائمة حظر” لأسماء المستخدمين المربوطة لتكون جزءًا من كائن (كائنات) حظر في صندوق الصادر للخادم.
يحدد الحد الأقصى لطول الأحرف لملاحظة مربوطة باستخدام إعداد موقع، أي activitypub_note_excerpt_maxlength.
يحدد النص المرتبط بالرابط المضمن في المنشور الأول لموضوع Discourse المربوط في “تخصيص > نص”.
يحدد ما إذا كان الرابط العائد (والنص) للمنتدى مضمنًا في المنشورات المربوطة على أساس كل فئة.
يضيف زوج مفاتيح عبر إعدادات الموقع للتوقيع على المحتوى المربوط.
تقني
ستتضمن الإضافة اختبارات شاملة (اختبارات الوحدة / التكامل واختبارات js).
الفئة هي Actor تلقائي لـ ActivityPub داخل Discourse (كـ Group ActorType). يتم تعيين preferredUsername المربوط بواسطة المسؤول عند تمكين الاتحاد ويتم تخزينه في حقل مخصص للفئة. اسم الربط (المعروف أيضًا باسم اسم العرض) هو full_name للفئة.
المستخدمون هم Actors في المحتوى الذي تربطه فئة Actor. preferredUsername المربوط هو اسم مستخدم Discourse الخاص بالمستخدم وقت الربط. يتم تخزين preferredUsername للمستخدم في حقل مخصص للمستخدم في حالة قيام المستخدم بتغيير اسم مستخدم Discourse الخاص به. اسم الربط (المعروف أيضًا باسم اسم العرض) هو اسم Discourse الخاص بالمستخدم.
بشكل عام، سيتم ربط كائنات ActivityPub بكائنات Discourse المكافئة لها باستخدام حقول مخصصة عند الاقتضاء (مثل معرفات الكائنات أو الممثلين)، وجداول جديدة عند الاقتضاء (مثل صندوق الوارد وصندوق الصادر).
النشاط الأساسي لـ ActivityPub الذي سيتم تنفيذه هو Follow والأنشطة والنماذج المرتبطة المطلوبة لتنفيذه، أي صندوق الوارد وصندوق الصادر والإجراءات والمجموعات المطلوبة.
سيتم ربط منشورات Discourse كـ Notes لـ ActivityStream، مع المحتوى كـ HTML.
سيتم التعامل مع المصادقة باستخدام HTTP Signatures، انظر هنا و هنا. سيتم معالجة جميع اعتبارات الأمان الأخرى في مواصفات ActivityPub حسب الاقتضاء.
سيتم حماية نقاط نهاية الاتحاد حسب الاقتضاء للمواصفات، أي التأكد من استخدام redirect_to_login_if_required في وحدات التحكم، وإضافة guardian لإذن رؤية كل شخص للفئة.
أنا متحمس جدًا لرؤية هذه الأخبار! شكرًا لك! يسعدني أيضًا أنك تبدأ بتنفيذ أولي بسيط بدلاً من محاولة أكل الفيل المجازي (ليس إشارة مبهمة إلى Mastodon). أتردد في اقتراح إضافة أي شيء، ولكن بما أنك تطلب اقتراحات، فإن أحدها آمل أن يكون أقل جهدًا بشكل غير مهم:
ما رأيك في نشر مقتطفات من الردود اختياريًا أيضًا، باستخدام inReplyTo لربطها؟ أعتقد أن هذا سيبرز الحوار الذي يحدث على Discourse وسيكون أكثر جاذبية؛ إلى جانب “ناقش على منتدانا” أتوقع أن رؤية المحادثة من المرجح أن تجلب المزيد من الأشخاص.
تكمن المشكلة في دمج الردود في هذه المرحلة في أنه قد يؤدي إلى خلق توقعات بالمشاركة لن يتم تلبيتها حتى تحصل على دعم مناسب لها. من المهم الحفاظ على وضوح توقعات المستخدم هنا. بينما قد يفهم بعض المستخدمين القيود المفروضة على تلك الردود المدمجة، قد لا يفعل آخرون ذلك. المشكلة الأخرى هي محاولة تقليل عدد التحديات التقنية التي يجب معالجتها دفعة واحدة.
ومع ذلك، فقد نظرنا بالفعل في امتداد “موضوع كامل” لمواصفات “المنشور الأول فقط” التي تراها أعلاه. لقد شاركت بعض الملاحظات التقنية لذلك أدناه لإعطائك فكرة عن الاتجاه الذي يمكن أن يسير فيه هذا. أود التأكيد على أن امتداد “موضوع كامل” ليس جزءًا من المواصفات الأولية وهو مجرد احتمال في هذه المرحلة.
امتداد الموضوع الكامل
سيتم نشر الملاحظات الواردة كمواضيع جديدة أو ردود (باستخدام inReplyTo أو Replies).
سيتم تطبيق مرشحات الأمان والبريد العشوائي الخاصة بـ Discourse على الكائنات الواردة قدر الإمكان باستخدام Accept / Reject objects.
سيتم نسب منشورات الملاحظات إلى مستخدم مرحلي مرتبط بمعرف الفاعل عبر حقل مخصص. سيتطلب هذا اختلافًا غير قائم على البريد الإلكتروني لمفهوم المستخدم المرحلي حيث لن يكون لدى المستخدم بريد إلكتروني حقيقي (يمكن إنشاء عنصر نائب باستخدام معرّف الفاعل المدمج و preferredUsername).
سيكون من الممكن ربط مستخدمي ActivityPub المرحليين بمستخدمي Discourse القياسيين، ولكنه غير مدرج حاليًا في أي جزء من هذه المواصفات. هذه مشكلة “هوية مدمجة” والحلول المرتبطة بها.
لن تدعم المنشورات المدمجة الإشارات @ المدمجة، أو أي شيء آخر من هذا القبيل خارج مواصفات ActivityPub/Stream الأساسية. يمكن إضافة دعم لمثل هذه الميزات في إصدارات لاحقة، على سبيل المثال باستخدام Webfinger، بالاقتداء بـ Mastodon.
المفتاح في هذا الإصدار الأول هو التركيز على الحد الأدنى من التنفيذ القابل للتطبيق. بمجرد وضع هذا الأساس، سيكون دعم الدمج الكامل (أو الأوسع)، ربما على غرار ملاحظات “الموضوع الكامل” تلك، أكثر جدوى. أود التأكيد على أن اتجاه المكون الإضافي سيكون شيئًا تحدده CDCK. أي شيء أذكره هنا هو مجرد طرق محتملة يمكن بناء مواصفات الأساس عليها.
ملاحظة: أود أيضًا أن أذكر أنني تلقيت اتصالًا من دانييل كلابرز، المطور الأساسي لـ Flarum، في نوفمبر من العام الماضي، والذي أخبرني أنهم يعملون على امتداد ActivityPub. لا أعرف ما هو الوضع الحالي، ولكن قد يكون من الجيد أن تتعاون جميع المشاريع في مجال المنتديات لتحقيق أقصى قدر ممكن من التشغيل البيني في هذا المجال.
فيما يتعلق بهذا التشغيل البيني، أود أيضًا أن أشير إلى عملية اقتراح تحسينات Fediverse، و FEP على Codeberg:
هنا، على سبيل المثال، أكمل Lemmy مؤخرًا FEP لمجموعات ActivityPub. تجري المناقشات على SocialHub على:
(عملية FEP تكتسب زخماً مع نمو Fediverse وهي حاليًا أفضل مكان لتوحيد آليات البروتوكول)
شكراً @aschrijver، مفيد جداً! سأركز شخصياً على مواصفات تنفيذ الحد الأدنى من المنتج القابل للتطبيق الموضحة أعلاه، بالعمل عن كثب مع CDCK. بعبارة @mcdanlj الموجزة، من الضروري ألا يحاول هذا الجهد “ابتلاع الفيل”. نحن حريصون على سماع أي ملاحظات بناءة حول المواصفات، لا سيما على الجبهة التقنية.
أود أن أضيف مع ذلك أن عضوين آخرين من Pavilion@nmeyne (محنك في مجتمع SSI؛ خاصة الشهادات القابلة للتحقق)، و @merefield يعملان أيضاً في هذا المجال، وهما مهتمان ببعض الأسئلة الأوسع التي أثرتها.
على سبيل المثال، لتوضيح سوء الفهم الحقيقي الناتج عن وهم الدقة، تتمثل إحدى المشكلات التي واجهناها في منتديات Maker، حيث قمنا باستيراد العديد من مجتمعات Google+ عندما اختفى Google+، في أن الاستيراد كان عالي الدقة بما يكفي لدرجة أن الوافدين الجدد إلى الموقع لا يدركون أنهم يحاولون التفاعل مع مستخدمين آخرين لم يصلوا (بعد) إلى الموقع من Google+، ولذلك لدينا رد جاهز لإعلامهم بأن الشخص الذي يحاولون التحدث إليه ليس موجودًا للرد عليهم.
شكرًا لك على تقديم تفاصيل حول فكرة “توسيع الموضوع بأكمله”.
في حال تمت إضافة هذا لاحقًا… على أي حال، أنا حقًا أحب النهج الذي قدمه Pterotype لـ Wordpress، وهو أن أي تعليقات موحدة يتم ترحيلها مباشرة إلى الإشراف / الموافقة الجماعية قبل نشرها مرة أخرى في موضوع المنتدى الأصلي كـ رد.
في حالة المنتدى، قد تكون هذه مهمة مناسبة بشكل أفضل لأنواع TL4 / TL3 بدلاً من الموظفين.
شخصيًا، وجدت أن هذا يثبت أنه مفيد بشكل خاص في منع الردود غير المتعلقة بالموضوع / على غرار وسائل التواصل الاجتماعي من إرباك موضوع المناقشة الأصلي.
نعم، استخدام قائمة المراجعة هو شيء ناقشناه للمحتوى الوارد. كما لاحظت، هذا شيء يجب مراعاته إذا وصلنا إلى هناك (وليس في الإصدار الأول).
مجرد ملاحظة أن المسائل الإدارية المتعلقة بهذا العمل قد تم فرزها، لذلك سأبدأ العمل على المواصفات الأسبوع المقبل. نرحب بأي ملاحظات فنية إضافية أو ملاحظات حول المواصفات.
سيستغرق الأمر بضعة أشهر حتى تؤتي هذه الثمار، لذا تحلوا بالصبر.
إذا تم حذف منشور في Discourse، هل يمكن إرسال إجراء Delete إلى المتابعين؟
في منتديات Maker، لدينا ما يكفي من “نقاط جوجل” التي نحصل منها على الكثير من برامج الإعلانات المتسللة لتحسين محركات البحث. لدينا أذونات مريحة نسبيًا للمستخدمين الجدد لأن شكلاً شائعًا للاستخدام الجديد هو شخص محبط يبحث عن مساعدة ذات صلة بالموقع، وهذا يساعدنا على مساعدتهم بشكل أسرع. لكن هذا يعني أن برامج الإعلانات المتسللة تميل إلى نشر منشور سبام بسرعة نسبيًا، ثم يتم وضع علامة عليه كبريد عشوائي، وإزالته، ثم حذفه.
أود أن يتم حذف تلك المنشورات المدمجة ونشر الحذف عبر Delete حتى ننظف البريد العشوائي من ذاكرة التخزين المؤقت المدمجة. هل هذا ممكن ضمن النطاق؟
قد يكون من المفيد في هذه الحالة وجود تأخير في الاتحاد، لعدد معين من الساعات، للسماح بالتعامل مع البريد العشوائي قبل الاتحاد. (ربما حتى تطبيق التأخير فقط على المنشورات الأولى للمستخدمين الجدد نسبيًا؟)
إذا لم يكن الأمر يتطلب عملاً إضافياً كبيراً في البداية، فإن نشر تعديلات المشاركات كأنشطة تحديث سيكون ذا قيمة أيضاً. إذا كان أحد تلك الأشياء التي يمكن المساهمة بها بعد الحد الأدنى من المنتج القابل للتطبيق (MVP)، فإن التصميم الذي يستوعب إضافتها لاحقاً بشكل معقول سيكون رائعاً.
للعلم، سأضبط التأخير على مستوى منخفض في نسختي/نسخي. لن أخطط لاستخدامه لتجنب نشر رسائل البريد العشوائي، لأنه من المحتمل جداً أن تكون إشارة تجلب مشرفاً من موجز الـ fediverse الخاص بهم إلى Discourse الخاص بنا لاتخاذ إجراء. لدي chat_integration_delay_seconds مضبوطة على 20 لتعديلات الأخطاء المطبعية السريعة، وأتوقع أن أفعل شيئاً مشابهاً هنا. على الأقل، يضع هذا الإعداد سابقة لمثل هذا التأخير.
