Ils stockeront les données ActivityPub associées à une balise jouant le rôle d’un acteur ActivityPub. Je n’ai besoin d’aucune sérialisation vers des parties du client dans discourse/discourse. L’utilisateur ne verra pas ces données dans aucune partie du client normal discourse/discourse. Les données seront sérialisées vers le client administrateur, avec d’autres données, cependant cela est géré par le plugin dans des routes d’administration dédiées au plugin. Comme vous le dites, la sérialisation dans les routes de balises existantes discourse/discourse (ou le sérialiseur de site) serait délicate, pour diverses raisons et ce n’est pas quelque chose que je souhaite tenter, c’est pourquoi je n’ai pas ajouté de méthodes api préchargées ou modifiables.
En plus d’avoir une API stable avec laquelle travailler, la raison pour laquelle ils sont préférables dans le plugin ActivityPub est que le plugin stocke les activités ActivityPub dans un ensemble distinct de modèles de données, les tables discourse_activity_pub_*, qui s’intègrent ensuite avec discourse/discourse via les API de plugin définies et les champs personnalisés des modèles principaux. Il y a une certaine redondance intentionnelle ici pour assurer une séparation appropriée des préoccupations entre les données Discourse et ActivityPub. Comme Discourse et ActivityPub ont une série de concepts et de modèles de données interdépendants, mais différents, il est nécessaire de maintenir une distinction claire entre les données ActivityPub et les données discourse/discourse pour conserver une certaine clarté (et santé mentale) dans ce qui est un plugin vaste et complexe. L’utilisation de champs personnalisés comme point d’intégration est très utile pour maintenir cette séparation propre et stable.
Il y a une brève explication de cela dans le README du plugin.