Oui, Discourse pourrait faire quelque chose de similaire avec son widget d’intégration de commentaires. Entre autres choses, cela pourrait aider à réduire la gêne que certaines personnes éprouvent lorsqu’elles lancent un forum qui n’a que quelques utilisateurs actifs : AI sockpuppet accounts to jumpstart my community?. Les nouveaux sites Discourse pourraient utiliser des articles de blog pour promouvoir et amorcer leur forum. C’est en quelque sorte possible maintenant, mais permettre aux utilisateurs de commenter directement depuis le widget d’intégration rendrait le processus plus transparent.
3 « J'aime »
Un simple formulaire de commentaire connecté à Discourse du côté Wordpress, afin que les visiteurs n’aient pas à aller d’abord sur Discourse et à y créer un compte avant de poster un commentaire, aiderait à réduire les frictions et à renforcer l’engagement, du moins pour les éditeurs comme moi.
Dans mon cas d’utilisation, il serait idéal qu’un commentateur puisse laisser son commentaire simplement avec un nom et une adresse e-mail. Cela pourrait ensuite être utilisé pour créer un utilisateur temporaire dans Discourse et l’inviter à rejoindre pleinement pour continuer la conversation, sans l’empêcher de laisser son commentaire.
Nous constatons que la friction supplémentaire liée à la création d’un compte pour laisser un commentaire sur un article publié rend difficile le renforcement de l’engagement et, à terme, la croissance de la communauté sur notre forum. Par exemple, lorsqu’on lui a posé des questions sur notre section de commentaires (en utilisant l’intégration actuelle Discourse-Wordpress), un auteur nous a donné le retour suivant :
Concernant la zone de conversation : maintenant que vous le mentionnez… je me souviens l’avoir vue. Et à l’époque, j’ai pensé que je l’oublierais pour le moment car cela semblait prendre du temps de s’inscrire. C’est une preuve solide de ce que la plupart des gens ressentiraient à devoir passer par ce processus. Je suis normalement obsédé par le fait de voir des commentaires sur mes écrits. Je me souviens avoir ri en moi-même et dit : “Je suppose que je ne suis pas assez obsédé pour m’en occuper maintenant.” Idéalement, vous devriez laisser les commentaires ouverts à tout le monde sans processus d’inscription. Mais tout niveau de simplification/facilité améliorerait l’engagement. Les commentaires comme ceux-là sont généralement un acte impulsif. Si les gens sont bloqués, ils ont tendance à passer à autre chose et à ne pas prendre le temps.
3 « J'aime »
Je pensais justement à ça l’autre jour. Étrangement, mes articles de blog me manquent car il semblait si rapide pour les gens de commencer, une très faible barrière à l’entrée.
Malgré un processus d’inscription très simple, actuellement, si quelqu’un veut commenter un article, il doit visiter une nouvelle page. Je pense que franchir ce seuil peut sembler trop lourd. C’est presque comme si je voulais commenter A, mais que je devais visiter B pour commenter A, puis retourner à A pour voir le commentaire. Il serait plus naturel de commenter A juste en dessous de A.
J’aime l’idée de mettre en scène des utilisateurs. Je peux imaginer bricoler cela en faisant en sorte que le formulaire de commentaire Wordpress envoie un e-mail au forum Discourse, puis en créant un utilisateur de cette manière, bien que j’imagine que cela pourrait devenir plus complexe à intégrer complètement de cette façon.
3 « J'aime »
Je pense que c’était possible auparavant, mais je suis à peu près sûr que Discourse compare maintenant l’en-tête « From » de l’e-mail avec son chemin de retour. Si ceux-ci ne correspondent pas, l’e-mail est rejeté. (Si Discourse ne vérifie pas le chemin de retour, le système de commentaires pourrait être facilement exploité - n’importe quelle adresse e-mail pourrait être saisie dans le formulaire.)
Il y a plusieurs façons d’aborder le problème de Discourse en tant que système de commentaires. Je pense que la meilleure approche serait que Discourse améliore son iframe d’intégration de commentaires afin que les utilisateurs puissent interagir avec lui en tant qu’utilisateurs Discourse authentifiés. Si ce n’est pas possible, une application web de commentaires Discourse intégrée pourrait être développée. Ce serait un projet intéressant, mais je voudrais m’assurer que Discourse ne fournira pas de fonctionnalité similaire via son iframe de commentaires intégrée avant de poursuivre trop loin.
Il existe également quelques solutions spécifiques à WordPress. La plus simple étant d’activer les commentaires WordPress et le plugin WP Discourse. Le risque est que cela réduise l’activité sur le forum Discourse. Je pense qu’il y aurait des moyens d’aider à cela dans l’interface utilisateur de WordPress, par exemple, en créant des liens vers des conversations connexes qui se déroulaient sur Discourse.
Il serait également possible de développer quelque chose de spécifique aux sites WordPress qui fonctionnaient comme fournisseur d’authentification unique (SSO) Discourse. J’en ai parlé dans des articles précédents sur ce sujet. Pour bien faire, cela pourrait nécessiter des changements importants dans le plugin WP Discourse. Sauf si (je réfléchis à voix haute ici) :
Ce que j’essaie d’indiquer avec la capture d’écran ci-dessus, c’est que pour le cas d’un site WordPress qui est le fournisseur d’authentification unique (SSO) Discourse, les commentaires pourraient être affichés avec l’iframe de commentaires Discourse. Les commentaires pourraient être créés via un formulaire qui publie sur l’API Discourse. Cela pourrait nécessiter quelques modifications de l’iframe de commentaires Discourse pour s’assurer qu’il se rafraîchit lorsqu’un nouveau commentaire est ajouté, mais ne nécessiterait pas que les utilisateurs puissent interagir avec lui en tant qu’utilisateurs Discourse authentifiés.
4 « J'aime »
Donc, si je comprends bien, l’idée serait que le commentateur s’inscrive du côté WordPress, puis laisse un commentaire via l’iframe Discourse intégrée, qui serait publié sur le sujet dans Discourse, puis rafraîchirait l’affichage sur WordPress, de sorte qu’il apparaisse immédiatement.
Le processus d’inscription WordPress validerait l’e-mail, je suppose. Mais cela nécessiterait également de passer à WordPress comme fournisseur Discourse SSO — faisable, mais d’une certaine manière regrettable, car cela déplace la friction vers l’autre côté pour les personnes qui souhaitent simplement s’inscrire au forum.
J’ai tendance à être d’accord avec ce que vous avez dit ici :
S’il était même possible de s’inscrire directement dans l’iframe, ou au moins d’être mis en scène, de sorte que l’on puisse procéder au commentaire (qui ne serait peut-être publié qu’une fois l’e-mail validé), cela me semblerait être une solution qui équilibre la facilité d’utilisation et la sécurité.
2 « J'aime »
Oui, vous avez bien compris. Si WordPress est le fournisseur SSO, le problème de permettre aux utilisateurs de commenter des sujets Discourse n’est pas très difficile à résoudre. La partie délicate, en termes de travail avec l’état actuel du plugin WP Discourse, est de déterminer comment afficher les commentaires sur WordPress - actuellement, la section de commentaires de WP Discourse ne reflète pas les réponses du sujet Discourse. Au lieu de cela, une sélection des « meilleurs » commentaires est affichée.
Il serait possible de mettre à jour le plugin WP Discourse pour gérer ce cas d’utilisation, mais pour le faire correctement, il faudrait réécrire complètement la façon dont il gère les commentaires Discourse. Ce n’est pas ma décision, mais je pense qu’investir des efforts dans l’amélioration de l’iframe de commentaires Discourse serait une meilleure utilisation du temps.
5 « J'aime »
Je voulais juste ajouter ma voix pour vouloir cette fonctionnalité.
Ce serait vraiment bien si les utilisateurs sur WP pouvaient simplement s’inscrire/se connecter et commenter directement sous un article sur WP sans avoir à naviguer vers le forum, de sorte que l’ensemble ressemble davantage à un système de commentaires. Leur commentaire apparaîtrait à la fois sous l’article et dans le fil de discussion qui a été créé. Et ils ont toujours le choix de publier soit sur Discourse, soit sur WordPress, soit sur les deux - de manière transparente. Je n’ai aucune idée de la façon dont cela serait réalisé, mais ce serait un moyen vraiment transparent d’intégrer les commentaires WP avec Discourse qui semble moins maladroit et améliorerait sans aucun doute considérablement le nombre de commentaires que nous obtenons actuellement avec le plugin existant.
3 « J'aime »
Peut-être ceci :
Mais cela détourne totalement la connexion de Discourse AFAIK.
Cela permettrait-il aux utilisateurs de publier des commentaires directement sous un article WordPress et de remplir automatiquement cet article dans le fil de discussion Discourse correspondant ?
Je travaille sur cela maintenant. La première version est destinée à un site WordPress headless qui utilise le framework Remix pour son front-end. Une fois cela fait, je ferai une version pour les sites WordPress classiques. Ce sera probablement un plugin qui étend le plugin WP Discourse. J’espère que la plupart de ce que je fais sur le site WordPress headless pourra être transféré aux sites WordPress classiques, mais cela pourrait nécessiter des compromis.
Permettre aux utilisateurs de commenter directement depuis un site externe est trivial à implémenter. La principale exigence est que le site externe ait accès aux identifiants de l’utilisateur Discourse. Cela peut être fait soit en utilisant le site externe comme fournisseur DiscourseConnect pour Discourse, soit en configurant Discourse comme fournisseur DiscourseConnect pour le site externe.
Dans le second scénario - où le site externe n’est pas le fournisseur DiscourseConnect pour Discourse - la première fois qu’un utilisateur souhaite commenter depuis le site externe, il devra cliquer sur un lien pour connecter son compte sur le site externe à son compte Discourse (ou pour s’inscrire sur Discourse s’il ne l’a pas encore fait). Cela peut être assez transparent du point de vue de l’utilisateur.
Le changement ci-dessus ne donne pas l’impression d’un système de commentaires classique. Une attente normale pour un système de commentaires est que vous puissiez lire et interagir avec tous les commentaires. Le plugin WP Discourse n’affiche qu’une sélection de commentaires extraits d’une route spéciale fournie par Discourse. Il ne fournit aucune fonctionnalité pour interagir avec les commentaires.
Les parties difficiles du problème sont :
- la pagination de tous les commentaires d’un sujet sur WordPress, en gardant à l’esprit qu’il pourrait y en avoir des milliers
- fournir une interface utilisateur qui donne à l’utilisateur un retour sur sa position dans une longue liste de commentaires
- déterminer comment afficher les commentaires qui sont des réponses directes à d’autres commentaires. (La convention de Discourse à ce sujet est en décalage avec la façon dont la plupart des systèmes de commentaires gèrent les réponses.)
- permettre aux utilisateurs de répondre directement à un commentaire, d’aimer un commentaire, de modifier leurs propres commentaires, etc.
- gérer les commentaires créés sur Discourse qui pourraient contenir du contenu ou du balisage qui ne peuvent pas être facilement rendus ou avec lesquels on ne peut pas interagir sur le site externe. Par exemple, les oneboxes, les sondages…
- fournir un moyen de filtrer les commentaires par récents, plus anciens, meilleurs, etc…
Tout cela doit être accompli sans surcharger le serveur du site externe, sans faire trop de requêtes API à Discourse, ou sans consommer trop de mémoire sur l’appareil de l’utilisateur (l’objectif est de créer un système de commentaires léger). C’est réalisable, mais ce n’est pas quelque chose qui peut être simplement intégré dans le code WP Discourse existant sans y apporter des modifications importantes.
4 « J'aime »
Bonne nouvelle que vous ayez commencé !
Juste une idée : comme une partie de l’idée est de réduire les frictions pour que les gens commentent en premier lieu, ce pourrait être une bonne idée de se concentrer sur la fluidité de ce premier commentaire. Comme mentionné ci-dessus, il semble que beaucoup de gens veuillent simplement pouvoir commenter avec leur adresse e-mail ; le problème est alors la validation et la connexion, ou la création de compte (selon, je suppose, la configuration de DiscourseConnect).
Une fois qu’un utilisateur est entré, je m’attendrais à ce qu’il soit plus susceptible de visiter le sujet de discussion correspondant pour obtenir toutes les fonctionnalités de discussion basées sur Discourse. J’espère juste que toutes ces parties difficiles du problème n’entraveront pas la résolution du problème du « premier commentaire ». Avoir des milliers de commentaires pour lesquels nous devrons trouver la pagination serait alors un « bon problème à avoir ». 
4 « J'aime »
Ceci me suffit car les nouveaux et les anciens utilisateurs participeront et interagiront les uns avec les autres. Ce n’est pas grave pour moi, un externe
Ouais, c’est une préoccupation légitime. La première étape consiste à mettre en ligne un site de démonstration. Avoir un site en direct pour tester les choses devrait rendre évidents les points de friction.
Il serait techniquement possible de permettre aux utilisateurs anonymes de commenter les publications. La seule façon non bidouille que je puisse imaginer serait que les commentaires soient publiés au nom de l’utilisateur anonyme par un utilisateur réel. Cela semble un peu étrange cependant.
Je sais que WordPress a un paramètre pour permettre aux utilisateurs « invités » de créer des commentaires. Il a la limitation qu’un commentaire « invité » ne sera pas associé à un utilisateur réel si l’utilisateur qui a créé le commentaire invité s’inscrit sur le site après avoir créé le commentaire. Publier « au nom de » un utilisateur devrait fonctionner de manière similaire - il n’y aurait aucun moyen de savoir que l’utilisateur qui a créé le commentaire anonyme était le propriétaire de l’adresse e-mail qu’il avait fournie avec le commentaire.
Idéalement, les utilisateurs seront authentifiés sur le site externe ou sur Discourse avant de créer un commentaire.
Du point de vue de l’utilisateur, le moins de friction possible serait le cas où le site externe est le fournisseur SSO pour Discourse. Cela leur permettrait de commenter les sujets Discourse sans jamais avoir à visiter le site Discourse.
Du point de vue du propriétaire du site, le moyen techniquement le plus simple d’authentifier les utilisateurs serait que Discourse fonctionne comme un fournisseur d’authentification pour le site externe. C’est la configuration que j’utilise actuellement sur mon site de test local. Le site externe (Remix) n’a même pas de table d’utilisateurs. Il crée simplement une session utilisateur basée sur la réponse de la route /session/sso_provider de Discourse.
L’inconvénient d’utiliser Discourse comme fournisseur d’authentification pour le site externe est qu’il oblige les utilisateurs à passer par le processus d’inscription/connexion de Discourse. Il n’y a rien de mal à ce processus, sauf qu’il semble forcer les utilisateurs à télécharger tous les actifs Discourse alors qu’ils pourraient simplement vouloir laisser un commentaire sur le site externe. C’est donc un peu lent. Je vais enquêter davantage…
Ce le serait Peut-être réduire cela à des centaines pour un scénario plus réaliste. Le point que j’essaie de faire est que le problème devient complexe une fois que vous dépassez 1 page de publications (20 publications).
Modifier : il serait possible d’utiliser les invitations Discourse pour simplifier le processus - si un utilisateur anonyme voulait commenter une publication, un champ e-mail serait affiché avec le formulaire de commentaire. La soumission du commentaire déclencherait Discourse pour envoyer une invitation à l’adresse e-mail. Le commentaire serait conservé dans une file d’attente jusqu’à ce que l’invitation soit acceptée. Cela permettrait aux utilisateurs de créer le commentaire lorsqu’ils en ressentent l’inspiration et de recevoir un retour immédiat sur le statut de leur commentaire.
4 « J'aime »
J’ai hâte de voir quelle sera la solution de @simon ici.
Je voulais juste noter qu’une solution qui se développe sur une voie différente sur ce front est l’utilisation d’ActivityPub. Dans sa dernière version, le plugin officiel Wordpress ActivityPub a ajouté la prise en charge du plugin Discourse ActivityPub.
Cela signifie que si vous avez le plugin Wordpress ActivityPub installé et le plugin Discourse ActivityPub installé, tout ce que vous avez à faire est de configurer une catégorie pour “Suivre” un acteur Wordpress qui publie (ou le site Wordpress entier) et vos publications Wordpress apparaîtront comme de nouveaux sujets dans cette catégorie Discourse.
(notez que le plugin Wordpress a un délai de publication, c’est pourquoi il faut une minute pour qu’il apparaisse dans Discourse dans la vidéo ; passez à 1:40 pour le voir apparaître).
Le plugin Wordpress ActivityPub prend également en charge l’ingestion d’activités, et est déjà configuré pour traiter les activités entrantes en réponse à une publication comme un “Commentaire” sur cette publication, cependant cette partie particulière ne fonctionne pas encore avec les activités envoyées par le plugin Discourse (je pense que le plugin Wordpress ne prend pas encore en charge les notes annoncées). Mais cela devrait bientôt fonctionner aussi.
Voir plus loin
6 « J'aime »
Notez que Matthias, le mainteneur du plugin Wordpress, a réussi à faire fonctionner cela, il devrait donc bientôt y avoir une prise en charge du partage de publication et des commentaires natifs bidirectionnels entre Discourse et Wordpress (via ActivityPub).
https://socialhub.activitypub.rocks/t/this-is-a-test-federation/4164/2
https://pfefferle.org/this-is-a-test-federation/#comment-148
3 « J'aime »
Ce sujet a commencé avec l’idée qu’un système de commentaires propulsé par Discourse pourrait fournir une fonctionnalité similaire à Coral, avec l’avantage supplémentaire de permettre aux commentaires d’un site web de se transformer en sujets Discourse classiques. Discourse offre la possibilité de modérer les commentaires d’un site web et permet aux discussions liées aux commentaires de se dérouler sur le forum.
Je ne pense pas qu’il soit nécessaire de justifier le besoin de modération.
Le besoin de permettre aux commentaires de se transformer en véritables sujets Discourse pourrait être moins évident. Je pars du principe que toute conversation en ligne est difficile - la conversation en personne fournit toutes sortes d’indices subtils qui n’existent pas en ligne. Avoir des conversations en ligne significatives avec plus qu’une poignée de personnes est presque impossible. C’est là qu’intervient Discourse. La fonctionnalité de groupe de Discourse offre la possibilité de limiter qui peut participer à un sujet. Des groupes de commentateurs peuvent être autorisés à participer à des sujets Discourse isolés. C’est un peu le contraire du fonctionnement du fediverse.
Cela dit, je suis curieux de savoir comment l’intégration de Discourse/WordPress dans le fediverse pourrait fonctionner. Par exemple, si Sally commente un article WordPress de Bob, que devrait-il se passer pour le commentaire de Sally si elle avait un compte Discourse ? Que devrait-il se passer pour le commentaire de Sally si elle n’avait pas de compte Discourse ? Y a-t-il un moyen pour Sally de refuser que son commentaire soit publié sur le fediverse ?
Hors sujet, mais avec les différents types de lois sur les préjudices en ligne qui sont mises en œuvre ou proposées dans les pays occidentaux, si le commentaire de Sally est jugé offensant, qui est responsable de sa publication ? Je suppose que c’est une question sans réponse pour le moment.
3 « J'aime »
Intéressant !
La façon dont je suggérerais de réfléchir au fonctionnement d’ActivityPub avec la modération et le regroupement (et d’autres rubriques de communication en ligne) est qu’il s’agit principalement d’une norme de communication. Elle fournit certains mécanismes pour traiter ces questions, mais les laisse largement aux divers clients du système.
L’e-mail, en tant que norme de communication, est une analogie imparfaite, mais peut-être utile. « L’e-mail » est une collection de normes de communication qui vous permet d’échanger des messages avec n’importe qui sur Internet. Il présente divers problèmes de « contrôle qualité », par exemple le spam. Certains aspects de la collection de normes que nous appelons « e-mail » aident à traiter ces problèmes (par exemple, DMARC, DKIM, SPF, etc.), mais la principale façon dont le contrôle qualité est géré est peut-être dans les clients de messagerie eux-mêmes. Gmail est devenu un client de messagerie populaire en partie parce qu’il gérait apparemment très bien le spam (et les problèmes de contrôle qualité similaires).
En suivant l’analogie, Discourse serait le « Gmail » d’ActivityPub. Tous les outils de modération, le regroupement d’utilisateurs et les autres fonctionnalités qui font de Discourse une excellente plateforme de discussion sont (à peu près) toujours disponibles dans le contexte d’ActivityPub. Je vais développer cela en commençant à répondre à vos questions.
Je vais commencer par décrire ce qui se passe, puis nous pourrons peut-être passer aux questions plus nuancées. Je vais laisser de côté beaucoup de choses ici, dans le but de répondre aux bases :
-
Le commentaire de Sally est publié en tant qu’objet ActivityPub depuis WordPress.
-
L’objet est ingéré dans Discourse et converti en un message.
-
Si l’« Acteur » de Sally est associé à un compte utilisateur dans Discourse, le message sera associé à ce compte utilisateur. Si son Acteur n’est pas déjà associé à un compte utilisateur, un utilisateur temporaire sera créé à partir de l’acteur de Sally et il sera propriétaire du message.
Vous pouvez voir ce qui précède en action dans ce sujet :
-
La catégorie Discourse WordPress - SocialHub suit le WordPress de Matthias.
-
Matthias a publié un nouvel article sur son blog en utilisant son compte WordPress habituel.
-
Cela est apparu dans Discourse comme un nouveau sujet, le message étant associé à un utilisateur temporaire associé à l’Acteur de Matthias.
-
La façon dont les commentaires fonctionnent est exactement la même.
Juste pour répondre à la question la plus évidente : Matthias peut-il réconcilier l’utilisateur « temporaire » créé à partir de son acteur WordPress et de son compte Discourse normal sur ce serveur ?
La réponse à court terme est que le plugin Discourse dispose d’un ensemble de fonctionnalités d’« Autorisation » qui vous permet actuellement de revendiquer la propriété de vos acteurs d’autres serveurs Discourse ou Mastodon, ce qui fusionne tous les utilisateurs temporaires dans votre compte (ce qui signifie que vous possédez désormais les messages dans votre compte Discourse principal). Cet ensemble de fonctionnalités pourrait être étendu à WordPress. J’apprécie que ce soit un peu verbeux, et il pourrait être plus facile de comprendre ce que je veux dire avec cette démo :
La réponse à plus long terme est que les preuves d’identité pourraient être intégrées aux activités ActivityPub à un moment donné, supprimant peut-être le besoin d’une autorisation pilotée par l’utilisateur, ce qui signifie que la « réconciliation » pourrait être (plus) automatique.
Peut-être qu’une autre question est de savoir si la « réconciliation » est nécessaire, étant donné que Matthias contrôle toujours les attributs d’identité de son utilisateur temporaire via son Acteur ActivityPub (qui est modifiable sur WordPress, les modifications se répercutant sur l’utilisateur temporaire sur Discourse).
Je dis la plupart de ces choses comme une forme de mise en bouche, afin que nous puissions passer à vos questions plus nuancées et importantes. J’espère que je me fais comprendre jusqu’à présent.
2 « J'aime »
C’est clair.
Concernant le problème de modération, je parle de l’utilisation de Discourse pour modérer les commentaires WordPress. C’est la fonctionnalité qui permettrait d’utiliser Discourse de manière similaire à Coral. C’est facile à réaliser si les commentaires WordPress sont en réalité des commentaires Discourse publiés de WordPress vers Discourse via l’API. Cela fonctionne tout simplement. Cela permet par exemple d’utiliser des outils de modération basés sur l’IA fournis par Discourse. Je me demande si quelque chose de similaire pourrait être réalisé avec l’intégration ActivityPub de WordPress/Discourse.
Quelle est la preuve d’identité pour l’utilisateur temporaire ? Son adresse e-mail est-elle transmise depuis le serveur d’origine ?
Pour ma préoccupation (personnelle) de ne pas vouloir publier de contenu sur l’ensemble du fediverse, il semble techniquement possible d’établir une relation ActivityPub un à un entre un site Discourse et un site WordPress, mais je me demande si cela ne va pas à l’encontre de l’objectif du protocole ActivityPub.
Edit : il pourrait être utile d’ajouter que l’objectif est de créer une relation gagnant-gagnant entre un site web et un forum Discourse associé. Les outils de modération de Discourse sont destinés à rassurer sur le fait que le système de commentaires du site web est bien modéré. La section de commentaires du site web est destinée à être utilisée pour alimenter le site Discourse en sujets et en utilisateurs.
2 « J'aime »
Le message converti à partir de l’objet ActivityPub a presque* les mêmes fonctions de prétraitement et de post-traitement appliquées que celles d’un message créé via l’API. Le point d’entrée est différent (c’est-à-dire un contrôleur ActivityPub au lieu du contrôleur de messages), mais la façon dont les messages sont créés est en grande partie la même.
*En termes plus techniques, si vous créez un message via l’API, le traitement réel est effectué par le NewPostManager, qui délègue ensuite la majeure partie du travail au PostCreator. La principale chose que le NewPostManager gère (pour nos besoins ici) est la file d’attente de révision. Tout le reste est géré dans le PostCreator.
Actuellement, le plugin ActivityPub ignore le NewPostManager et le délègue au PostCreator dans son propre PostHandler (celui du plugin). Je l’ai fait principalement pour réduire la complexité de l’implémentation initiale. Il n’y a aucune raison intrinsèque pour que le PostHandler du plugin ne puisse pas déléguer le message au NewPostManager et bénéficier des vérifications de la file d’attente de révision.
En bref, il n’y a pas de différence substantielle entre les messages créés via le plugin ActivityPub et via l’API normale.
Il y a plusieurs niveaux à cela.
-
Premièrement, la requête POST du serveur d’origine à votre serveur est signée à l’aide de signatures HTTP pour garantir que la requête provient bien de l’origine.
-
Deuxièmement, chaque Acteur (c’est-à-dire utilisateur) sur cette origine a un UUID, c’est-à-dire un identifiant lié à son domaine, unique dans le fediverse. Il ressemble à ceci :
https://angus.ngrok.io/ap/actor/f4b517bf6f81dbddfad3e44a45c9619dLes e-mails ne sont pas utilisés dans ActivityPub.
-
Chaque Activité (par exemple, une création d’un objet de type message) que vous recevez est associée à un identifiant d’Acteur. Et chaque identifiant d’Acteur peut être résolu en attributs d’Acteur.
-
Ainsi, au moment où vous recevez une “Activité”, par exemple la création d’un nouvel objet de type message, sur votre serveur, vous connaissez, selon le domaine d’où vous avez reçu l’activité, les attributs de l’Acteur qui effectue l’Activité. Vous faites confiance au domaine d’envoi ici, mais c’est toujours le cas dans la mesure où, par exemple, Discourse fait confiance aux instances Wordpress avec le plugin WP Discourse pour envoyer les bons attributs d’utilisateur associés.
L’utilisateur mis en scène n’a donc pas besoin d’une preuve d’identité en soi, de la même manière qu’un utilisateur mis en scène par e-mail n’a pas besoin d’une preuve d’identité.
Le besoin d’une preuve d’identité survient lorsque la vraie personne associée à l’acteur ActivityPub, et un autre compte Discourse, comme dans l’exemple avec Matthias ci-dessus, souhaite consolider (ou “rapprocher”) son identité. Elle pourrait ne pas aimer avoir effectivement deux “utilisateurs” sur un seul Discourse. Je noterais que, sans une telle consolidation, elle peut contrôler
-
Les attributs d’identité de l’Acteur ActivityPub / utilisateur mis en scène via le domaine source, par exemple en mettant à jour son profil Wordpress, ces mises à jour étant fédérées et Discourse appliquant les mêmes) ; et
-
Le contenu associé à l’Acteur ActivityPub / utilisateur mis en scène via le domaine source, par exemple en modifiant son commentaire Wordpress, une activité de mise à jour étant envoyée puis traitée par Discourse.
Mais, néanmoins, elle pourrait trouver cela “désordonné” d’avoir effectivement deux utilisateurs sur Discourse. C’est pourquoi le plugin dispose de son ensemble de fonctionnalités “Autorisation”, pour vous permettre de montrer que votre utilisateur Discourse normal est associé à l’acteur ActivityPub avec son utilisateur mis en scène. Ceci est actuellement fait via des mécanismes d’autorisation spécifiques à la plateforme :
-
Pour Mastodon, cela se fait via l’API OAuth de Mastodon. Il vous faut authentifier votre compte sur Mastodon pour prouver que vous contrôlez l’acteur concerné.
-
Pour Discourse, cela se fait via l’API Utilisateur. C’est ce qui est montré dans la vidéo de mon précédent message.
-
Il existe plusieurs façons de faire la même chose pour Wordpress, par exemple, DiscourseConnect via le plugin WP Discourse. Ce n’est pas encore implémenté.
Une fois que vous prouvez que vous possédez l’acteur associé à l’utilisateur mis en scène, l’utilisateur mis en scène est fusionné avec votre utilisateur normal, ses messages deviennent les vôtres, et toute nouvelle activité associée à cet Acteur vous devient automatiquement associée. Mais cet ensemble de fonctionnalités vise vraiment à améliorer l’expérience utilisateur et n’est strictement pas nécessaire. La vraie personne derrière ces différents utilisateurs contrôle dès le départ les attributs de l’utilisateur et leur contenu.
Oui, il est possible de canaliser la cible des publications sortantes et de restreindre la source des publications entrantes. La question de savoir si cela va à l’encontre du but d’ActivityPub est discutable. Strictement parlant, ActivityPub est juste une norme. Je dirais qu’il n’y a aucune raison pour que vous ne puissiez pas utiliser la norme de cette manière. Historiquement, ActivityPub a été associé aux réseaux sociaux décentralisés, en particulier Mastodon, ce qui explique peut-être pourquoi vous avez l’impression que ce type d’approche va à l’encontre du but d’ActivityPub. Mais je ferais une distinction entre la norme ActivityPub elle-même et ses implémentations existantes ici.
De plus, dans ce contexte, je noterais que, comme pour les e-mails, ce que nous appelons “ActivityPub” est en réalité une collection de normes. Le document de normes intitulé “ActivityPub” doit être lu en parallèle d’un autre document de normes appelé “ActivityStreams”, qui décrit les principaux objets en jeu ici. La norme ActivityStreams est plus fermement “neutre vis-à-vis du service” qu’ActivityPub lui-même (c’est-à-dire moins liée aux réseaux sociaux décentralisés).
Pour utiliser (une autre) analogie, la blockchain en tant que technologie est simplement un registre décentralisé, la première fois qu’elle m’a été expliquée, elle m’a fait penser au système Torrens d’enregistrement foncier, inventé au 19ème siècle (en Australie) pour essentiellement les mêmes raisons que la blockchain a été inventée (c’est-à-dire pour prévenir la fraude dans les transactions immobilières). Mais l’implémentation la plus populaire de la blockchain est Bitcoin, qui a un usage spécifique (différent) et certaines valences culturelles. L’analogie n’est pas la meilleure, mais une façon d’y penser est que Mastodon et les réseaux sociaux décentralisés sont à ActivityPub ce que Bitcoin est à la blockchain.
En effet, l’une des raisons pour lesquelles j’ai contribué à la création d’un nouveau groupe de travail W3C ActivityPub for Forums avec NodeBB, Flarum et d’autres est d’essayer de déplacer l’accent de l’intégration ActivityPub des implémentations existantes (par exemple, Mastodon) vers les préoccupations des forums, comme celles relatives à la modération que vous soulevez. Nous avons d’ailleurs notre prochaine réunion aujourd’hui. Si vous avez le temps, j’adorerais avoir un autre “Discoursien” (est-ce un terme ?) là-bas
4 « J'aime »
Je parle de l’utilisation des outils de modération de Discourse pour modérer les commentaires qui apparaissent sur WordPress. Techniquement, cela pourrait être fait avec une requête API Discourse ou un Webhook - après qu’une action de modération ait eu lieu sur Discourse, une requête pourrait être faite pour changer le statut du commentaire sur WordPress.
En supposant que les choses soient modifiées de manière à ce que les publications ActivityPub soient gérées par la file d’attente de révision, il y aurait toujours un problème avec le délai entre le moment où le commentaire est initialement publié sur WordPress et le moment où il apparaît sur Discourse. Je crois que c’est quelques minutes ?
Pour ce cas particulier, l’un des principaux arguments de vente est « utiliser Discourse pour modérer les commentaires de votre site Web ». Il énumère ensuite les fonctionnalités de modération de Discourse, le système de niveaux de confiance, la file d’attente de révision, les outils de modération basés sur l’IA, etc. Ce sont des outils qui seraient utiles pour les petits blogs, mais une exigence pour les sites d’actualités grand public. Je pense que la meilleure façon d’y parvenir est d’utiliser Discourse comme source unique de vérité pour les commentaires, au lieu d’avoir des commentaires existant dans deux (ou plus) bases de données.
C’est excellent ! Sans avoir le temps d’y réfléchir davantage, je ne pense pas que je serais un bon représentant de Discourse.
J’ai quelques préoccupations générales concernant l’idée de traiter les sujets, les publications et les utilisateurs comme de simples données. Il doit y avoir un moyen de s’assurer que le contexte de l’endroit où une discussion se déroule n’est pas perdu.
Sur un plan plus pratique, le protocole ActivityPub a pris son essor avant l’introduction des lois sur les préjudices en ligne qui sont introduites dans divers pays. Il doit y avoir une certaine assurance que les serveurs qui consomment des données d’une origine respecteront les demandes de suppression. Sinon, les utilisateurs qui génèrent du contenu sur un serveur d’origine risquent des répercussions juridiques si leur contenu est ultérieurement jugé préjudiciable dans leur pays.
3 « J'aime »