يغطي هذا الموضوع كيفية متابعة ممثل ActivityPub في Discourse باستخدام إضافة Discourse ActivityPub، وهو امتداد لـ إعداد ممثل ActivityPub. إذا لم تكن متأكدًا مما يعنيه هذا، فانتقل إلى موضوع إضافة Discourse ActivityPub أولاً.
المعرّف في لقطة الشاشة هو @angusmcleod@mastodon.social
البحث عن ممثل
عند إدخال معرّف ممثل في نافذة “متابعة جديدة” والنقر فوق “بحث”، يبحث المكون الإضافي عن المعرّف باستخدام WebFinger. قد لا ينجح هذا البحث. إذا لم يتم إرجاع أي نتائج:
تحقق من المعرّف الذي نسخته.
تحقق من وجود خادم مباشر يدعم ActivityPub في نطاق المعرّف.
حاول البحث عن المعرّف على خدمة ActivityPub أخرى.
إذا جربت ما سبق وتعتقد أن المشكلة قد تكون في موقعك، أو في المكون الإضافي:
تحقق من تمكين إعداد الموقع activity pub verbose logging.
قم بإجراء البحث مرة أخرى.
تحقق من /logs بحثًا عن سجلات تحمل عنوان “ActivityPub”.
حتى الآن، أتمكن من ربط المنشورات والردود بين Discourse و Mastodon، ولكن ليس بين Discourse و Discourse. فئات Discourse المربوطة مفتوحة للجميع، لكن المثيلات تتطلب دعوة قبل إنشاء حساب. هل تعتقد أن هذا قد يكون له علاقة بالموضوع؟
أيضاً، الردود على المنشورات المربوطة التي قام بها أشخاص آخرون لا يتم ربطها بالمثيلات الأخرى المشاركة في الموضوع. هل هذا طبيعي ومتوقع؟
قد يكون كذلك! دعني أختبر هذا السيناريو وأعود إليك.
تنشر Discourse الأنشطة في موضوع لجميع المشاركين في الموضوع، حتى لو لم يكونوا يتابعون الجهة الفاعلة ذات الصلة (أي الفئة أو العلامة). لذا، هذا ليس متوقعًا. قد تكون مشكلة من جانب Discourse (يرجى التحقق من السجلات وإخباري إذا رأيت أي شيء). قد تكون أيضًا مشكلة على المنصة التي تتوقع رؤية الردود عليها.
عذرًا @angus، يجب عليّ ترحيل نسختي إلى خادم آخر. عندما قمت بتفعيل ActivityPub على نسختي ديسكورس، لم يتمكن جهاز Raspberry pi 4 الخاص بي بسعة 8 جيجابايت من التعامل مع حركة مرور ActivityPub واستمر في السخونة والتجمد. سأقدم تحديثًا إذا حاولت تشغيل ActivityPub على نسخة تجريبية.
هل هناك أي اقتراحات لإلغاء إدراج نطاق تطبيق بالكامل بعد تفعيله على ActivityPub؟
أنا غير قادر تقريبًا على استخدام النطاقات الفرعية السابقة بسبب حركة المرور المكثفة التي لا تزال تتلقاها على الرغم من أنني ألغيت متابعة حسابات الفئات على نسخة ماستودون التي أستخدمها.
مرحباً روب، يؤسفني سماع أنك تواجه مشاكل. يحتوي المكون الإضافي ActivityPub بالفعل على عدد من الحمايات للتعامل مع أحمال حركة المرور الكثيفة، وخاصة إعدادات الموقع هذه:
activity_pub_rate_limit_post_to_inbox_per_minute: القيمة الافتراضية لهذا هي 10. هذا يعني أنه افتراضيًا، تتم معالجة 10 طلبات POST واردة لكل عنوان IP في الدقيقة. حاول تقليل هذا.
activity_pub_rate_limit_get_objects_per_minute: القيمة الافتراضية لهذا هي 30 لكل عنوان IP في الدقيقة. هذا يعني أنه افتراضيًا، تتم معالجة 30 طلب GET لكل عنوان IP في الدقيقة. حاول تقليل هذا.
activity_pub_blocked_request_origins: يتيح لك هذا حظر جميع الطلبات من نطاق (نطاقات) قد تسبب لك مشاكل.
activity_pub_allowed_request_origins: يتيح لك هذا تقييد الطلبات إلى نطاقات معينة، مما يعني حظر الطلبات من جميع المصادر الأخرى.
إذا كان الحمل المروري المرتفع هو بالفعل سبب مشكلتك، فإن الطريقة للتعامل معه هي استخدام الحمايات المذكورة أعلاه، ما لم يكن لديك سيطرة على الخوادم التي تأتي منها حركة المرور.
شكراً لك على النصيحة يا أنجوس. أقدر ذلك حقًا. سأقوم بإعداد نسخة أخرى من Discourse على خادم تجريبي لن يؤثر على خدماتي الأخرى وسأحاول مرة أخرى باتباع اقتراحاتك.
لست متأكدًا من الطبقة في بنيتي التحتية التي تكمن فيها المشكلة حقًا، ولكن قد تكون وكيل العكسي (reverse proxy).
أنا أستخدم Cosmos Server كمراقب للخادم، وواجهة مستخدم لإدارة حاويات Docker، ووكيل عكسي لحاويات Docker الأخرى مثل Discourse والخدمات الأخرى. أشعر أن وكيل العكسي قد يحتاج إلى تكوين مماثل للحد المناسب من المعدل لاتصالات ActivityPub الواردة.
ربما كانت طلبات مزامنة ActivityPub الواردة من خادم Mastodon الخارجي هي التي أرهقت وكيل العكسي وتسببت في وصول استخدام ذاكرة الوصول العشوائي (RAM) ووحدة المعالجة المركزية (CPU) والشبكة إلى الحد الأقصى وارتفاع درجة الحرارة.
سأقوم بالتحديث مرة أخرى بمجرد استلام شحنتي التالية من Raspberry Pis وسيكون لدي لوحة احتياطية لاستخدامها كخادم تجريبي.
شكراً لمقاطع الفيديو الرائعة. هل فاتني شرح لكيفية رد المتابعين/التفاعل مع تلك المواضيع؟ أتساءل عما إذا كان ذلك سيجعلها “خادمًا” خفيف الوزن لفريق وسائل التواصل الاجتماعي
