Eles armazenarão dados do ActivityPub associados a uma tag que desempenha o papel de um ator do ActivityPub. Não preciso de nenhuma serialização para nenhuma parte do cliente em discourse/discourse. O usuário não verá esses dados em nenhuma parte do cliente normal do discourse/discourse. Os dados serão serializados para o cliente de administração, juntamente com outros dados, embora isso seja gerenciado pelo plugin em rotas de administração dedicadas do plugin. Como você disse, a serialização nas rotas de tag existentes do discourse/discourse (ou no serializador do site) seria complicada, por vários motivos e não é algo que eu queira tentar, é por isso que não adicionei métodos de API de pré-carga ou editáveis.
Além de ter uma API estável para trabalhar, o motivo pelo qual eles são preferíveis no plugin ActivityPub é porque o plugin armazena atividades do ActivityPub em um conjunto separado de modelos de dados, as tabelas discourse_activity_pub_*, que então se integram ao discourse/discourse por meio das APIs de plugin definidas e dos campos personalizados dos modelos principais. Há alguma redundância intencional aqui para garantir a separação adequada de responsabilidades entre os dados do Discourse e do ActivityPub. Como o Discourse e o ActivityPub têm séries de conceitos e modelos de dados inter-relacionados, mas diferentes, manter uma distinção clara entre os dados do ActivityPub e os dados do discourse/discourse é necessário para reter alguma clareza (e sanidade) em um plugin grande e complexo. O uso de campos personalizados como ponto de integração é bastante útil para manter essa separação limpa e estável.
Há uma breve explicação disso no README do plugin.