ملاحظة فقط بأننا حاليًا في هذه الخطوة
5 إعجابات
هذا يبدو رائعًا!
لقد قمت مؤخرًا بإعداد خادم Discourse لتعاونية CoSocial الخاصة بنا، والذي يدير خادم Mastodon. انتهى بي الأمر بإعداد إضافة OAuth2 بحيث نقبل فقط تسجيلات الدخول من خادم Mastodon الخاص بنا → https://members.cosocial.ca (تثبيت جديد بسيط جدًا، فقط “إثبات OAuth”).
سؤالي / طلب الميزة هو أن يكون من الممكن دمج / دمج حسابات Mastodon في حسابات Discourse، بحيث عندما يرد المستخدمون على Mastodon، يمكن ربطهم / امتلاكهم بواسطة حساب Discourse المرتبط.
كيف لا يفعل Lemmy هذا
لقد وثقت كيف لا يفعل Lemmy هذا - يمكنك التفاعل عبر Mastodon، ويتم إنشاء حساب في Lemmy لحساب Mastodon هذا، ولكن لا يمكنك فعليًا تسجيل الدخول واستخدام الميزات من الدرجة الأولى لـ Lemmy باستخدام حساب Mastodon الخاص بك.
4 إعجابات
هذا على جدول الأعمال…
وهو بالفعل في قائمة الانتظار للمراجعة
3 إعجابات
عظيم. يبدو أن مستخدمي إضافة Discourse OAuth الخاصة بي سيحتاجون إلى “تأكيد مرة أخرى” للتفاعل مع إضافة AP هذه.
أعتقد أن هذا جيد تمامًا في هذه المرحلة، فقط أريد الإشارة إلى خادم OAuth كزاوية أخرى، طالما أنه لا يتعارض. الشيء “الجميل أن يكون لديك” هو “إذا كان OAuth مع خادم Mastodon، فقم بربط هوية ممثل AP تلقائيًا”. هذا مستقبلي تمامًا وفريد من نوعه لهذا النوع من الإعداد!
(وأعتذر عن عدم فتح الصفحة للنظر في هذا الجزء! رائع!)
إعجاب واحد (1)
تم الآن دمج طلب السحب الذي يضيف هذه المجموعة من الميزات.
كما أشار أنجوس أعلاه، فإن الخطوة التالية هي التحقق من المستخدم عبر رموز OAuth.
إعجابَين (2)
يبدو أن المشاكل التي رأيتها سابقًا مع ظهور علامات Markdown الخام تؤثر على meta أيضًا. أنا أتابع @feature@meta.discourse.org وقبل ساعات قليلة، تم إنشاء هذه المشاركة التي تم تنسيقها من هذا الممثل:
ظهرت لي في Mastodon بشكل خاطئ هكذا:
في Elk، تبدو هكذا؛ أفضل قليلاً:
لقد بدأت للتو في متابعة @feature@meta.discourse.org في حساب Mastodon الخاص بي الآن لاختبار ذلك، ولكن بالطبع فات الأوان لرؤية هذه المشاركة المحددة هناك. 
لذلك، لم تكن علامات Markdown المضمنة التي رأيتها سابقًا من تثبيتي الخاص قاعدة بيانات سيئة، أو إذا كانت كذلك، فقد كانت مشكلة قاعدة بيانات مشتركة مع meta وبالتالي ربما لم تكن مرتبطة باختباري.
إعجابَين (2)
نعم، يمكنني تكرار ذلك، أرى مخرجات مماثلة في مثيل ماستودون وفي Ivory (تطبيق iOS).
إعجابَين (2)
لست متأكدًا مما إذا كان هذا يعمل بشكل صحيح. المكون الإضافي ممكّن وقد أنشأت موضوعًا في فئة تم تمكين ActivityPub فيها، لكنني لا أرى الشارة بجوار المنشورات (وبدا أن محاولتي لمتابعة ممثل الفئة الخاص بـ ActivityPub فشلت، نظرًا لأنها تتصرف كما لو كان الخادم سيوافق يدويًا على المتابعات من قبل مستخدم).
لاحظت للتو أن نفس المشكلة حدثت مع Feature على Meta.
إعجاب واحد (1)
سيكون من الرائع فهم الهدف النهائي للقيود، دون القلق بشأن الحالة الوسيطة.
على سبيل المثال، أعتقد أنني رأيت إشارة في طلب سحب (PR) تفيد بأنه سيتم حظر تغيير مالكي المشاركات إذا تم تمكين المكون الإضافي. بصفتي مسؤولاً، يجب علي استخدام هذه الميزة في مناسبات نادرة (على سبيل المثال، عند تغيير مشرف الفئة، أجعل مشرف الفئة الأساسي الجديد مالك الفئة للمنشور المثبت). آمل أن يؤدي هذا في النهاية إلى حذف وإعادة نشر، أو حتى تجاهله ببساطة، بدلاً من حظر تغيير الملكية.
أتساءل أيضًا عن نقل المشاركات بين الفئات. يجب علي القيام بذلك بشكل متكرر، خاصة عندما ينشر المستخدمون الجدد في الفئة الخاطئة. أتوقع بشكل ساذج أن يؤدي ذلك إلى قيام أحد جهات الفئة بإزالة تعزيزها، وقيام جهة الفئة الجديدة بإضافة تعزيز، ولكن ليس حذف المنشور الأساسي، بحيث إذا رأى شخص آخر منشورًا وعززه، فلن يختفي تعزيزه بمجرد اختفاء تعزيز جهة الفئة.
بشكل عام، سيكون من المفيد حقًا معرفة ما تتوقع أن يتم حظره عند إضافة هذا المكون الإضافي، بعد اكتمال تطوير الميزات المحددة حاليًا، بغض النظر عن القيود المعمول بها حاليًا.
إعجاب واحد (1)
@hello-smile6 أرى نفس الشيء مع التحديث الذي تم اليوم للمكون الإضافي:
لا أرى إعدادات له، لذا أفترض أنه خطأ.
إعجابَين (2)
شكرًا على التقرير الإضافي. أنا أبحث في هذا الأمر.
شكرًا على التقرير، نحن نبحث في هذا الأمر.
أنا أقدر وجهة نظرك، ولكن
-
بينما يتم تطوير المكون الإضافي بنشاط، فإن محاولة شرح الأشياء بهذه الطريقة ستكون غير منتجة لأن الشرح قد يتغير.
-
هناك العديد من السيناريوهات والحالات الطرفية المختلفة التي يتعامل معها المكون الإضافي بالفعل، وبالنسبة لي لشرح كل منها سرديًا في هذه المرحلة سيستغرق وقتًا طويلاً (أي، القيام بهذا المنشور الطويل بشكل فعال عدة مرات). هناك بالفعل أكثر من 400 مواصفات مختلفة للمكون الإضافي.
-
ومع ذلك، غالبًا ما يتم شرح القيود سرديًا في التعليقات على طلبات السحب (PRs) والالتزامات (commits)، والتي أعتقد أنك تقرأها بالفعل.
تمت مناقشة هذا بعمق في طلب السحب (PR)
لقد قيدت تغيير مالكي المشاركات وإنشاء مشاركات ويكي، حتى للمسؤولين، في مواضيع AP. هذا لأن المشاركات البعيدة لـ AP يجب أن تحتفظ بالدقة مع الأصل وقد يكسر كلا الإجراءين تلك الدقة.
قد تكون هناك طريقة لجعل الاتحاد يعمل مع كل من الويكي وتغيير مالكي المشاركات، ومع ذلك أقترح أن نضيف ذلك كـ “ميزة” في طلب سحب (PR) مستقبلي لأنه سيتعين عليه مضاعفة أو تغيير الممثل المرتبط بكائن تم توزيعه عبر منصات متعددة. أعتقد أننا لن نتمكن أبدًا من السماح بتغيير مالكي المشاركات للمشاركات المستوردة لـ AP (ملاحظات)، حيث أن الارتباط بين الممثل والكائن لا تملكه Discourse، بل المكان الذي تم فيه تأليف المحتوى. لإعطاء تشبيه توضيحي، في هذا السياق، يعتبر حذف مشاركة مرتبطة بملاحظة مستوردة أقل من “حذف” بحد ذاته، بقدر ما هو اختيار عدم إظهار ملاحظة.
هناك العديد من السيناريوهات المختلفة التي تتضمن نقل المشاركات. سأتعامل مع السيناريو المحدد الذي ذكرته الآن، وهو نقل مشاركة بين فئتين تم تمكين ActivityPub لهما.
أنت تفترض أن المرة الوحيدة التي يتم فيها نقل مشاركة بين الفئات هي عندما يتم نشر المشاركة في الأصل في الفئة الخاطئة، ويتم النقل بعد وقت قصير من إنشاء المشاركة. ماذا لو، بعد 4 أشهر من إنشاء مشاركة، قمت بنقل تلك المشاركة إلى فئة أخرى لأنك تريد تجميع مجموعة معينة من المشاركات في موضوع جديد في فئة مختلفة؟ هل سيكون من المنطقي إرسال “تراجع” للتعزيز الأصلي في هذا السيناريو؟
يعتمد هذا على ما إذا كنا نتحدث عن تكوين المشاركة الأولى أو تكوين الموضوع الكامل. بالنسبة للأول، سنضيف زرًا للمشاركة الأولى ليتم نشره يدويًا للتعامل مع سيناريو نقل الفئة بشكل خاص. بالنسبة للأخير، قد يكون إضافة تعزيز تلقائيًا منطقيًا، سأفكر في ذلك أكثر.
أنا أفهم وجهة نظرك، ومع ذلك لقد شاركت بالفعل قدرًا كبيرًا من التفاصيل حول الحالة النهائية في مواصفات المرحلة الثانية أعلاه. بخلاف تلك المواصفات، وبوضع هذا بأكثر الطرق لطفًا، هناك عدد كبير جدًا من حالات الاستخدام والسيناريوهات التي لا يمكنني مناقشتها معك بالتفصيل، ثم مع فريق Discourse.org أيضًا، أثناء العمل عليها 
سأقوم بتحديث المنشور الأصلي (OP) بنظرة عامة على السلوك المتوقع بمجرد اكتمال المرحلة الثانية.
إعجاب واحد (1)
لا يمكنني إعادة إنتاج هذه المشكلة. لقد قمت للتو بمتابعة feature@meta.discourse.org من حساب Mastodon تجريبي، ولم أر أي خطأ (في Mastodon أو Discourse).
إعجاب واحد (1)
قد يكون الأمر متعلقًا بالنسخة التي اتبعته منها، هل تقوم هذه النسخة بأي شيء غير عادي؟
يا إلهي، في محاولتي لطرح سؤال واضح، بدا الأمر وكأنني أطلب الكثير من العمل. أعتذر عن سوء التواصل. أقدر الرد المدروس.
هذا ما كنت أقصد أن أطلبه، وليس تحديثات مفصلة مستمرة في هذا الموضوع. كان قصدي بـ “بعد” في “بعد اكتمال تطوير الميزة المحددة حاليًا” هو تطبيقها على وقت تكون فيه التوضيح ذا قيمة، وليس القصد أن أطلب منك الآن وصف الحالة المستقبلية. كان سؤالي بصيغة غامضة. آسف لذلك!
هذا ما أردت حقًا أن أفهمه: هل الهدف النهائي، بشكل عام، هو قصر Discourse على ما يدعمه ActivityPub الأصلي فقط، أم هو الاتحاد من تجربة Discourse أصلية غير مقيدة إلى fediverse على أساس أفضل جهد؟ خبرتي السابقة مع تكاملات Discourse دفعتني إلى توقع أفضل جهد؛ الآن أفهم أن خطتكم هي السعي لتحقيق الدقة بدلاً من ذلك، بتكلفة وظائف Discourse، وليس فقط كإجراء مؤقت أثناء التطوير.
أنا لا أفترض ذلك. لماذا سيكون هناك فرق لمدة أربعة أشهر هنا؟ إنه في فئة موحدة حديثًا، فلماذا لا يتسبب ذلك في تعزيز الفئة الموحدة له؟ أنا، على الأقل، كنت أتوقع بشكل ساذج أن يحدث ذلك. غالبًا ما أرى أشخاصًا يعززون منشورات عمرها أشهر عديدة، لذلك لا أعرف سببًا معينًا يجعل هذا مختلفًا.
ونعم، أعتقد أنه سيكون من المنطقي إرسال “تراجع” للتعزيز الأصلي. هذا يبدو شائعًا. (في الواقع، يبدو أن التراجع عن تعزيز ثم تعزيز جديد هو آلية شائعة لـ “دفع” المحتوى؛ غير مرتبط بهذا الغرض ولكنه يوضح أن التراجع عن التعزيز يستخدم بشكل شائع وبالتالي لا ينبغي أن يسبب مشاكل لتطبيقات ActivityPub الأخرى.)
أرى نفس الشيء الآن بالنسبة لـ feature@meta.discourse.org من mastodon.cloud والتي أعتقد أنها تعمل بنسخة Mastodon عادية.
إعجاب واحد (1)
شخصيًا، لا أفكر في الأمر بأي من الطريقتين. سيحدد Discourse.org الأجندة العامة هنا، ولكن بشكل عام يتم اتخاذ القرارات على أساس كيفية عمل الأشياء، وما هو عملي. إذا كانت هناك طريقة معقولة ومستدامة للسماح بتغييرات في المؤلف على جميع المشاركات، بغض النظر عن مصدرها، فهذا رائع.
بالتركيز فقط على إلغاء التعزيز الأصلي، لا يبدو أن هذا الإلغاء المحدد يخدم غرضًا؟ إنه أيضًا مفاجئ بعض الشيء في بعض السيناريوهات كما حاول مثالي أن يوضح. قد لا يكون الهدف من نقل الفئة هو عكس (إلغاء) “قابلية الاكتشاف” الأصلية للمحتوى. قد يكون لتغيير تنظيم المحتوى لاحقًا لسبب مختلف.
بمعنى آخر، تطبيق عكس تلقائي للإعلان الأصلي عند تغيير الفئة في Discourse يعمل في بعض السيناريوهات، ولكنه لا يعمل في سيناريوهات أخرى. وحتى في السيناريوهات التي يبدو فيها منطقيًا أكثر، فإن الإعلان الأصلي لا يسبب أي ضرر حقًا. لذا، بالسعي لتحقيق مبادئ الضرر الأقل والمفاجأة الأقل، يبدو أن ترك الإعلان الأصلي في مكانه هو الأكثر منطقية. آسف إذا كنت أفتقد شيئًا ما.
للتفكير في الأمر من زاوية أخرى، لا أعتقد أنه من الصحيح التفكير في أنشطة الإعلان الخاصة بـ “ممثل الفئة” (Category Actor) كمرادفة للدور التصنيفي للفئات نفسها. الإعلان هو الطريقة التي يشارك بها ممثل الفئة المحتوى مع متابعيه، ولكنه ليس تصنيفًا بحد ذاته. إنها طريقة لاكتشاف المحتوى داخل الـ Fediverse. لا أعتقد أن هناك حاجة إلى علاقة 1:1 بين الفئات وأنشطة الإعلان لممثلي الفئات.
3 إعجابات
آه. إذن فهذه مسألة للفريق حقًا. 
هذا منطقي أيضًا. أتفق معك، لا توجد قيمة كبيرة في التراجع عن التعزيز.
إذن هي إشارة تُشغّل عند الحافة؛ هذا يعني “أن منشورًا قد دخل للتو إلى هذه الفئة، إما عن طريق كتابته أو نقله إلى الفئة”. هذا بسيط من الناحية المفاهيمية.
سأفكر بعد ذلك في تغيير تأليف المنشور بنفس الطريقة. سيكون الفاعل الجديد هو الذي ينشئ نشاطًا جديدًا لمنشور المؤلف الجديد، ولا توجد حاجة خاصة للقيام بأي شيء بالنشاط القديم الذي تم إجراؤه تحت المؤلف القديم، لأن المؤلف القديم لن يكتب أي تعديلات، ولا ينبغي أن يُنسب إليه الفضل في هذه التغييرات الجديدة. لم يحذفوا منشورهم فعليًا على Discourse، لذا فإن حذف نشاط المؤلف الأصلي لن يعكس بالضرورة حقيقة أساسية. ولكن ما تم نشره سابقًا بواسطة فاعل المؤلف القديم سيكون ما كتبوه، ولن يكون هناك سبب لحذف هذه المنشورات. وإذا قام شخص ما بالنقر على الرابط مرة أخرى إلى Discourse، فسيرى المحتوى الحالي والتأليف، مع (إذا كانت الأذونات كافية) عرض سجل التعديلات.
ينطبق نفس المنطق على الويكي. تظهر على Discourse تحت تأليف فردي ولكنها تسمح للآخرين بالكتابة. لا تُنسب التحديثات من قبل مؤلفين آخرين على نطاق واسع (ما لم يكن لديك إذن كافٍ لقراءة السجل). ليس من المهم حقًا ما إذا كان هذا الإسناد معروضًا بواسطة صورة رمزية في عرض الويب داخل Discourse أو فاعل activitypub مرتبط بنشاط؛ النتيجة النهائية هي إسناد يُقدم للقارئ البشري في نهاية إحدى خطوط أنابيب العرض أو أخرى.
إعجاب واحد (1)
همم، لست متأكدًا من موافقتي. ستكون النتيجة النهائية وجود ملاحظتين متطابقتين في Fediverse من تأليف فاعلين مختلفين، وكلاهما سيظل مرئيًا على منصات متعددة. بالنسبة لشخص جديد يأتي إلى هذا المحتوى لأول مرة، سيرى نفس المحتوى من تأليف أشخاص مختلفين. على العكس من ذلك، عندما تقوم بتغيير مؤلف في Discourse، فإنك تعيد كتابة التاريخ بشكل أساسي، وبالنسبة لشخص جديد يأتي إلى المحتوى لأول مرة، فإنك ترى فقط المؤلف الجديد. هناك فرق في ذلك، ألا تعتقد ذلك؟
لست متأكدًا من أنني أفهم تمامًا. هل تقصد أن جميع تعديلات منشور الويكي، من قبل أي مستخدم، يجب أن تُعامل على أنها أنشطة تحديث قياسية تُنسب إلى الفاعل الأصلي (أي الشخص الذي نشرها)؟
لاحظ أن هذا هو موضوع طلب السحب هذا، مصحوبًا بملاحظات توضيحية.
4 إعجابات