Plugin ActivityPub

Eh bien, un utilisateur de Mastodon le verra dans le contexte d’une chronologie, et les chronologies sont généralement limitées. Sur Mastodon, par défaut, une chronologie totale ne dépasse pas 400 messages. Si vous regardez l’original, vous regardez de toute façon dans Discourse. Donc, bien que ce soit vrai en théorie, je ne pense pas que cela cause de confusion réelle en pratique. Vous devez déjà être un follower pour voir le contenu ; suivre un lien vers l’original vous amène dans Discourse où la confusion est résolue.

Pas parfait, mais peut-être une option “la moins mauvaise” ?

Je suppose que, comme alternative, vous pourriez fédérer une modification qui annote le message comme étant remplacé par un transfert de propriété, un peu comme ajouter le lien “discutez-en sur notre forum” ?

Bien sûr, je ne dis pas que ce n’est pas une différence, seulement que cela semble être une différence acceptable, par rapport au blocage d’une fonctionnalité Discourse utile et utilisée.

Supprimer l’original orphelinera les fils dans le contexte d’autres plateformes vers lesquelles vous fédérez, car vous ne pouvez pas modifier l’acteur associé à une activité dans une modification (si je comprends bien).

Une alternative pourrait être d’arrêter de fédérer les modifications du tout si le message dans Discourse a un auteur différent de celui qu’il avait lors de sa première fédération. Peut-être avec un avertissement ? “Changer de propriétaire désactivera la fédération pour ce message, voulez-vous vraiment continuer ?”

Oui. C’est ce que voit un utilisateur normal dans Discourse, qui pourrait ne pas savoir qu’il peut cliquer sur l’icône du crayon et parcourir les modifications pour les examiner, ou qui n’a pas les permissions. Ce sont des éléments intégrés à l’utilisation normale de Discourse, comme je le vois :

  • Faire d’un message un wiki, c’est dire que vous acceptez que les modifications d’autres personnes apparaissent dans une utilisation normale sous votre propre nom.
  • Même si ce n’est pas un wiki, les utilisateurs suffisamment privilégiés peuvent modifier votre message dans Discourse, en fonction de la configuration du site.

De mon point de vue, c’est aussi proche que possible de l’équivalent, compte tenu des différences de modèle sous-jacent.

Comme je le vois, le lien “cliquer pour voir le message sur le site d’origine” affiche déjà un contenu différent entre les implémentations qui sont d’abord fediverse, même en ignorant ce plugin. Différents commentaires visibles, balisage différent, gestion différente des articles. Donc, certaines différences visibles via ce plugin ne me surprennent pas ; je pense que c’est inévitable.

(Merci encore pour votre examen attentif de ces idées. Je reconnais qu’il s’agit de cas limites difficiles, je suis reconnaissant pour le travail, je ne suppose pas que mes idées soient les meilleures, et je n’ai pas l’intention de créer un sentiment d’obligation pour cette phase ou toute phase de travail sur ce sujet, ni même de répondre à quoi que ce soit en particulier que j’écris.)

1 « J'aime »

Comme pour le changement de catégorie, je pense que cela dépend vraiment du scénario. Considérons par exemple

  1. Le message 1 est créé dans la catégorie 1 par l’utilisateur 1 (Acteur 1)
  2. L’auteur du message 1 est changé par l’utilisateur 3 (un administrateur) à l’utilisateur 2 (Acteur 2) 2 minutes plus tard
  3. La catégorie 1 est suivie par 400 acteurs sur 20 domaines et 5 plateformes logicielles différentes, chacune avec une implémentation légèrement différente des chronologies et de la découverte de contenu.
  4. Dans les 2 minutes suivant la création du message 1, il y a 2 Notes avec un contenu identique et des acteurs différents POSTÉES à ces 400 followers.

Je pense que cela risque de causer de la confusion pour un bon sous-ensemble de followers, sans parler du fait que l’utilisateur 2 ne réalisera peut-être même pas que son nom est maintenant associé à ce contenu dupliqué qu’il n’a pas écrit sur 20 domaines différents. Il pourrait être d’accord avec les administrateurs qui font cela sur une seule instance, c’est en quelque sorte implicitement consenti en postant sur cette instance, cependant je pense que nous devrions être très prudents quant à l’extension de ce consentement implicite à l’ensemble du fediverse, surtout dans les circonstances imparfaites de duplication du contenu. Changer les propriétaires de messages est une fonction administrative puissante, spécifique à Discourse, et implicitement liée au “contrat social” d’une seule instance.

Je pense que le cas des wikis est plus solide, cependant j’observerais à nouveau ce que vous avez déjà évoqué. Les wikis sont un concept ancré dans l’utilisation normale de Discourse. Associer les modifications de n’importe qui (pas seulement du personnel) à l’auteur d’origine est un concept de Discourse, sans analogue dans ActivityPub. Nous devrions être prudents quant à l’extension de ce concept en utilisant les méthodes standard d’ActivityPub à travers l’ensemble du fediverse. Ces activités de mise à jour seront traitées comme toute autre activité de mise à jour sur de nombreuses instances et plateformes logicielles différentes, décontextualisées de leur contexte wiki d’origine. De plus, comme vous l’avez également évoqué, il existe déjà un problème potentiel dans ce sens avec la capacité du personnel et des utilisateurs très fiables à modifier les messages des autres. Je pense que cette question plus limitée nécessite plus de réflexion avant d’aborder la question des wikis.

Je n’essaie pas de créer un choix binaire entre Discourse et ActivityPub pour ces fonctionnalités. Ce que je dis, c’est que nous ne devrions pas simplement essayer de mapper des fonctionnalités sensibles de Discourse sur le Fediverse sans réfléchir prudemment aux conséquences. La règle par défaut devrait être que ces fonctionnalités plus sensibles sont désactivées sur les messages ActivityPub jusqu’à ce que nous ayons un peu plus confiance que nous ne allons pas nuire ou surprendre un sous-ensemble décent d’utilisateurs ou de cas d’utilisation.

Personnellement, je ne pense pas que nous en soyons là avec l’un ou l’autre, bien que mon instinct me dise que le cas du wiki a plus de potentiel à ce stade, même si je ne vois pas encore de bonne solution.

8 « J'aime »

Ces deux éléments sont maintenant terminés, je viens de fusionner la PR d’Angus pour la vérification d’identité via OAuth. Sous réserve de corrections de bugs et d’améliorations des performances, cela achève la phase actuelle des fonctionnalités ajoutées au plugin.

En l’état, le plugin est très riche en fonctionnalités. Pour récapituler rapidement les principales fonctionnalités, le plugin prend en charge :

  • Publication de messages “Followers Only” dans ActivityPub (par défaut, Public)
  • Publication du premier message ou du sujet complet (par défaut, premier message)
  • Synchronisation bidirectionnelle lors de l’utilisation de la publication du sujet complet, c’est-à-dire que tous les messages créés par Discourse dans un sujet seront publiés dans ActivityPub, et vice versa, les réponses dans ActivityPub seront publiées dans Discourse
  • Option de publier les messages sous forme de Notes (pour les services de contenu courts comme Mastodon) ou d’Article (plus approprié pour les services de contenu longs)
  • Vérification d’identité

Ensuite, nous travaillerons à l’affinage des fonctionnalités actuelles et à l’amélioration de l’utilisabilité. Les commentaires sont toujours les bienvenus, bien sûr. Je suis particulièrement intéressé par les moyens d’expliquer comment tout cela fonctionne aux utilisateurs réguliers, ce n’est pas une mince affaire.

Je suis tout à fait d’accord avec @angus, notre objectif est de faire ce qui est pratique et réalisable avec un effort raisonnable. À cet égard, nous sommes prêts à accepter certaines fonctionnalités réduites dans Discourse pour le moment. C’est notre meilleure chance de savoir si des limitations spécifiques sont importantes à aborder ou non (par exemple, les utilisateurs du plugin rencontreront-ils souvent des limitations wiki-ActivityPub ?).

6 « J'aime »

Ai-je bien compris, alors, que nous en sommes au point où il est judicieux d’articuler les restrictions ?

Salut :slight_smile:

Tout d’abord, merci pour le développement de tout cela.

Ensuite, je suis très intéressé par la connexion de différents services ActivityPub ensemble, et d’après ce que j’ai lu, il s’agit principalement d’envoyer des messages de Discourse à Mastodon dans les deux sens.

Je suis conscient que le protocole est indépendant du service, mais existe-t-il une documentation pour, disons, connecter différentes instances Discourse, ou intégrer Nextcloud, ou PeerTube, etc. ?

1 « J'aime »

Nous avons désactivé les changements d’auteur de publication et les wikis dans les sujets ActivityPub pour le moment pour les raisons que j’ai déjà mentionnées (leurs hypothèses ne fonctionnent pas avec ActivityPub dès la sortie de la boîte). Ce sont les deux seules fonctionnalités qui ont été temporairement désactivées dans les sujets ActivityPub de cette manière. Toute autre fonctionnalité réduite devrait être signalée comme un problème.

Il s’agit d’un plugin ActivityPub qui suit de près la spécification ActivityPub, il est donc conçu pour fonctionner avec tout service qui suit cette spécification, y compris tous ceux que vous avez mentionnés (et d’autres). Mastodon est la première plateforme ActivityPub avec laquelle nous nous sommes concentrés sur l’intégration car, en pratique, il faut assurer la compatibilité avec un service à la fois et c’est la plus grande plateforme ActivityPub.

4 « J'aime »

Essayé deux fois sur https://meta.discourse.org/u/rokejulianlockhart/preferences/activity-pub

```json { "errors": ["You are not permitted to view the requested resource."], "error_type": "invalid_access" } ```

Que dois-je faire ?

2 « J'aime »

Salut @rokejulianlockhart, merci pour vos commentaires. Comment effectuez-vous le flux d’autorisation ? Cliquez-vous sur « Autoriser » dans la capture d’écran ci-dessus dans un navigateur (quel navigateur aussi ?) Ou copiez-vous / collez-vous les URL d’une manière ou d’une autre ? Je demande parce que vous les avez là dans votre publication. Voici une vidéo du flux standard qui fonctionne pour moi sur meta.discourse.org

Faites-vous quelque chose de différent de cela ?

2 « J'aime »

@angus,

  1. rokejulianlockhart@mastodon.social

  2. Vous êtes sur le point de vous connecter au site « mastodon.social » avec le nom d’utilisateur « rokejulianlockhart », mais le site Web ne nécessite pas d’authentification. Il pourrait s’agir d’une tentative de vous tromper.

    Est-ce « mastodon.social » le site que vous souhaitez visiter ?

    Ici, je clique

    Oui

  3. Log in - Mastodon

    Autorisation requise
    meta.discourse.org souhaite la permission d’accéder à votre compte. Il s’agit d’une application tierce. Si vous ne lui faites pas confiance, vous ne devriez pas l’autoriser.
    Examiner les autorisations

    Comptes
    Accès en lecture seule

    Ici, je clique

    Autoriser

  4. Ensuite, le précédent

    Est-ce « mastodon.social » le site que vous souhaitez visiter ?

    s’affiche, et je fais de même.

  5. https://meta.discourse.org/ap/auth/oauth/redirect?code=s2H3Og_3oLTb8cAsYN9Kmgeh8xPySeOaWSp2bdZ2sEE

    1. .JSON

      {"errors":["Vous n'êtes pas autorisé à afficher la ressource demandée."],"error_type":"invalid_access"}
      
    2. En-têtes

      X-Firefox-Spdy: h2
      content-encoding: gzip
      content-type: application/json; charset=utf-8
      date: Mon, 25 Sep 2023 11:39:30 GMT
      referrer-policy: strict-origin-when-cross-origin
      server: nginx
      vary: Accept-Encoding
      x-content-type-options: nosniff
      x-discourse-route: o_auth/redirect
      x-discourse-username: rokejulianlockhart
      x-download-options: noopen
      x-frame-options: SAMEORIGIN
      x-permitted-cross-domain-policies: none
      x-request-id: 01276bd6-77ea-42ae-8f60-6fa365a70e1f
      x-xss-protection: 0
      
      Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
      Accept-Encoding: gzip, deflate, br
      Accept-Language: en-GB,en;q=0.7,en-US;q=0.3
      Connection: keep-alive
      Host: meta.discourse.org
      Sec-Fetch-Dest: document
      Sec-Fetch-Mode: navigate
      Sec-Fetch-Site: cross-site
      Sec-Fetch-User: ?1
      Upgrade-Insecure-Requests: 1
      User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/117.0
      

Bonjour, après la dernière mise à jour, il semble que les profils utilisateurs (/u/user) soient cassés. Le nom d’utilisateur et la photo de profil s’affichaient (ainsi que la liste des infractions de l’utilisateur en haut).

Nous avons parcouru notre liste de plugins et désactivé chacun d’eux un par un jusqu’à ce que le problème disparaisse. Cela a également fonctionné avec le mode sans échec activé. Voici quelques-unes des erreurs client que nous recevrions :

Cannot read properties of null (reading 'getBoundingClientRect')
at Object.offset (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:5104:37)
at e.scrolled (https://amcforum.wiki/assets/discourse-9756bc4a118ac228ac6ac3f2b29c7d4a7d60a9f16ece25de4a772f0055c6eb94.js:2347:106)
at p.invoke (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4339:182)
at p.flush (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4331:141)
at h.flush (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4346:207)
at $._end (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4410:9)
at $.end (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4363:240)
at $._runExpiredTimers (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4417:192)

Voici à quoi cela ressemble avec le plugin activé (pour votre propre compte)

Pour un autre utilisateur (dans ce cas, 9pfs)

Voici un autre bug amusant causé par le plugin :

Nous utilisons actuellement la version 3.2.0.beta2-dev de ce commit et nous utilisons la version 0.1.0 du plugin de ce commit.

1 « J'aime »

@rokejulianlockhart Avez-vous désactivé les cookies ou une extension de confidentialité ? Le flux d’autorisation repose actuellement sur un cookie de session sécurisé pour fonctionner.

@aboutDavid Merci pour votre rapport. Bien que ce soit possible, il semble peu probable que ce que vous partagez soit causé par un problème dans ce plugin. Pourriez-vous partager un lien vers votre site ? Avez-vous également activé des thèmes ou des composants de thème ?

2 « J'aime »

D’après le dépannage en mode sans échec, nous savons avec certitude ce qui suit :

  1. C’est un plugin non officiel
  2. Ce n’est pas un thème ou un composant de thème.

Pour autant que je sache, nous avons deux plugins non officiels :

  1. Animate avatars (confirmé manuellement comme n’étant pas le coupable)
  2. ActivityPub

Quant à un lien vers le site :

3 « J'aime »

L’interface utilisateur de mise à niveau affiche une coche à côté de tous les plugins, à l’exception de ces deux (indiquant qu’il s’agit de plugins officiels).

2 « J'aime »

Le problème sur votre site est probablement causé par quelque chose qui utilise l’outlet user-profile-avatar-flair. Ce plugin n’utilise pas cet outlet. Le plugin animated-avatars le fait cependant.

Comment avez-vous confirmé cela ?

1 « J'aime »

@aboutDavid a vérifié et s’est assuré que le plugin n’avait pas de JS côté client. Le problème est-il en partie côté serveur ?

1 « J'aime »

Non, l’absence de JS côté client ne signifie pas nécessairement l’absence de problèmes côté client. Dans ce cas, le problème semble provenir de la manière dont un point de sortie de plugin est utilisé, potentiellement dans un modèle. Pourriez-vous essayer de supprimer le plugin d’avatars animés et me faire savoir le résultat ?

(Soit dit en passant, le plugin Animated Avatars a bien du JS côté client. Voir par exemple).

1 « J'aime »

Je viens de modifier une catégorie ici sur Meta (pour changer certaines autorisations d’accès de groupe). Je n’ai modifié aucun paramètre lié à ActivityPub, mais nous avons fini avec ces trois entrées dans le journal du personnel :

Je suppose qu’ils sont techniquement passés de nil à leur valeur par défaut, il n’y a donc aucun changement réel de comportement ? Néanmoins, il serait bon d’éviter cette journalisation de suppression pour éviter toute confusion.

2 « J'aime »

Merci pour le rapport David, j’y jetterai un coup d’œil bientôt.

1 « J'aime »

Oups, je suis un peu bête aujourd’hui, désolé

edit : oui, ce sont très probablement des avatars animés, désolé d’avoir perdu votre temps lol

3 « J'aime »

@angus, pas à ma connaissance.

et j’ai vérifié que j’avais désactivé uBlock Origin, même si je n’utilise pas les listes de confidentialité de toute façon.


Cependant, j’ai rencontré un problème différent en testant cela aujourd’hui.

Log in - Mastodon

L’authentification du client a échoué en raison d’un client inconnu, d’une absence d’authentification du client incluse ou d’une méthode d’authentification non prise en charge.

Google Search.