This document outlines suggestions for the further development of the WordPress ActivityPub plugin regarding its interoperability with other WordPress plugins that could enhance ActivityPub functionality.
- **transformers:** a piece of code that converts items of particular WordPress post types to an ActivityPub object. For example a transformer that can transform:
-`post` or `page` to `Note`, `Article`, `Image`, `Audio` or `Article` depending on the [post-format](https://wordpress.org/documentation/article/post-formats/)
-`tribe_events` (Event post the of [The Event Calendar](https://wordpress.org/plugins/the-events-calendar/)) to `Event`
-`podcast` (Podcast post of [Podlove Podcast Publisher](https://github.com/podlove/podlove-publisher)) to `PodcastEpisode` (as proposed and [implemented by Castopod](https://code.castopod.org/adaures/castopod/-/blob/main/app/Libraries/PodcastEpisode.php))
- should be aware (or even control) the whole chain from creating some content within WordPress to being published via ActivityPub. For sure, it should be the only plugin that directly sends and receives ActivityPub.
- should not get any more complex by default, the out-of-the box functionality/features and simplicity should be similar to version 1.0.0.
- offers other plugins the possibility to register custom transformers.
- (maybe) offers other plugins the possibility to register new WordPress actor types, e.g. the `tribe_organizer` post type of [The Event Calendar](https://wordpress.org/plugins/the-events-calendar/).
- handles the controls collisions of actor names:
* collisions that are already present during activation of a WordPress actor type on the settings page
* (maybe) show notifications/warnings when using an actor name which has been used and followed by in the past, as there may be issues due to caching of the old public key.
## Goals of the WordPress Event Federation project
The aim of the event federations project is to enable seamless federation of events created within an event plugin as an ActivityPub object with Type `Event` and accompanying meta-data, as typically seen in common ActivityPub implementations like Mobilizon. This will guarantee optimal compatibility between various services.
Nevertheless, we see a lot of other cases that can benefit, if the primary goals of the Event Federation project are achieved this using a modularized approach as proposed below. The following list indicates examples what might be those other benefits:
- ActivityPub offers features how to deal with multilingual content ([contentMap - see Example 115](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-contentmap)) which could be implemented differently by multilingual and translation plugins (example search for the current use of `->set_content_map` within the ActivityPub plugin).
**Note:** CastoPod, to give an example, has currently decided that podcast episodes will not be sent to followers as a `Create` activity directly containing the `PodcastEpisode` object, but will send a `Note` which is linking to the `PodcastEpisode`, because most Fediverse implementations currently ignore by default all object types they don't know. This is likely the same reason [flohmarkt](https://codeberg.org/grindhold/flohmarkt) is currently also using the `Note` and not `Product` even though that one would be available in the official specification.
Currently, all this functionality is handled via one hard-coded transformer in `includes/transformer/class post.php` ([Source](https://github.com/Automattic/wordpress-activitypub/blob/master/includes/transformer/class-post.php)) and the actual logic that assigns the type is somewhere else.
All publicly accessible WordPress post types can become active for ActivityPub federation when selecting a transformer available for the relevant post type. **It is up to the transformer to determine the target ActivityPub object type**, which may vary depending on variables such as post type or post format. If there is no specific transformer available for a given post type, it cannot be assigned through the user interface.
**Note:** Only one or zero selections can be made in each row.
- For any custom post type, if there is a custom transformer registered, indicate that one should be selected as default (or select it right ahead?).
- Should not differ too much from the current view: Maybe completely hide the current activity object type part of the settings and only show the buttons for `enable` and `disable` and move the transformer table to an advanced settings page.
- Maybe make the tables more advanced and clearly show the origin of the transformer (built-in, etc.) and maybe a Pop-Up with a description, or even a link to a configuration page of the transformer.
- Highly unlikely: The ActivityPub plugin provides an even more high level framework for adding transformers. For example for events the ActivityPub plugin could provide a built-in transformer to the object type `Event` which only needs a mapping (might make things harder, instead of making them easier). See Appendix.
More comprehensive actor management would benefit our project aims and potentially meet the needs of others in the future. Nevertheless, **its importance is considerably lower than that of Transformer management**. In the future, the following factors may become more important when larger websites should be using the ActivityPub plugin.
Currently, the whole logic controlling this is written within the `Activity_Dispatcher` [class](https://github.com/Automattic/wordpress-activitypub/blob/master/includes/class-activity-dispatcher.php#L21) which is currently triggered only within the `Scheduler` [class](https://github.com/Automattic/wordpress-activitypub/blob/master/includes/class-scheduler.php#L14-L15).
Furthermore, although a blog actor is available, the ActivityPub plugin is still written in such a way that WordPress users are the default ActivityPub actors. This also reflects in things like the class which is responsible for the actor lookup is still called `Users` and yet handles the `Blog` and the `Application` user too, see the [Source](https://github.com/Automattic/wordpress-activitypub/blob/master/includes/collection/class-users.php).
The ActivityPub specification allows for immense flexibility in its application. As WordPress websites fulfill a variety of tasks and objectives, it is **challenging to implement control features and options for actor management that are more capable without sacrificing user-friendliness.**
- For maximum Mobilizon compatibility we would love to have simply an actor of type `Application`, preferable called `@relay@wordpress.site`, that announces all events. Nonetheless, in theory, a Mobilizon instance should have the capability to follow any other actor as well. More or less this can already be achieved with the current blog-actor.
- Additionally, for example, organizers in [The Event Calendar](https://wordpress.org/plugins/the-events-calendar/) could also offer their own actor of type `Organizer` or `Group` to publicize events (getting referred to via [attributedTo](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-attributedto)) if the `author`-actors are enabled, or create events (being the [actor](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-actor) directly) if the `author`-actors are not enabled.
- Optional: As events are sometimes published a long time before they start, adding the possibility that events get announced again at a scheduled time before the start, e.g. by sending an `Announce` activity.
Other WordPress actor types might have valid use cases, like actors for categories, or specific post types in general: "I only want to see the blog updates, but I do not want to spam my timeline with each product they post on their website, even if they choose to federate them."
We keep in mind that every post shall only ever be sent as a `Create` Activity once, by one single actor.
Therefore when the ActivityPub plugin makes use of a certain WordPress actor type, the WordPress actor type must exactly return one actor, which may depend on the current post being published and on the user doing the action (latter information should also be available within the WP_Post object).
But in reality [webfinger](https://webfinger.net/) is used: `@actor-name@instance.tld`. Actors like Persons and Groups and Applications have public keys attached to them, as well as their ID is probably cached by most software. So assigning some actor-name to something new also can cause unintended behavior.
If multiple plugins want to individually federate their content (like events, products, and blog posts or even the built-in WordPress categories), they must be able to have something like an actor API, the ActivityPub plugin can register. The ActivityPub plugin being the main coordinator is necessary because actors are globally unique.
[youtube-dl](https://github.com/ytdl-org/youtube-dl) is solving a similar problem with "extractors" that return data to the processing-chain of youtube-dl. They provide a base class that includes useful functions for common issues e.g. automatic testing, geo-bypassing, login/cookie/header management. The most [basic extractor](https://github.com/ytdl-org/youtube-dl#adding-support-for-a-new-site) is about 40 lines of code.
They can also chain extractors recursively, like a extractor for mastodon videos, that gets the video from the post and returns the source of the video, that could be YouTube, Vimeo or anything else youtube-dl supports.
