Almacenarán datos de ActivityPub asociados con una etiqueta que desempeña el papel de un actor de ActivityPub. No necesito ninguna serialización a ninguna parte del cliente en discourse/discourse. El usuario no verá estos datos en ninguna parte del cliente normal de discourse/discourse. Los datos se serializarán al cliente de administración, junto con otros datos, sin embargo, eso es administrado por el plugin en rutas de administración de plugins dedicadas. Como dices, la serialización en las rutas de etiquetas existentes de discourse/discourse (o el serializador del sitio) sería complicada, por diversas razones y no es algo que quiera intentar, por eso no agregué métodos de API de precarga o editables.
Además de tener una API estable con la que trabajar, la razón por la que son preferibles en el plugin de ActivityPub es porque el plugin almacena actividades de ActivityPub en un conjunto separado de modelos de datos, las tablas discourse_activity_pub_*, que luego se integran con discourse/discourse a través de las API de plugins definidas y los campos personalizados de los modelos principales. Hay cierta redundancia intencional aquí para garantizar la debida separación de responsabilidades entre los datos de Discourse y ActivityPub. Dado que Discourse y ActivityPub tienen una serie de conceptos y modelos de datos interrelacionados, pero diferentes, mantener una distinción clara entre los datos de ActivityPub y los datos de discourse/discourse es necesario para conservar cierta claridad (y cordura) en lo que es un plugin grande y complejo. El uso de campos personalizados como punto de integración es bastante útil para mantener esa separación limpia y estable.
Hay una breve explicación de esto en el archivo Léeme del plugin.