Why do we need more Fediverse Enhancement Proposals?

Table of Contents

• When to write a FEP?
• Why a dedicated FEP for event-attendance?
  • Some existing implementations
    • Friendica
    • Mobilizon
  • Interoperability
• Conclusion

https://event-federation.eu/2026/11/14/fep-1cbd-event-attendance-and-attendee-collections/

As I published quite a few Fediverse Enhancement Proposals (FEPs) these days, and will publish an additional one soon, I felt like it would be a good idea to talk about why I am doing this the way I do.

When to write a FEP?

In the time of LLM generated text-output I saw a discussion about a flood of FEPs, and whether to forbid LLM-generated ones, and I agree, I would hope that all submitted FEPs are from people, that really spend a lot of time investigating and understanding what they want to solve and what they want to see working, and at best they are prototyping or contributing that same feature in an application.

Why a dedicated FEP for event-attendance?

My background with the Event Bridge For ActivityPub WordPress plugin was trying to bring WordPress event plugins in the Fediverse, at least in one-way: not as a consumer but as a sender. The next step now is for selected event plugins to implement event-attendance features (RSVP) that other Fediverse application like Friendica or Mobilizon already have implemented.

The first step, which began almost two years ago, was understanding how existing attendance-implementations work and differ. This was mostly achieved by inspecting code and APIs directly, rather than documentation. This was not a matter of preference. It was simply because the documentation was either sparse or unavailable.

Some existing implementations

Friendica

In Friendica events are realized via an invite flow:

{ "@context": "https://www.w3.org/ns/activitystreams", "summary": "Sally accepted an invitation to a party", "type": "Accept", "actor": { "type": "Person", "name": "Sally" }, "object": { "type": "Invite", "actor": "http://john.example.org", "object": { "type": "Event", "name": "Going-Away Party for Jim" } }}

Mobilizon

Mobilizon chose a different approach. I guess they had two reasons. The first was they are focusing rather on publishing information about events, and having attendance as a secondary feature, and they wanted their events to show up in other Fediverse platforms, especially in the popular Mastodon. Mastodon does not support an Invite activity, therefor Mobilizon uses a Create activity. The same Mastodon is using for any status which is an Note object in the background.

{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Create", "actor": { "type": "Group", "id": "https://mobilizon.example/organizers/1", "name": "Activists for a strong Democracy" }, "object": { "type": "Event", "id": "https://mobilizon.example/events/1", "name": "Demonstration for better social benefits", "startTime": "..." }}

And optionally people could mark as participating via

{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Join", "actor": { "type": "Person", "name": "Alice" }, "object": "https://mobilizon.example/events/1"}

So can you guess whether Mobilizon expects this Join to be agreed on before it is counted, for example by an Accept activity?

{ "@context": "https://www.w3.org/ns/activitystreams", "summary": "The organizer accepted Alice's request to participate in the event.", "type": "Accept", "actor": "https://mobilizon.example/organizers/1", "object": { "type": "Join", "actor": { "type": "Person", "name": "Alice" }, "object": "https://mobilizon.example/events/1" }}

Interoperability

So both Mobilizon and Friendica had something they wanted to implement and they did, and it works for their ecosystem. However, they made quite some assumptions that only work within their application. There are plenty of details I could point out here, but just to give one example: Mobilizon does not care about listing who is participating, they just care about a count, therefore all Join requests that are send by Mobilizon are private, these requests do not have a public visibility. However another application might go a different way, Mobilizon might show their event, offer the same Join buttons in their user interface, but it would not work as expected.

When writing FEP-1cbd, I tried to bear in mind existing implementations and how they work, as well as accounting for my own developments. For instance, I am currently developing federated attendance features for GatherPress, a free, modern, modular WordPress event plugin. The realm of ‘existing implementations’ even extends beyond events. I evaluated and reused successful implementation patterns wherever possible, such as Mastodon’s approach to obtaining consent for being quoted or listed in a featured collection.

I also tried to be aware of potential future extensions, which should not break things but extend seamless:

• attendance status, such as not attending or possibly attending.
• Advanced Waiting-List features
• Bringing guests within an attendance.
• Covering tentative accepts of an attendance coupled for example to apayment.

Conclusion

This was harder than it should have been. I have a wish for all Fediverse developers out there: if you are implementing new federation architecture on top of ActivityPub, take a look at existing implementations and study the FEPs. If you are designing something new, document it while you are drafting the first versions of your application code so that you can still take into account cross-application feedback from the broader Fediverse community on your design. If you publish the FEP after implementing a feature, it may be too late for feedback to easily find its way into your code, but this is still better than not documenting it at all.