Or maybe game developers

@lapesanta i tant!

https://play.google.com/store/apps/details?id=cat.spla.tuts&pcampaignid=web_share

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.

@katzkowski ne, mach mal nicht. Gute Besserung!

cross-posted from: piefed.social/…/piefed-v1-9-is-released-shared-bl…

New features

• Shared blocklists - these are like feeds except instead of listing communities to join it lists people to block. To to Account -> Blocklists to find this feature. Changes by the blocklist author effect all the people who subscribe to the list, causing them to block the list members. They federate, so you can subscribe to blocklists on other instances.
• Edit comments inline, without loading a separate page - wjs018
• Fediverse statistics at piefed.social/statistics
• 2-factor authentication (TOTP) - can be added to your account in the ‘Security’ page in your settings.

For admins

• Auto-ban based on the bans that instances you choose, with keyword matching on the ban reason. Go to /admin/users/auto_ban. Try putting ‘piefed.social’ in as the instance and ‘spam’ as the keyword filter. It’ll cut down on the work involved in running your instance SO much.
• Voting pattern graph on user profiles to help spot automated voting.
• Reset the password of any user.
• Lots of inauthentic behaviour reports for finding bots and serial downvoters, see /admin/votes and PM me for an instructional video. It’s a lot to take in but the video will explain it all.

API

• edit matrix user id when saving user profile data.
• scheduled post endpoints - wjs018

Plus a lot more bits and pieces, browse the list of recent releases in the 1.8.x line at codeberg.org/rimu/pyfedi/releases for details.

To upgrade from 1.8.x or earlier

git pull
git checkout v1.9.x

Then,

./deploy.sh or ./deploy-docker2.sh

Donations

PieFed is free and open-source software while operating without any advertising, monetization, or reliance on venture capital. Your donations are vital in supporting the PieFed development effort, allowing us to expand and enhance PieFed with new features.

Donations can be made via Patreon, Liberapay or Ko-fi.

@pokemon Arctozolt.

Not quite, @neatnik, sorry! That's not the one. Want to try again?

To be fair a messageboard mixtape/CD swap was an undercover police job so…