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

Hooray! It is now official: We have been granted funding by NLnet to support the realisation the vision we outlined in our last post.

Events are at the heart of social life and deserve to be treated accordingly in the Fediverse. […]

In addition, we will also investigate the Fediverse Auxiliary Service Provider Specifications (FASPs) for discoverability and filtering of public events.

#FASPs #Fediverse #NGI0 #NLnet

Details will follow soon — but the work on events in the #Fediverse is far from complete. Key upcoming milestones include:

• Improvements and new features for the Event Bridge for ActivityPub plugin for WordPress
  Continued development to maintain, fix issues, enhance, and expand functionality.
• Work on Fediverse Enhancement Proposals (FEPs)
  Ensuring a robust final status of FEP-8a8e and focus on recurring and irregularly scheduled events.
• Support for event interoperability in other Fediverse applications
  Contribute to other Fediverse applications and help them to explore and improve support for Event objects. For example, @linos@graz.social has outlined a potential roadmap for Mastodon.
• Contribution to GatherPress
  Active involvement in the GatherPress project — a modern and truly FLOSS community oriented WordPress event plugin — to ensure full ActivityPub compatibility, including RSVP support and advanced federation features.
• Community engagement and outreach
  Participation in conferences, public talks, and direct conversations to foster knowledge exchange, gather feedback, and grow the ecosystem around federated events.

Additional updates and technical details will be shared soon. Input, testing, and collaboration from interested parties are always welcome. Or if you know any conferences we should attend, let us know.

#ActivityPub #Events #Fediverse #FEP #GatherPress #WordPress

The FEP-8a8e (Fediverse Enhancement Proposal) had at lot of progress in the last months. In the meantime, the document has become somewhat more extensive than originally planned, but contains not only instructions for new features that have to be tediously implemented, but also a lot of advice and points that should provide orientation for developers of Fediverse applications that support events.

It now covers:

• Required attributes
• Events with Open End
• Timezone
• Physical and Virtual Locations
• Event status
• RSVP (Attendee Management)
• Event Banner and Poster Images
• Event Categories
• Discoverability
• Event Organizers
• Upcoming Events Collection for ActivityPub actors
• Term Definitions

Many thanks again to all reviewers and co-editors:

@lesion @heiglandreas @naturzukunft @laurin

We warmly welcome further feedback from the communities of #Friendica, #Mobilizon, #Hubzilla, and other Fediverse platforms supporting events.
If you’re working on such an application or are part of these communities, your insights would be very valuable! @developers @mobilizon

#ActivityPub #Fediverse #FEP

When you hear ‘CloudFest’, many people associate it with a business-to-business event, which it is, but the hackathon in the run-up to it still has a certain degree of community character. On the initiative of Andreas Heigl (@heiglandreas@andreas.heigl.org) and the support of Matthias Pfefferle (@pfefferle), this year’s hackathon provided the resources and space for an exchange of ideas around ‘federated events’.

Our group was one of the largest and very diverse. We used the first day primarily to exchange ideas about our goals and the status quo. Afterwards, we reviewed and improved existing features and developed prototypes and concepts for new ones.

For me as a developer of the WordPress plugin Event Bridge For ActivityPub, the best thing about these days was to finally get to know the entire WordPress/Automattic team involved with ActivityPub in person (greatings at @mattwiebe and @obenland).

I would like to emphasise a few achievements in particular, without neglecting the achievements of all:

• Matthias Heigl took the time to take an intensive look at the FEP-8a8e. His many years of experience with the development of calendar features and iCal provided important suggestions for making the specification even more far-sighted.
• Laura (https://working-directory.com/) helped to reduce the barriers new developers face when experimenting with the interaction of Gancio/Mobilizon and WordPress and others.
• Finally, many thanks to Cloudfest for the great organisation and hosting!

Links:

• https://codeberg.org/cfh25-fce
• https://hackathon.cloudfest.com/project/federated-community-events/
• https://fedivents.blog/

#Hackathon #Fedivents #WordPress #CloudFest

#CloudFest #Fedivents #Hackathon #WordPress

When is the right time to release version 1.0.0? – If I had waited until every interoperability issue was resolved, probably never.

However, the main goal of this plugin is now realized: enhancing the WordPress ActivityPub plugin to support third-party integrations – specifically, ensuring that events from popular WordPress event plugins can be shared and discovered across the Fediverse (Release on Codeberg.org). Checkout this Gancio demo site, where you can see events sourced from a WordPress site in action!

A special thanks to the team at Radically Open Security (@ros) for their security review. My correspondence with the pentester Marcus Bointon (@Synchro) was not only professional but also fun and incredibly insightful – I learned far more than I could have imagined.

I’m also grateful to Matthias Pfefferle (@pfefferle) and the other developers of the WordPress ActivityPub plugin. Collaborating with them to make the plugin more adaptable for third-party use has been a rewarding experience.

A huge shoutout to @lesion for his contributions to FEP-8a8e, his insightful ideas, valuable discussions, and his incredibly quick implementations of all kinds of suggestions and bug reports in Gancio.

Most importantly, a huge thank you to NLnet (@nlnet) and NGI Zero (@NGIZero). Without their support, I wouldn’t have had the opportunity to develop this piece of software.

• Support more Event Plugins: Added support for the EventPrime and EventON event plugins.
• Event Self-Announce: Automatically announces events at a configurable time before they start as reminders.
• Blueprint Preview: Try out the plugin in the WordPress Playground.
• Event Sources: Fetch, cache, and display events from remote ActivityPub profiles.
• Custom ActivityPub Preview: Improved visibility of how events appear in the Fediverse.
• Admin Setting for Plain Text Summaries: Option to enforce plain-text event summaries.
• Updated Dependencies: Now requires ActivityPub plugin version 5.1.0 or higher.
• Bug Fixes & Admin UI Improvements: dozens of small fixes and refinements.

Despite this milestone, some interoperability issues remain. To point out a few:

• Mastodon: Currently, Mastodon does not handle updates for Event objects. Issue #31114
• Mobilizon’s customized ActivityPub dialect: Mobilizon was developed with the focus on federating with other Mobilizon instances. It is likely to reject everything it does not understand. Issue #1669.
• Content warning & event summaries: Mastodon uses the summary property of ActivityPub for object types it doesn’t support natively. At the same time repurposed the summary property of ActivityPub together with the additional flag sensitive for content warnings. Thanks to the developers of Sharkey for the interesting discussions on this.
• Instance following: Using FEP-2667 for to find an appropriate relay actor turned out not to be a good generic approach. While it works for Gancio or Mobilizon, a more complex system like WordPress has to fulfill more needs.
• A common basis for using the Event object in ActivityPub: Finish FEP-8a8e and bring it to life.
• Upstream ActivityPub plugin: The recent version 5.0.0 brought many improvements but also two critical bugs which limit what our plugin can do. Issue #1245 and #1269.

I hope that this release will be a significant step towards making events part of the Fediverse event ecosystem, and I’m excited to see how it develops! While I have new features and concrete improvements in mind, I’m most excited to hear feedback from users and see it in action.

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.