Estou planejando como melhor adicionar suporte ao ActivityPub às Tags, ou seja, permitir que as Tags sejam atores do ActivityPub. Um modelo com suporte ao ActivityPub precisa de armazenamento personalizado específico do registro. Uma maneira de fazer isso é com campos personalizados, por exemplo:
Existem outras maneiras de alcançar o mesmo resultado, mas os campos personalizados são talvez os mais diretos e seriam os mais consistentes com o modelo de dados do plugin ActivityPub e, talvez, do próprio Discourse.
Portanto, pensei em primeiro avaliar o interesse em adicionar suporte a CustomField às Tags, para o qual posso fazer um PR para o discourse/discourse.
Eu fiz um PR para isso. Note que esta é a implementação mais básica possível, pois nem a serialização da lista de tags nem a edição de informações (ou seja, na interface de informações de tags) são necessárias:
@sam Estou curioso para saber o que você pensa sobre isso? Temos desencorajado ativamente o uso de campos personalizados internamente há algum tempo, então não estou muito animado para abrir isso para tags.
Acho que a atração dos campos personalizados é que eles têm uma estrutura de integração predefinida, por exemplo, o registro de plugins e a API de plugins. Ter uma maneira estável de integrar com um modelo principal é preferível a criar uma integração personalizada do meu ponto de vista.
Eu sei o que você quer dizer sobre campos personalizados. Acho que diria que esses problemas existem de qualquer maneira. Se os campos personalizados de tags existem ou não, isso não mudará.
Com o tempo, o problema com campos personalizados tornou-se que eles são flexíveis demais, e as pessoas tendem a armazenar estruturas enormes e complexas em um blob.
Eu entendo totalmente que você quer algum tipo de mapa “oficial” de como fazer isso.
Acho que devolvendo a pergunta para você… exatamente do que estamos falando aqui?
Toda vez que o Discourse exibe uma tag, ele precisa exibir algo especial? (isso é um monstro para otimizar, pois há muitos lugares onde as tags são exibidas)
É apenas a página de tags?
É apenas uma tarefa em segundo plano configurada por administradores?
Acho que vamos começar por aí? O que exatamente você quer fazer? O que os vários usuários veem? etc…
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.
Desculpe pelo atraso aqui, @angus. Podemos tentar adicionar suporte a tags ao ActivityPub sem campos personalizados de tags?
Sei que isso não é consistente com o modelo de dados que estamos usando atualmente para categorias, mas é nossa abordagem preferida. Adicionar suporte a campos personalizados para tags no core significa que abriremos a porta para suporte total a elas no core. Sei que seu PR não adiciona isso, mas isso vai incentivar o próximo desenvolvedor a empurrar a porta um pouco mais para abrir.
