عندما تحذف منشور AP على Discourse، نرسل طلب حذف للمحتوى إلى Mastodon. الأمر متروك لهم لمعالجته. يجب أن يعمل هذا، لذلك إذا كان بإمكانك تزويدي بأمثلة محددة، يمكنني محاولة معرفة أين لا يعمل تدفق الحذف كما هو متوقع (أي ما إذا كان ذلك من جانب Discourse أو Mastodon).
السبب في أن هذا هو الحال هو أن Mastodon لا يسمح حاليًا بتغيير المقابض. هذا هو السبب الجذري للمشكلة التي تواجهها. لقد كنت أدعو إلى أن يكون هذا هو الحال لبعض الوقت ولدي طلب سحب (PR) معلق لـ Mastodon. عندما يتم دمج ذلك، ستتمكن من حل هذا عن طريق تغيير المقبض في Discourse.
فائدة تعطيل المقبض هي أنه لن تتم معالجة أي محتوى وارد إلى هذا المقبض ولن يرسل أي محتوى جديد. الأمر متروك للمنصات الأخرى فيما تفعله بمحتواك الحالي، بما في ذلك كيفية معالجتها لنشاط الحذف الذي نرسله إليها.
هذا متوقع إذا كان إعداد “النشر الكامل” قيد التشغيل (وهو ما يجب أن يكون في حالتك). يتم نشر المحتوى باسم ممثل المستخدم (أي أنت في هذه الحالة). إذا كنت ترغب في النشر باسم ممثل الفئة، فيجب عليك استخدام “المنشور الأول”. في هذه الحالة، يتم نشر المنشور الأول فقط لكل موضوع. يمكنك رؤية مثال لنهج “المنشور الأول” في هذا الفيديو:
نعم، هذا هو الحال. شكراً لمساعدتك. بالطبع رأيت مقاطع الفيديو وجعلت بعض الأمور واضحة جداً بالنسبة لي وساعدت في تكوينها. شكراً لذلك!
لذلك بالطبع لا يمكنني حذف هذه المقابض التي تم إنشاؤها والتي لم أنشئها أبداً بنشاط.
عندما أفكر في الأمر، لا أشعر بالراحة تجاه ذلك… عندما يستخدمه الجميع مثلي، هناك أطنان من مقتطفات المحتوى من أشخاص لا يمكن حذفها أبداً. إنها تملأ الإنترنت بمعانٍ أقل، أم أنني لست على حق في ذلك؟
ليس خطأك، أحاول فقط أن أفهم ما سيحدث، إذا كان الجميع أغبياء مثلي ويملأون الإنترنت بمنشورات اختبار لا يتم حذفها أبداً
يمكنك حذف المشاركات. عند حذف مشاركة، يرسل Discourse أمر حذف إلى Mastodon ويجب على Mastodon حذف نسخته. إذا لم ينجح ذلك، حاول استعادة المشاركة وحذفها مرة أخرى. تحقق من السجلات عند القيام بذلك.
كما قلت، يجب أن تكون قادرًا على حذف المشاركات نفسها، ولكن بخلاف ذلك، بصراحة، لا تقلق بشأن ذلك كثيرًا. Mastodon هو منصة تعتمد على التدفق. ستضيع مشاركاتك التجريبية بسرعة في تدفق المحتوى. علاوة على ذلك، هل كان أي شخص آخر (غيرك) يتابع حسابك في ذلك الوقت؟ لدي مئات المشاركات التجريبية في fediverse ولم يكن لها أي تأثير على الإطلاق
لكن أخبرني كيف سارت الأمور معك في محاولة حذف المشاركات.
من مجتمعات Discourse التي أشارك فيها، لا يمكنني التفكير إلا في ثلاثة حيث أرغب في متابعة بعض الفئات، ولكنني لن أرغب في متابعة جهة فاعل التطبيق لـ Discourse بأكمله.
لدي قارئ RSS، وأتابع مواقع كاملة عبر RSS؛ سيكون ActivityPub تجربة أفضل، خاصةً للرد.
هل جهة فاعل التطبيق صعبة أم ذات أولوية منخفضة فقط؟
إن متابعة مثيل كامل تعني أنك تحصل على كل منشور على هذا المثيل في موجز Mastodon الخاص بك كتيار مستمر واحد. ما لم يكن المثيل لا يحتوي على الكثير من النشاط، أراهن أن هذه ستكون حالة استخدام متخصصة. ربما سأثبت خطئي، ولكن بمجرد النظر إليها، يبدو لي غير معقول أن تكون شائعة.
هل نظرت في السجلات؟ دعنا نتأكد من أننا نرسل نشاط الحذف إلى Mastodon.
هناك، أعتقد، ذيل طويل حقًا من مثيلات Discourse منخفضة الحركة ولكنها نشطة بالتأكيد ولا تزال تحتوي على فئات متعددة. من الواضح أن meta ليست واحدة من هذه المثيلات الصغيرة. ولكن من بين مثيلات Discourse الثلاثة التي أديرها شخصيًا، فإن أحدها يتمتع بحركة مرور عالية جدًا لدرجة أنني لن أضع العديد من فئاته في موجز Mastodon الخاص بي، واثنان لديهما معدلات حركة مرور منخفضة كافية لدرجة أنني بالتأكيد أفضل متابعة الموقع بأكمله. هناك آخرون أنا عضو فيها حيث سأتابع الموقع بأكمله أيضًا إذا كان لدي الخيار.
لا أطلب منك تغيير الأولويات هنا. فقط أشارك المنظور البديل.
هذه “ميزة” (نوعًا ما) تراها في بعض منصات AP. أود أن أشير إلى أن مواصفات ActivityPub تنص على:
قد يتم إلغاء الرجوع إلى طريقة HTTP GET مقابل خاصية id للكائن لاسترداد النشاط. يجوز للخوادم استخدام التفاوض على محتوى HTTP كما هو محدد في [RFC7231] لتحديد نوع البيانات التي سيتم إرجاعها استجابةً لطلب، ولكن يجب تقديم تمثيل كائن ActivityStreams استجابةً لـ application/ld+json; profile="https://www.w3.org/ns/activitystreams"، ويجب أيضًا تقديم تمثيل ActivityStreams استجابةً لـ application/activity+json. يجب على العميل تحديد رأس Accept بنوع الوسائط application/ld+json; profile="https://www.w3.org/ns/activitystreams" لاسترداد النشاط.
يتطلب المكون الإضافي AP حاليًا منك إرسال رأس Accept مع “application/ld+json” أو “application/activity+json” لاسترداد أي كائن (أي النشاط، الملاحظة، إلخ). قد ندعم ما تشير إليه في المستقبل، ولكنه إلى حد ما ميزة “مستخدم قوي” لمنصات معينة.
معرفات الكائنات ليست مصممة حقًا للاستخدام كعناوين URL قابلة للمشاركة/النسخ من قبل مستخدم نهائي في عميل. نجعلها متاحة في نافذة حالة ActivityPub لأغراض التطوير/التصحيح. يجب أن يستخدم عميلك السمة url التي نقوم بتسلسلها على الكائن. على سبيل المثال، إذا قمت بزيارة الموضوع الذي ربطته على mastodon.social (هنا) ونقرت على “نسخ الرابط إلى الحالة” في قائمة الـ toot، ستجد أنه رابط مباشر للموضوع على meta. يستخدم Mastodon القياسي url للكائن لغرض مشاركة الرابط
سيكون ذلك بسبب عدم تعيين رأس القبول (Accept header). أنا منفتح على تعديل الأشياء (أي حل طلبات معرف الكائن برؤوس غير صحيحة إلى عنوان URL للنموذج المتصل)، ولكن في الوقت الحالي أعتقد أن الأشخاص الذين يصنعون عميلك قد يحتاجون إلى مطابقته للمواصفات (أي استخدام url الكائن بدلاً من id الكائن كعنوان URL للمستخدم).
لقد كنت أتابع @feature@meta.discourse.org و @announcements@meta.discourse.org في ماستودون منذ فترة وجيزة بعد الإعلان عنها، وسرعان ما توقفت عن تلقي التحديثات. اعتقدت أن السبب هو إزالة المكون الإضافي من meta، وتجاهلت الأمر، ومضيت قدمًا.
ولكن إذا كان لا يزال نشطًا بالفعل، فأنا أتساءل ما هي مشكلة الاتحاد مع social.makerforums.info.
كانت هناك العديد من التغييرات في وقت مبكر من حياة المكون الإضافي، لذا أعتذر إذا أزال أحد هذه التغييرات متابعتك. يرجى المحاولة مرة أخرى لمعرفة ما سيحدث.
هل هو تفرع من glitch-soc؟ لا أرى نافذة المشاركة التي قمت بتضمينها في الكود الخاص بهم. ولكن نعم، يسعدني العمل مع مسؤول الخادم الخاص بك لتوضيح الأمور بشكل أكبر إذا لزم الأمر.
تُظهر الروابط https://social.makerforums.info/users/mcdanlj والتي تتضمن النطاق بشكل صحيح، ولكن أي شخص يحاول إدخال ما يراه في قائمة المتابعين هذه للبحث عني أو متابعتي سيفشل.
لم أجد أي مكان في جانب Mastodon يقوم بتقليم النطاق الفرعي.