Let’s take back control of our events! #JoinMobilizon

English below

Mobilizon (“Let’s mobilize!”) est le nouveau produit promu par Framasoft qui a auparavant lancé la campagne « Dégooglisons Internet » puis dans la foulée lancé le projet « Contributopia » et le développement de PeerTube. Comme PeerTube avait proposé la décentralisation de YouTube, et fort de ce succès, Framasoft lance un produit dont l’objectif est de remplacer et décentraliser Facebook Events.

Si Mobilizon est très attendu parmi les activistes, il reste que son approche pose un certain nombre de problèmes : le premier étant l’ignorance complète des solutions déjà existantes, le second une centralisation de fait des activités de développement par Framasoft qui, nous semble-t-il n’entre pas dans ses prérogatives ni ses intérêts à long terme.

Nous voudrions donc approfondir une réflexion sur ce qui pose problème avec l’approche de Framasoft et comment on pourrait tirer partie d’alternatives coopératives plutôt que concurrentielles, surtout dans un domaine (le partage d’informations événementielles) qui n’appelle vraiment pas à la redondance de fonctionnalité.

Un regard sur l’existant

La problématique se pose de savoir pourquoi préférer un nouveau développement plutôt qu’une amélioration des solutions existantes.

Les activistes technophiles utilisent depuis longtemps Dudle par Benjamin Kellermann de l’université technique de Dresden, une version libre (AGPL-3.0) de Doodle, un outil permettant à un groupe (anonyme) de se coordonner pour trouver la meilleure date pour une rencontre. La fonctionnalité de Dudle est simple et efficace, ne requiert aucun compte préalable ni aucune interopérabilité entre instances : tout se passe sur le Web à une URL spécifique et avec des cookies. C’est la simplicité de Dudle qui a fait son succès auprès de certain·e·s activistes.

Il existe différents logiciels qui peuvent permettre de s’organiser de créer des groupes et de publier des événements ; je pense à Loomio ou Discourse par exemple : ces logiciels ont une vue de l’organisation un peu plus large que l’événement seulement et appuient l’organisation collective et la structuration de l’information.

On peut se poser la question du besoin de dissocier l’annonce des événements de l’organisation même de la communauté, partage d’information, et prise de décision par exemple. En effet un logiciel qui se contenterait simplement d’annoncer les événements (tel EventBrite) ne contribue pas à renforcer la communauté mais dirige simplement les énergies vers une instance éphémère, c’est pour cela que Facebook Events lui est souvent préféré. Mobilizon semble favoriser un format qui serait un peu plus avancé que la simple annonce d’événements, cependant on voit mal comment il atteindra le niveau de sophistication d’un Discourse en terme de gestion des groupes, des sujets, capacité d’édition, etc… car Discourse est largement partagé et a plusieurs années d’expérience.

Cependant comme Framasoft a une belle assise par son travail intense et généreux qui a bénéficié à toute la communauté, beaucoup de monde attend Mobilizon, et nous pouvons imaginer que le logiciel sera largement adopté et sera un succès. Par conséquent la question se pose de savoir si une adoption large d’un logiciel d’événements ne serait pas une proposition un peu limitée qui nuirait à d’autres initiatives en cours proposant déjà des modèles d’organisation participatifs et avancés.

Mobilizon is a tool designed to create platforms for managing communities and events.

Il existe déjà :

Pourtant rien dans l’approche de Framasoft indique qu’ils ont un quelconque intérêt à utiliser les outils déjà en usage parmi les activistes hors-Facebook. C’est là pour moi la principale erreur faite par Framasoft : les deux fonctionnalités mises en avant, à savoir les « multiples identités » et « la gestion des groupes » du dernier stade de financement de la campagne sont totalement hors-sujet, non-seulement parce qu’ils sont orthogonaux avec la fonctionnalité événementielle, mais encore parce qu’ils entrent en concurrence avec les outils déjà utilisés par ailleurs par les communautés concernées, il semble important que la communication soit ouverte dès maintenant avec ces différentes communautés.

Décentraliser la décentralisation

Plusieurs initiatives s’attachent à penser comment s’organiser collectivement, Petites Singularités en fait partie : nous menons différentes initiatives auprès de plusieurs groupes afin de penser avec eux comment s’organiser en réseau, comment partager de l’information, comment fédérer des groupes, et surtout comment structurer l’information produite dans nos collectifs de résistance afin de la transformer en savoir. Il s’agit d’un travail de longue haleine dans lequel nous avançons pas à pas avec peu de moyens ; il ne s’agit pas pour nous de « sortir les gens de Facebook ou de Google » mais de proposer un modèle d’organisation différent. Nous ne nous positionnons pas par rapport à ces entreprises : nous sommes ailleurs, dans la création de collectif et la résistance.

Pour nous le discours réducteur de « sortir les gens de … » est problématique, car comme toute affirmation simple et directe, elle est facile à comprendre et fédératrice, cependant elle élude la pensée sur la technologie, et parfois reproduit des modèles existants qui ont été définis par d’autres à des fins qui ne sont pas les nôtres (voire visent à nous diviser), donnant lieu à des comparaisons qui n’ont pas lieu d’être, sur Foo je peux faire cela que je ne peux pas faire sur le nouveau logiciel.
Selon nous il s’agit de proposer des modèles techniques radicalement différents, décentralisés et partagés, or bien souvent nous nous heurtons à la popularité du discours « sortir de » et cela laisse peu de place à d’autres propositions. Mobilizon à cet égard est particulièrement problématique car il se situe bien sur le terrain de l’organisation et n’a pas été décidé en concertation.

Si Framasoft a tout notre soutien pour ses projets: il faudrait que Framasoft entre en contact avec ses alliés pour imaginer des avenirs en commun, plutôt que décider unilatéralement la carte à jouer et la jouer sans concertation. À l’opposé de cette approche, celle de IN COMMON cherche à intégrer dans sa réflexion l’ensemble des act·eur·ice·s impliqués dans le développement des outils pour servir les communs. Il nous paraît primordial de faire de Mobilizon un outil de gestion d’événements utilisable dans d’autres logiciels, sans imposer des notions telles les « identités multiples » qui est une idée trompeuse dans la mesure ou elles sont reliées au même e-mail ces identités sont très facilement réassociables, ce qui ne relèvent en rien de la problématique considérée : chacun est libre de maintenir plusieurs calendriers ou aspects de sa vie qui nécessitent une ségrégation volontaire, mais le faire au sein de ce logiciel crée plus de difficultés qu’il n’en résout ;il faut que Mobilizon s’assure qu’il intègre les fonctionnalités requises sous forme de plugins dans Communecter, Démosphère ou Discourse par exemple.

Mobilizon (“Let’s mobilize!”) is the new product promoted by Framasoft, which previously launched the “Internet Negotiations” campaign and then launched the “Contributopia” project (https://contributopia.org/) and the development of PeerTube. As PeerTube had proposed the decentralization of YouTube, and building on this success, Framasoft is launching a product whose objective is to replace and decentralize Facebook Events.

If Mobilizon is much awaited among activists, it remains that its approach poses a certain number of problems: the first being the complete ignorance of existing solutions, the second a de facto centralization of development activities by Framasoft which, it seems to us, does not fall within its prerogatives or its long-term interests.

We would therefore like to reflect further on what is problematic with Framasoft’s approach and how we could take advantage of cooperative rather than competitive alternatives, especially in an area (event information sharing) that really does not require redundancy of functionality.

Looking at what already exists

The question arises as to why to prefer a new development rather than an improvement of existing solutions.

Technophile activists have long used Dudle by Benjamin Kellermann of Dresden Technical University, a free version (AGPL-3.0) of Doodle, a tool that allows a (anonymous) group to coordinate to find the best date for a meeting. Dudle’s functionality is simple and efficient, requires no prior account and no interoperability between instances: everything happens on the Web at a specific URL and with cookies. It is Dudle’s simplicity that has made him successful with some activists.

There are different software programs that can be used to organize groups and publish events; I am thinking of Loomio or Discourse for example: these programs have a slightly broader organizational view than the event alone and support collective organization and information structuring.

One may question the necessity to separate the announcement of events from the community’s own organization, such as information sharing and decision-making. Indeed, software that would simply announce events (such as EventBrite) does not contribute to strengthening the community but simply directs energies to an ephemeral instance, which is why Facebook Events is sometimes preferred. Mobilizon seems to favor a format that would be a little more advanced than simply announcing events, but it is difficult to see how it will reach the level of sophistication of a Discourse in terms of group management, topics, editing ability, etc… because Discourse is widely shared and has several years of experience.

However, as Framasoft is well established through its intense and generous work that has benefited the entire community, many people are expecting Mobilizon, and we can imagine that the software will be widely adopted and will be a success. Therefore, the question arises as to whether a broad adoption of event software would not be a somewhat limited proposal that would undermine other ongoing initiatives already proposing participatory and advanced organizational models.

Mobilizon is a tool designed to create platforms for managing communities and events.

already existing:

Yet nothing in Framasoft’s approach indicates that they have any interest in using the tools already in use among off-Facebook activists. For me, this is the main mistake made by Framasoft: the two features highlighted, namely the “multiple identities” and “group management” of the last stage of financing of the campaign are totally off-topic, not only because they are orthogonal with the event functionality, but also because they compete with the tools already used elsewhere by the communities concerned, it seems important that communication be opened as of now with these different communities.

Decentralize decentralization

Several initiatives are focused on thinking about how to organize themselves collectively,petites singularités is one of them: we lead different initiatives with several groups in order to think with them about how to organize ourselves in a network, how to share information, how to federate groups, and especially how to structure the information produced in our resistance collectives in order to transform it into knowledge.

It is a long-term task in which we move forward step by step with few resources; it is not a matter of “getting people off Facebook or Google” but of proposing a different organizational model. We do not position ourselves in relation to these companies: we are elsewhere, in the creation of collectives and resistance.

For us, the reductive discourse of "getting people out of… "is problematic, because like any simple and direct statement, it is easy to understand and unifying, yet it avoids thinking about technology, and sometimes reproduces existing models that have been defined by others for purposes that are not ours (or even aim to divide us), giving rise to comparisons that are not relevant, on Foo I can do this, I cannot do it with the new software.
In our opinion, it is about proposing radically different, decentralized and shared technical models, but very often we come up against the popularity of the “out of” discourse and this leaves little room for other proposals. Mobilizon in this respect is particularly problematic because it comes from a very popular initiative in the field and has not been decided in consultation with existent projects.

If Framasoft has our full support for its projects, we also think that Framasoft should contact its allies to imagine common futures, rather than unilaterally decide on the card to play and play it without consultation. In contrast to this approach, that of IN COMMON seeks to integrate into its reflection all the actors involved in the development of tools to serve the common. It seems essential to us to make Mobilizon an event management tool that can be used in other software, without imposing notions such as “multiple identities” which is a misleading idea insofar as they are linked to the same e-mail, these identities are very easily re-associated, which is not at all part of the problem under consideration: everyone is free to maintain several schedules or aspects of their lives that require voluntary segregation, but doing so within this software creates more difficulties than it solves. Mobilizon must ensure that it integrates the required functionality as plugins into Communecter, Demosphere or Discourse for example.

Peertube & Mobilizon

Peertube came to the world without an existing alternative: the terrain was virgin, and the Fediverse embraced Peertube with pleasure and delight. Providing an alternative to Fakebooz Events or Meetup is another use case entirely though, since activists have been using various solutions outside of those for years, most notably Demosphere, Dudle, and Radar: here the terrain is already inhabited, and the Mobilizon team should take care of integrating existing solutions in their strategy rather than ignoring them and providing a solution that may harm these existing software and communities.

So far the discussion with Mobilizon designers did not convince us that there is a proper understanding of the existing solutions within the problem space that Mobilizon is tackling. As we appreciate and support Framasoft and Contributopia, we’re very careful that its upcoming success is to benefit the whole of the existing alternative community, and not only those who are still trapped in Fakebooz: flooding the event management space with people who have not the political background nor technical and ethical understanding of what we’re up against may interfere with how knowledgeable activists have been doing so far, and may damage our ways to share events. In this eventuality, we would have two separate populations: activists, and “transfuges”, and we must ensure that both communities will overlap and not separate.

Given the state of the reflexion so far, we’re not convinced this situation has been given proper attention. We’d like to ensure this debate happens while the process is still ongoing and before Mobilizon becomes to disparate from existing approaches.

I’ll just introduce myself, and throw in some specifics, that might be helpful for a start. @how invited me into the chat. I’m one of the current devs on https://radar.squat.net/

I’m at this stage not actually sure what Mobilizon are planning, even down to how and what would federate. I’m now in their matrix chat, and will be trying to keep conversation open as things develop.

I think technically it sounds like they’re looking at some activitypub with schema.org which is certainly the direction I was thinking in. What I’m not sure about is how much they want to make instances be able federate or interact with each other and at what level. The whole problem space of sharing events is something we at radar have come over again-and-again. So maybe it helps me writing something of our model and experiences so far, before returning to the activitypub end of things.

Radar itself is particular, it’s ended up like that as it covers a lot of real-world organisational realities. Our core entities are:

  • user (accounts) - which are only used to log in, and depending on how people operate are individual or shared
  • group - which have members (user accounts with roles) and events and can have a location (or multiple). Groups usually correlate to a group of people who are organising a space - this is the case where the group has a single location. It can also be groups organising events in different places, or groups that organise listing events (usually for a city eg. Plotter Köln, Stressfaktor Berlin, Backbord Luzern etc.) Each group can set their own permissions for who can post events, and if it needs moderation.
  • event - they are related to a group (or multiple groups) and location (or multiple locations). Events can repeat, and individual repeating events can be edited out of sequence.
  • location - an address, point on the map, or area. (And because it’s squat.net if it is or was a squat :wink:

[Even more technical aside: basically everything here, except for event repeat rules, maps very nicely into schema.org, including the relations]

Lots of groups, the type of groups with a location who run a space, import their events from their own sites using iCal. That or they export the events from radar and display them in their own site using the API (with plugins).

Radar integrates with other’s APIs too. Like Plotter is its own site and radar imports events from their API. This is where different data models become interesting. Plotter does also have the concept of an organising group and location. Sometimes it has these attached to events, more often they don’t have an organising group. So Radar needs to accommodate the idea of events only being in a ‘listings group’ (these being like Plotter).

We’ve tried, and would love to also work with federating events with other listings too - demosphere has always been one of these. The lack of machine readable metadata has been one of the largest stumbling blocks. iCal is pretty rubbish for forcing a format for the location for example. Let alone the format for Organizer that could theoretically, but never (yet) in practice map to groups. So till now it’s been best if the people running a calendar are interested in working with us like Plotter where we end up with a custom integration.

The related trouble has been, and it’s even more apparent with Indymedia, that there’s no authority or identity on events or organisers (groups). Most of the listings groups so far basically have a monopoly on posting/moderating for their city, whether they do it by pushing events into radar, or entering them themselves. So there’s no duplication. Indymedia, and possibly demosphere instances, however overlap events and there’s little way of working out duplication and authority.

This is one of the points activitypub became very attractive. Groups can have their endpoint as defined by their url/@account and events can be related to this. We can have a standard for pushing them around, but maintaining authority.

So that’s where I started coming to this from. I don’t know what else you’ve managed to get out of Mobilizon devs, but if you want anything more about how we could work together socially or technically as radar on this AMA!

1 Like

Welcome @ekes! It was nice to meet you at CCCamp19. I wish we had more time to discuss this, but Camp is not really the place for serious discussions. Thank you for unfolding your position with Radar, it’s a great writeup to understand where you came from. I discovered the Radar while I was living at The Fiber, a squat in Ruysdaelstraat 79, Am*dam.

Indeed that’s the point of thinking together about this: most of the time, “federation” is achieved on the client side with a calendar application subscribing to many iCal feeds. Now with the prospect of Mobilizon, a standard way to exchange data exportable to iCal, but hopefully more precise on some confusing specification such as the ones you mention with locations, is on the way and it would be useful for experimented developers to chime in and figure out a collectively satisfying solution to this.

One aspect I’m worried about is the frontend integration of Mobilizon: most of the time people create a monolithic block of code spanning from function to form ; with ActivityPub, we have an opportunity to approach applications in a more modular way, with an API-first approach, plugging in an arbitrary frontend. If this is right, then adding the AP layer to interchange data should be enough to bring all event management applications to par.

But some concepts introduced in the higher bids of the crowdfunding campaign appear problematic to me and might become a technical burden for others to join the game:

  • the concept of “multiple identites” seem to me a terrible mistake. First of all, it’s not really about “identities” but rather about different views, or aspects of one’s eventing activity. I see it as something that should be taken care of on the client side, where people can actually separate their “identities”: someone could use a Firefox profile for family events, and a special smartphone for activist events – why would an activist use the same devices for all their activities? The confusion of identities with what I would call workspaces seems to open a rats’ nest…
  • the concept of “groups” as presented so far in Mobilizon seem to defeat the idea of subscribers in the ActivityPub approach. Not that groups are not welcome, as you mention in Radar, they do match a real purpose. But I’m concerned that Mobilizon could create a coupled interface mixing events and groups and making it difficult for others to share events with unworkable metadata in them.

What I’d like to see is cooperation to ensure that a minimal “headless” version of Mobilizon can be used and implemented in sister projets without having to dive into questionable concepts coupled with the Mobilizon UI. Does it make sense?

I just thought of one more point about groups: the interface between technical model, and reality.

Radar moderates groups, not events. This maps nicely with the concept of following activitypub actors as being organising groups themselves. However, as explained above, not all the systems want to quite work like that, so you do need to build into the system the idea of listings groups (the secretary for a region) which is much like demosphere seems to work I think.

1 Like

@marcel would you like to expand on @ekes’ comment about the way Demosphere works?

OK so I’m just looking at the spec in detail in this direction now.

The actor that has a stream to me would seem to be the ‘Group’. The spec has a actors Group, Organization, People, but they’re all just actor Objects. So it’s object identifier url/@account is the group, and if it’s posting the events it’s the authority.

How the frontend decides to allow management of the actor is up to them. It could be managed by actor People, but it’s probably just easier that it’s just got login/s that can administer it.

Now I think Mobilizon wants to do more social? So I assume they’d also have People who can do stuff like sign-up to events etc. But that’s up to each implementation I’d think.

Identities I just don’t see fitting here - in the spec or in reality. Like platforms will want to curate what groups they have for specific audiences. There isn’t going to ever be one meetup or facebook and what differentiates the platforms. Groups don’t have to divulge people running them, so identities not needed there. So it’s only the social part, who subscribes to what, or signs up or whatever. But that would have to in effect be making a new actor for each, so it’s just that the platform allows you to administer more than one ‘account’ from an ‘account’?

Does that make sense?

Yes, this is exactly the use-case: having separate “identities” to avoid mixing your kinky party with your mother’s birthday. But that sounds like a convenience rather than a functionality: if you’re really serious about separating your night life from your family life, you’d use two separate accounts, right?

In addition, if it’s AP, we would expect federated accounts to be using the system. I guess some people remember when Google and Youtube accounts were merged, revealing embarrassing habits from people who treated the two as separate, but using a single email to access the two. Oops.


Do you think it would be useful to invite someone from Indymedia developers in this discussion? I’m not even sure there’s still a common pool of developers for it…

So separating the frontend / backend if the identities are separate activitypub actors (and not something non-standard that mobilizon is implementing) then it’s fine from the outside you are dealing with two separate things just as if they were created independently - it’s just their UX nightmare. If they are doing some masking non-standard thing, then they’ll just expose it in AP which would make the whole task pointless?


There’s no central group of Indymedia devs - dev has been organised around platforms. The only platforms left in active use that I know of are Drupal and SF-Active. The events on both are treated very much the same as articles, open posted - hence the authority issues. On a technical level I had been wondering about maybe trying to make the time to do something more general for Drupal implementation of AP - which would be useful if any of the Drupal sites wanted to federate (inward at least) events. For the rest it would be more discussing with the moderators of the remaining active indymedia’s what they’d actually want of a calendar (my anecdotal experience so far is they’re kinda happy the way it is).

I would not even consider putting one finger into this if they were exposing it to AP: I think it’s confusing for users to talk about “identities” and not have a simple way to understand that merging “identities” into one place is like putting all your eggs in the same basket. Hopefully we’re mistaken about their intent…

@ekes If you’re interesting in pursuing this, I’m pretty sure there’s some funding available for this in NGI0 Discovery where you can apply individually for 5 to 50K EURO (and up to 200K for a single project). Since Drupal is one of the most used software in the EU web sites, it should be really easy to get the funding, and it comes with very few overhead!

Yes. Plus thinking about it more. I can’t see the instances that are authority for your grandmother’s birthday are likely to be the same ones as your kinky party. Even federated with Mastodon you create accounts on different instances depending on the nature of the local community. I’d expect it to work a bit more like that.

So much UX confusion for not so much gain?

OK interesting. The Radar implementation is going to be a bit quirky, but with that it should be clear how to do a more general one. I’m thinking it’d be on the low end of their grants, so maybe that would make sense. I’ve already ping’d swentel - he’s in Gent - he’d looked at it already and has done masses of work on indyweb integration.

1 Like

I propose we let the soup cool down a bit and leave time for @marcel to chime in. Then we might want to write a friendly warning to Mobilizon to get the discussion started on their side. I don’t want to rush anything, but the debate needs to happen before it’s too late.

Next weekend there’s the ActivityPub Conference in Prague and it could be interesting to raise the question of cooperation among AP developers. I’ll be there and willing to address this and other community issues.

Hi everybody,

I develop Demosphere.

Demosphere does not have much “social networking” functionality. There are no groups, and each instance basically boils down to one large list of events. Instances cover a single region and each instance is managed by a team of moderators, independently of other instances. Currently, all instances are hosted on our servers, but that hasn’t always been the case.

Most of the code consists of productivity tools to help moderators find, publish and manage events. For example, there are tools for scraping a large number of sites (including Facebook & Twitter), finding events in mailing-lists, interacting with users that have published events, etc.

In our experience almost all events concern a single region/instance. There hasn’t been much demand for functionality to share events between instances (we do have a few basic tools though).

Since the discussion here seems to be oriented around “social networking” functionality, I’m not sure how I can contribute. I’ll be happy to answer any questions you have about Demosphere.

Cheers,

Marcel.

1 Like

It’s one of the request we get: why radar doesn’t have events from demosphere.

This is what I understood. Thus becomes the authority for a region - as my other listing group examples above. With the secretary type function of maintaining that list. It’s quite different model, but it should be accommodated by anything being designed, as it’s quite common for there to be a single person, or small group, maintaining lists for a city.

Neither does radar, and it really doesn’t want to either. Maintaining a followers collection that can include user identifiable accounts rather than just applications is already more private information than we want to store. It’s something to come to terms with and make clear to users. Having a standard for sharing events to other calendars, and to groups websites themselves would be great! We have it already to quite a degree, but it’s all custom, or bodged iCal.

The other demand comes from users who want to publicize their events - and being able to do that with social media platforms that aren’t twitter or facebook (read largely Mastodon in this case) integrated has excited a lot of users. It also passes that to the appropriate platform rather than having it on radar.

1 Like

Another one for your list of examples: the https://reseaumutu.info/ maintain calendars as well.

1 Like

Welcome @marcel!

Therefore it’s important that the event management functionality in Mobilizon be thought to accommodate specialized sites like yours.

@marcel I guess having ActivityPub federation would help your network to decentralize servers – which is only relevant if each local community has its own sysadmins. How is/are your server(s) set up now? Do you have a single farm holding all the events, or are you using instances for each locality?

Indeed, that’s probably the point we should be insisting on towards Mobilizon developers, so that we do not end up with an either-or situation that would harm existing projects and communities. I totally get that events are local/instance-based, therefore aggregating events from various sources would help making them visible to a larger audience, and that voluntary federation would also help to keep things relevant to each person and community.

Do you know anyone from there who would be interested in this discussion?

Sorry, I need to reed up on ActivityPub.

All instances are currently hosted on our servers. There used to be a few exceptions, but as the software grew and the system became more complex, it became too much work to host them separately. Moreover, most teams managing instances don’t have any sysadmin skills.

I contacted the people from Réseau Mutu so they can participate in this discussion.

Great to see you all here, I am super happy this is happening. Indeed from an exterior view it seems AP would be a way to bring projects together especially if people communicate before hand to make sure they can build bridges. AP is most probably used by Discourse soon, its probably quite a good point of exchange.
Should I invite Tcit (Mobilizon developer) here ?
@tibkat would be nice if you check the conversation, a lot of things have been said.

Hybrid & Fragile Aesthetics  |  ParticipateEngageCooperate