Memorizzeranno i dati di ActivityPub associati a un tag che svolge il ruolo di un attore di ActivityPub. Non ho bisogno di alcuna serializzazione in alcuna parte del client in discourse/discourse. L’utente non vedrà questi dati in alcuna parte del normale client discourse/discourse. I dati verranno serializzati nel client admin, insieme ad altri dati, tuttavia ciò è gestito dal plugin in percorsi admin dedicati al plugin. Come dici tu, la serializzazione negli attuali percorsi di tag discourse/discourse (o nel serializzatore del sito) sarebbe complicata, per varie ragioni e non è qualcosa che voglio tentare, motivo per cui non ho aggiunto metodi api di precaricamento o modificabili.
Oltre ad avere un’API stabile con cui lavorare, il motivo per cui sono preferibili nel plugin ActivityPub è che il plugin memorizza le attività di ActivityPub in un set separato di modelli di dati, le tabelle discourse_activity_pub_*, che quindi si integrano con discourse/discourse tramite le API del plugin definite e i campi personalizzati dei modelli core. C’è una certa ridondanza intenzionale qui per garantire una corretta separazione delle responsabilità tra i dati di Discourse e ActivityPub. Poiché Discourse e ActivityPub hanno una serie di concetti e modelli di dati interrelati, ma diversi, mantenere una chiara distinzione tra i dati di ActivityPub e i dati di discourse/discourse è necessario per mantenere una certa chiarezza (e sanità mentale) in quello che è un plugin grande e complesso. L’uso di campi personalizzati come punto di integrazione è molto utile per mantenere questa separazione pulita e stabile.
C’è una breve spiegazione di questo nel readme del plugin.