Merci pour les suggestions @NateDhaliwal.
Pour clarifier, le sujet que vous avez lié a été créé à l’origine sur socialhub.activitypub.rocks. Vous pouvez voir où il a été publié à l’origine dans les informations ActivityPub.
Peut-être si j’explique un peu plus comment cela fonctionne, vous comprendrez pourquoi cela n’aurait pas de sens.
Discourse prend en charge deux types d’acteurs ActivityPub qui peuvent publier et recevoir des messages : les catégories et les tags. Actuellement, sur meta, il y a deux catégories et quatre tags pour lesquels ActivityPub est activé. Vous pouvez les voir ici.
Pour réaliser ce que vous suggérez, il suffit de créer un acteur de catégorie. Les messages reçus par Announcements ou Feature (c’est-à-dire les messages envoyés à announcements@meta.discourse.org ou feature@meta.discourse.org) vont directement dans ces catégories (si l’acteur de catégorie a l’option “sujet complet” activée).
Ce que vous remarquez, c’est que les messages reçus par un acteur de tag, par exemple activitypub@meta.discourse.org pour activitypub, ne vont pas automatiquement dans une catégorie spécifique. Si vous y réfléchissez dans le contexte que j’ai décrit, ce serait un peu étrange qu’ils le fassent.
Le rôle d’un tag est de regrouper taxonomiquement des sujets dans différentes catégories. S’il y avait une catégorie par défaut dans laquelle tous les messages envoyés à activitypub@meta.discourse.org finiraient, alors nous devrions simplement créer une catégorie activitypub et y créer un acteur, au lieu d’un tag.
En prenant un peu de recul, si vous y réfléchissez plus largement, il serait peut-être préférable d’utiliser un tag pour une taxonomie générique comme activitypub au lieu d’une catégorie, et de catégoriser manuellement les sujets entrants au besoin. Il existe des acteurs plus spécifiques liés à des catégories spécifiques, cependant activitypub peut englober une variété de types de sujets.
Fondamentalement, cela dépend de la manière dont une communauté souhaite se gérer et gérer sa relation avec le fediverse. Je ne pense pas qu’une solution technique soit nécessaire ici, du moins pas encore. Peut-être que @tobiaseigen aura d’autres réflexions sur la manière dont il souhaite aborder cette question.
