نفس الشيء هنا. لا يمكنني تغيير مالك سلسلة محادثات. على الرغم من أن الفئة ليست فيدرالية.
هذه تحذيرات، وليست أخطاء. لا يعني بالضرورة أن هناك خطأ ما، بل هي موجودة لتزويدك بمزيد من المعلومات حول ما يحدث. قد تكون هناك عدة أسباب لعدم معالجة المحتوى من Fediverse، والعديد منها يتعلق بالشخص الذي يرسل المحتوى. إذا كنت لا تريد ظهورها في سجلاتك، فقم بإيقاف تشغيل تسجيل الإسهاب لمكون ActivityPub الإضافي (activity pub verbose logging).
هل الموضوع في فئة ActivityPub أم أنه يحتوي على علامة ActivityPub؟
هل تم إنشاء الموضوع في فئة ActivityPub أو بعلامة ActivityPub؟
يرجى ملاحظة أنه تم تعطيل تغيير مالك الموضوع عن قصد لمواضيع ActivityPub. لمعرفة سبب ذلك، يرجى الاطلاع أعلاه:
إنها فئة مرتبطة بـ Activitypub، لكننا نتحدث عن مالك الموضوع الذي لا يشارك في Activitypub لأنه حساب مختلف.
أعتقد أنه يجب أن يكون هناك خيار للسماح بتغيير المالك على أي حال، وإلا فلن يكون من المنطقي أن يكون لدى Discourse نافذة لتغيير المالك.
أيضًا، تغييره دون إرسال أي تحديثات إلى Activitypub مثالي بالنسبة لنا.
إعجاب واحد (1)
أتفهم أن الناس يريدون القدرة على تغيير ملكية المنشورات. القضية التي يجب معالجتها في هذا الصدد هي القضية التي أوضحتها أعلاه، وتحديداً هذا:
المحتوى الذي يظهر على Discourse الخاص بك يأتي من خدمة لست مسؤولاً عنها، وبدون ActivityPub، لن يكون لديك أي سيطرة عليها على الإطلاق. مجرد توسيع القدرة على تغيير مؤلف هذا المحتوى دون اعتبار كافٍ لهذه الحقيقة لن يكون حكيماً.
بالنسبة للمحتوى الذي يؤلفه المستخدمون من Discourse الخاص بك في موضوع منشور عبر ActivityPub، فكر فيما يجب أن يحدث إذا تم إجراء أي تحديثات على المحتوى بعد تغيير مؤلف المنشور. هل نقوم بما يلي:
- إيقاف نشر تحديثات ActivityPub؛ أو
- نشرها بواسطة “الممثل” (المستخدم) “القديم”؛ أو
- نشرها بواسطة “الممثل” (المستخدم) “الجديد”.
نشر أنشطة التحديث لكائن موجود مع ممثل جديد (أي 3) سيعمل مع Discourse (كما حاولت تقديم إمكانية لهذه المسألة)، ولكنه لن يعمل مع خدمات ActivityPub الأخرى. في الواقع، لقد دفعت بالفعل في هذه النقطة، لهذا السبب، في نظام ActivityPub البيئي. انظر هنا:
ولدي PR معلق لـ Mastodon لجعل 3 ممكنًا
لإعطاء مثال واحد فقط على المشاكل هنا، ضع في اعتبارك الحالة التي تنشر فيها محتوى ActivityPub مع حسابك (واسمك وصورتك) مرتبطين به. يتابع أحد “منافسيك” محتواك. على خادمهم، يقومون بعد ذلك بتغيير ملكية جميع المنشورات التي تحتوي على محتواك لتكون منشورات خاصة بهم (مع اسمهم وصورتهم) بدلاً من منشوراتك. قد يكون هذا، وبشكل مفهوم إلى حد ما، مزعجًا لك. نعم، بالطبع هذا ممكن مع كود مخصص على أي حال، ولكن السؤال هو ما إذا كنت تريد بناء ذلك في الإمكانيات الافتراضية للمكون الإضافي.
بالتفكير في هذا طوال الليل، فإن أحد الأساليب التي قد تخفف من هذا إلى حد ما هو إذا أضفنا الممثل الناشر إلى عرض حالة ActivityPub:
أنا منفتح على أفكار أخرى في هذا الاتجاه.
صحيح، أعتقد أنني سأقوم بإزالة النافذة المنبثقة تمامًا من مواضيع ActivityPub حتى نحل المسألة الأساسية هنا.
إعجابَين (2)
أفهم المشكلة، في حالتنا نستخدم Activitypub بحساب لكل فئة وننشر هذا التحديث.
لذلك، من يملك الموضوع لا يهمه كثيرًا بالنسبة لنا في Activitypub للحالات المختلفة، لهذا السبب أقول إنه يجب أن نكون قادرين على القيام بذلك على أي حال.
ActivityPub لا يتعلق فقط بكيفية استخدام منتداك، بل يتعلق بكيفية تفاعل منتداك مع بقية الـ fediverse. علاوة على ذلك، لبناء شيء ما في المكون الإضافي، يجب أن نأخذ في الاعتبار حالات استخدام أخرى أيضًا.
لا أريد أن أعطي انطباعًا بأن السماح بتغيير مالك المنشور ليس قضية قيد الدراسة بنشاط، أو أنه لن يُسمح به في تحديث مستقبلي. أنا مهتم بأي أفكار لدى الأشخاص لحل المشكلات الأساسية هنا، والتي أوضحت بعضها أعلاه.
معالجة هذا المثال، سيكون من المنطقي منع تغيير ملكية المنشورات التي تم فيدرتها، مع السماح للمسؤولين بتغيير ملكية المنشورات التي تم إنشاؤها داخل مثيل Discourse هذا، بغض النظر عما إذا كانت فيدرالية أم لا.
يمكن للمسؤول انتحال شخصية مستخدم. لذلك، يمكن للمسؤول، ضمن المنصة مع إمكانياتها الحالية، إنشاء محتوى ينتحل شخصية أي مستخدم على المنصة. آمل ألا يسيء المسؤولون استخدام هذه القوة؛ أنا لا أفعل. ومع ذلك، فإن هذه القوة مشابهة في تأثيرها للقدرة على تغيير ملكية منشور، سواء كان فيدراليًا أم لا. بشكل عام، “يمكن للمسؤول فعل شيء خبيث” هو أمر صحيح بالفعل بطرق لا حصر لها.
أتفق (على الأقل بقدر ما أفهم 
) أن تغيير ملكية منشور تم إنشاؤه عن طريق الفيدرالية (وبالتالي، ليس منشور موضوع؟) لا معنى له. على عكس تغيير ملكية المنشورات التي تم إنشاؤها في الموقع، لا أتذكر رؤية حالة استخدام معبر عنها.
أحب هذا ليس فقط من منظور المتانة ضد هذا النوع من الهجمات، ولكن لجعل الفيدرالية أكثر وضوحًا، مما يسهل على زائر الموقع العثور على ممثلين للمتابعة. كيف سيبدو هذا لحالة يوجد بها ممثل فئة (وربما، في يوم من الأيام، ممثل موقع؟) وممثل شخص؟ هل سيكون لديك قائمة؟
- تم النشر بواسطة
[@category@site](link) - تم النشر بواسطة
[@person@site)(link)
إعجاب واحد (1)
شكراً لك على تحليلك المفيد.
أتفق.
هذا التحليل ينطبق فقط على المنشورات غير المدمجة. السؤال ليس ما إذا كان تغيير مالك المنشور منطقيًا لـ Discourse نفسه. السؤال هو ما هي الآثار التي يحدثها تغيير الملكية على المحتوى المدمج. إذا قمت بتغيير ملكية منشور محلي تم دمجه، فعليك التعامل مع هذا السؤال:
أود أن أبدأ بالإشارة إلى أن كل من الخيارين 1 و 2 لهما بعض المشكلات الجوهرية، والتي يمكنني توضيحها إذا لزم الأمر. قد يكون الجواب هو ما يدعمه المكون الإضافي حاليًا، وهو “3”، ولكن إذا سلكنا هذا المسار، فسيحدث هذا (بافتراض عدم دمج طلب السحب الحالي الخاص بي إلى Mastodon):
- يتم دمج الموضوع.
- تظهر منشورات الموضوع على Mastodon.
- يقوم مسؤول الموقع بتغيير مالك المنشور.
- يقوم المالك الجديد للمنشور بإجراء تعديلات مختلفة على المنشور.
- لا تصل التعديلات إلى Mastodon (أو أي منصة ActivityPub أخرى بالمناسبة).
وبناءً على ذلك:
- سيأتي شخص ما إلى هنا ويقول “تعديلاتي لا يتم دمجها”. السبب وراء ذلك لن يكون واضحًا على الفور لأنه بقدر ما يتعلق الأمر بـ Discourse، يتم دمجها.
النقطة الرئيسية هنا هي أنه إذا اتخذنا هذا النهج، فسنكون أول منصة في fediverse (على حد علمي) تفعل ذلك. كونك العقدة الوحيدة في نظام مترابط من العقد لفعل شيء ما ليس شيئًا مرغوبًا فيه بشكل واضح. قد نحفز التغيير في هذا الصدد، ولكن يجب أن ندرك أن هذا هو ما سنحاول القيام به.
ومع ذلك، لقد قمت بالفعل بتطبيق الخيار 3، وأعتقد أن هذا سيكون الجواب النهائي الذي سيسمح لي بإزالة هذا القيد. ما زلت أحتفظ ببعض الأمل في أن يتمكن شخص ما من التوصل إلى نهج أكثر دقة قليلاً، أو شيء لم أفكر فيه بعد.
سيتم إدراج الممثل attributedTo للكائن فقط، لذلك سيكون هناك ممثل واحد فقط.
إعجاب واحد (1)
أرى القبح. عملية التفكير التي أوصلتني إلى هناك هي شيء من هذا القبيل…
يمكنني أن أتخيل بسذاجة شيئًا مثل #3 مع القليل جدًا من #2 - لدمج تحديث تم إنشاؤه من المستخدم القديم يضيف إلى آخر إصدار نشره نصًا تم إنشاؤه بواسطة النظام في الأعلى أو الأسفل شيئًا يشبه إلى حد ما “للتحديثات المستقبلية، اتبع @newuser@site”.
ثم سيكون من المنطقي (مرة أخرى بسذاجة) تخصيص معرف جديد للمنشور المحدث تحت attributedTo الجديد والذي يُستخدم لتحديثات المالك الجديد.
ستكون حالة حافة واضحة بالنسبة لي هي تغيير الملكية مرة أخرى إلى المالك الأصلي - هل يعود إلى معرف المنشور القديم أم يخصص معرفًا آخر؟ أعتقد أنه سيعود، وفي هذه الحالة سيكون معرف المنشور المدمج مفتاحًا لـ (مستخدم، منشور ديسكورس) tuple. أتوقع أن يتطلب هذا ترحيلًا لدعمه مع التوافق مع الإصدارات السابقة.
كل ذلك كتجربة فكرية يجعلني أقدر بوضوح أكبر لماذا لن تكون متعجلًا في المضي قدمًا في تغييرك المقترح إلى Mastodon قيد النظر! 
باستثناء قبول طلب سحب Mastodon الخاص بك، يمكنني أن أتخيل أن أكون قادرًا على تحديد منشورات فردية على أنها غير مدمجة، والتي سيتم دمجها كحذف إذا تم دمجها سابقًا، و/أو يمكن القيام بها مع تثبيت المكون الإضافي ولكن قبل تمكين الدمج، ثم السماح بتغيير الملكية للمنشورات غير المدمجة فقط. جميع المنشورات التي أرغب في تغيير ملكيتها هي منشورات ليست ذات قيمة للدمج، بقدر ما أستطيع أن أقول.
يمكنني أن أتخيل أن يكون ذلك ذا قيمة حتى لو تم قبول طلب سحب Mastodon الخاص بك، وتم دعم تغيير الملكية. لست متأكدًا من أن له أي معنى لدمج منشورات موضوع الفئة، على سبيل المثال. على الأقل، أعتقد أنني سأستبعدها جميعًا من الدمج في موقعي حتى لو تم دعم تغيير الملكية، إذا كان لدي خيار لاستبعادها.
تجربة فكرية مثيرة للاهتمام، ومع ذلك لن تعمل لعدة أسباب.
- أنت لا تتبع المستخدمين الأفراد في نشاط ديسكورس.
- لا يمكنك تغيير معرف كائن نشاط موجود (ستحتاج إلى إنشاء كائن جديد).
- كما تقول، إذا تغيرت الملكية مرة أخرى، أو مرات متعددة، فسينتهي بك الأمر بعدة كائنات لمنشور واحد، وهو ما سيكون غير قابل للإدارة.
أحد الأشياء التي يمكنني القيام بها الآن في هذا الصدد هو تغيير القيد إلى ما إذا كان المنشور الأول في موضوع محلي قد تم نشره. سيساعد ذلك في بعض المواضيع كما تقول.
إعجاب واحد (1)
سوء فهم مني؛ اعتقدت أنك قد أنشأت أيضًا القدرة على القيام بذلك، بالإضافة إلى ممثلي الفئات. (ليست طلب ميزة، مجرد سوء فهم.)
هذا ما كنت أحاول وصفه، وفشلت بوضوح. كان المقصود منه أن يكون شيئًا مثل reductio ad absurdum على أي حال. 
سيكون ذلك رائعًا! 
إعجاب واحد (1)
مرحباً، هل هناك حد لـ Lemmy؟
لا يمكنني متابعة: @batepapo@lemmy.eco.br كمثال
في الواقع، يمكنني المتابعة. حتى زر “إلغاء المتابعة” يظهر تحت الملف الشخصي، ولكن عندما أقوم بتحديث الصفحة، يختفي كل شيء.
إعجاب واحد (1)
عمل رائع! لدي سؤال بخصوص تأخير تسليم نشاط pub بالدقائق. هل هناك طريقة لتعطيل الميزة بحيث يكون المنشور مرئيًا على الفور؟
الإعداد 1 دقيقة هو على الفور تقريبًا ولكني أرغب في نشر كليهما في الوقت الفعلي أيضًا.
إعجاب واحد (1)
@David_Ghost اقرأ هذا
إعجابَين (2)
هذا هو أول شيء لاحظته أيضًا. ما هي العيوب المحتملة لإضافة عنوان موضوع جديد إلى المنشور الموزع عبر ActivityPub؟
[عنوان موضوع Discourse]
[سطر فارغ]
[نص موضوع Discourse، كما تم نشره الآن]
كان مطورو Lemmy يعملون على إضافة التوافق مع Discourse. هذا على جدول أعمالي لمتابعته.
هذا يعني أن Discourse يرسل متابعة ولكنه لا يتلقى قبولاً من Lemmy.
حاليًا، يمكنك القيام بذلك فقط باستخدام متغير بيئة (على سبيل المثال، قم بتعيينه في ملف app.yml الخاص بك)
DISCOURSE_ACTIVITY_PUB_DELIVERY_DELAY=0
عنوان الموضوع منشور بالفعل. إنه name للمجموعة المرتبطة بالموضوع.
بهذه الطريقة، يتم تضمين عناوين المواضيع في الاتصال بين Discourse و Discourse، أو Discourse و NodeBB، أو Discourse وأي منصة تشبه المنتديات. لا يقوم Mastodon بمعالجة العناوين. إذا وضعنا عنوان الموضوع في محتوى الملاحظة كما تقترح، فسيؤدي ذلك إلى مشاكل، على سبيل المثال، عند نشر المحتوى على منصات تدعم العناوين.
بشكل أساسي، القيد الذي تصفه هو أن Mastodon منصة تدوين مصغر. لقد أضفنا بالفعل وظائف لاستيعاب ذلك، أي ترميز [note][/note] لتحديد المحتوى الذي تقوم بنشره. إذا كنت ترغب في الحصول على اتصال منتديات مناسب، أقترح الاتصال بمثيلات Discourse الأخرى.
نعم، هناك العديد من مثيلات Mastodon. ولكن هناك أيضًا العديد من مثيلات Discourse. إذا لم يكن مثيل Discourse الذي ترغب في الاتصال به معدًا لذلك بعد، فسأكون سعيدًا بمساعدتهم في الإعداد.
5 إعجابات
هل من الممكن حذف الممثلين؟
وهل سيكون من الممكن إعداد فئات متعددة، بحيث ينشر كل شيء جديد في الخطاب؟
وإلا سيتعين على شخص ما متابعة xx مقابض على ماستودون للحصول على كل المحتوى من جميع الفئات.
يمكنك تعطيل ممثل، مما يعطل كل ما يتعلق بهذا الممثل.
إذا قمت بحذف الفئة أو العلامة التي يرتبط بها الممثل، فسيؤدي ذلك إلى حذف الممثل. لا يمكن حاليًا حذف ممثل بمعزل عن غيره. أوصي بتعطيل الممثل فقط.
قد يكون هذا ممكنًا في المستقبل (على المدى المتوسط إلى الطويل) إذا أضفنا ممثل “تطبيق” لمثيل discourse بأكمله. من المحتمل دائمًا أن يكون توحيد كل شيء في discourse من خلال ممثل واحد حالة استخدام متخصصة.
إعجاب واحد (1)
حسناً. ربما يختلف فهمي للإمكانيات…
بالأمس قمت بإعداده وكان يعمل بشكل جيد. حذفت المنشورات على Discourse، لأنني كنت أجرب فقط، لكن المنشورات لا تزال متاحة عبر الإنترنت على Mastodon. لذلك اعتقدت أنه يمكنني حذف الحساب لحذف المحتوى من Mastodon أيضاً.
عندما أقوم بتعطيله فقط، يظل المحتوى متاحاً عبر الإنترنت على Mastodon.
وعندما لا أتمكن من حذفه، لا يمكنني استخدام هذا المعرّف مع فئات أخرى في المستقبل. قد أرغب في تغيير بعض الفئات في المستقبل ولكن لا يمكنني استخدامه مع هذا المعرّف الذي يتابعه xx شخصاً. لذا أحتاج إلى إنشاء معرّف جديد ويجب على الجميع متابعته مرة أخرى. لا أرى أي مزايا لتعطيل معرّف لا أحتاجه بعد الآن.
وبالإضافة إلى ذلك: عندما أقوم بتعطيل معرّف واحد، يتم تعطيل المعرّف الآخر أيضاً. لذا هل يمكنني تشغيل معرّفات متعددة فقط أم لا شيء؟
لكن هذا ما أريده، أم أنني أفهم الأمر بشكل خاطئ؟ أريد إبلاغ الأشخاص على شبكة اجتماعية بالمناقشات التي تجري على منصة Discourse بأكملها الخاصة بي وليس فقط لوسم أو فئة واحدة. عندما أقوم بتشغيل قسم “الأخبار”، يمكنني فهم ذلك، لكنني أريد أن يشارك الجميع في المناقشات لذا يجب عليّ نشر كل شيء وليس فئة واحدة فقط.