It is all about the community

When writing the initial version of our project plan as signed and agreed with by NlNet we didn’t know yet about the dynamics of the community, specifically about how the cooperation between the maintainers of the plugin and would be like. The level of collaboration with other developers would determine whether our project goals could only be achieved through a series of workarounds, or whether we could work together to strengthen interoperability and compatibility in the Fediverse.

Mobilizon was the first Fediverse application with true event federation. has very limited ActivityPub capabilities, partly by design, but is working on an enhanced federation, and other services like have a very different approach to events: their implementation focuses on sending invitations rather than publishing events. might get initial event support soon and it’s fork #Rebase already implemented it. As is usual with any software, you will find a lot of small bugs if you have not done any tests beforehand. In the case of Mobilizon, this was not possible since there were no alternative platforms to do the tests with in the past, especially if it comes to the instance-to-instance federation, so the only option was to test the Federation with other Mobilizon servers. We seem to be the first and we are fascinated and incredibly grateful for the willingness and prioritization that such issues have among the other developers (thanks to tcit and les). The issues may seem small, but they have a big impact: 304, 33, 321, 1509, 1507, 1392, 1385, 1388, 1387, 1378, 1376.

The other deciding factor for us was that we didn’t know how close the interaction with the upstream WordPress ActivityPub project would be. The exchange of ideas and the desire for a joint solution is strong. We would like to thank @pfefferle again for the regular exchange, his ideas and inspiration, without his commitment to the community our project would be less sustainable.

Tasks done (almost)

  • We published a repository that aims to make it easy for other developers, including ourselves to start developing and debugging WordPress along with Mobilizon.
  • We have created a pull request to add management of various ActivityPub transformers to the admin interface. The current implementation basically works, but we have a lot to polish and improve on our roadmap.
  • Using that patched ActivityPub plugin we explored writing transformers for two popular event plugins, this gave us a lot insight on what is important. These transformers already have fundamental compatibility with Moblizon.
  • Updating our About us page showing some information who we are.

Upcoming tasks

  • Implement FEP-2677: Identifying the Application Actor
  • Implement the followers list of the application actor in the admin UI along with the ability to reject, approve, and remove followers. We are very inspired by how has solved this in the admin UI. This of course includes a an option as:manuallyApprovesFollowers that can be set for an ActivityPub actor within WordPress.
  • Write an initial draft of the user documentation informing about custom ActivityPub transformers and instance-to-instance federation with Mobilizon. The target audience will be non-tech people. Parts of this will also be used as a non-tech description of our project.
  • Improve the admin UI and propose a solution to handle the settings for each transformer, if there are any.
  • Write more transformers for other popular event plugins to discover common pitfalls.

If you have any questions, ideas, or would like to help us, for example by testing our progress in case your are running a WordPress site with events yourself, please don’t hesitate to contact us. We don’t care if you have technical experience or what your background is: any kind of involvement is valuable to us.


All posts are licensed under CC-BY-SA 4.0

Comments

6 responses to “It is all about the community”

  1. @blog @pfefferle Really excited about this development. I wish you all the success possible in this endeavor… I will definitely try to do some user testing of this soon when I get a chance. Having serious fediverse event support across the whole internet is something I can see having a really solidifying impact.

    1. @liaizon @blog @pfefferle Thank you! But please, before you try to test anything, please contact us first, at least at the moment. There is no rush and we have a dedicated workshop and user testing phase in our project, but it will take at least two more months to get there!

  2. @blog @pfefferle What do you mean by 'the only Fediverse application with true event federation'? Rebased (a fork of Pleroma) has support for creating and interacting with Mobilizon-compatible events for over a year.

    Smithereen also has events support, though it's incompatible with both Mobilizon and Friendica (they're an extension over its groups feature).

  3. @pfefferle @blog I’m really grateful for your work, and looking forward to seeing events being more commonly shared on the Fediverse. In a previous life I built an indie music gigs WP site and often dreamed of such a thing.

    I’d like to see some technical posts about the current implementations out there, how they differ, and what needs to be done to enable cooperation. As a Friendica user I’ve played with the current events implementation and agree it… does what it does, but not anything else. But I also don’t quite understand what the spec intended here. There’s all kinds of semantics you could support, it’d be great to hear about your decisions.

  4. “and other services like #Friendica have a very different approach to events: their implementation focuses on sending invitations rather than publishing events”

    As described in the ActivityStreams vocabulary specification.

    These servers can easily send Create/Event and I believe Friendica does, but it is a redundant activity because RSVP to a Create activity is ambiguous. You can RSVP to an Invite activity and the meaning is clear.  So for example streams just sends the Invite/Event. Saves a lot of unnecessary network traffic and accomplishes the same thing and is in compliance with the specification. For compatibility we also support RSVP (for instance) as Accept/Event because I believe Friendica uses this construct, but the spec compliance of doing so is somewhat undefined. You could be accepting the Create of the event or somebody’s Like of the event, but not have made any attendance decision at all. For that you really need to Accept the Invite activity and not the Event itself.

    This is one of those cases where ActivityStreams and ActivityPub both dropped the ball and allowed for wildly different interpretations. All are valid and ideally your software will eventually be compatible with all of them and not just one flavour.

    1. @mikedev @blog Thanks for your thoughts! The WordPress ActivityPub implementation is currently focused on getting the publishing side of ActivityPub right. After that, we will consider such cases. The friends plugin is of interest in this regard, but also creating events within WordPress that are invite only might use a different approach than sending a `Create` Activity. When the time comes, I might ask you again to chat about this! Regards, André

      https://de.wordpress.org/plugins/friends/

Leave a Reply

Your email address will not be published. Required fields are marked *