Juste une note indiquant que nous en sommes actuellement à cette étape
5 « J'aime »
C’est super !\n\nJ’ai récemment configuré un serveur Discourse pour notre coopérative CoSocial qui gère un serveur Mastodon. J’ai fini par configurer le plugin OAuth2 afin que nous n’acceptions que les connexions de notre serveur Mastodon -\u003e https://members.cosocial.ca (installation neuve et assez simple, juste une « preuve d’OAuth »).\n\nMa question / demande de fonctionnalité est qu’il soit possible de mettre en scène / fusionner des acteurs Mastodon dans des comptes Discourse, de sorte que lorsque des comptes sur Mastodon répondent, ils puissent être liés / appartenir au compte Discourse associé.\n\n[details="Comment Lemmy ne fait pas cela"]\nJ’ai documenté comment Lemmy ne fait pas cela - vous pouvez interagir via Mastodon, et un compte est créé dans Lemmy pour ce compte Mastodon, mais vous ne pouvez pas vraiment vous connecter et utiliser les fonctionnalités de première classe de Lemmy avec votre compte Mastodon.\n[/details]
4 « J'aime »
C’est à l’ordre du jour…
Et déjà dans la file d’attente pour examen
3 « J'aime »
Excellent. Il semble que mes utilisateurs du plugin Discourse OAuth devraient « confirmer à nouveau » pour interagir avec ce plugin AP.
Je pense que c’est tout à fait acceptable à ce stade, je voulais juste signaler le serveur OAuth comme un angle supplémentaire, tant qu’il n’y a pas de conflit. Le « nice to have » serait « si OAuth avec le serveur Mastodon, alors lier automatiquement l’identité de l’acteur AP ». C’est totalement futuriste et aussi unique à ce type de configuration !
(Et désolé de ne pas avoir ouvert la page pour regarder cette partie ! Excellent !)
1 « J'aime »
Le PR ajoutant cet ensemble de fonctionnalités est maintenant fusionné.
Comme Angus l’a noté ci-dessus, la prochaine étape est la vérification des utilisateurs via des jetons OAuth.
2 « J'aime »
Les problèmes que j’ai rencontrés précédemment avec le markdown brut qui apparaissait semblent affecter également meta. Je suis @feature@meta.discourse.org et il y a quelques heures, ce post a été créé et fédéré à partir de cet Acteur :
Cela m’est apparu sur Mastodon avec des bugs comme ceci :
Dans Elk, cela ressemble à ceci ; un peu mieux :
Je viens de commencer à suivre @feature@meta.discourse.org sur mon compte Mastodon pur pour tester cela, mais bien sûr, il est trop tard pour voir ce post particulier là-bas. 
Donc, le markdown intégré que j’ai vu plus tôt de ma propre installation n’était pas une mauvaise base de données, ou si c’était le cas, c’était un problème de base de données partagé avec meta et donc probablement pas associé à mes tests.
2 « J'aime »
Oui, je peux reproduire cela, je vois une sortie similaire dans une instance Mastodon et dans Ivory (application iOS).
2 « J'aime »
Je ne suis pas sûr que cela fonctionne correctement. Le plugin est activé et j’ai créé un sujet dans une catégorie avec ActivityPub activé, mais je ne vois pas le badge à côté des publications (et ma tentative de suivre l’acteur ActivityPub de la catégorie a semblé échouer, car cela se comporte comme un serveur le ferait si les suivis devaient être approuvés manuellement par un utilisateur).
Je viens de remarquer que le même problème semblait se produire avec Feature sur Meta.
1 « J'aime »
Il serait formidable de comprendre l’objectif final des restrictions, sans se soucier de l’état intermédiaire.
Par exemple, je pense avoir vu une référence dans une PR indiquant que le changement de propriétaire des publications sera bloqué si le plugin est activé. En tant qu’administrateur, je dois utiliser cette fonctionnalité à de rares occasions (par exemple, lorsque je change le modérateur de catégorie, je fais du nouveau modérateur de catégorie principal le propriétaire de la catégorie concernant la publication épinglée). J’espère qu’à terme, cela se traduira par une suppression et une republication, ou même simplement ignoré, plutôt que de bloquer le changement de propriété.
Je me demande aussi à propos du déplacement des publications entre catégories. Je dois le faire assez fréquemment, surtout lorsque de nouveaux utilisateurs publient dans la mauvaise catégorie. Je m’attendrais naïvement à ce que cela se traduise par un acteur de catégorie retirant son boost, et le nouvel acteur de catégorie ajoutant un boost, mais sans supprimer la publication sous-jacente, de sorte que si quelqu’un d’autre avait vu et boosté une publication, son boost ne disparaîtrait pas simplement parce que le boost de l’acteur de catégorie a disparu.
En général, il serait vraiment utile de savoir ce que vous vous attendez à ce qui soit interdit lorsque ce plugin sera ajouté, une fois le développement des fonctionnalités actuellement spécifiées terminé, quelles que soient les restrictions actuellement en place.
1 « J'aime »
@hello-smile6 Je vois la même chose avec le plugin mis à jour aujourd’hui :
Je ne vois pas de configuration pour cela, donc je suppose que c’est un bug.
2 « J'aime »
Merci pour ce nouveau rapport. Je suis en train d’examiner cela.
Merci pour le rapport, nous sommes en train d’examiner cela.
Je comprends votre point de vue, cependant :
-
Tant que le plugin est en cours de développement actif, tenter d’expliquer les choses de cette manière serait improductif car l’explication pourrait changer.
-
Il existe un nombre considérable de scénarios et de cas limites que le plugin gère déjà. Pour moi, expliquer chacun d’eux de manière narrative à ce stade prendrait trop de temps (c’est-à-dire, faire effectivement ce long post un certain nombre de fois). Il y a déjà plus de 400 spécifications pour le plugin.
-
Néanmoins, les restrictions sont souvent expliquées narrativement dans les commentaires sur les PR et les commits, que je pense que vous lisez déjà.
Cela a été discuté en profondeur sur le PR
J’ai restreint le changement de propriétaire des posts et la création de wikis de posts, même pour les administrateurs, dans les sujets AP. En effet, les posts AP distants doivent conserver leur fidélité par rapport à l’original et ces deux actions peuvent potentiellement briser cette fidélité.
Il peut y avoir un moyen de faire fonctionner la fédération avec les wikis et le changement de propriétaire des posts, cependant je suggère que nous ajoutions cela comme une « fonctionnalité » dans un futur PR car cela impliquera de multiplier ou de changer l’acteur associé à un objet qui est fédéré sur plusieurs plateformes. Je pense que nous ne pourrons jamais autoriser le changement de propriétaire des posts importés (notes) AP, car l’association acteur/objet n’est pas détenue par Discourse, mais par l’endroit où le contenu a été créé. Pour donner une analogie illustrative, dans ce contexte, la suppression d’un post associé à une note importée est moins une « suppression » en soi qu’un choix de ne pas afficher une note.
Il existe un certain nombre de scénarios impliquant le déplacement de posts. Je vais m’occuper du cas spécifique que vous avez mentionné pour l’instant, à savoir le déplacement d’un post entre deux catégories différentes activées pour ActivityPub.
Vous supposez que la seule fois où un post est déplacé entre catégories est lorsque le post est initialement publié dans la mauvaise catégorie, et que le déplacement se produit peu de temps après sa création. Et si, 4 mois après la création d’un post, vous le déplacez dans une autre catégorie parce que vous voulez consolider une certaine collection de posts dans un nouveau sujet dans une catégorie différente ? Serait-il logique d’envoyer un « Annuler » pour le boost d’origine dans ce scénario ?
Cela dépend si nous parlons de la configuration du premier post ou de la configuration complète du sujet. Pour la première, nous ajouterons un bouton pour que le premier post soit publié manuellement afin de traiter spécifiquement le scénario de déplacement de catégorie. Pour la seconde, l’ajout automatique d’un boost peut avoir du sens, j’y réfléchirai davantage.
Je comprends votre point de vue, cependant j’ai déjà partagé pas mal de détails sur l’état final dans la spécification de la Phase 2 ci-dessus. Au-delà de cette spécification, et en disant cela aussi doucement que possible, il y a beaucoup trop de cas d’utilisation et de scénarios pour que je puisse tous les discuter en profondeur avec vous, puis aussi avec l’équipe de Discourse.org, tout en travaillant dessus 
Je mettrai à jour l’OP avec un aperçu général du comportement attendu une fois la Phase 2 terminée.
1 « J'aime »
Je ne parviens pas à reproduire ce problème. Je viens de suivre feature@meta.discourse.org à partir d’un compte Mastodon de test, et je n’ai vu aucune erreur (ni dans Mastodon ni dans Discourse).
1 « J'aime »
Il pourrait être lié à l’instance que j’ai suivie, est-ce que cette instance fait quelque chose d’inhabituel ?
Oh là là, dans ma tentative de poser une question claire, j’ai donné l’impression de demander beaucoup de travail. Je m’excuse pour ce malentendu. J’apprécie votre réponse réfléchie.
C’est ce que je voulais demander, pas des mises à jour détaillées continues dans ce fil. Mon « après » dans « après que le développement de la fonctionnalité actuellement spécifiée soit terminé » était destiné à indiquer quand la clarification serait utile, et non à vous demander de décrire maintenant l’état futur. Ma question était formulée de manière ambiguë. Désolé pour cela !
C’est ce que je voulais vraiment comprendre : l’objectif final, dans les grandes lignes, est-il de restreindre Discourse à ce que prend en charge le protocole ActivityPub canonique, ou est-il de fédérer une expérience Discourse native non restreinte vers le fediverse sur la base du meilleur effort ? Mon expérience passée avec les intégrations Discourse m’avait amené à m’attendre au meilleur effort ; maintenant, je comprends que votre plan est de privilégier la fidélité, au détriment des fonctionnalités de Discourse, et non pas seulement comme une mesure temporaire pendant le développement.
Je ne suppose pas cela. Pourquoi quatre mois feraient-ils une différence ici ? Elle est nouvellement dans une catégorie fédérée, pourquoi cela ne provoquerait-il pas un boost de la catégorie fédératrice ? Moi, du moins, je m’attendrais naïvement à ce que cela se produise. Je vois souvent des gens booster des publications qui datent de plusieurs mois, donc je ne connais pas de raison particulière pour que cela soit différent.
Et oui, je pense qu’il serait logique d’envoyer un Annuler pour le boost original. Cela semble être courant. (En fait, Annuler un boost puis un nouveau boost semble être un mécanisme typique pour « remonter » du contenu ; sans rapport avec cet objectif, mais illustrant que Annuler sur un boost est couramment utilisé et ne devrait donc pas causer de problèmes aux autres implémentations ActivityPub.)
Je vois la même chose en ce moment pour feature@meta.discourse.org depuis mastodon.cloud qui, je pense, fonctionne avec Mastodon standard.
1 « J'aime »
Personnellement, je n’y pense ni dans un sens ni dans l’autre. Discourse.org définira l’agenda général ici, mais dans les grandes lignes, les décisions sont prises sur la base de son fonctionnement et de ce qui est pratique. S’il existe un moyen sensé et durable de permettre les modifications d’auteurs sur tous les messages, quelle que soit leur provenance, alors c’est parfait.
En se concentrant uniquement sur l’annulation du boost d’origine, cette Annulation spécifique ne semble pas servir à quelque chose ? Elle est également discutable et un peu surprenante dans certains scénarios, comme l’a montré mon exemple. L’intention du changement de catégorie pourrait ne pas être d’annuler (Undo) la « découvrabilité » d’origine du contenu. Il peut s’agir de modifier l’organisation du contenu plus tard pour une raison différente.
Pour le dire autrement, l’application d’une inversion automatique de l’Annonce d’origine sur un changement de catégorie dans Discourse fonctionne dans certains scénarios, mais pas dans d’autres. Et même dans les scénarios où cela semble plus logique, l’Annonce d’origine ne cause aucun tort. Donc, en poursuivant les principes du moindre préjudice et de la moindre surprise, il semble plus logique de laisser l’Annonce d’origine en place. Désolé si je rate quelque chose.
Pour y réfléchir sous un autre angle, je ne pense pas qu’il soit juste de considérer les activités d’Annonce d’un Acteur de Catégorie comme synonymes du rôle taxonomique des Catégories elles-mêmes. Une Annonce est la façon dont un acteur de Catégorie partage du contenu avec ses abonnés, mais ce n’est pas une taxonomie en soi. C’est une façon dont le contenu est découvert dans le Fediverse. Je ne pense pas qu’il doive y avoir une relation 1:1 entre les catégories et les activités d’Annonce des acteurs de catégorie.
3 « J'aime »
Ah. Alors c’est vraiment une question pour l’équipe. 
Cela a du sens aussi. Je suis d’accord, il n’y a pas beaucoup de valeur à annuler le boost.
C’est donc un signal déclenché par un bord ; cela signifierait « un message vient d’entrer dans cette catégorie, soit en étant écrit, soit en étant déplacé dans la catégorie ». C’est conceptuellement simple.
Je penserais alors à changer l’auteur d’un message de la même manière. Ce serait le nouvel acteur créant une nouvelle activité pour le message du nouvel auteur, et il n’y aurait pas de raison particulière de faire quoi que ce soit avec l’ancienne activité effectuée sous l’ancien auteur, car l’ancien auteur n’écrirait aucune modification et ne devrait pas être crédité de ces nouveaux changements. Ils n’ont pas réellement supprimé leur message sur Discourse, donc la suppression de l’activité de l’auteur d’origine ne refléterait pas nécessairement une vérité fondamentale. Mais ce qui avait été publié auparavant par l’acteur de l’ancien auteur serait ce qu’ils avaient écrit, et il n’y aurait aucune raison de supprimer ces messages. Et si quelqu’un suivait le lien vers Discourse, il verrait le contenu et l’auteur actuels, avec (si les permissions sont suffisantes) la vue de l’historique des modifications.
La même logique s’applique aux wikis. Ils apparaissent sur Discourse sous une paternité singulière mais permettent à d’autres d’écrire. Les mises à jour par d’autres auteurs ne sont pas largement attribuées (sauf si vous avez suffisamment de permissions pour lire l’historique). Il n’est pas vraiment significatif que cette attribution soit affichée par un avatar dans la vue Web au sein de Discourse ou par un acteur activitypub associé à une activité ; le résultat final est une attribution présentée au lecteur humain à l’autre bout d’un pipeline de rendu ou d’un autre.
1 « J'aime »
Hm, je ne suis pas sûr d’être d’accord. Le résultat final sera deux Notes identiques dans le Fediverse, écrites par différents Acteurs, qui seront toutes deux toujours visibles sur plusieurs plateformes. Pour une nouvelle personne découvrant ce contenu pour la première fois, elle verra le même contenu écrit par différentes personnes. Inversement, lorsque vous changez un auteur dans Discourse, vous réécrivez essentiellement l’histoire. Pour une nouvelle personne découvrant le contenu pour la première fois, vous ne voyez que le nouvel auteur. Il y a une différence, vous ne pensez pas ?
Je ne suis pas sûr de comprendre entièrement. Dites-vous que toutes les modifications apportées à la publication wiki, par n’importe quel utilisateur, devraient simplement être traitées comme des activités de mise à jour standard attribuées à l’Acteur d’origine (c’est-à-dire la personne qui l’a publiée) ?
Notez que c’est l’objet de cette PR, accompagné de notes explicatives.
4 « J'aime »