Notices by Event Federation (blog@event-federation.eu)

It’s been a long road, but now a first version (v0.3.5) of the plugin is available via the official plugin sources on WordPress.org.

https://wordpress.org/plugins/event-bridge-for-activitypub/

Further features are almost ready and will follow in the coming days. This is includes some more complex features like aggregating events from other remote ActivityPub actors and improvements like better accessibility in the admin UI.

We are looking forward to feedback from users. You can find our guidelines for contributing here.

Unfortunately, interoperability with other applications is still limited, often caused by unresolved issues within other applications. However, we all are all working on it and are confident that things will be smoothed out in the course of this year!

This was a good reason for us to move the repository from our self-hosted Forgejo to Codeberg.org for several reasons:

• less maintenance
• less hurdles to contribute
• @Codeberg is awesome
• we love Forgejo actions and can still use our own Forgejo-runner

We’d like to thank @NGIZero and @nlnet for allowing us to spend the considerable time we’ve put into developing this plugin.

#ActivityPub #codeberg #Events #WordPress

First of all I would like to thank all reviewers and contributors to the FEP (Fediverse Enhancement Proposal): @lesion, @mro, @naturzukunft, @laurin and more.

This article tries to outline some areas where the FEP is currently undergoing evolution:

Providing an endTime is now mandatory, but guidelines how to deal with events that do not have one set are also included. In addition, a new attribute has been proposed to mark an event as open-ended, so that no end date should be displayed to users, while at the same time being available to applications, e.g. for processing a list of current and future events.

It has not yet been decided whether to include a property to mark an event as all day, or to use a similar flag for the start time.

There are currently no plans to include proposals for recurring events, both based on schedules or not, in the proposal. As the topic seems to be too complex, it looks like it will be in a separate FEP.

When writing ActivityPub integrations for several existing WordPress event plugins, it became apparent that handling organizers only via attributedTo is not practical. This became even more apparent when it came to interoperability between different applications. For example, Gancio has only one actor, but can have multiple users and therefore organisers, but the organisers are intentionally hidden, and the ActivityPub actor in attributedTo is just the Gancio instance.

We therefore proposed an organizers attribute which is a collection holding the organizers. If it’s not present fallback guidelines are provided, and it’s also possible to leave it explicitly empty. Note that this also gives the opportunity to just include links to non-ActivityPub things.

Still under discussion is whether to include a process or proof that an ActivityPub actor has actually agreed to be part of an organiser collection for a particular event. Contributions are very welcome here!

In this respect, the question arised as to whether mechanisms should be included to allow pre-confirmation of whether anonymous (non-ActivityPub-public) joins are allowed, or whether they are rejected by default.

Everyone is welcome to help us improve this document. Every comment helps. If you are familiar with code forges, comments and reviews on codeberg are preferred, but replies to this article are also very welcome!

The 1.0 release of our WordPress plugin Event Bridge for ActivityPub is scheduled for early January 2025.

Over the past year, the development plan for the 1.0 release of our WordPress plugin, Event Bridge for ActivityPub, has evolved significantly. After extensive testing and an evaluation process with real users, we’ve finalized the feature set for this upcoming release as follows:

• Basic support for 10 widely-used WordPress event plugins.
• Compatibility with multiple event plugins simultaneously, as we found that switching between plugins is common and maintaining archives is essential.
• Event Aggregation from the Fediverse: follow other ActivityPub profiles to get and display their events. Will only be available with select event plugin integrations.
• Map WordPress event categories to federated event categories, ensuring consistency across platforms.
• Customizable event summaries for platforms like Mastodon that don’t natively support events in ActivityPub.
• Send reminders (via Announce or custom Note) to followers at a configurable time before the event starts.
• A streamlined admin dashboard that includes health checks and feedback to guide users to easily resolve faulty configurations.

A security and accessibility review is currently taking place, and we will also be adapting the results of this.

Our plugin submission to WordPress.org has just been rejected by the reviewers because they feel it violates trademarks by starting the plugin slug with “activitypub”.

The current name is ActivityPub Event Bridge and therefore the slug is activitypub-event-bridge. They suggest to rename it to Event Bridge for ActivityPub and adjust the slug to event-bridge-activitypub.

Should we just comply and do as they say, or should we make them reconsider that “ActivityPub” is not a trademark in this sense?

@pfefferle I would really appreciate you sharing your thoughts on this.

An initial draft for the FEP A common approach to using the Event object type has been published.

https://codeberg.org/linos/fep/src/branch/fep-8a8e/fep/8a8e/fep-8a8e.md

The pull request is still marked as work-in-progress. Firstly, we would like to have a discussion about it with the community, which you are invited to join on SocialHub.

Reply Collections have not yet really reached the centre of the #Fediverse. Among other things, moderation aspects play a role here (see FEP-7458 or FEP-5624). But in principle, they offer a wonderful opportunity to maintain consistency in discussion threads in the Fediverse.

Smaller instances in particular often lack reactions to content published in the Fediverse. In principle, this is not a bad thing. Nevertheless, it makes sense for both servers and clients to be able to retrieve a complete comment tree in some scenarios (possibly at the request of a user).

To this end, we have submitted a first draft in a pull request to the Upstream #ActivityPub plugin for #WordPress. In this case, we benefit from the already existing comment management of the WordPress core and only list approved comments in the replies collection.

#ActivityPub #Fediverse #WordPress

We promised to keep you updated every two months, though this post comes a bit delayed (see reasons). Thankfully NLnet extended our time period. Now that at least one person can dedicate a regular 30 hours a week to the project, we are confident things will develop more quickly from now on.

We are currently having our first exchanges with venues and organizations that will likely use WordPress ActivityPub for their event publishing. From these initial interviews, we are gathering insights to ensure we are on the right track. We’ve chosen several institutions based in Graz, where most of us live, because face-to-face conversations are invaluable and sometimes the only way to make sure we’re communicating our true intentions – we’re not trying to sell anything, we have a vision. A detailed report on those results will follow.

However, anyone else with a WordPress site who wants to explore publishing events to the Fediverse and help shape future features (such as attendee management, participant notifications, etc.) is welcome to contact us. We’d love to hear from you!

#ActivityPub #WordPress

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:

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 risk this time comes, the risk is minimal. So far this approach seems like a good pragmatic solution for us.

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

#ActivityPub #WordPress

Visibility and discoverability have been much discussed topics recently, especially when Mastodon announced the introduction of a full-text search. Protecting users from abusive searches is a major concern. In the case where one instance follows another, this results in a different complexity of the problem, especially if there are two software applications that specialize in events but have a completely different approach to them, like Gancio, Mobilizon or a local community site run with WordPress.

We would like to find a common denominator for this problem and have therefore opened a topic on Socialhub. We look forward to everyone contributing to the discussion or just leaving some thoughts in the replies.