Un sujet est créé avec un lien dans le premier message - pour commencer, détecter soit un seul lien dans le premier message, soit un URL collé dans le titre.
Optionnel : Pour éviter le spam trivial, attendez la première réponse ou activez un paramètre du site.
Sondez la page pour voir si WebMention est pris en charge.
Un commentaire WebMention est envoyé avec le texte « Cette page est discutée sur =SITE\_DOMAIN=: »=TITLE=» =TOPIC\_LINK= =CATEGORY_AND_TAGS= » (en utilisant le default_locale du site).
Le site reçoit le WebMention (délégant potentiellement à fed.brid.gy, appliquant un anti-spam, etc.) et l’affiche éventuellement comme un commentaire.
L’acteur (l’« auteur » du commentaire) prendrait soit le logo de haute qualité du site, soit l’avatar @system, et le nom court du forum.
Juste une parenthèse : je ne l’ai pas mentionné dans le post, mais le protocole prend en charge l’envoi de likes et de reposts comme des citoyens de première classe, comme les réponses, ce serait bien si Discourse implémentait cela aussi
Pavilion a soumis une demande à NLnet pour 40 000 Euros afin d’ajouter la prise en charge de la fédération à Discourse (voir ci-dessous). Elle a été rejetée et nous avons fini par postuler (et avons été acceptés) pour DAPSI à la place.
Une mise à jour ici. Pavilion et CDCK (Discourse.org) discutent de la création d’un plugin ActivityPub pour Discourse. Après quelques discussions, nous sommes arrivés à la spécification ci-dessous. Tous les commentaires ou suggestions sont les bienvenus avant que nous ne la finalisions. Notez que
La prise en charge du contenu entrant (par exemple, les publications sur Mastodon, etc. importées dans Discourse) est intentionnellement exclue. Il sera possible d’ajouter cela dans une version ultérieure.
La prise en charge du suivi des utilisateurs (par opposition aux catégories) est également intentionnellement exclue. Il serait également possible d’ajouter cela dans une version ultérieure.
Pavilion construira le plugin MVP (je vais y travailler), et CDCK le possédera et l’hébergera (c’est-à-dire qu’il s’agira d’un plugin CDCK, pas d’un plugin Pavilion).
Vue d’ensemble
Un plugin ActivityPub (AP) pour Discourse.
L’objectif du plugin est une implémentation MVP des spécifications ActivityPub, ActivityVocab et ActivityStreams dans Discourse avec une intégration démontrée de la fonctionnalité MVP pour une plateforme conforme à l’AP, à savoir Mastodon. Dans la mesure du possible, l’implémentation sera conçue pour prendre en charge davantage les protocoles et toute extension.
Cette spécification concerne l’activation de la prise en charge de l’AP sur une base par catégorie, où seule la première publication de chaque sujet dans une catégorie activée pour l’AP est fédérée (“première publication uniquement”).
Utilisateurs
L’utilisation du plugin sera documentée de manière exhaustive sur meta dans un sujet de plugin.
Utilisateur normal
S’abonne à (également appelé “suit”) une catégorie Discourse activée pour la fédération (FDC) sur Mastodon (ou tout autre service fediverse) en utilisant le pseudonyme de la catégorie, par exemple @announcements@meta.discourse.org.
Voit un extrait de la première publication de tous les sujets FDC (publiés après leur abonnement) dans son flux Mastodon, chacun avec un lien vers le sujet associé, par exemple “Discuter sur notre forum”.
Toute action liée à la publication dans Mastodon n’apparaît pas dans Discourse.
Toute action liée à la publication dans Discourse n’apparaît pas dans Mastodon.
Les extraits de publications fédérées peuvent être contrôlés par l’auteur de la publication à l’aide d’une balise similaire à celle utilisée pour contrôler les extraits de sujets, par exemple <div>{text}</div>
Administrateur
Active la fédération sur une base par catégorie à l’aide d’un paramètre de catégorie. La fédération ne peut être activée que dans les catégories visibles par “tout le monde” sur les instances publiques.
Définit le nom d’utilisateur fédéré de la catégorie via l’interface de paramètres de catégorie (ne peut pas être modifié).
Définit des listes d’autorisation et de refus de domaines via les paramètres du site à partir desquels l’activité est automatiquement acceptée ou rejetée.
Définit une “liste de blocage” de noms d’utilisateur fédérés pour faire partie d’un objet(s) de blocage dans la boîte d’envoi du serveur.
Définit la longueur maximale des caractères d’une note fédérée à l’aide d’un paramètre de site, c’est-à-dire activitypub_note_excerpt_maxlength.
Définit le texte associé au lien inclus dans la première publication d’un sujet Discourse fédéré dans “Personnaliser > Texte”.
Définit si le lien de retour (et le texte) vers le forum est inclus dans les publications fédérées sur une base par catégorie.
Ajoute une paire clé via les paramètres du site pour signer le contenu fédéré.
Technique
Le plugin inclura des tests complets (tests unitaires / d’intégration et tests js).
La catégorie est un Acteur ActivityPub automatisé au sein de Discourse (en tant que Groupe de type Acteur). Le preferredUsername fédéré est défini par l’administrateur lors de l’activation de la fédération et stocké dans un champ personnalisé de catégorie. Le nom fédéré (alias nom d’affichage) est le full_name de la catégorie.
Les utilisateurs sont des Acteurs dans le contenu fédéré par l’Acteur de catégorie. Le preferredUsername fédéré est le nom d’utilisateur Discourse de l’utilisateur au moment de la fédération. Le preferredUsername d’un utilisateur est stocké dans un champ personnalisé d’utilisateur au cas où l’utilisateur changerait son nom d’utilisateur Discourse. Le nom fédéré (alias nom d’affichage) est le nom d’utilisateur Discourse.
En général, les objets ActivityPub seront associés à leurs objets Discourse équivalents à l’aide de champs personnalisés le cas échéant (par exemple, identifiants d’objet ou d’acteur), et de nouvelles tables le cas échéant (par exemple, boîte de réception et boîte d’envoi).
L’activité ActivityPub principale à implémenter est Suivre et les activités et modèles associés requis pour l’implémenter, c’est-à-dire la boîte de réception, la boîte d’envoi et les Actions et Collections associées requises.
Les publications Discourse seraient fédérées en tant que Notes ActivityStream, avec le contenu en HTML.
L’authentification sera gérée à l’aide de signatures HTTP, voir ici et ici. Toutes les autres Considérations de sécurité dans la spécification ActivityPub seront traitées de manière appropriée.
Les points de terminaison de fédération seront protégés comme il convient à la spécification, c’est-à-dire que redirect_to_login_if_required sera utilisé dans les contrôleurs, et que le gardien sera ajouté pour la permission que tout le monde puisse voir la catégorie.
Je suis vraiment ravi de voir cette nouvelle ! Merci ! Je suis également heureux que vous commenciez par une implémentation initiale simple au lieu d’essayer de manger l’éléphant proverbial (ce n’est pas une référence oblique à Mastodon). J’hésite à suggérer d’ajouter quoi que ce soit, mais puisque vous demandez des suggestions, voici une qui, je l’espère, représente un travail insignifiant :
Que penseriez-vous de publier également, en option, des extraits des réponses, en utilisant inReplyTo pour les relier ? Je pense que cela mettrait en évidence le dialogue qui se déroule sur Discourse et serait plus invitant ; avec le message “Discutez sur notre forum”, je m’attendrais à ce que le fait de voir la conversation soit plus susceptible d’attirer plus de monde.
Le problème de la fédération des réponses à ce stade est que vous pourriez créer des attentes d’engagement qui ne seront pas satisfaites tant que vous n’aurez pas un support adéquat. Il est important de maintenir des attentes claires pour les utilisateurs à cet égard. Si certains utilisateurs comprendront les limitations de ces réponses fédérées, d’autres non. L’autre problème est celui de la réduction du nombre de défis techniques à relever en même temps.
Cela dit, nous avons déjà envisagé une extension « sujet entier » à la spécification « premier message uniquement » que vous voyez ci-dessus. J’ai partagé certaines notes techniques à ce sujet ci-dessous pour vous donner une idée de ce à quoi cela pourrait aboutir. Je soulignerais que l’extension « sujet entier » ne fait pas partie de la spécification initiale et n’est qu’une possibilité à ce stade.
Extension sujet entier
Les notes entrantes seraient publiées sous forme de nouveaux sujets ou de réponses (en utilisant inReplyTo ou Replies).
La sécurité et les filtres anti-spam de Discourse seraient appliqués aux objets entrants autant que possible en utilisant Accept / Reject objects.
Les notes seraient attribuées à un utilisateur temporaire associé à l’identifiant de l’acteur via un champ personnalisé. Cela nécessitera une variation non basée sur l’e-mail du concept d’utilisateur temporaire, car l’utilisateur n’aura pas de véritable e-mail (un espace réservé peut être généré en utilisant l’identifiant de l’acteur fédéré et preferredUsername).
L’association d’utilisateurs temporaires ActivityPub avec des utilisateurs Discourse standard serait possible, mais n’est actuellement incluse dans aucune partie de cette spécification. C’est un problème d’« identité fédérée » et de ses solutions associées.
Les messages fédérés ne prendraient pas en charge les @mentions fédérées, ni quoi que ce soit d’autre dans ce sens en dehors des spécifications de base d’ActivityPub/Stream. La prise en charge de telles fonctionnalités pourrait être ajoutée dans des versions ultérieures, par exemple en utilisant Webfinger, en suivant Mastodon.
La clé de cette première version est de se concentrer sur l’implémentation minimale viable. Une fois cette base posée, une fédération complète (ou plus complète), potentiellement dans la lignée de ces notes sur le « sujet entier », sera plus réalisable. Je soulignerais cependant que l’orientation du plugin sera déterminée par CDCK. Tout ce que je mentionne ici ne sont que des façons possibles dont la spécification de base pourrait être construite.
Quelques publications et discussions en cours sur le Fediverse :
PS. Je voudrais également mentionner que j’ai été approché par Daniël Klabbers, développeur principal de Flarum, en novembre dernier, qui m’a dit qu’ils travaillaient sur une extension ActivityPub. Je ne connais pas l’état d’avancement, mais il serait peut-être bon que tous les projets dans le domaine des Forums collaborent pour obtenir autant d’interopérabilité que possible dans cet espace.
Concernant cette interopérabilité, je voudrais également souligner le processus de Fediverse Enhancement Proposal (FEP), le FEP sur Codeberg :
Ici, par exemple, Lemmy a récemment finalisé un FEP pour les groupes ActivityPub. Les discussions ont lieu sur le SocialHub à :
(Le processus FEP prend de l’ampleur avec la croissance du Fediverse et constitue actuellement le meilleur endroit pour standardiser les mécanismes de protocole)
Merci @aschrijver, très utile ! Je me concentrerai personnellement sur l’implémentation du MVP spécifiée ci-dessus, en travaillant en étroite collaboration avec CDCK. Pour reprendre la phrase concise de @mcdanlj, il est essentiel que cet effort n’essaie pas de « manger l’éléphant ». Nous sommes désireux d’entendre tout commentaire constructif sur la spécification, en particulier sur le plan technique.
J’ajouterais cependant que deux autres membres de Pavilion, @nmeyne (un vétéran de la communauté SSI ; en particulier des identifiants vérifiables) et @merefield, travaillent également dans ce domaine et s’intéressent à certaines des questions plus larges que vous avez soulevées.
Pour illustrer les malentendus réels dus à une illusion de fidélité, l’un des problèmes que nous avons rencontrés sur les forums Maker, où nous avons importé de nombreuses communautés Google+ lorsque Google+ a disparu, est que l’importation était d’une fidélité suffisante pour que les nouveaux venus sur le site ne réalisent pas qu’ils essaient d’interagir avec d’autres utilisateurs qui ne sont pas (encore) arrivés sur le site depuis Google+, et nous avons donc une réponse toute faite pour leur faire savoir que la personne à qui ils essaient de parler n’est pas là pour leur répondre.
Merci d’avoir fourni les détails sur l’idée de « l’extension de sujet entier ».
Au cas où cela serait ajouté plus tard… pour information, j’aime beaucoup l’approche qu’offrait Pterotype pour Wordpress, qui consistait à relayer tous les commentaires fédérés directement à la modération / approbation du groupe avant de les renvoyer vers le sujet de discussion d’origine en tant que réponse.
Dans le cas d’un forum, cela pourrait être une tâche mieux adaptée aux types TL4 / TL3 plutôt qu’au personnel.
Personnellement, j’ai trouvé que cela s’avérait particulièrement utile pour empêcher les réponses hors sujet / de type réseau social de submerger le sujet de discussion d’origine.
Oui, l’utilisation de la file d’attente de révision est quelque chose dont nous avons discuté pour le contenu entrant. Comme vous le notez, c’est quelque chose à considérer si et quand nous y parviendrons (pas dans la première version).
Juste une note que les questions administratives concernant ce travail ont été réglées, donc je commence à travailler sur la spécification la semaine prochaine. Tout commentaire technique supplémentaire ou note sur la spécification est le bienvenu.
Il faudra quelques mois pour que cela aboutisse, alors patientez.
Si un message est supprimé dans Discourse, une action Delete peut-elle être envoyée aux abonnés ?
Sur les forums Maker, nous avons suffisamment de « points Google » pour recevoir beaucoup de spammeurs SEO. Nous avons des autorisations relativement souples pour les nouveaux utilisateurs, car une forme d’utilisation courante est une personne frustrée cherchant de l’aide pertinente pour le site, et cela nous aide à les aider plus rapidement. Mais cela signifie que les spammeurs ont tendance à publier un message de spam, puis celui-ci est rapidement signalé comme spam, retiré de la liste, puis supprimé.
J’aimerais que ces messages fédérés soient supprimés et que la suppression soit publiée via Delete afin que nous puissions nettoyer le spam des caches fédérés. Est-ce éventuellement dans le périmètre ?
Il pourrait être utile dans ce cas d’avoir un délai pour la fédération, d’un certain nombre d’heures, pour permettre de traiter le spam avant la fédération. (Peut-être même appliquer le délai uniquement aux premiers messages des utilisateurs relativement nouveaux ?)
J’anticipe que nous ferons cela dans le MVP pour les raisons que vous mentionnez. J’en discuterai plus en détail avec les gens de Discourse au bon moment.
Suggestion utile. La fédération sera certainement asynchrone. La manière dont le délai est défini et géré est quelque chose que nous devrons aborder d’une manière ou d’une autre dans le MVP.
Les suggestions spécifiques comme celles-ci pour le MVP, en particulier basées sur des cas d’utilisation antérieurs ou une expertise technique du domaine, sont les bienvenues.
Si ce n’est pas un travail considérablement plus important au départ, la fédération des modifications de messages en tant qu’activités Update serait également précieuse. S’il s’agit de quelque chose qui peut être ajouté après le MVP, alors une conception qui permet raisonnablement de l’ajouter plus tard serait formidable.
Pour ce que ça vaut, je réglerais le délai bas sur mon/mes instance(s). Je n’envisagerais pas de l’utiliser pour éviter de fédérer des messages de spam, car ce serait raisonnablement susceptible d’être un signal qui amènerait un modérateur de son flux fediverse dans notre Discourse pour agir. J’ai chat_integration_delay_seconds réglé sur 20 pour des modifications rapides de fautes de frappe, et je m’attendrais à faire quelque chose de similaire ici. À tout le moins, ce paramètre établit un précédent pour un tel délai.
Une brève mise à jour ici ! Nous sommes à un mois du développement et, dans les grandes lignes, nous avons maintenant ce qui suit qui fonctionne :
Les gens peuvent suivre des catégories avec ActivityPub activé
Le premier message des sujets dans les catégories activées par ActivityPub est fédéré aux abonnés
Il y a un certain nombre de petites choses aussi, mais qui ne valent pas la peine d’être abordées à ce stade. Il y aura au moins un mois de développement supplémentaire avant que nous commencions les tests internes.
