I’m planning out how best to add ActivityPub support to Tags, i.e. allow Tags to be ActivityPub actors. A model with ActivityPub support needs record-specific custom storage. One way to do this is with custom fields, e.g.
There are other ways to achieve the same result, but custom fields are perhaps the most straightforward, and would be the most consistent with the data model of both the ActivityPub plugin and perhaps Discourse itself.
So I thought I’d first gauge the appetite for adding CustomField support to Tags, for which I can make a PR to discourse/discourse.
I’ve made a PR for this. Note this the most basic possible implementation, as neither tag list serialization, nor info editing (i.e. in the tag info UI) is necessary:
@sam I’m curious what you think about this? We have been actively discouraging the use of custom fields internally for awhile now so I’m not really keen on opening up this for tags.
I guess the attraction of custom fields is that they have a predefined integration structure, e.g the plugin registry and plugin api. Having a stable way of integrating with a core model is preferable to rolling a custom integration from my vantage point.
I know what you mean about custom fields. I guess I would say that those issues are there regardless. Whether tag custom fields exist or not won’t change that.
Over time the trouble with custom fields has become that they are way too flexible, and people tend to store enormous complex structures in a blob.
I totally get that you want some sort of “official” map of how to do this.
I guess turning back the question to you… exactly what are we talking here?
Every time discourse displays a tag, does it need to display something special? (this is a monster to optimise cause there are lots of places where tags are displayed)
Is this just the tag page?
Is this just a background task that is configured by admins?
I guess lets start there? What exactly do you want to do? What do various users see? etc…
They will be storing ActivityPub data associated with a tag performing the role of an ActivityPub actor. I don’t need any serialisation to any parts of the client in discourse/discourse. The user won’t see this data in any part of the normal discourse/discourse client. The data will be serialised to the admin client, along with other data, however that is managed by the plugin in dedicated plugin admin routes. As you say, serialisation in the existing discourse/discourse tag routes (or the site serializer) would be tricky, for various reasons and not something I want to attempt, which is why I didn’t add preload or editable api methods.
In addition to having a stable api to work with, the reason they’re preferable in the ActivityPub plugin is because the plugin stores ActivityPub activities in a separate set of data models, the discourse_activity_pub_* tables, which then integrate with discourse/discourse via the defined plugin apis and core model’s custom fields. There is some intentional redundancy here to ensure proper separation of concerns between Discourse and ActivityPub data. As Discourse and ActivityPub have series of interrelated, but different, concepts and data models, keeping a clear distinction between ActivityPub data and discourse/discourse data is necessary to retain some clarity (and sanity) in what is a large and complex plugin. Using custom fields as an integration point is quite useful in keeping that separation clean and stable.
There is a brief explanation of this in the plugin’s readme.
So sorry for the delay here @angus. Can we try and add tag support to ActivityPub without tag custom fields?
I know it’s not consistent with the data model we’re currently using there for categories, but it’s our preferred approach. Adding custom fields support for tags in core means we’d open the door to full support for them in core, I know your PR doesn’t add this, but it will nudge the next developer to push the door slightly more open.
