Lorsque vous supprimez une publication AP sur Discourse, nous envoyons une suppression pour le contenu à Mastodon. C’est à eux de le traiter. Cela devrait fonctionner, donc si vous pouvez me montrer des exemples spécifiques, je peux essayer de voir où le flux de suppression ne fonctionne pas comme prévu (c’est-à-dire si c’est du côté de Discourse ou de Mastodon).
La raison pour laquelle il en est ainsi est que Mastodon ne permet pas actuellement de changer de pseudonyme. C’est la cause profonde du problème que vous rencontrez. Je plaide pour que cela soit le cas depuis un certain temps et j’ai une PR en attente pour Mastodon. Lorsque celle-ci sera fusionnée, vous pourrez résoudre ce problème en changeant le pseudonyme dans Discourse.
L’utilité de désactiver un pseudonyme est qu’aucun contenu entrant vers ce pseudonyme ne sera traité et il n’enverra aucun nouveau contenu. C’est aux autres plateformes de décider ce qu’elles font de votre contenu existant, y compris comment elles traitent une activité de suppression que nous leur envoyons.
C’est normal si le réglage « Full Post » est activé (ce qui doit être le cas dans votre situation). Le contenu est publié sous le nom de l’Acteur de l’utilisateur (c’est-à-dire vous dans ce cas). Si vous souhaitez publier sous le nom de l’Acteur de la catégorie, vous devriez utiliser « First Post ». Dans ce cas, seul le premier message de chaque sujet est publié. Vous pouvez voir un exemple de l’approche « First Post » dans cette vidéo :
Oui, c’est le cas. Merci de m’avoir aidé. Bien sûr, j’ai vu les vidéos et cela m’a éclairé sur certains points et m’a aidé à le configurer. Merci pour cela !
Donc, bien sûr, je ne peux pas supprimer ces “handles” créés que je n’ai jamais créés activement.
Quand j’y pense, je ne me sens pas bien à ce sujet… Si tout le monde l’utilise comme moi, il y aura des tonnes de “content snippets” de personnes qui ne pourront jamais être supprimés. Cela remplit Internet de moins de sens, ou ai-je tort ?
Ce n’est pas de votre faute, j’essaie juste de comprendre ce qui se passera si tout le monde est aussi idiot que moi et remplit Internet de “test-postings” qui ne seront jamais supprimés
Vous pouvez cependant supprimer les publications. Lorsque vous supprimez une publication, Discourse envoie une commande de suppression à Mastodon et Mastodon devrait supprimer sa copie. Si cela n’a pas fonctionné, essayez de restaurer la publication et de la supprimer à nouveau. Vérifiez les journaux lorsque vous faites cela.
Comme je l’ai dit, vous devriez pouvoir supprimer les publications elles-mêmes, mais à part cela, je ne m’en inquiéterais pas trop. Mastodon est une plateforme basée sur le flux. Vos publications de test se perdront rapidement dans le flux de contenu. De plus, quelqu’un d’autre (à part vous) suivait-il réellement votre acteur à ce moment-là ? J’ai des centaines de publications de test dans le fediverse et cela n’a eu aucun impact
Mais faites-moi savoir comment vous vous en sortez pour supprimer les publications.
J’ai restauré les publications et les ai à nouveau supprimées.
Elles sont visibles sur Mastodon. Lorsque je clique, cela me renvoie à la publication supprimée sur Discourse.
Parmi les communautés Discourse auxquelles je participe, je ne peux en penser que trois où je voudrais suivre certaines catégories, mais où je ne voudrais pas suivre l’acteur Application pour l’ensemble du Discourse.
J’ai un lecteur RSS, et je suis des sites entiers via RSS ; ActivityPub serait une meilleure expérience, particulièrement pour répondre.
L’acteur Application est-il difficile à mettre en œuvre ou simplement de faible priorité ?
Suivre une instance entière signifie que tous les publications de cette instance apparaissent dans votre flux Mastodon sous forme de flux continu. À moins que l’instance n’ait pas beaucoup d’activité, je parierais que ce sera un cas d’utilisation de niche. Peut-être que je me trompe, mais à première vue, il me semble peu probable que cela devienne populaire.
Avez-vous examiné les journaux ? Confirmons que nous envoyons l’activité de suppression à Mastodon.
Il existe, je pense, une très longue traîne d’instances Discourse à faible trafic mais définitivement actives qui ont encore plusieurs catégories. Évidemment, meta ne fait pas partie de ces petites instances. Mais des trois instances Discourse que j’administre personnellement, l’une a un trafic si élevé que je ne mettrais même pas plusieurs de ses catégories dans mon flux Mastodon, et deux ont des taux de trafic suffisamment bas que je préférerais certainement suivre le site entier. Il y en a d’autres dont je suis membre où je suivrais également le site entier si j’en avais l’option.
Je ne vous demande pas de changer les priorités ici. Je partage simplement la perspective alternative.
C’est une « fonctionnalité » (en quelque sorte) que l’on retrouve sur certaines plateformes AP. Je note que la spécification ActivityPub stipule :
La méthode HTTP GET peut être référencée contre la propriété id d’un objet pour récupérer l’activité. Les serveurs PEUVENT utiliser la négociation de contenu HTTP telle que définie dans [RFC7231] pour sélectionner le type de données à retourner en réponse à une requête, mais DOIVENT présenter la représentation de l’objet ActivityStreams en réponse à application/ld+json; profile="https://www.w3.org/ns/activitystreams", et DEVRAIENT également présenter la représentation ActivityStreams en réponse à application/activity+json. Le client DOIT spécifier un en-tête Accept avec le type de média application/ld+json; profile="https://www.w3.org/ns/activitystreams" afin de récupérer l’activité.
Le plugin AP exige actuellement que vous envoyiez un en-tête Accept avec soit « application/ld+json » soit « application/activity+json » pour récupérer un objet (c’est-à-dire une activité, une note, etc.). Nous pourrions prendre en charge ce à quoi vous faites référence à l’avenir, mais il s’agit quelque peu d’une fonctionnalité « power user » de plateformes spécifiques.
Les identifiants d’objet ne sont pas vraiment destinés à être utilisés comme URL partageables/copiables par un utilisateur final dans un client. Nous les rendons disponibles dans la fenêtre modale de statut ActivityPub à des fins de développement/débogage. Votre client devrait utiliser l’attribut url que nous sérialisons sur l’objet. Par exemple, si vous visitez le sujet auquel vous avez lié sur mastodon.social (ici) et que vous cliquez sur « Copier le lien vers le statut » dans le menu du toot, vous constaterez qu’il s’agit d’un lien direct vers le sujet sur meta. Mastodon standard utilise l’attribut url de l’objet pour, eh bien, partager l’URL
Ce sera parce que l’en-tête Accept n’est pas défini. Je suis ouvert à des ajustements (c’est-à-dire à résoudre les requêtes d’identifiant d’objet avec les mauvais en-têtes vers l’URL du modèle connecté), mais pour le moment, je pense que les personnes qui développent votre client devront le mettre aux normes (c’est-à-dire utiliser l’attribut url de l’objet au lieu de l’attribut id de l’objet comme URL visible par l’utilisateur).
J’ai suivi @feature@meta.discourse.org et @announcements@meta.discourse.org sur Mastodon peu de temps après leur annonce, et j’ai rapidement cessé de recevoir des mises à jour. J’ai pensé que c’était parce que le plugin avait été supprimé de meta, j’ai haussé les épaules et j’ai laissé tomber.
Mais s’il est toujours actif, je me demande quel est le problème de fédération avec social.makerforums.info.
Il y a eu beaucoup de changements au début de la vie du plugin, donc je m’excuse si l’un de ces changements a supprimé votre suivi. Veuillez réessayer de suivre et voyez comment cela se passe.
Est-ce une fork de glitch-soc ? Je ne vois pas la fenêtre de partage que vous avez mise en capture d’écran dans leur code. Mais oui, je serais heureux de travailler avec l’administrateur de votre serveur pour clarifier les choses davantage si nécessaire.
Les liens affichent https://social.makerforums.info/users/mcdanlj qui inclut correctement le domaine, mais quelqu’un qui essaierait d’entrer ce qu’il voit dans cette liste d’abonnés afin de me rechercher ou de me suivre échouerait.
Je n’ai trouvé nulle part du côté de Mastodon où le sous-domaine est tronqué.