نعم ولكن هذا سيكون مكونًا إضافيًا مكلفًا ومكلفًا.
إعجاب واحد (1)
هل يمكنني باستخدام SSO أو LDAP السماح بتسجيل الدخول ذهابًا وإيابًا دون الحاجة إلى نقل الجميع إلى تسجيل دخول نطاق واحد فقط؟
على سبيل المثال، لدي منتديات أ، ب، ج. أود أن يتمكن أعضاء المنتدى أ من تسجيل الدخول والنشر باستخدام بيانات اعتماد المنتدى أ الخاصة بهم إلى المنتديين ب وج. وينطبق الشيء نفسه على الأعضاء المسجلين في ب وج.
أعتقد أن هذا المنشور والمشاركات التالية يجب أن تذهب إلى موضوع خاص بها لأنها تتعلق بمجموعة فرعية من الميزات التي تمت مناقشتها هنا.
إعجاب واحد (1)
Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) - Integrations - Discourse Meta قد يكون مفيدًا لك 
إعجاب واحد (1)
من الناحية النظرية، أفترض أن هناك احتمالًا آخر بخلاف إنشاء إضافة Discourse تعمل كخادم لبروتوكول النشاط الفيدرالي (ActivityPub Federation Protocol)، وهو إعداد حسابات على خادم ActivityPub منفصل يدعم بروتوكول واجهة برمجة تطبيقات العميل (Social API) للعميل، وجعل إضافة Discourse تتحدث بروتوكول العميل إلى هذا الخادم، بدلاً من أن تكون خادم ActivityPub. قد يكون لهذا فائدة في التكامل الأقرب مع عقد ActivityPub الحالية. لكنني لا أعتقد أنه أسهل في التنفيذ من بروتوكول الخادم، وسيتطلب الأمر الكثير من العمل اليدوي للإعداد لمشغل المنتدى مقارنة بكونه خادم بروتوكول فيدرالي.
في فكرتي لما يجب تنفيذه، للسماح بإمكانية تفاعل المستخدمين، يجب أن تكون هناك طريقة للتمييز بين ممثلي مستخدمي Discourse (discourse-user-actors) وممثلي النظام في Discourse (discourse-system-actors) (مثل الفئات). يمكنني أن أتخيل أن @#slug@discourse.example.org سيكون ممثل فئة، مما يترك مجالًا للإضافة اللاحقة لممثلي المستخدمين @username@discourse.example.org. ولكن نظرًا لانتشار علامات التصنيف (hashtags)، قد لا يعمل هذا ببساطة في الممارسة العملية.
سيكون من الأسهل التركيز ببساطة على النقاط 1-3 على أساس أن النقاط 4-5 تقترب من محاولة تحويل Discourse إلى خادم ActivityPub للأغراض العامة، وهو بالتأكيد ليس الهدف.
إعجابَين (2)
يستخدم Mastodon التعبيرات النمطية التالية للتحقق:
USERNAME_RE = /[a-z0-9_]+([a-z0-9_\\.-]+[a-z0-9_]+)?/i
MENTION_RE = /(?<=\^|[^\\/[:word:]])@((#{USERNAME_RE})(?:@[[:word:]\\.\\-]+[[:word:]]+)?)/i
على حد علمي، يتم تطبيق USERNAME_RE على المستخدمين البعيدين، لذلك ليس من الواضح لي كيف يمكن أن يكون لدى مستخدمي Discourse والفئات في مساحات أسماء منفصلة بهذه الطريقة. كما أنه يستبعد شرائح الفئات الفرعية العادية. @parentcategory:subcategory@discourse.example.org لن تعمل مع هذا التعبير النمطي أيضًا.
أعتقد أنه يمكن أن يكون هناك نطاق فرعي اختياري @username@users.discourse.example.org ولكن هذا سيتطلب المزيد من إعدادات SSL و DNS ومن المحتمل أن يتم تكوينه بشكل خاطئ كثيرًا. ربما لا يستحق الأمر الذهاب إلى هناك.
إعجاب واحد (1)
ربما يكون من المنطقي عدم إنشاء اتحاد مع منصات أخرى، ولكن إنشاء اتحاد بين جميع مثيلات discourse، نظرًا لأن عدد مثيلات discourse كبير جدًا
إعجابَين (2)
هناك إمكانات هائلة هنا، بالتأكيد. الاحتمالات والجدوى تستدعي دراسة متأنية ورصينة.
قد يكون هذا مجال شاندو… (اقرأ منشور جيف أعلاه واتبع الرابط فيه.) هذا التكامل الواسع جدًا ربما يكون غير مرغوب فيه لمعظم مديري/مشغلي مثيلات Discourse. إجراء مسح رسمي للمديرين والمشغلين أمر ضروري (على عكس “مسح حسب مستوى حركة المرور” في منتديات المناقشة).
هذا يبدو وكأنه دعوة لاختراقات أمنية لأنه يعرض “مفاتيح المملكة” لأي شخص يمكنه اختراق بيانات اعتماد المستخدم لأي من المواقع الموحدة. على الأقل، سيتعين إيقاف تشغيل هذه الميزات افتراضيًا أو تحميلها صراحةً كمكونات إضافية - مع تمكين معظم الميزات الأمنية وتأمينها. علمنا Zoom هذا الدرس من خلال ترك منصته مفتوحة وسهلة الاستخدام عن حق (لاكتساب المستخدمين بسرعة وتنميتهم عند البدء) ولكن بعد ذلك اضطر إلى تأمينها بسرعة بمجرد أن وجد الأوغاد الباب الأمامي مفتوحًا.
ومع ذلك، فإن اتحادًا مصغرًا للمواقع سيكون دفعة لتنفيذ Discourse. إذا كان بإمكاني إنشاء دائرة من المواقع لبلديتي توحد نفس مجموعة المستخدمين (مواطني المقاطعة/المدينة على سبيل المثال)، فإن هذا سيضع الناس في تواصل ويمكن أن يؤدي إلى بعض النتائج الإيجابية في الحكم المحلي وحياة المجتمع. ينطبق هذا المبدأ نفسه أيضًا على أي عمل تجاري كبير بما يكفي لتبرير التكلفة الإضافية لإدارة مثيلات Discourse متعددة بحيث يمكن لكل قسم الحصول على حاوية Discourse الخاصة به مع سهولة التنقل إلى الأقسام الأخرى. *هذا سيكون تجسيدًا لـ meta.discourse. *
يحتاج Jeff و Sam و Co. [@codinghorror @sam] و/أو لجنة التوجيه الخاصة بهم أولاً إلى تحديد ما إذا كان Discourse منصة اجتماعية أم منصة مؤسسية. تصويتي هو للمؤسسات لأنني أرى أكبر إمكانات هناك لكلا جانبي هذا الانقسام. ستنتج المؤسسات أكبر عائد مالي وفائدة اجتماعية فورية من خلال تحسين قدرة الشركات على دعم الموظفين (اعتني بالعمل التجاري جيدًا ويمكن للعمل التجاري أن يعتني بك جيدًا). يمكن بعد ذلك دعم بعض تلك الأموال التجارية من مؤسسة social.discourse.org. من المحتمل جدًا أيضًا أن تنتقل الميزات المفيدة للمؤسسة بشكل جيد إلى المجال الاجتماعي. هذان العاملان يجعلان فوزًا شاملاً للجميع.
المجالان بحاجة إلى أن يكونا منفصلين، على الرغم من أنهما مختلفان جدًا. وستحتاج الميزات “الجميلة” بالضرورة إلى تفضيل أي إصدار هو حالة الاستخدام الأساسية.
لحسن الحظ، تتدفق الفوائد في كلا الاتجاهين حيث أن أي شخص مهتم بـ social.discourse.org يحصل على مكافأته من الجوانب الاجتماعية لبناء المجتمع والقدرة على متابعة الأنشطة المتعلقة بالمجتمع، وبالتالي سيعمل - وغالبًا ما يعمل بجد - لهذه المكافآت غير المالية. سيؤدي هذا العمل في social.discourse.org حتمًا إلى تطوير وميزات مفيدة في سياق المؤسسات وبالتالي إعادة القيمة إلى Enterprise Discourse Incorporated مقابل الدعم غير الربحي لمؤسسة Social Discourse Foundation. المزيد من الفوز للجميع.
لاحظ أنه لا توجد علامة تعجب واحدة أعلاه. هذه مجرد حقائق وبيانات عن النتائج المحتملة. واقعية جدًا.
لقد كنت أبحث عن منصة GroupWare مناسبة لشركاتي لعدة سنوات. ألهم Slack آمالًا كبيرة لفترة وجيزة حيث تم تطويره للاستخدام الداخلي للأعمال (وله قصة أصل مثيرة للاهتمام للغاية) ولكنه لم يمر حتى من الفحص الأولي. أنا معجب جدًا بـ Discourse ومتفائل بشأنه.
إعجاب واحد (1)
هذه هي النقطة الكاملة لهذا الموضوع، أي بين مثيلات Discourse.
لقد تم ذكره في OP:
إعجابَين (2)
حسنًا، و
و
اتحاد مصغر للمواقع سيكون دفعة
كلها في صلب الموضوع، أليس كذلك؟ 
ليس بالضرورة شرطًا مسبقًا. هناك نظام المكونات الإضافية (plugins) الذي يجب أخذه في الاعتبار.
غالبًا ما يتم تطوير الميزات الكبيرة بشكل كبير كمكونات إضافية أو حتى مكونات قائمة المواضيع (Theme Components) (حيثما أمكن) لا تتضمن مثل هذه التكاليف الإدارية ولا التخطيط المركزي.
هذا جزء من جمال نظام Discourse البيئي.
على سبيل المثال، قام Pavilion بإنشاء Locations و Topic List Previews و Multilingual و Follow و Layouts و Custom Wizard (على سبيل المثال لا الحصر) كل ذلك دون استشارة CDCK. ومن هنا، جزئيًا، مشاركتنا في هذه المناقشة.
7 إعجابات
بارك الله في مطوري الإضافات لدينا! إنهم يقدمون بسخاء أمثلة لإثبات المفهوم يمكن اختبارها ميدانيًا والنظر في إدراجها في المنتج الأساسي. إضافتك متعددة اللغات مثال ممتاز!
في python.org، يلعب مطورو المكتبات هذا الدور الذين ينشئون أحيانًا وظائف “يجب أن تكون لديك” والتي يتم قبولها للإدراج في حزمة Python الأساسية أو مكتبة التوزيع القياسية.
إعجابَين (2)
لقد كنت أدعو ديسكورس لإضافة دعم الاتحاد في مجموعة من المواضيع في هذا المنتدى، مثل هنا. مع انتشار الفيديفيرس الآن، وإضافة تمبلر وربما فليكر وما شابه ذلك لدعم الاتحاد، فإن السؤال هو ما إذا كان ديسكورس لديه المزيد من الاهتمام بإضافة الدعم أيضًا.
لقد تم الاتصال بي من قبل المطور الرئيسي لـ Flarum لتقديم المشورة بشأن تنفيذ AP وقدمت بعض الروابط، من بينها الرابط المذكور للتو.
ملاحظة: في منتدى SocialHub، مجتمع المطورين للفيديفيرس، نبحث منذ فترة طويلة عن كيفية أن نكون جزءًا من الفيديفيرس حيث أظهرت المنتديات المنفصلة أنها تشكل حاجزًا كبيرًا لمعظم الناس للمشاركة.
7 إعجابات
لقد أصبحت مهتمًا قليلاً بـ Mastodon مؤخرًا (بما يكفي لشراء اسم نطاق، ولكن ليس لتثبيت Mastodon فعليًا)، لذلك قرأت القليل عن مصادقة Discourse مع Mastodon.
وجدت بعض المشاركات تشير إلى أن الأمر أصعب مما كان يعتقده الناس. على ما أذكر، بدا الأمر وكأن منحة قد عُرضت لتطوير إضافة ولكن يبدو أنها فشلت. تخميني الجامح هو أنها مشكلة بقيمة 10000 دولار؛ إذا كنت على حق، فهذا هو نوع الدفاع الذي ستحتاجه.
تحرير: لكنني كنت أخلط بين المصادقة والاتحاد.
إعجاب واحد (1)
اهتمامي العام هنا هو أن الأفكار ضخمة بشكل عام، ومن الصعب جدًا تقسيمها إلى أجزاء صغيرة.
أجد فكرة الاتحاد مثيرة للاهتمام. يمكن أن يكون التنفيذ الملموس المحتمل كالتالي:
- السماح لمسؤولي Discourse بدمج فئة.
- يمكن للمستخدمين على mastodon متابعتها بعد ذلك، على سبيل المثال متابعة:
announcements@meta.discourse.org - عند إنشاء مواضيع إعلانات جديدة، يتم دمج منشور جديد مع مقتطفات ورابط للمنشور الأصلي.
- عندما يستجيب المستخدمون على discourse، يتم دمج الردود الجديدة وتنسب (كردود على الموضوع الأصلي).
- عندما يرد شخص ما على fediverse، يتم إنشاء منشور “ظلي” في الموضوع المنسوب إلى الناشر على mastodon.
شيء كهذا على الأقل صغير بما يكفي ليتناسب بشكل صحيح في ذهني.
13 إعجابًا
تكمن المشكلة في ActivityPub في أنه معيار مفتوح سهل القراءة، ولكن تنفيذه لا يجعلك “جزءًا من Fediverse” بعد. هناك مجموعة من الأشياء الأخرى التي يجب تنفيذها، و - بالنسبة لمجال منتديات المناقشة - مفردات ActivityPub مخصصة لتبادل الرسائل. هناك مشاريع أخرى “للبدء بها” وبعض المكتبات التي يمكن تبنيها، ولكن سيكون هناك بالفعل بعض التطوير الهام المطلوب.
من حيث الدعوة.. أشعر شخصيًا أنه عند القيام به بشكل جيد، يمكن لدعم AP إضافة نقاط بيع فريدة للمنتج. عدم الاضطرار إلى التسجيل في كل منتدى هو أمر واحد.. إنه حاجز بالنسبة لي أيضًا. هل أقوم بالتسجيل في Discourse آخر، فقط لهذه المشاركة الواحدة التي أرغب في إضافتها؟
لكن الاتحاد قد يجلب قيمة أكبر بكثير. في السيناريو الحلم الخاص بي، سأقوم بتثبيت Discourse شخصي أو التسجيل في مثيل، والذي - مثل Mastodon - سيكون فارغًا تمامًا في البداية. ثم سأقوم بملئه بهيكل مجتمع بنفسي، بناءً على احتياجاتي واهتماماتي. اختر هذه المجموعة ذات الطابع الخاص، وأضفها تحت هذه الفئة، وأضف مجموعة أخرى.
تحديث: تم النشر المشترك مع @sam .. كان هذا ردًا على @pfaffman
5 إعجابات
نعم، ستكون تلك بداية رائعة. مجمّع روابط Lemmy يعمل بشكل مشابه، حيث يقدم اتحادًا للمجتمعات. لاحظ - على الرغم من أن التفاعل على نطاق أوسع سيكون إضافة لطيفة جدًا - يمكن تنفيذ الاتحاد بين مثيلات Discourse / المستأجرين فقط في البداية.
ليس كل شيء يناسب Mastodon.. إنه تطبيق تدوين مصغر، لا يدعم ترميز Markdown (على الرغم من أن تطبيقات Fedi الأخرى تفعل ذلك).
حاليًا، يجري العمل على دعم إضافي للمجموعات المتحدّة. Lemmy مثال. Bonfire سيضيف دوائر تشبه Google+، إلخ.
3 إعجابات
نعم! هذه هي سير العمل التي أود رؤيتها. والترويج لها. 
سيكون طول المقتطف قابلاً للتكوين بشكل ملائم، حيث يعني 0 المقالة بأكملها بدلاً من مقتطف. لاحظ أن حد الـ 500 حرف الخاص بـ Mastodon اعتباطي، ولا علاقة له بـ Fediverse أو ActivityPub أو ActivityStream. عقد Mastodon التي أديرها حاليًا لديها حدود 2000 حرف، وحد social.kernel.org هو 31337 حرفًا. حتى Mastodon الافتراضي بحد الـ 500 حرف الخاص به لكتابة المنشورات لا يزال يعرض منشورات أطول بشكل جيد.
الصعوبة الطفيفة التي أراها هي أن مساحات أسماء المستخدم والفئة منفصلة في Discourse ولكنها “فاعل” واحد في ActivityPub، وعلى الأقل لدى Mastodon تعبير عادي مقيد إلى حد ما للتعرف على الفاعلين. بالنظر إلى @announcements@meta.discourse.org لفئة #announcements، سيتم نشر هذا التعليق كمنشور بواسطة @mcdanlj@meta.discourse.org
بشكل افتراضي، كمسؤول Discourse، أود استخدام اسم الفئة كاسم الفاعل. أفترض أنه إذا اختار المسؤول، عند إعداد الاتحاد لفئة ما، اسم الفاعل، والذي سيكون افتراضيًا هو اسم الفئة، وسيكون (مثل اسم مجموعة) فريدًا فيما يتعلق بأسماء مستخدمي Discourse.
(بالمناسبة، كنت قلقًا بشأن التعبير العادي لـ Mastodon للتعرف على أسماء الفاعلين، لكنني أعتقد أنه يُستخدم فقط للإشارة إلى الأشخاص، وهو أمر غير مفيد هنا على أي حال. لذلك قد يكون من الممكن حتى أن يكون لدينا، على سبيل المثال، #documentation:admins ممثلة بـ @documentation:admins@meta.discourse.org على الرغم من أنني بالتأكيد أرغب في اختبار ذلك مع العديد من أنظمة التدوين المصغر الرئيسية، بما في ذلك بالتأكيد Mastodon و Pleroma.)
3 إعجابات
أعتقد أن ما سيبدو عليه الأمر بالفعل من منظور مستخدم Mastodon أو Pleroma، على سبيل المثال، هو أن @announcements@meta.discourse.org سيقوم بتعزيز / إعادة نشر منشور موضوع بواسطة، على سبيل المثال، @sam@meta.discourse.org ثم يقوم أيضًا بتعزيز/إعادة نشر منشور تعليق بواسطة، على سبيل المثال، @mcdanlj@meta.discourse.org كتعليق على المنشور الأصلي — لا المنشور الأصلي ولا التعليق يتم إنشاؤهما فعليًا بواسطة الفئة، بل يتم إنشاؤهما بواسطة شخص، في فئة.
قد يكون من الممكن أن يقوم المكون الإضافي في البداية بتطبيق webfinger فقط لممثلي الفئات (لكي تتمكن من متابعتهم)، ولكن قد يكون من المنطقي في النهاية تطبيقه للمستخدمين الأفراد أيضًا. قد أرغب بشكل معقول، على Mastodon، في متابعة @sam@meta.discourse.org لرؤية منشوراته وتعليقاته.
إعجابَين (2)
السؤال: ما هو الوضع الحالي لهذا النقاش والخطط للتنفيذ المحتمل؟ هل تحتاج إلى أي دعم للاختبار على سبيل المثال؟ أم أن هذا السؤال “مبكر جدًا” 