Ce sujet couvre le suivi d’un acteur ActivityPub dans Discourse avec le plugin Discourse ActivityPub, et fait suite à Configuration d’un acteur ActivityPub. Si vous n’êtes pas sûr de ce que cela signifie, rendez-vous d’abord sur le sujet Plugin Discourse ActivityPub.
Obtenez le « handle » de l’acteur que vous souhaitez suivre (voir ci-dessous).
Accédez à l’onglet « Fédération » dans la vue de la liste des sujets de la catégorie ou du tag de l’étape 1.
Cliquez sur « Nouveau suivi », entrez le handle de l’étape 2, puis cliquez sur « Rechercher » (voir ci-dessous).
Cliquez sur « Suivre » lorsque l’acteur est trouvé.
Handles d’acteur
La plupart des services ActivityPub utilisent un protocole appelé WebFinger pour permettre la découverte des acteurs par un « handle ». Celui-ci est généralement au format
username@domain
Parfois, le nom d’utilisateur est précédé d’un symbole, par exemple @.
Discourse
Obtenez le handle d’un acteur Discourse en accédant à l’onglet « Fédération » dans la vue de la liste des sujets de l’acteur.
Le handle dans la capture d’écran est @angusmcleod@mastodon.social
Recherche d’un acteur
Lorsque vous entrez un handle d’acteur dans la fenêtre modale « Nouveau suivi » et que vous cliquez sur « Rechercher », le plugin recherche le handle à l’aide de WebFinger. Cette recherche peut échouer. Si aucun résultat n’est retourné :
Vérifiez le handle que vous avez copié.
Vérifiez qu’il existe un serveur actif compatible ActivityPub sur le domaine du handle.
Essayez de rechercher le handle sur un autre service ActivityPub.
Si vous avez essayé ce qui précède et que vous pensez que le problème vient de votre site ou du plugin :
Vérifiez que le paramètre du site activity pub verbose logging est activé.
Effectuez à nouveau la recherche.
Vérifiez /logs pour les journaux intitulés « ActivityPub ».
Signalez tout problème que vous trouvez dans une réponse à ce sujet.
Jusqu’à présent, j’arrive à fédérer les posts et les réponses entre Discourse et Mastodon, mais pas entre Discourse et Discourse. Mes catégories Discourse fédérées sont ouvertes à tous, mais les instances exigent une invitation avant qu’un compte puisse être créé. Penses-tu que cela puisse avoir un rapport ?
De plus, les réponses aux posts fédérés par d’autres personnes ne sont pas fédérées vers les autres instances impliquées dans le fil de discussion. Est-ce normal et attendu ?
Cela pourrait bien être le cas ! Laissez-moi tester ce scénario et je reviendrai vers vous.
Discourse publie les activités d’un sujet à tous les participants du sujet, même s’ils ne suivent pas l’acteur pertinent (c’est-à-dire la catégorie ou l’étiquette). Ce n’est donc pas attendu. Il pourrait s’agir d’un problème du côté de Discourse (veuillez vérifier les journaux et me faire savoir si vous voyez quelque chose). Il pourrait également s’agir d’un problème sur la plateforme sur laquelle vous vous attendez à voir les réponses.
Désolé @angus, je dois migrer mon instance vers un autre serveur. Lorsque j’ai activé ActivityPub sur mes deux instances discourse, mon Raspberry pi 4 de 8 Go n’a pas pu gérer le trafic ActivityPub et a continué à surchauffer et à geler. Je fournirai une mise à jour si je tente de faire fonctionner ActivityPub sur une instance expérimentale.
Des suggestions pour supprimer complètement un domaine d’application après l’avoir activé sur ActivityPub ?
Je suis pratiquement incapable d’utiliser les sous-domaines précédents en raison du trafic intense qu’ils reçoivent toujours, même si j’ai désabonné les comptes de catégorie sur l’instance Mastodon que j’utilise.
Salut Rob, je suis désolé d’apprendre que tu rencontres des problèmes. Le plugin ActivityPub dispose déjà d’un certain nombre de protections pour gérer les charges de trafic importantes, en particulier ces paramètres du site :
activity_pub_rate_limit_post_to_inbox_per_minute : La valeur par défaut est de 10. Cela signifie que, par défaut, 10 requêtes POST entrantes par adresse IP par minute sont traitées. Essaie de réduire cette valeur.
activity_pub_rate_limit_get_objects_per_minute : La valeur par défaut est de 30 par adresse IP par minute. Cela signifie que, par défaut, 30 requêtes GET par adresse IP par minute sont traitées. Essaie de réduire cette valeur.
activity_pub_blocked_request_origins : Cela te permet de bloquer toutes les requêtes provenant de domaines qui pourraient te causer des problèmes.
activity_pub_allowed_request_origins : Cela te permet de restreindre les requêtes à certains domaines, ce qui signifie que les requêtes provenant de toutes les autres sources sont bloquées.
Si une charge de trafic élevée est effectivement la cause de ton problème, la façon de le gérer est d’utiliser les protections énumérées ci-dessus, à moins que tu n’aies le contrôle sur les serveurs d’où provient le trafic.
Merci pour ces conseils, Angus. J’apprécie vraiment. Je vais configurer une autre instance Discourse sur un serveur expérimental qui n’affectera pas mes autres services et réessayer en suivant vos suggestions.
Je ne suis pas sûr de la couche de mon infrastructure qui pose problème, mais il se pourrait que ce soit le proxy inverse.
J’utilise Cosmos Server comme moniteur de serveur, interface utilisateur de gestion de conteneurs Docker et proxy inverse pour mes autres conteneurs Docker comme Discourse et d’autres services. J’ai l’impression que le proxy inverse pourrait nécessiter une configuration similaire pour une limitation de débit adéquate des connexions ActivityPub entrantes.
Il se pourrait que ce soient les requêtes de synchronisation ActivityPub entrantes du serveur Mastodon externe qui aient submergé le proxy inverse et provoqué une utilisation maximale de la RAM, du CPU et du réseau, entraînant une surchauffe.
Je vous tiendrai informé une fois que j’aurai reçu ma prochaine livraison de Raspberry Pis et que j’aurai une carte de rechange à utiliser comme serveur expérimental.
Merci pour vos vidéos soignées. Ai-je manqué une explication sur la façon dont les abonnés peuvent répondre/interagir sur ces sujets ? Je me demande si cela pourrait constituer un “serveur” léger pour l’équipe des médias sociaux.
