Note: This article is targeting a rather technical audience.
Our first project phase was called Architecture decisions & plugin skeleton: The most major decision is whether the plugin should work stand-alone, or as a child plugin of the existing ActivityPub-Plugin followed by a technical design draft: most API endpoints and the structure of the code should be sketched.
It consisted of two parts:
1. Research and decision whether to start of with a “child” or standalone plugin. Proposing solutions how to manage ActivityPub actors and ActivityPub transformation of custom post types. Proposing needed extensions of the upstream ActivityPub plugin.
As explained in previous posts, we decided that it would be best to work as closely as possible with the upstream ActivityPub plugin. We wrote two design proposals on how to implement flexible and dynamic actor and transformer management within the upstream plugin.
Actor management has proven to be extremely complex. With version 1.0 of the ActivityPub plugin, a blog-wide actor became available and we found out through direct exchange with the maintainer that there is already an application actor that would covers use cases like server-to-server following. Such fine-grained settings for ActivityPub profiles seem to be a feature that is mostly relevant for professional users in an advanced interface. That even the current complexity can be overwhelming for the average became clear to us. In addition, it seems reasonable to us not to develop such features before we know whether and how exactly they are needed. Furthermore, we believe it makes sense to implement other related features, such as moving accounts, first.
Transformer management: as a way to handle custom WordPress to ActivitPub transformers, e.g. that an custom post type that handles events does not end up as a Note, we proposed an addon-like structure where third party plugins could register their transformer(s) and in the ActivitPub settings the user would have a final control over which one is used. This approach would also mean a more complex admin UI, which was likely the main reason Matthias Pfefferle decided to go for a simpler, but maybe more error-prone solution: the upstream plugin provides a hook (filter) where other plugins could directly replace the transformer. In the future, a collision of multiple plugins trying to override a transformer might become more likely, but until this time comes, the risk is minimal. So far this approach seems like a good pragmatic solution for us.
2. Plugin skeleton for the ActivityPub event extensions and extending/creating the needed ActivityPub classes and ActivityStream representations for the events.
A pull request implementing more flexible ActivityPub object handling and a skeleton for and Event object which provides common extensions currently used mainly by Mobilizon has been merged upstream and is already released in the latest versions.
We created a repository for our ActivityPub event extensions plugin. This work is still pre-alpha, it is just kind of a public playground at the moment. Please don’t try to use it yourself until we tag first alpha or beta releases. We started adding transformers for popular event plugins. After many unsuccessful attempts to find out why our Transformers were no longer compatible with Mobilizon, we decided that a test site for developers was necessary, which we are currently trying to implement as a side project.
In addition, we have recognized the need to display various help messages and hints in the admin area in order to be able to better handle typical stumbling issues on the WordPress ActivityPub setup, which have also happened to us (more than once).
Leave a Reply