Estoy planeando cómo añadir mejor el soporte de ActivityPub a las etiquetas, es decir, permitir que las etiquetas sean actores de ActivityPub. Un modelo con soporte de ActivityPub necesita almacenamiento personalizado específico del registro. Una forma de hacerlo es con campos personalizados, por ejemplo:
Hay otras formas de lograr el mismo resultado, pero los campos personalizados son quizás los más sencillos y serían los más coherentes con el modelo de datos del plugin ActivityPub y, quizás, del propio Discourse.
Así que pensé en medir primero el interés en añadir soporte de campos personalizados a las etiquetas, para lo cual puedo hacer una PR a discourse/discourse.
He hecho una PR para esto. Tenga en cuenta que es la implementación más básica posible, ya que ni la serialización de la lista de etiquetas ni la edición de información (es decir, en la interfaz de usuario de información de etiquetas) son necesarias:
@sam Tengo curiosidad por saber qué opinas de esto. Hemos estado desalentando activamente el uso de campos personalizados internamente desde hace un tiempo, así que no me entusiasma abrir esto para las etiquetas.
Supongo que el atractivo de los campos personalizados es que tienen una estructura de integración predefinida, por ejemplo, el registro de complementos y la API de complementos. Tener una forma estable de integrarse con un modelo central es preferible a crear una integración personalizada desde mi punto de vista.
Sé a qué te refieres con los campos personalizados. Supongo que diría que esos problemas existen de todos modos. Que existan campos personalizados de etiquetas o no, no cambiará eso.
Con el tiempo, el problema con los campos personalizados ha sido que son demasiado flexibles, y la gente tiende a almacenar estructuras enormes y complejas en un blob.
Entiendo perfectamente que quieras algún tipo de mapa “oficial” de cómo hacer esto.
Supongo que te devuelvo la pregunta… ¿de qué estamos hablando exactamente?
¿Cada vez que Discourse muestra una etiqueta, necesita mostrar algo especial? (esto es un monstruo para optimizar porque hay muchos lugares donde se muestran las etiquetas)
¿Es solo la página de etiquetas?
¿Es solo una tarea en segundo plano configurada por los administradores?
Supongo que empecemos por ahí. ¿Qué quieres hacer exactamente? ¿Qué ven los diversos usuarios? etc…
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.
Lamento mucho la demora aquí, @angus. ¿Podemos intentar agregar soporte para etiquetas a ActivityPub sin campos personalizados de etiquetas?
Sé que no es coherente con el modelo de datos que estamos utilizando actualmente para las categorías, pero es nuestro enfoque preferido. Agregar soporte para campos personalizados para etiquetas en el núcleo significa que abriremos la puerta al soporte completo para ellas en el núcleo, sé que tu PR no agrega esto, pero impulsará al próximo desarrollador a empujar la puerta un poco más abierta.
