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. plugin.rb main activity_pub_actor&.post_object_type end add_to_class(class_name, :activity_pub_publication_type) do activity_pub_actor&.publication_type || "full_topic" end add_to_class(class_name, :activity_pub_first_post) do activity_pub_publication_type === "first_post" end add_to_class(class_name, :activity_pub_full_topic) do activity_pub_publication_type === "full_topic" end add_to_class(class_name, :activity_pub_default_object_type) do DiscourseActivityPub::AP::Actor::Group.type end add_to_class(class_name, :activity_pub_deleted?) { activity_pub_actor.tombstoned? } add_to_class(class_name, :activity_pub_follower_count) { activity_pub_followers.count } add_to_class(class_name, :activity_pub_visibility) { "public" } add_to_class(class_name, :activity_pub_delete!) { perform_activity_pub_activity(:delete) } add_to_class(class_name, :performing_activity_after_perform) do if performing_activity.delete? && activity_pub_actor if !activity_pub_actor.model || activity_pub_actor.model.destroyed? 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. cc @pmusaraj

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: Add tag custom fields (#26049) main ← angusmcleod:add_tag_custom_fields opened 10:49AM - 06 Mar 24 UTC (UTC) [תמונה] angusmcleod +44 -0 See further https://meta.discourse.org/t/tag-custom-fields/297798?u=angus Not…e that: - serialization of custom fields in lists of tags is not yet needed (and may never be) hence no preload structure should be added at this stage. - editing of tag custom fields via the tag info UI is not yet needed (and may never be) hence no editable custom field structure should be added at this stage.

Yeah I am generally against sadly, this just ends up causing too much pain and suffering down the line. @angus why not just add a new table here with a tag_id column?

Yes, I could. 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. But there are other options, so up to you :+1:

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. README.md main # Discourse ActivityPub Plugin Allows you to publish Discourse posts via ActivityPub so they can be read on services that support ActivityPub such as Mastodon. For more information, please see https://meta.discourse.org/t/activitypub-plugin/266794 ## Contributing This section is about contributing to the plugin and assumes familiarity with Discourse plugin development. If you want to learn more about Discourse plugin development check out the guides on [meta.discourse.org](https://meta.discourse.org/t/developing-discourse-plugins-part-1-create-a-basic-plugin/30515). ### Server Think about the plugin server as comprising three parts: 1. the AP module; 2. the plugin; and 3. Discourse integration. #### The AP Module The AP module: This file has been truncated. show original

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.

No worries, I appreciate the consideration. I’ll find another way.

תיוג שדות קאסטום?

מפתח

tgxworld (Alan Tan) 12 במרץ,‏ 2024,‏ 5:37am 3

@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.

נושא		תגובות	צפיות
How to add custom fields to models Extras pavilion	48	9774	30 בספטמבר,‏ 2025
Feature request: tag replies, not just topics Feature	4	902	16 במרץ,‏ 2018
Are custom_fields on posts/topics available via the API? Development	7	3562	24 באוקטובר,‏ 2018
Is anyone else using tags on a Discourse forum in a big way? Community Building	11	4073	16 בינואר,‏ 2020
Is this a use case for user custom fields? Product Support	15	1556	27 במאי,‏ 2020

תיוג שדות קאסטום?

נושאים קשורים