blog, 2 months ago to fediverse

First project phase recap

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:

1. Research and decision whether to start of with a “child” or standalone plugin. Proposing solutions how to manage ActivityPub actors and ActivityPub transformation of custom post types. Proposing needed extensions of the upstream ActivityPub plugin.

---

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.

2. Plugin skeleton for the ActivityPub event extensions and extending/creating the needed ActivityPub classes and ActivityStream representations for the events.

---

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

blog, 3 months ago to fediverse

Fediversity at O₄FFDEM

Last weekend FOSDEM took place in Brussels, Belgium. However it was O₄FFDEM that provided the space for about 20 people to meet and discuss the future of events in the Fediverse for the whole Saturday. Among them developers like @lesion (developer of Gancio), setop (upcoming coordinator of Mobilizon), @dreirik (foss.events), @laurin (contributor to ActivityPods) and community members, (h)activists and event organizers like @becha or @eest9, just to name a few, and myself. Eventually, there were people from half of Europe: Montpellier, Strasbourg, Graz, Amsterdam, Italy, Vienna, Ljubljana, and Rotterdam.

Expectations

It was impressive how, despite the number of people present, it was possible for the group to de facto moderate itself, in particular through the experienced careful intervention of a few at the right moments. We began with a short round of introductions, in which expectations for the day were also clarified. We first decided to talk about values, to clarify what needs and concerns are generally present. We were all united by the desire to become independent of Big Tech, although there were several completely different concepts of how this would be achieved from a single point of view in the mix.

Dilemmas

It has become evident that in the case of events, from of a software developer’s point of view, one cannot simply speak of users, but must distinguish between organizers and participants, although the distinction can also be blurred in the case of a small community. Following dilemmas were identified:

• regional vs global calendars
• topical vs mixed calendars
• aggregation vs autonomy
• moderation vs censorship

Advantages of a physical meeting

The discussion about these aspects was extensive and, admittedly, did not always seem to me to be very target-oriented. However, it was necessary to balance our different backgrounds and bring us up to the same level of knowledge and it became more concrete after the lunch break when we decided to compare and work out the intentions and use cases of the existing applications and developments in more detail. I could recap this in detail here, but I think it is best to write a stand-alone follow-up article. Each project has its own approach: some focus on local communities, some focus on private events an another wants to provide a way to organize larger political movements with as few social features as possible. On top of that, people have come up with use cases that no developer ever seemed to think of before.

One activist’s question, “What’s the difference between federation and interoperability?“, which had been floating around the room all day, was finally addressed in a satisfying way with examples. Even if all applications can successfully aggregate and display events of others, it does not mean that they respect all mechanisms that control how the event is listed, whether the event is joinable via ActivityPub, whether these joins have to be manually approved, whether some event details visibility have a certain scope, etc.

Calendiverse

Perhaps one of the most important points was to enable the creation of event calendars, which are also aimed at people who do not want to have an account anywhere, but are simply looking for events. From the point of view of people looking for events, regional or topic-specific calendars are particularly important. Which events are aggregated and shown on an individual platform would be in the hands of the platform operators, which would then automatically play a major role in moderation.

Why use ActivityPub?

ActivityPub covers most of the features iCal offers for creating calendars by aggregating multiple sources, but adds a few more:

• Follow relationships become tangible
• Social media like features:
  • Boosting
  • Liking
  • Replies
• Push, not pull based
• Joining (Participants management)
• Use moderation and governance tools from the Fediverse

Getting to a Common Ground

Mobilizon has already introduced a huge set of custom properties and ways to manage event objects in the ActivityPub world. We decided on a process to re-evaluate their choices and draft a Fediverse Extension Proposal (FEP) for the least common set of them. What makes an event:

• What: title, summary, content, etc.
• When: start-time, end-time, timezone (for displaying), recursion
• Where:
  • on/offline/hybrid
  • URL/location
  • Private locations which may be disclosed on participant’s acceptance
• From Whom
• To Whom: Public, Private, Unlisted
  • Why if not want to get listed just not “send” the event: e.g., Mobilizon -> federated groups -> federated private events
  • Let the sender of an event set the discoverability : the recipient might mistreat that

We decided to deal with advanced mechanisms such as sub-events, recurring events, irregularly rescheduled events in the future.

Summary

All in all, it was simply nice to get to know each other and exchange ideas with other people who pursue common or similar goals. Especially the exchange between developers and non-developers, who were in the majority, was of great importance from my point of view. Unfortunately, it is almost impossible to capture all the aspects in such a short recap. If you are missing something important, please have a comment. Many thanks to all of you, especially the organizers and those who were taking the meeting minutes.

#ActivityPub #Calendiverse #Fedivent #Fediversity #Gancio #Gathio #Mobilizon #OFFDEM #WordPress

blog, 3 months ago to fediverse

O₄FFDEM

This weekend @linos is going to attend OFFDEM (FOSDEM) in Brussels. There will be a Fediverse Event-Gathering on Saturday:

Fediverse Event-Gathering

We are some hackers that currently work on different solutions serving the same goals: free users from having to use Meetup or GAFAM sh*t to aggregate and organize their events. We want to gather and work together and agree on common standards to benefit from interoperability and each other. Current solutions we are working on include but are not limited to:

• Mobilizon
• Gancio
• https://event-federation.eu
• gath.io
• // foss.events

Our preliminary agenda looks like

• welcome each other / warm up
• quick presentations of each project to help understand common features and differences
• discuss and agree on a common standard for event data in the Fediverse
• use the rest of the day to hack-a-thon, chat, learn, cooperate

We expect a number of 5-10 people joining from the mentioned projects. Other people are welcome to join if they are interested in the topic and/or like to contribute to one of these projects.

Checkout the full OFFDEM program on the here.

Really looking forward to it! 🙂

#Fediverse #FOSDEM #OFFDEM

blog, 3 months ago to random

Visibility & discoverability

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.

blog, 4 months ago to wordpress

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 #WordPress #ActivityPub plugin and #Mobilizon would be like. The level of collaboration with other #Fediverse 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, until our project, the only Fediverse application with true event federation. #Gancio limits its ActivityPub capabilities to sending notes, but is working on a true federation of events, and other services like #Friendica have a very different approach to events: their implementation focuses on sending invitations rather than publishing events. 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, 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 AktivityPub 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 #PeerTube 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 yourself if your operate a WordPress site with events, 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.

https://event-federation.eu/2023/12/20/it-is-all-about-the-community/

#ActivityPub #Fediverse #Friendica #Gancio #Mobilizon #PeerTube #WordPress

blog, 5 months ago to random

Sneak preview

For the first time, we were able to see the goals of our project with our own eyes. But we still have a long way to go. We’ll tell you more about where we are and what our next tasks are in the coming days.

Screenshot of a WordPress event, shown on the WordPress page.Screenshot of an Event created in WordPress but seen in Mobilizon.

image/png

blog, 6 months ago to wordpress

What has been done so far

As we have announced from the very beginning, it is important to us to make our work as sustainable as possible. In this context, sustainability means being modular and trying to enable necessary extension functionality in the upstream project, the WordPress ActivityPub plugin. Regarding the functionality that our project should ideally offer, we have created two posts in the discussion section of the repository on Github to provide a place where these feature additions can be discussed by the community while we work on a draft for a pull request.

• Flexible management of how posts gets transformed to ActivityPub objects
• Management of ActivityPub actors

During the planning stage of our proposals, we had fantastic meetings with other ActivityPub developers, whom we would like to sincerely thank.

• The lead developer of the ActivityPub plugin @pfefferle provided a fascinating insight into previous and ongoing challenges, as well as future strategies, eagerly embracing our concepts with receptiveness.
• The lead developer of Mobilizon @tcit informed us about the most important hurdles in the development of Mobilizon and helped us to assess what challenges in interoperability we were likely to face.
• With @grindhold, the developer of flohmarkt, a federated marketplace with ActivityPub support, we discussed common issues such as working with non-note object types, implementing instance/application actors, and took a look at some Fediverse Enhancement Proposals (#FEP) that are of interest to both our projects.

A later task in our project plan is testing with real users to identify typical pitfalls in setup, use and documentation. Although this user study will not take place in the near future, we have recognised the need to start thinking about it now and have already had discussions about planning this task.

Current tasks

Currently we are designing and prototyping the architecture of the hook system, how plugins can register their own ActivityPub transformers to the main plugin.

Upcoming tasks

Next, we will write a small WordPress plugin containing hardcoded transformer classes for the three most installed WordPress event plugins, as well as extending and improving the admin interface for managing transformers.

https://event-federation.eu/2023/11/12/getting-started/

#ActivitiyPub #FEP #WordPress