حسنًا، سيرى مستخدم Mastodon ذلك في سياق جدول زمني، وعادةً ما تكون الجداول الزمنية محدودة. على Mastodon، افتراضيًا، لا يتجاوز إجمالي الجدول الزمني 400 مشاركة. إذا كنت تنظر إلى الأصل، فأنت تنظر في Discourse على أي حال. لذا، بينما هذا صحيح نظريًا، لا أعتقد أنه سيسبب ارتباكًا فعليًا في الممارسة العملية. يجب أن تكون بالفعل متابعًا لرؤية المحتوى؛ يؤدي النقر على رابط إلى الأصل إلى نقلك إلى Discourse حيث يتم حل الارتباك.
ليس مثاليًا، ولكنه قد يكون الخيار “الأقل سوءًا”؟
أفترض، كبديل، أنه يمكنك نشر تعديل يوضح المشاركة على أنها تم استبدالها بنقل ملكية، يشبه إلى حد كبير إضافة رابط “ناقش هذا في منتدانا”؟
بالتأكيد، أنا لا أجادل بأنها ليست فرقًا، بل أقول فقط إنها تبدو فرقًا مقبولًا، مقارنةً بحظر ميزة مفيدة ومستخدمة في Discourse.
سيؤدي حذف الأصل إلى يتيم الخيوط في سياق المنصات الأخرى التي تقوم بالاتصال بها، نظرًا لأنه لا يمكنك تغيير الممثل المرتبط بنشاط في تعديل (حسب فهمي).
قد يكون البديل هو التوقف عن نشر التعديلات على الإطلاق إذا كان للمشاركة في Discourse مؤلف مختلف عما كانت عليه عند نشرها لأول مرة. ربما مع تحذير؟ “سيؤدي تغيير المالك إلى تعطيل الاتحاد لهذه المشاركة، هل تريد حقًا المتابعة؟”
نعم. هذا ما يبدو عليه الأمر في Discourse للمستخدم العادي، الذي قد لا يعرف أنه يمكنه النقر على أيقونة القلم والانتقال عبر التغييرات للمراجعة، أو ليس لديه الأذونات. هذه متأصلة في الاستخدام العادي لـ Discourse، كما أرى:
جعل المشاركة ويكيًا يعني أنك تقبل ظهور تعديلات الآخرين في الاستخدام العادي باسمك الخاص
حتى لو لم تكن ويكيًا، يمكن للمستخدمين ذوي الامتيازات الكافية تعديل مشاركتك في Discourse، اعتمادًا على تكوين الموقع
من وجهة نظري، هذا أقرب ما يكون إلى ما يعادله، نظرًا للاختلافات في النموذج الأساسي.
كما أرى، فإن “النقر لرؤية المشاركة على الموقع الأصلي” يعرض بالفعل محتوى مختلفًا بين التطبيقات التي تركز على Fediverse أولاً، حتى مع تجاهل هذا المكون الإضافي. مجموعة مختلفة من التعليقات المرئية، ترميز مختلف، معالجة مختلفة للمقالات. لذا فإن بعض الاختلافات المرئية من خلال هذا المكون الإضافي لا تفاجئني؛ أعتقد أنها حتمية.
(شكرًا لك مرة أخرى على تفكيرك المتأني في هذه الأفكار. أدرك أن هذه حالات حدودية صعبة، وأنا ممتن للعمل، ولا أفترض أن أفكاري هي الأفضل، ولا أقصد إنشاء أي شعور بالالتزام لهذه المرحلة أو أي مرحلة من العمل على هذا، أو حتى الرد على أي شيء على وجه الخصوص أكتبه.)
مثل تغيير الفئة، أعتقد أنه يعتمد حقًا على السيناريو. ضع في اعتبارك على سبيل المثال
تم إنشاء المنشور 1 في الفئة 1 بواسطة المستخدم 1 (الممثل 1)
تم تغيير مؤلف المنشور 1 بواسطة المستخدم 3 (مسؤول) إلى المستخدم 2 (الممثل 2) بعد دقيقتين
يتم متابعة الفئة 1 بواسطة 400 ممثل عبر 20 نطاقًا و 5 منصات برمجية مختلفة، لكل منها تنفيذ مختلف قليلاً لجداول المحتويات واكتشاف المحتوى.
في غضون دقيقتين من إنشاء المنشور 1، تم نشر ملاحظتين بنفس المحتوى وممثلين مختلفين لهؤلاء المتابعين الـ 400.
أعتقد أن هذا من المرجح أن يسبب ارتباكًا لمجموعة فرعية معقولة من المتابعين، ناهيك عن حقيقة أن المستخدم 2 قد لا يدرك حتى أن اسمه مرتبط الآن بهذا المحتوى المكرر الذي لم يكتبه عبر 20 نطاقًا مختلفًا. قد يكونون على ما يرام مع قيام المسؤولين بذلك على مثيل واحد، فهذا مقبول ضمنيًا عند النشر على هذا المثيل، ومع ذلك أعتقد أنه يجب أن نكون حذرين للغاية بشأن توسيع هذا القبول الضمني عبر Fediverse بأكمله، خاصة في الظروف غير المثالية لتكرار المحتوى. تغيير مالكي المنشورات هو وظيفة إدارية قوية، خاصة بـ Discourse، ومرتبطة ضمنيًا بـ “العقد الاجتماعي” لمثيل واحد.
أعتقد أن الحالة الخاصة بالويكي أقوى، ومع ذلك سألاحظ مرة أخرى ما أشرت إليه بالفعل. الويكي هي مفهوم متأصل في Discourse العادي. ربط تعديلات أي شخص (ليس فقط الموظفين) بالمؤلف الأصلي هو مفهوم Discourse، بدون نظير في ActivityPub. يجب أن نكون حذرين بشأن توسيع هذا المفهوم باستخدام الطرق القياسية لـ ActivityPub عبر Fediverse بأكمله. سيتم التعامل مع أنشطة التحديث هذه مثل أي نشاط تحديث آخر عبر العديد من المثيلات والمنصات البرمجية المختلفة، مع فصلها عن سياق الويكي الأصلي. علاوة على ذلك، كما أشرت أيضًا، هناك بالفعل مشكلة محتملة في هذا الصدد مع قدرة الموظفين والمستخدمين الموثوق بهم للغاية على تعديل منشورات الآخرين. أعتقد أن هذا السؤال المحدود يحتاج إلى مزيد من النظر قبل أن نصل إلى مسألة الويكي.
أنا لا أحاول إنشاء خيار ثنائي بين Discourse و ActivityPub لهذه الميزات. ما أقوله هو أنه لا ينبغي لنا فقط محاولة تعيين وظائف Discourse الحساسة على Fediverse دون التفكير بحذر في العواقب. يجب أن يكون الافتراضي هو تعطيل هذه الميزات الأكثر حساسية على منشورات ActivityPub حتى يكون لدينا ثقة أكبر في أننا لن نؤذي أو نفاجئ مجموعة فرعية معقولة من المستخدمين أو حالات الاستخدام.
شخصيًا، لا أشعر أننا وصلنا إلى هذا الحد مع أي منهما، على الرغم من أن حدسي هو أن حالة الويكي لديها إمكانات أكبر في هذه المرحلة، حتى لو لم أر حلاً جيدًا بعد.
تم إنجاز هذين البندين أيضًا، لقد قمت للتو بدمج PR الخاص بـ Angus للتحقق من الهوية عبر OAuth. باستثناء إصلاحات الأخطاء وتحسينات الأداء، يكمل هذا المرحلة الحالية من الميزات المضافة إلى المكون الإضافي.
نشر المنشورات الخاصة بالمتابعين فقط في ActivityPub (الافتراضي هو العام)
نشر أول منشور أو الموضوع بالكامل (الافتراضي هو أول منشور)
مزامنة ثنائية الاتجاه عند استخدام نشر الموضوع بالكامل، أي سيتم نشر جميع المنشورات التي تم إنشاؤها بواسطة Discourse في موضوع ما في ActivityPub، والعكس صحيح، سيتم نشر الردود في ActivityPub إلى Discourse
خيار لنشر المنشورات كملاحظات (لخدمات المحتوى الأقصر مثل Mastodon) أو مقالات (أكثر ملاءمة لخدمات المحتوى الطويل)
التحقق من الهوية
التالي سنعمل على ضبط الميزات الحالية وتحسين سهولة الاستخدام. لا يزال التقييم مرحبًا به بالطبع. أنا مهتم بشكل خاص بالطرق لشرح كيفية عمل كل هذا للمستخدمين العاديين، فهذه ليست مهمة سهلة.
أنا متفق تمامًا مع @angus، هدفنا هو القيام بما هو عملي وقابل للتحقيق بمقدار معقول من الجهد. تحقيقًا لهذه الغاية، نحن على استعداد لقبول بعض الوظائف المخفضة في Discourse في هذا الوقت. هذا هو أفضل رهان لنا لمعرفة ما إذا كانت قيود معينة مهمة لمعالجتها أم لا (على سبيل المثال، هل سيواجه مستخدمو المكون الإضافي قيود wiki-ActivityPub كثيرًا؟).
بعد ذلك، أنا مهتم حقاً بربط خدمات ActivityPub المختلفة معاً، وعلى حد علمي، يتعلق الأمر في الغالب بإرسال الرسائل من Discourse إلى Mastodon ذهاباً وإياباً.
أنا على علم بأن البروتوكول مستقل عن الخدمة، ولكن هل هناك أي نوع من الوثائق، لنقل، لربط مثيلات Discourse مختلفة، أو دمج Nextcloud، أو PeerTube، إلخ؟
لقد قمنا بتعطيل تغييرات مؤلفي المشاركات والويكي في مواضيع ActivityPub حاليًا للأسباب التي ذكرتها بالفعل (افتراضاتهم لا تعمل مع ActivityPub بشكل مباشر). هذان هما الميزتان الوحيدتان اللتان تم تعطيلهما مؤقتًا في مواضيع ActivityPub بهذه الطريقة. يجب الإبلاغ عن أي وظائف أخرى مخفضة كمشكلة.
هذا مكون إضافي لـ ActivityPub يتبع عن كثب مواصفات ActivityPub، لذلك تم تصميمه للعمل مع أي خدمة تتبع هذه المواصفات، والتي تشمل جميع الخدمات التي ذكرتها (وغيرها). Mastodon هي أول منصة ActivityPub ركزنا على التكامل معها لأنه، من الناحية العملية، عليك التأكد من التوافق مع خدمة واحدة في كل مرة وهي أكبر منصة ActivityPub.
مرحباً @rokejulianlockhart، شكراً على ملاحظاتك. كيف تقوم بتنفيذ تدفق التفويض؟ هل تنقر على “تفويض” في لقطة الشاشة أعلاه في متصفح (وأي متصفح؟) أم تقوم بنسخ/لصق عناوين URL بطريقة ما؟ أسأل لأن لديك إياها في منشورك. إليك مقطع فيديو للتدفق القياسي يعمل معي على meta.discourse.org
مرحباً، بعد آخر تحديث، يبدو أنه يعطل ملفات تعريف المستخدمين (/u/user). سيظهر اسم المستخدم وصورة الملف الشخصي (بالإضافة إلى قائمة مخالفات المستخدم في الأعلى)
لقد مررنا بقائمة الإضافات لدينا وعطلنا كل واحدة منها على حدة حتى اختفت المشكلة. كما أنها عملت مع تمكين الوضع الآمن. إليك بعض أخطاء العميل التي كنا نحصل عليها:
لا يمكن قراءة خصائص null (قراءة 'getBoundingClientRect')
في Object.offset (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:5104:37)
في e.scrolled (https://amcforum.wiki/assets/discourse-9756bc4a118ac228ac6ac3f2b29c7d4a7d60a9f16ece25de4a772f0055c6eb94.js:2347:106)
في p.invoke (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4339:182)
في p.flush (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4331:141)
في h.flush (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4346:207)
في $._end (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4410:9)
في $.end (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4363:240)
في $._runExpiredTimers (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4417:192)
@rokejulianlockhart هل لديك ملفات تعريف الارتباط معطلة أو نوع من الإضافات الخصوصية قيد التشغيل؟ يتدفق التفويض حاليًا بالاعتماد على ملف تعريف ارتباط آمن للجلسة ليعمل.
@aboutDavid شكرًا على التقرير. بينما هذا ممكن، يبدو غير مرجح أن ما تشاركه ناتج عن مشكلة في هذا المكون الإضافي. هل يمكنك مشاركة رابط لموقعك؟ وهل لديك أي سمات أو مكونات سمات ممكّنة؟
من المحتمل أن تكون المشكلة في موقعك ناتجة عن شيء يستخدم منفذ الإضافات user-profile-avatar-flair. هذه الإضافة لا تستخدم هذا المنفذ. لكن إضافة الرسوم المتحركة للصور الرمزية تستخدمه.
لا يعني عدم وجود جافاسكريبت من جانب العميل بالضرورة عدم وجود مشاكل من جانب العميل. في هذه الحالة، تبدو المشكلة ناتجة عن طريقة استخدام منفذ المكون الإضافي، ربما في قالب. هل يمكنك محاولة إزالة المكون الإضافي للصور الرمزية المتحركة وإعلامي بالنتيجة؟
(جانباً، يحتوي المكون الإضافي للصور الرمزية المتحركة على جافاسكريبت من جانب العميل. انظر على سبيل المثال).
لقد ذهبت للتو لتعديل فئة هنا على ميتا (لتغيير بعض أذونات الوصول للمجموعات). لم أقم بتغيير أي إعدادات متعلقة بـ activitypub، لكننا انتهينا بهذه الإدخالات الثلاثة في سجل الموظفين:
أعتقد أنها انتقلت تقنيًا من nil إلى قيمتها الافتراضية، لذلك لا يوجد تغيير فعلي في السلوك؟ ومع ذلك، سيكون من الجيد تجنب تسجيل هذا الإزالة لتجنب الارتباك.
