Un problème courant auquel sont confrontés de nombreux utilisateurs de Discourse est l’incapacité d’afficher une agrégation de tous les groupes d’intérêt auxquels ils sont abonnés. Il n’existe aucun moyen simple de consommer du contenu provenant de plusieurs instances Discourse sous la forme d’un fil d’actualité utilisateur centralisé et social. Les plateformes centralisées comme Reddit contournent ce problème en proposant un unique identifiant de connexion pour toutes les communautés et un flux agrégé de toutes les communautés affiché dans un seul flux sur la page d’accueil de reddit.com. C’est cette dernière fonctionnalité que nous souhaitons reproduire dans Discourse grâce au protocole ActivityPub.
Par exemple, la personne A fréquente plusieurs instances Discourse : une pour la politique, deux pour des loisirs, une pour son forum de quartier local, mais n’a aucun moyen de consommer tout le contenu pertinent dans un seul et même flux. En comparaison, si vous avez rejoint plusieurs groupes Facebook ou plusieurs subreddits, les publications les plus pertinentes apparaissent déjà dans votre fil d’actualité.
Spécification (v1)
Nous pourrions prototyper un MVP en activant les fonctionnalités suivantes via un plugin Discourse :
Générer un flux ActivityPub à la demande (pour chaque page disposant déjà d’un flux RSS)
Similaire à l’ajout de .rss à l’URL, cela permettra de récupérer du contenu en utilisant le protocole AP en accédant au bon point de terminaison.
Nous pourrions même être en mesure de l’activer pour du contenu privé en ajoutant des clés API utilisateur à l’URL.
Permettre aux administrateurs de forum d’activer ActivityPub (sortant) par catégorie ou de le laisser activé par défaut ? (Je crois que @Falco avait quelques idées à ce sujet)
Trouver un moyen de consommer ce contenu sur un forum Discourse / un flux Mastodon (entrant)
Prochaines étapes
Nous devons absolument commencer petit, nous devons donc d’abord décider d’un ensemble restreint et réalisable de fonctionnalités qui seront incluses dans la première itération. J’ai parcouru le protocole ActivityPub mais je ne connais pas encore très bien son fonctionnement interne. Par conséquent, j’invite d’autres personnes qui ont montré un vif intérêt pour ce sujet à rejoindre la discussion (@Falco, @hellekin, @merefield) afin de nous aider à élaborer une spécification réalisable pour la première itération et de recommander des modifications à la spécification ci-dessus.
Je commencerais par dire : ne devrions-nous pas nous concentrer d’abord sur le quoi plutôt que sur le comment ? L’architecture technique vient plus tard. La raison pour laquelle je dis cela, c’est que cela pourrait limiter les fonctionnalités si elle est choisie trop tôt.
J’aimerais beaucoup voir pour la Version 1. des listes de « Découverte de la Découverte », en commençant par :
une liste « Derniers » qui affichait un aperçu de chaque sujet récent des sources incluses (simple union des listes Derniers de toutes les sources)
une liste « Surveillés », qui affichait un aperçu de chaque Sujet pour lequel vous avez choisi d’être notifié en cas d’activité. (cela s’inspire de l’application mobile existante : elle étend les notifications de nouvelle activité sur les Sujets surveillés vers les aperçus des Sujets eux-mêmes).
Je dois dire que la proposition originale, qui fait une analogie avec Facebook, me dépasse : je n’ai aucune idée de ce que fait Facebook, et je ne comprends pas en quoi cela se rapporte à Discourse.
Ma compréhension du support d’ActivityPub pour Discourse est qu’il pourrait aider à fédérer des sujets, voire à partager une catégorie entre plusieurs instances Discourse. Par exemple, un sujet d’annonce sur discourse.joinmastodon.org pourrait être fédéré vers socialhub.activitypub.rocks dans la catégorie #software:mastodon correspondante : là-bas, les utilisateurs locaux pourraient aimer, répondre, citer, etc., comme s’il s’agissait d’un sujet local, sauf que le sujet original résiderait sur l’instance de joinmastodon.
Un autre aspect est que, si l’on dispose d’un compte sur les deux instances, il devrait être possible de les lier, c’est-à-dire d’utiliser une instance Discourse spécifique comme fournisseur d’identité principal. Je comprends que ce n’est pas l’objectif d’une première itération, mais il est bon de garder cela à l’esprit, car nous pourrions finir par avoir une option « Se connecter avec [insérez ici votre implémentation ActivityPub préférée] ».
Ce que je comprends des propositions ci-dessus, c’est une réplication de l’application Discourse sur Android, où vous avez une liste d’instances et recevez des notifications de toutes. Il semble un peu dangereux de mélanger des réponses sans rapport provenant de nombreuses sources, surtout lorsqu’elles perdent leur contexte.
Ai-je bien compris, et ma compréhension constituerait-elle une bonne deuxième étape pour votre vision de l’intégration d’ActivityPub avec Discourse ?
Toutes les implémentations actuelles d’ActivityPub s’attendent à ce que les publications soient émises par des Acteurs stables. Vous aurez donc probablement besoin de l’une des options suivantes :
Un compte système publiant toutes les publications
Un compte par flux suivable
Un compte par flux suivable, qui fait des Announce de publications supposées être rédigées par un compte correspondant à chaque utilisateur Discourse
La première option est probablement la plus simple à mettre en œuvre ; la troisième assure la meilleure intégration des modèles de données.
Il y a aussi le choix de publier le contenu complet des sujets, uniquement les premiers messages des sujets, ou quelque chose de similaire aux flux Twitter de StackExchange où des publications distinctes promeuvent des messages depuis la page /top. Ou bien cela pourrait simplement être le fonctionnement du flux « meilleurs messages », tandis que les autres flux publient tout…
Sur le plan technique, l’URL ne devrait pas avoir besoin de changer : tous les serveurs enverront Accept: application/activity+json ou ses variantes.
Une application de lecture qui mélange des flux provenant de différentes sources à différents moments dans ActivityPub — recréant la « chronologie algorithmique » comme une option facultative — est quelque chose que je souhaite depuis un moment, et qui ne semble pas exister aujourd’hui.
@hellekin : Je pense que l’écriture inter-domaines risque fortement de contourner de nombreuses protections anti-spam mises en place par Discourse. La lecture est plus importante à implémenter : après tout, la lecture est fondamentale !
Je ne pense pas : les utilisateurs distants pourraient toujours être mis en file d’attente, sauf s’ils lient leur compte distant à un compte local, auquel cas l’antispam s’appliquerait à ce compte.
Je n’ai jeté qu’un coup d’œil rapide aux commentaires, je dois l’avouer. Je suggérerais que chaque catégorie soit un acteur distinct (avec le type “Groupe”). Ainsi, les personnes de l’extérieur pourraient simplement s’abonner à des catégories spécifiques. Les publications dans ces catégories pourraient alors être réalisées en annonçant les publications des utilisateurs via le compte “Groupe”. Nous aurions ainsi à la fois la catégorie et l’auteur. C’est ainsi que nous procédons avec notre propre logiciel. Avec l’utilisation de signatures JSON-LD, cela serait sécurisé même pour les catégories non publiques.
La question est de savoir quoi faire des commentaires provenant de l’extérieur. Je suggérerais que les comptes de groupe soient définis comme “validation manuelle”. On pourrait alors ajouter un processus de validation pour éviter le spam aléatoire. Ces comptes validés pourraient ensuite commenter ces publications.
Cela permettrait immédiatement aux personnes de (presque) tout le fédéivers de se connecter et d’interagir avec les systèmes Discourse.
Chaque groupe de catégorie puisse avoir un propriétaire disposant du pouvoir de gérer la catégorie : contrôler les permissions de publication, bannir ou supprimer des utilisateurs, définir la visibilité (publique ou privée)…
Les utilisateurs locaux puissent créer des catégories sur leur instance, à condition que le personnel de l’instance approuve ces créations.
Si un propriétaire de catégorie ne convient pas à sa fonction, le personnel du site puisse le remplacer.
C’est ainsi que fonctionnent de nombreux forums et communautés centralisés. Ce qu’il reste à améliorer, c’est de rendre cela fédéré.
Néanmoins, il subsiste encore des problèmes :
Les id des acteurs doivent-ils être mutables ? Les noms d’utilisateur de Discourse peuvent être configurés comme modifiables dans les paramètres du site. Cependant, je doute que d’autres logiciels AP puissent gérer cela. Is Object's `id` immutable? - ActivityPub - SocialHub
(À compléter)
Quelqu’un de l’équipe Discourse viendra au SocialHub à l’OFFDEM la semaine prochaine ? Ce serait un excellent moment pour rencontrer et échanger avec d’autres implémenteurs d’AP.
@heluecht et @misaka4e21 ont évoqué le support de l’acteur Group. Une discussion en cours a lieu sur SocialHub concernant les moyens de mettre cela en œuvre de manière plus ou moins standardisée.
5 « J'aime »
sl007
(Sebastian Lasse | @sl007@mastodon.social)
14
Félicitations pour le financement de l’UE !
Y a-t-il une feuille de route ?
Quelqu’un de l’équipe Discourse sera-t-il présent à la conférence ActivityPub ?
Ce serait un excellent moment pour rencontrer et échanger avec d’autres implémentateurs d’AP. https://conf.activitypub.rocks
Nous espérons discuter de l’implémentation d’ActivityPub dans Discourse lors de la session Birds of a Feather dimanche prochain, pendant APConf2020. Consultez le sujet dédié sur SocialHub :
@rishabh, il serait formidable de vous avoir parmi nous, au moins dans le sujet si vous ne pouvez pas être présent dimanche. Nous ne connaissons pas encore l’heure exacte, mais cela aura lieu dimanche matin. Je mettrai à jour ce message dès que j’aurai plus d’informations.
Désolé de ne pas avoir pu y être. Je dois t’informer que nous n’avons pas postulé pour le financement NGI0 et que personne ne travaille actuellement sur ce sujet. Je ne suis pas non plus la meilleure personne pour mener cela, car je ne connais pas bien le protocole, mais je vais prévenir @Falco pour voir s’il a des idées ou s’il serait intéressé à prendre le relais.
Eh bien, à l’époque, l’un de vos membres d’équipe l’a fait – même s’il n’est plus dans l’équipe – et vous avez été sélectionné, donc quelqu’un a dû l’approuver. Je ne sais donc pas à quel « nous » vous faites référence. En tout cas, j’ai hâte d’échanger avec @Falco. Un certain support AP serait vraiment utile pour la communauté ActivityPub, surtout car cela faciliterait le travail entre les instances Discourse et améliorerait l’intégration avec le Fediverse.
Je suis conscient du problème de lutte contre le spam, mais je pense qu’il peut être atténué en traitant les utilisateurs du Fediverse comme des utilisateurs non enregistrés (par exemple, par e-mail) jusqu’à ce qu’ils créent réellement un compte local.
Bien sûr, ce serait vraiment agréable de voir cela.
Oui, nous avons effectivement postulé pour ce financement par le passé, mais nous avons parlé avec l’équipe NLnet plus tôt cette année pour clore le projet et libérer le financement qui nous était réservé. Même si nous avions été sélectionnés à l’époque, la collaboration avec NGI0 est annulée pour l’instant. Bien sûr, nous sommes libres de faire des propositions à l’avenir.
Je viens de me souvenir que @riking pourrait aussi être intéressé
1 « J'aime »
sl007
(Sebastian Lasse | @sl007@mastodon.social)
20
Intéressant.
Ce projet a été financé par le NGI0 Discovery Fund, un fonds créé par NLnet avec le soutien financier du programme Next Generation Internet de la Commission européenne, sous l’égide de la DG Communication, Réseaux, Contenus et Technologies, dans le cadre de la convention de subvention n° 825322.
Donc : parlent-ils d’un autre « Discourse » ?
Je pose la question à cause du « Site web du projet : https://discourse.org »…
Oh, je ne savais pas que cette page existait. J’envoie un e-mail à notre contact chez NLnet pour les relancer au cas où ils auraient oublié de la retirer, et je publierai une mise à jour ici.
En tout cas, j’ai hâte d’échanger avec