Sie werden ActivityPub-Daten speichern, die mit einem Tag verbunden sind, der die Rolle eines ActivityPub-Akteurs ausführt. Ich benötige keine Serialisierung für Teile des Clients in discourse/discourse. Der Benutzer wird diese Daten in keinem Teil des normalen discourse/discourse-Clients sehen. Die Daten werden zusammen mit anderen Daten an den Admin-Client serialisiert, dies wird jedoch vom Plugin in dedizierten Plugin-Admin-Routen verwaltet. Wie Sie sagen, wäre die Serialisierung in den bestehenden discourse/discourse-Tag-Routen (oder dem Site-Serializer) aus verschiedenen Gründen schwierig und nichts, was ich versuchen möchte, weshalb ich keine Preload- oder bearbeitbaren API-Methoden hinzugefügt habe.
Zusätzlich zu einer stabilen API, mit der gearbeitet werden kann, sind sie im ActivityPub-Plugin vorzuziehen, da das Plugin ActivityPub-Aktivitäten in einem separaten Satz von Datenmodellen speichert, den discourse_activity_pub_*-Tabellen, die dann über die definierten Plugin-APIs und benutzerdefinierten Felder der Kernmodelle mit discourse/discourse integriert werden. Es gibt hier eine beabsichtigte Redundanz, um eine ordnungsgemäße Trennung der Zuständigkeiten zwischen Discourse- und ActivityPub-Daten sicherzustellen. Da Discourse und ActivityPub eine Reihe von miteinander verbundenen, aber unterschiedlichen Konzepten und Datenmodellen haben, ist die Beibehaltung einer klaren Unterscheidung zwischen ActivityPub-Daten und discourse/discourse-Daten notwendig, um etwas Klarheit (und geistige Gesundheit) in einem großen und komplexen Plugin zu bewahren. Die Verwendung von benutzerdefinierten Feldern als Integrationspunkt ist sehr nützlich, um diese Trennung sauber und stabil zu halten.
Eine kurze Erklärung dazu finden Sie in der README-Datei des Plugins.