L’éducation populaire au numérique, Peertube, Mobilizon, un service « tout-en-un »… Pour l’année 2020, nous avons encore de nombreuses envies… nous espérons que vous nous donnerez les moyens de les réaliser en rejoignant les donateurs et donatrices, et en tout cas nous sommes heureuses et heureux de vous faire part du petit programme que voici.

À Framasoft, nous ne gardons pas les deux pieds dans le même sabot. Si, parfois, nous prenons des chemins détournés (la route principale est tellement longue…) c’est parce que nous avons beaucoup de cartons avec plein de projets dedans. Lesquels choisir ? C’est ce genre de question qui nous occupe au moins autant que d’élaborer des stratégies pour les réaliser.

De l’éducation populaire aux enjeux du numérique

Le quotidien de Framasoft, ce sont de nombreuses interventions, ateliers, conférences, tables-rondes… c’est aller régulièrement à la rencontre de publics variés. Il s’agit pour nous de partager nos observations sur l’hégémonie des géants du Web et le monde que nous préparent les entreprises du Capitalisme de Surveillance. Nous proposons aussi des pistes d’émancipation numérique pour aller vers une société de contribution plutôt que de consommation.

Nous travaillons aussi, avec d’autres structures et collectifs, à faciliter l’adoption de pratiques numériques plus « saines ». Recenser les acteurs et actrices de la médiation au numérique libre, travailler sur des outils pratiques avec des fédérations d’éducation populaire ou des coopératives de formation, cela fait partie des actions que nous voulons poursuivre en 2020. Car l’association Framasoft, avec ses 35 membres, ne peut pas être partout, et n’a aucune envie d’être omniprésente ! C’est pour cela que nous essayons de partager notre expérience avec les personnes qui, quotidiennement, animent des actions d’éducation populaire, et sont au plus près des gens qui cherchent à reprendre le pouvoir sur leur vie numérique.

Un autre gros chantier qui nous attend en 2020, c’est de préparer la fermeture de certains services que nous hébergeons. Rappelons qu’il vous sera alors proposé d’accéder aux mêmes services, hébergés par des organisations qui partagent les mêmes valeurs. On le sait, c’est inconfortable d’entendre qu’il y aura un changement, même lointain, dans un paysage numérique où il est difficile de faire confiance et de changer ses habitudes. Nous voulons donc travailler à ce que les pages web qui vous redirigerons vers « la même chose, mais ailleurs » soient claires, et qu’elles vous mettent en confiance.

Pour cela, nous souhaitons aussi continuer de nous investir dans le collectif d’hébergeurs alternatifs CHATONS. Nous avons envie de vous donner de bonnes raisons de faire confiance aux membres de ce collectif. Nous souhaitons que vous sachiez pourquoi vous pouvez leur confier vos données. Nous pourrons aussi contribuer à clarifier ce qu’offrent les hébergeurs de ce collectif, afin de vous permettre de trouver le service ou la structure qui corresponde le mieux à vos besoins.

Offrir à Mobilizon la v1 qu’il mérite

La mobilisation des efforts collectifs et des ressources, c’est tout le miel de la vie associative et de multiples formes d’interactions sociales. C’est la raison de Mobilizon. Notre vision pour ce projet est claire : offrir une alternative agréable aux événements, aux groupes voire aux pages Facebook. Nous aimerions réaliser un outil émancipateur pour les associations, les militant·es, les citoyen·nes… et toutes ces personnes qui dépendent encore de Facebook pour s’organiser ensemble.

#gallery-1 { margin: auto; } #gallery-1 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 50%; } #gallery-1 img { border: 2px solid #cfcfcf; } #gallery-1 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

Actuellement en version bêta, nous comptons développer :

• l’aspect « fédération » de ce logiciel d’ici fin décembre ;
• les fonctionnalités de pages et de groupes (avec messagerie, modération, outils d’organisation) au premier trimestre 2020 ;
• les correctifs, les éventuels retards et les finitions qui stabilisent et documentent le logiciel, pour sa sortie prévue avant l’été 2020.

Afin que vous puissiez suivre ces développements en toute transparence, les mises à jour seront régulièrement visibles sur le site de démonstration test.mobilizon.org

Cette publication de la première version stable et publiquement utilisable de Mobilizon est un rendez-vous que nous ne voulons pas manquer. Nous souhaitons l’accompagner d’un outil qui facilite la compréhension de ce qu’est Mobilizon, comment ça marche, à quoi ça sert et à quoi ça ne sert pas. Pour y arriver, nous voulons prendre le temps de refondre complètement le site joinmobilizon.org, probablement sur le modèle du tout nouveau site web joinpeertube.org.

Financer les ambitions de PeerTube

Lors de la sortie de la version 2 de PeerTube, nous faisions le bilan de cette alternative libre et fédérée aux plateformes de vidéos telles que YouTube. Si nous venons de lui consacrer un an de développement sur nos fonds propres, c’est parce que nous croyons au potentiel émancipateur de cette solution. En 2020, nous souhaitons trouver les moyens d’accroître la popularité de PeerTube. Pour cela, nous aurons besoin de matériel (vidéos, illustrations, métaphores…) qui promeuvent les avantages d’un outil fédéré, ainsi que les fonctionnalités de PeerTube.

Et si on faisait plus de vidéos pédagogiques comme celle réalisée par LILA…?

Nous envisageons aussi, pour 2020, d’animer une nouvelle collecte qui nous permettra de financer la version 3 de PeerTube. La liste des fonctionnalités que cette collecte financera n’est pas encore fixée, mais nous avons noté, grâce à vos retours (que vous pouvez proposer ici, sur notre forum), quelques idées…

Tout d’abord nous pensons que PeerTube gagnerait beaucoup si on retravaillait son expérience d’utilisation et son interface. Nous constatons certains manques et points d’améliorations, mais nous pensons que le mieux serait de faire appel à des professionnels du design pour dresser un bilan et proposer des solutions.

Ensuite, le nouveau lecteur vidéo (le « HLS », celui qui est encore expérimental) offre de telles performances qu’il permet d’envisager le développement d’outils inimaginables pour PeerTube jusqu’alors. Par exemple, PeerTube pourrait offrir un outil de « Vidéo-Mix » (ou de « coupé-monté », pour les cinéphiles), où l’on crée une séquence en prenant 30 secondes de telle vidéo, 12 de telle autre puis une minute d’une troisième…

Enfin, la fonctionnalité qui nous fait rêver (et qu’on nous demande régulièrement), c’est la diffusion en direct. Avec du live-streaming, PeerTube ne marcherait pas seulement sur les platebandes du YouTube de Google, mais aussi sur celles du Twitch d’Amazon… Cette diffusion en direct devrait se faire de pair à pair, et ça, c’est un sacré défi technique !

Projet « cloud Framasoft » : un seul compte pour remplir la plupart des besoins

Depuis quelques années, le logiciel Nextcloud s’est grandement enrichi. Au départ, c’était une simple alternative aux Dropbox et autres GoogleDrive, pour sauvegarder et synchroniser des fichiers. Depuis, Nextcloud s’est augmenté de nombreuses applications pour faciliter la collaboration.

On peut y synchroniser ses contacts et ses agendas, travailler collaborativement sur des fichiers textes ou des tableurs (avec CollaboraOnline ou OnlyOffice), activer des visio-conférences ou des discussions par tchat, créer des formulaires basiques, y sauvegarder ses notes, ses images et ses listes, partager des albums photos, dessiner des cartes heuristiques (mindmaps), consulter ses flux RSS ou ses emails…

Le projet « cloud Framasoft » reposerait sur cette solution : une seule adresse, un seul compte à créer, et tous ces services sont à votre disposition. Afin de limiter les effets de centralisation vers nos services, nous envisageons de n’offrir que très très peu d’espace (quelques dizaines de mégas), juste assez pour une association qui veut collaborer sur quelques fichiers. Notre objectif est de vous faire découvrir cette solution, sans propager l’illusion que les ressources illimitées et gratuites, ça existe (ou que ce serait sain).

Pour les personnes qui, à un moment, se sentiraient à l’étroit, nous aimerions vraiment pouvoir développer un outil facilitant la migration de son compte vers un autre hébergement Nextcloud. Dans nos têtes, nous rêvons d’un « Votre compte cloud Framasoft vous plaît mais il est trop limité ? OK ! cliquez sur ce bouton pour déménager vers tel ou tel hébergeur alternatif ». Si nous pouvions nous rapprocher de cette simplicité…

Nous voulons, pour l’automne 2020, trouver les moyens d’accueillir toute personne, toute association qui voudrait avoir accès à une telle solution, quitte à se satisfaire d’un espace de stockage spartiate. Nous avons conscience que cela peut signifier accueillir des personnes par dizaines de milliers. Autant vous dire que cela représente un coût technique et humain, et donc financier, très important. Mais si vous nous en donnez les moyens, nous croyons que cela peut représenter une formidable porte d’entrée vers le Libre pour toute une population qui prend de plus en plus conscience des dangers que représentent les GAFAM.

La route est longue, alors libérons la voie

Si nous annoncions vouloir « Déframasoftiser Internet » et tourner certaines pages du passé, c’était justement pour faire de la place à des projets futurs. Cette année 2020 sera pour nous une année où nous voudrions poursuivre nos actions les plus émancipatrices (éducation populaire, Mobilizon…), tout en ouvrant de nouvelles portes vers le libre et l’autogestion (PeerTube v3, « cloud Framasoft »…). Nous en avons la volonté, il nous faut savoir si vous nous en donnerez les moyens.

Si nous avons une telle liberté et une telle indépendance dans nos actions, c’est parce que certaines et certains d’entre vous nous font un don (et qui mieux est, un don régulier), et que l’ensemble de ces dons financent notre budget annuel. L’association Framasoft étant reconnue d’intérêt général, rappelons que pour les contribuables Français·es, un don de 100 € à Framasoft revient, après déduction fiscale, à 34 €… et ce même avec le prélèvement à la source. 😉

Cette année encore, nous ne voulons pas utiliser les mécanismes de la culpabilité ou de l’économie de l’attention pour vous « manipuler » vers un don. Nous pensons qu’il suffit de vous dire, concrètement : voilà ce que nous avons fait, voilà ce que nous voulons faire. C’est à vous de déterminer si cela vous inspire, et si c’est l’occasion de contribuer à nos actions par un don (pour qui le peut) ou en partageant notre appel aux dons (pour tout le monde !).

Nous vous faisons confiance.

Mobilizon is an alternative to Facebook groups and events. After a successful crowdfunding, it is time we gave you a taste of this software and updated you on its progress.

La version originale (en Français) de cet article est à lire ici.

An eagerly awaited alternative to Facebook events

During the Spring of 2019, we launched our Mobilizon crowfunding, to fund a free/libre software allowing communities to liberate themselves from Facebook events, groups and pages.

This crowdfunding’s aim was to produce Mobilizon and to know how far you all wanted us to go with this project. Over one thousand people funded this project, and we are very pleased to see how enthusiastic you all were: evidently, many of us are tired of Facebook’s walled garden around our events!

Today, we are keeping a promise we made during the campaign: sharing Mobilizon’s progress with you. We decided to showcase it to you as soon as possible, even though most features are not developed yet. This is precisely what a beta is: some things are still rough around the edges, the paint is fresh, not everything is in place (yet)… but you can still get a clear picture of what we have achieved and how much work still remains to be done.

A beta release to lay the foundations

Mobilizon‘s aim is to create a free/libre software allowing communities to create their own spaces to publish event.

Here is everything you can do with Mobilizon:

• Sign up with your email and a password, then log in;
• Receive email notifications;
• Create and manage several identities from the same account;
  • to compartimentalize your events;
  • Every identity consists of an ID, a public name (name, nickname, username, etc.) an avatar and a bio
• Create, edit or delete events;
  • From the identity you used to create said event;
  • You can create, keep, edit (and delete) draft events;
  • You can manually aprove (or refuse) attendance requests.
  • You can easily share by mail or on your social medias;
  • You can add events to your calendar.
• Register for an event by choosing one of your identities;
• Report problematic content to the instance^[2] moderation;
• Manage reports of problematic content

We are very enthusiastic about the ability to use different identities. Under the same account, you can compartimentalize several aspects of your social life: one identity for sports, one for family gatherings, another one for activism, etc.

This is the sort of tool Facebook & Co will never offer, as they have a vested interest in gathering every aspects of our social lives under a single, and therefore advertiser-friendly, profile… Thus, it always brings us great joy to realize that when we distance oursleves from these platforms model, we can imagine user-friendly, emancipatory tools.

Better yet, you can have a look by yourself…

test.mobilizon.org: discover the software and its features

Wait up before you organize a Last Party Before Armageddon on test.mobilizon.org: it is only a demo site! Feel free to use it however you want, to click at will: there will be no consequences as every account, event etc. will be automatically deleted every 48 hours.

One of our promises while we were mapping out Mobilizon’s development was to create a tool by and for people, so we worked with UI/UX designers… we hope you like the result!

We have made room on our forum for your feedback. However, we will probably not be able to answer to requests pertaning to new features, as we already have much to do!

The way is already mapped out: we are Mobilized!

In the next few months, we will publish regular updates of this beta release, and show you its progress. This way, we will have time to observe and hear your feedback, up until the first fully functional release of Mobilizon, which is planned for the first semester of 2020.

Depending on your level of expertise, you may look under the hood and read Mobilizon’s source code. Nevertheless, we do not recommend installing Mobilizon on your server before we take care of its federated^[1] features.

As Mobilizon is not (yet) federated^[1], it is not (yet) possible, for example, to register to a Framaparty posted on Framasoft’s Mobilizon instance^[2] from an account created on a UnitedUni instance, hosted by your college. Both the federeated aspect and the ability to register to an event anonymously are being developed right now. We will introduce you to them when we keep you updated on the software again, around December.

During 1st semester of 2020, we will publish the first stable release of Mobilizon. We will implement moderation tools as well as collaborative ones (groups, organizational spaces, private messages). We will be in touch with pioneer installers and users (the latest have probably used their pals’ servers). We will be working on technical documentation too.

We keep our promises, starting now

We at Framasoft cannot wait to see as many people as possible free themselves for Facebook events, and use Mobilizon to organize, say, an advocacy group or a Climate March.

However, we might have to wait a bit before closing down all these Facebook groups that structure part of our lives. Meanwhile, we hope this demo will show the potential of a software meant to gather, organize and mobilize… people who are trying to make the world a better place.

Notes

Mobilizon sera une alternative aux événements et groupes Facebook. Suite au succès de son financement participatif, il est temps de vous donner un avant-goût de ce logiciel et de faire le point sur l’avancement du projet.

An english version of this post is available here.

Une alternative très attendue aux événements Facebook

Au printemps 2019, nous avons lancé une collecte autour du projet Mobilizon, un logiciel libre qui permettra à des communautés de s’émanciper des événements, groupes et pages Facebook.

L’objectif de la collecte était de nous donner les moyens de produire Mobilizon et de savoir jusqu’où vous vouliez que nous nous engagions sur ce projet. Plus de mille personnes ont financé ce projet, avec un enthousiasme qui fait plaisir à voir : visiblement, nous sommes nombreuses et nombreux à en avoir marre que Facebook soit l’outil qui enferme les événements rythmant nos vies !

Aujourd’hui, nous tenons une promesse faite lors de la collecte : partager avec vous l’avancement de Mobilizon. Nous avons décidé de vous le montrer le plus tôt possible, même si toutes les fonctionnalités promises ne sont pas encore développées. C’est le principe d’une version bêta : c’est encore brut, la peinture est fraîche, tout n’est pas (encore) présent… mais cela permet d’avoir une bonne idée de ce qui est réalisé et du travail qu’il reste à faire.

Une première version bêta qui pose les fondations

Le projet derrière Mobilizon, c’est d’avoir un logiciel libre qui permettra à des communautés d’héberger des espaces de publication pour y annoncer des évènements.

Voici tout ce que vous pouvez d’ores et déjà faire avec Mobilizon :

• Créer un compte, grâce à un email et un mot de passe, et vous y connecter ;
• Recevoir des notifications par email ;
• Créer et gérer plusieurs identités sur un même compte ;
  • pour cloisonner vos événements ;
  • Chaque identité comprend un identifiant, un nom à afficher (nom, surnom, pseudonyme, etc.), un avatar et une description ;
• Créer, modifier ou supprimer des événements ;
  • À partir de l’identité qui vous a servi à créer l’événement ;
  • Avec la possibilité de créer, conserver, modifier (et supprimer) des événements en mode brouillon ;
  • Avec la possibilité de valider (ou refuser) manuellement les demandes de participation ;
  • Que vous pouvez partager facilement sur vos réseaux ou par email ;
  • Que vous pouvez ajouter à votre agenda.
• S’inscrire à un événement en choisissant une de vos identités ;
• Signaler des contenus problématiques à la modération de l’instance^[2] ;
• Gérer les signalements de contenus problématiques.

Le principe d’avoir plusieurs identités est une idée qui nous enthousiasme beaucoup. Avec un seul et même compte, vous pouvez séparer divers aspects de votre vie sociale : utiliser une identité pour vos entraînements sportifs, une autre pour vos retrouvailles familiales, encore une autre pour vos actions militantes, etc.

C’est le genre d’outil que ne proposeront jamais des géants tels que Facebook, qui ont bien trop intérêt à ce que tous les aspects de votre vie sociale se fondent en un seul et unique profil publicitaire… Or, c’est toujours une joie de se rendre compte qu’en s’éloignant du modèle de ces plateformes, on arrive à imaginer des outils conviviaux et émancipateurs.

Mais le mieux, c’est encore que vous alliez voir par vous-même…

test.mobilizon.org, un site web pour découvrir le logiciel et ses fonctionnalités

Ne courez pas tout de suite y organiser la dernière fête avant la fin du monde, car test.mobilizon.org n’est qu’un site de démonstration ! Il vous permet d’y faire ce que vous voulez, de cliquer partout et n’importe où, en toute inconséquence vu que les comptes, événements, etc. y seront automatiquement effacés toutes les 48 heures.

Mobilizon a été créé avec des designers pour concevoir l’expérience d’utilisation et l’interface graphique. C’est une des promesses que nous avions faite en dressant la feuille de route Contributopia : faire des outils pour et avec les gens, en incluant des professionel·les du design dans notre travail… Nous espérons que le résultat vous plaira !

Nous avons ouvert un espace de notre forum pour que vous puissiez exprimer vos retours sur le travail effectué. En revanche, nous ne pourrons probablement pas répondre aux demandes de fonctionnalités supplémentaires, car notre planning est déjà bien chargé !

Le chemin est tracé, et nous sommes Mobilizé·es !

Au cours des prochains mois, nous allons proposer des mises à jour régulières de cette version bêta et vous en présenter les avancées. Cela nous permettra d’avoir le temps d’observer et de recueillir vos réactions jusqu’à la première version pleinement fonctionnelle de Mobilizon, prévue pour le premier semestre 2020.

Les plus expert·es d’entre vous peuvent aller voir sous le capot et consulter ici le code source de Mobilizon. Cependant tant que nous n’avons pas finalisé l’aspect fédéré^[1] de Mobilizon nous ne vous recommandons pas de l’installer sur votre serveur.

Parce que Mobilizon n’est pas (encore) fédéré^[1], il n’est pas (encore) possible, par exemple, de s’inscrire à la Frama-fête publiée sur l’instance^[2] Mobilizon de Framasoft, depuis un compte créé sur l’instance MobilizTaFac hébergée par votre université. La fédération, tout comme la possibilité de s’inscrire à un événement de manière anonyme, sont des fonctionnalités en cours de développement. Nous vous les présenterons lors d’un nouveau point sur le logiciel, courant décembre.

C’est au cours du 1er semestre 2020 que nous publierons la première version stable de Mobilizon. Nous y implémenterons des outils collaboratifs (les groupes, leur espace d’organisation, la messagerie) et des outils de modération. Nous échangerons alors avec les pionnier·es qui l’auront installée sur leurs serveurs (ou utilisée sur les serveurs des copains et copines), et nous travaillerons sur la documentation technique.

Le début d’une promesse tenue

Au sein de Framasoft, nous brûlons d’impatience, car nous avons envie de voir un maximum de monde s’émanciper des événements Facebook pour créer, grâce à Mobilizon, un groupe de plaidoyer citoyen ou une marche pour le climat.

Et pourtant, il va falloir se retenir encore un peu de fermer les groupes Facebook où s’organise une part de nos vies. En attendant, nous espérons que cette démonstration vous montrera le potentiel d’un outil qui contribuera à rassembler, à organiser et à mobilizer… celles et ceux qui changent le monde.

Notes

Marie-Cécile Godwin Paccard est designer indépendante et chercheuse UX. Elle accompagne des personnes et des organisations dans la définition de leurs fondamentaux et objectifs, en apportant un regard systémique. Elle s’occupe de comprendre les usages en profondeur et de concevoir des outils utilisables, éthiques et inclusifs. Elle fait partie de l’équipe qui travaille sur le logiciel Mobilizon. Nous lui avons posé 3 questions pour qu’elle nous explique son rôle sur le projet.

Bonjour Marie-Cécile ! Vous avez accompagné le projet Mobilizon, afin que celui-ci corresponde, dès sa conception, aux besoins et usages des personnes qui sont vouées à l’utiliser. Pouvez-vous nous expliquer en quoi il est particulièrement important pour ce projet de prendre en compte les besoins et attentes des futur⋅es utilisateur⋅ices ?

Bonjour à toute l’équipe ! Étudier les besoins et les usages, c’est essentiel si l’on veut concevoir un logiciel, un service ou même un objet qui soit utilisable, et donc utilisé. Mobilizon a pour ambition de permettre aux personnes de s’organiser et de se rassembler, et de leur donner le pouvoir de le faire librement et respectueusement. Rien de mieux pour commencer à parler « usages » dès le début de la réflexion autour du projet ! Toute l’équipe qui travaille sur Mobilizon a le souhait que les communautés existantes s’en emparent et que de nouvelles communautés s’y créent. On ne pourra pas atteindre cet objectif si on ne fait pas l’effort d’aller à la rencontre des personnes pour comprendre ce dont elles ont besoin, quels problèmes elles rencontrent et comment elles ont fait pour y pallier jusqu’à présent.

Quand on conçoit des choses destinées à être utilisées par d’autres personnes, il est très important de ne pas se contenter de nos propres suppositions, croyances ou idées fixes et d’ouvrir notre esprit à la perception et à l’expérience d’autres personnes. Une courte phase de recherche en usages peut donner des résultats rapides et précieux et permettre d’identifier très en amont des problématiques et des objectifs auxquels on n’avait pas forcément pensé et qui vont nous aider à questionner nos présupposés de départ.

Quelle a été votre démarche pour recueillir la parole de ces utilisateur⋅ices (ou communautés) ?

D’abord, nous avons passé un temps de réflexion ensemble à bien cadrer le projet, ses ambitions, mais aussi ses implications politiques (car TOUT est politique, surtout dans le design et le logiciel, qui plus est libre !) et comment Mobilizon s’inscrivait dans la mission de Framasoft. Nous avons fait le point sur les plateformes d’organisation existantes et ce qu’elles engendraient comme problèmes qui empêchaient les gens de s’organiser librement. J’ai ensuite proposé un plan de recherche à l’équipe, pour bien définir ce vers quoi nous allions orienter la phase de recherche. Nous avons lancé une première enquête en ligne, qui a recueilli pas loin de 300 réponses. Dans cette enquête, nous demandions aux personnes répondantes comment elles s’organisaient en général pour se rassembler à l’aide des plateformes numériques, soit en tant qu’invitées, soit en tant qu’organisatrices elles-mêmes. Nous avons recueilli des informations précieuses sur les problèmes qu’elles pouvaient rencontrer, et pourquoi elles utilisaient ou pas tel ou tel outil numérique pour le faire.

Dans un deuxième temps, nous avons défini des typologies de communautés à qui nous souhaitions nous adresser. À nouveau, il fallait partir des usages : des communautés très grandes avec différents niveaux d’organisation qui créent des rassemblements publics, des communautés spécialisées qui organisent des événements thématiques, des organisations qui souhaitent assurer respect de la vie privée à elles et aux personnes qui participent à leurs événements, etc. Je suis ensuite partie à la recherche de personnes qui correspondaient à ces cas d’usages pour leur poser des questions sur leur manière de s’organiser. On ne parle pas encore de logiciel, de code ou de graphisme à ce point : on se focalise encore et toujours sur les usages, sur la réalité de l’organisation d’événements et aux problèmes bien concrets qui se posent aux personnes qui les mettent en place.

Comment ces éléments alimentent-ils la réflexion sur les fonctionnalités de Mobilizon ?

Une fois que la phase de recherche est bouclée, il est temps de tirer des conclusions sur les données recueillies. Quelle est la réalité des usages des personnes et comment concevoir un logiciel qui ira dans leur sens ? On va ensuite arbitrer nos décisions avec ces données.

Certaines choses parlent tout de suite d’elles-mêmes : si je me rends compte à travers quasiment tous les entretiens qu’une problématique revient tout le temps, cela veut dire qu’il faut la garder en tête tout au long de la conception et du développement et trouver la meilleure manière d’y répondre. Certes, il y a des problèmes très humains que Mobilizon ne pourra pas résoudre, par exemple les « no-show », les personnes qui indiquent qu’elles participeront à l’événement mais finissent par ne pas venir. Même si l’on a pas de solution logicielle pour résoudre ce souci, comprendre pourquoi il embête les organisateurs et organisatrices permet de prendre de meilleures décisions par la suite.

Mobilizon ne pourra pas être « one-size-fits-all » (taille unique). Seront couvertes en priorité les fonctionnalités que nous pensons indispensables aux petites communautés qui n’ont pas les moyens techniques de se rassembler ailleurs. On ne remplacera pas un Mattermost ou un WhatsApp, et on n’aura jamais la même force de frappe que Facebook. Mais Mobilizon proposera les fonctionnalités essentielles pour que les communautés les plus exposées au capitalisme de surveillance puissent migrer hors de Facebook, mais ne pourra pas remplacer les centaines de pads imbriqués ou les conversations vocales de Discord à plus de 30 personnes !

En ce moment, je suis en train de concevoir le « back office » de Mobilizon, et toute l’articulation de la « tuyauterie » qui va permettre de créer un événement, un groupe, d’inviter des personnes dans ledit groupe pour s’organiser en amont de l’événement, de définir les différentes identités avec lesquelles on pourra dire que l’on participe à un événement en cloisonnant son activité, de modérer les participations ou les questions et commentaires…

Avec le reste de l’équipe, nous nous posons également plein de questions sur la manière dont Mobilizon va accompagner les personnes dans la compréhension des principes de la fédération et des instances. Le but est de nous assurer que dans tous les cas, la personne qui souhaite utiliser une instance Mobilizon pour créer un événement sur le web accède simplement aux tenants et aboutissants de tel ou tel choix, pour prendre la décision qui lui convient le mieux. Cela va se traduire dans plein d’aspects de la conception du logiciel : comment va se dérouler l’inscription (« on boarding »), quels éléments vont permettre de comprendre le principe des instances dans le texte et dans l’interface, etc.

Pour en savoir plus sur le logiciel Mobilizon, c’est sur https://joinmobilizon.org/.
Vous pouvez aussi vous inscrire à la newsletter Mobilizon pour recevoir les informations sur l’évolution du logiciel.

Protocole, HTTP, interopérabilité, ça vous parle ? Et normes, spécifications, RFC, ça va toujours ? Si vous avez besoin d’y voir un peu plus clair, l’article ci-dessous est un morceau de choix rédigé par Stéphane Bortzmeyer qui s’est efforcé de rendre accessibles ces notions fondamentales.

Protocoles

Le 21 mai 2019, soixante-neuf organisations, dont Framasoft, ont signé un appel à ce que soit imposé, éventuellement par la loi, un minimum d’interopérabilité pour les gros acteurs commerciaux du Web.

« Interopérabilité » est un joli mot, mais qui ne fait pas forcément partie du vocabulaire de tout le monde, et qui mérite donc d’être expliqué. On va donc parler d’interopérabilité, de protocoles, d’interfaces, de normes, et j’espère réussir à le faire tout en restant compréhensible (si vous êtes informaticien·ne professionnel·le, vous savez déjà tout cela ; mais l’appel des 69 organisations concerne tout le monde).

Le Web, ou en fait tout l’Internet, repose sur des protocoles de communication. Un protocole, c’est un ensemble de règles qu’il faut suivre si on veut communiquer. Le terme vient de la communication humaine, par exemple, lorsqu’on rencontre quelqu’un, on se serre la main, ou bien on se présente si l’autre ne vous connaît pas, etc. Chez les humains, le protocole n’est pas rigide (sauf en cas de réception par la reine d’Angleterre dans son palais, mais cela doit être rare chez les lectrices et lecteurs du Framablog). Si la personne avec qui vous communiquez ne respecte pas exactement le protocole, la communication peut tout de même avoir lieu, quitte à se dire que cette personne est bien impolie. Mais les logiciels ne fonctionnent pas comme des humains. Contrairement aux humains, ils n’ont pas de souplesse, les règles doivent être suivies exactement. Sur un réseau comme l’Internet, pour que deux logiciels puissent communiquer, chacun doit donc suivre exactement les mêmes règles, et c’est l’ensemble de ces règles qui fait un protocole.

Un exemple concret ? Sur le Web, pour que votre navigateur puisse afficher la page web désirée, il doit demander à un serveur web un ou plusieurs fichiers. La demande se fait obligatoirement en envoyant au serveur le mot GET (« donne », en anglais) suivi du nom du fichier, suivi du mot « HTTP/1.1 ». Si un navigateur web s’avisait d’envoyer le nom du fichier avant le mot GET, le serveur ne comprendrait rien, et renverrait plutôt un message d’erreur. En parlant d’erreurs, vous avez peut-être déjà rencontré le nombre 404 qui est simplement le code d’erreur qu’utilisent les logiciels qui parlent HTTP pour signaler que la page demandée n’existe pas. Ces codes numériques, conçus pour être utilisés entre logiciels, ont l’avantage sur les textes de ne pas être ambigus, et de ne pas dépendre d’une langue humaine particulière. Cet exemple décrit une toute petite partie du protocole nommé HTTP (pour Hypertext Transfer Protocol) qui est le plus utilisé sur le Web.

Il existe des protocoles bien plus complexes. Le point important est que, derrière votre écran, les logiciels communiquent entre eux en utilisant ces protocoles. Certains servent directement aux logiciels que vous utilisez (comme HTTP, qui permet à votre navigateur Web de communiquer avec le serveur qui détient les pages désirées), d’autres protocoles relèvent de l’infrastructure logicielle de l’Internet ; vos logiciels n’interagissent pas directement avec eux, mais ils sont indispensables.

Le protocole, ces règles de communication, sont indispensables dans un réseau comme l’Internet. Sans protocole, deux logiciels ne pourraient tout simplement pas communiquer, même si les câbles sont bien en place et les machines allumées. Sans protocole, les logiciels seraient dans la situation de deux humains, un Français ne parlant que français, et un Japonais ne parlant que japonais. Même si chacun a un téléphone et connaît le numéro de l’autre, aucune vraie communication ne pourra prendre place. Tout l’Internet repose donc sur cette notion de protocole.

Le protocole permet l’interopérabilité. L’interopérabilité est la capacité à communiquer de deux logiciels différents, issus d’équipes de développement différentes. Si une université bolivienne peut échanger avec une entreprise indienne, c’est parce que toutes les deux utilisent des protocoles communs.

Seuls les protocoles ont besoin d’être communs : l’Internet n’oblige pas à utiliser les mêmes logiciels, ni à ce que les logiciels aient la même interface avec l’utilisateur. Si je prends l’exemple de deux logiciels qui parlent le protocole HTTP, le navigateur Mozilla Firefox (que vous êtes peut-être en train d’utiliser pour lire cet article) et le programme curl (utilisé surtout par les informaticiens pour des opérations techniques), ces deux logiciels ont des usages très différents, des interfaces avec l’utilisateur reposant sur des principes opposés, mais tous les deux parlent le même protocole HTTP. Le protocole, c’est ce qu’on parle avec les autres logiciels (l’interface avec l’utilisateur étant, elle, pour les humain·e·s.).

La distinction entre protocole et logiciel est cruciale. Si j’utilise le logiciel A parce que je le préfère et vous le logiciel B, tant que les deux logiciels parlent le même protocole, aucun problème, ce sera juste un choix individuel. Malgré leurs différences, notamment d’interface utilisateur, les deux logiciels pourront communiquer. Si, en revanche, chaque logiciel vient avec son propre protocole, il n’y aura pas de communication, comme dans l’exemple du Français et du Japonais plus haut.

Babel

Alors, est-ce que tous les logiciels utilisent des protocoles communs, permettant à tout le monde de communiquer avec bonheur ? Non, et ce n’est d’ailleurs pas obligatoire. L’Internet est un réseau à « permission facultative ». Contrairement aux anciennes tentatives de réseaux informatiques qui étaient contrôlés par les opérateurs téléphoniques, et qui décidaient de quels protocoles et quelles applications tourneraient sur leurs réseaux, sur l’Internet, vous pouvez inventer votre propre protocole, écrire les logiciels qui le parlent et les diffuser en espérant avoir du succès. C’est d’ailleurs ainsi qu’a été inventé le Web : Tim Berners-Lee (et Robert Cailliau) n’ont pas eu à demander la permission de qui que ce soit. Ils ont défini le protocole HTTP, ont écrit les applications et leur invention a connu le succès que l’on sait.

Cette liberté d’innovation sans permission est donc une bonne chose. Mais elle a aussi des inconvénients. Si chaque développeur ou développeuse d’applications invente son propre protocole, il n’y aura plus de communication ou, plus précisément, il n’y aura plus d’interopérabilité. Chaque utilisatrice et chaque utilisateur ne pourra plus communiquer qu’avec les gens ayant choisi le même logiciel. Certains services sur l’Internet bénéficient d’une bonne interopérabilité, le courrier électronique, par exemple. D’autres sont au contraire composés d’un ensemble de silos fermés, ne communiquant pas entre eux. C’est par exemple le cas des messageries instantanées. Chaque application a son propre protocole, les personnes utilisant WhatsApp ne peuvent pas échanger avec celles utilisant Telegram, qui ne peuvent pas communiquer avec celles qui préfèrent Signal ou Riot. Alors que l’Internet était conçu pour faciliter la communication, ces silos enferment au contraire leurs utilisateurs et utilisatrices dans un espace clos.

La situation est la même pour les réseaux sociaux commerciaux comme Facebook. Vous ne pouvez communiquer qu’avec les gens qui sont eux-mêmes sur Facebook. Les pratiques de la société qui gère ce réseau sont déplorables, par exemple en matière de captation et d’utilisation des données personnelles mais, quand on suggère aux personnes qui utilisent Facebook de quitter ce silo, la réponse la plus courante est « je ne peux pas, tou·te·s mes ami·e·s y sont, et je ne pourrais plus communiquer avec eux et elles si je partais ». Cet exemple illustre très bien les dangers des protocoles liés à une entreprise et, au contraire, l’importance de l’interopérabilité.

Mais pourquoi existe-t-il plusieurs protocoles pour un même service ? Il y a différentes raisons. Certaines sont d’ordre technique. Je ne les développerai pas ici, ce n’est pas un article technique, mais les protocoles ne sont pas tous équivalents, il y a des raisons techniques objectives qui peuvent faire choisir un protocole plutôt qu’un autre. Et puis deux personnes différentes peuvent estimer qu’en fait deux services ne sont pas réellement identiques et méritent donc des protocoles séparés, même si tout le monde n’est pas d’accord.

Mais il peut aussi y avoir des raisons commerciales : l’entreprise en position dominante n’a aucune envie que des acteurs plus petits la concurrencent, et ne souhaite pas permettre à des nouveaux entrants d’arriver. Elle a donc une forte motivation à n’utiliser qu’un protocole qui lui est propre, que personne d’autre ne connaît.

Enfin, il peut aussi y avoir des raisons plus psychologiques, comme la conviction chez l·e·a créat·eur·rice d’un protocole que son protocole est bien meilleur que les autres.

Un exemple d’un succès récent en termes d’adoption d’un nouveau protocole est donné par le fédivers. Ce terme, contraction de « fédération » et « univers » (et parfois écrit « fédiverse » par anglicisme) regroupe tous les serveurs qui échangent entre eux par le protocole ActivityPub, que l’appel des soixante-neuf organisations mentionne comme exemple. ActivityPub permet d’échanger des messages très divers. Les logiciels Mastodon et Pleroma se servent d’ActivityPub pour envoyer de courts textes, ce qu’on nomme du micro-blogging (ce que fait Twitter). PeerTube utilise ActivityPub pour permettre de voir les nouvelles vidéos et les commenter. WriteFreely fait de même avec les textes que ce logiciel de blog permet de rédiger et diffuser. Et, demain, Mobilizon utilisera ActivityPub pour les informations sur les événements qu’il permettra d’organiser. Il s’agit d’un nouvel exemple de la distinction entre protocole et logiciel. Bien que beaucoup de gens appellent le fédivers  « Mastodon », c’est inexact. Mastodon n’est qu’un des logiciels qui permettent l’accès au fédivers.

Le terme d’ActivityPub n’est d’ailleurs pas idéal. Il y a en fait un ensemble de protocoles qui sont nécessaires pour communiquer au sein du fédivers. ActivityPub n’est que l’un d’entre eux, mais il a un peu donné son nom à l’ensemble.

Tous les logiciels de la mouvance des « réseaux sociaux décentralisés » n’utilisent pas ActivityPub. Par exemple,  Diaspora ne s’en sert pas et n’est donc pas interopérable avec les autres.

Appel

Revenons maintenant l’appel cité au début, Que demande-t-il ? Cet appel réclame que l’interopérabilité soit imposée aux GAFA, ces grosses entreprises capitalistes qui sont en position dominante dans la communication. Tous sont des silos fermés. Aucun moyen de commenter une vidéo YouTube si on a un compte PeerTube, de suivre les messages sur Twitter ou Facebook si on est sur le fédivers. Ces GAFA ne changeront pas spontanément : il faudra les y forcer.

Il ne s’agit que de la communication externe. Cet appel est modéré dans le sens où il ne demande pas aux GAFA de changer leur interface utilisateur, ni leur organisation interne, ni leurs algorithmes de sélection des messages, ni leurs pratiques en matière de gestion des données personnelles. Il s’agit uniquement d’obtenir qu’ils permettent l’interopérabilité avec des services concurrents, de façon à permettre une réelle liberté de choix par les utilisateurs. Un tel ajout est simple à implémenter pour ces entreprises commerciales, qui disposent de fonds abondants et de nombreu·ses-x programmeur·e·s compétent·e·s. Et il « ouvrirait » le champ des possibles. Il s’agit donc de défendre les intérêts des utilisateurs et utilisatrices. (Alors que le gouvernement, dans ses commentaires, n’a cité que les intérêts des GAFA, comme si ceux-ci étaient des espèces menacées qu’il fallait défendre.)

Qui commande ?

Mais au fait, qui décide des protocoles, qui les crée ? Il n’y a pas de réponse simple à cette question. Il existe plein de protocoles différents et leurs origines sont variées. Parfois, ils sont rédigés, dans un texte qui décrit exactement ce que doivent faire les deux parties. C’est ce que l’on nomme une spécification. Mais parfois il n’y a pas vraiment de spécification, juste quelques vagues idées et un programme qui utilise ce protocole. Ainsi, le protocole BitTorrent, très utilisé pour l’échange de fichiers, et pour lequel il existe une très bonne interopérabilité, avec de nombreux logiciels, n’a pas fait l’objet d’une spécification complète. Rien n’y oblige développeurs et développeuses : l’Internet est « à permission facultative ». Dans de tels cas, celles et ceux qui voudraient créer un programme interopérable devront lire le code source (les instructions écrites par le ou la programmeur·e) ou analyser le trafic qui circule, pour essayer d’en déduire en quoi consiste le protocole (ce qu’on nomme la rétro-ingénierie). C’est évidemment plus long et plus difficile et il est donc très souhaitable, pour l’interopérabilité, qu’il existe une spécification écrite et correcte (il s’agit d’un exercice difficile, ce qui explique que certains protocoles n’en disposent pas).

Parfois, la spécification est adoptée formellement par un organisme dont le rôle est de développer et d’approuver des spécifications. C’est ce qu’on nomme la normalisation. Une spécification ainsi approuvée est une norme. L’intérêt d’une norme par rapport à une spécification ordinaire est qu’elle reflète a priori un consensus assez large d’une partie des acteurs, ce n’est plus un acte unilatéral. Les normes sont donc une bonne chose mais, rien n’étant parfait, leur développement est parfois laborieux et lent.

Toutes les normes ne se valent pas. Certaines sont publiquement disponibles (comme les normes importantes de l’infrastructure de l’Internet, les RFC – Request For Comments), d’autres réservées à ceux qui paient, ou à ceux qui sont membres d’un club fermé. Certaines normes sont développées de manière publique, où tout le monde a accès aux informations, d’autres sont créées derrière des portes soigneusement closes. Lorsque la norme est développée par une organisation ouverte à tous et toutes, selon des procédures publiques, et que le résultat est publiquement disponible, on parle souvent de normes ouvertes. Et, bien sûr, ces normes ouvertes sont préférables pour l’interopérabilité.

L’une des organisations de normalisation ouverte les plus connues est l’IETF (Internet Engineering Task Force, qui produit notamment la majorité des RFC). L’IETF a développé et gère la norme décrivant le protocole HTTP, le premier cité dans cet article. Mais d’autres organisations de normalisation existent comme le W3C (World-Wide Web Consortium) qui est notamment responsable de la norme ActivityPub.

Par exemple, pour le cas des messageries instantanées que j’avais citées, il y a bien une norme, portant le doux nom de XMPP (Extensible Messaging and Presence Protocol). Google l’utilisait, puis l’a abandonnée, jouant plutôt le jeu de la fermeture.

Difficultés

L’interopérabilité n’est évidemment pas une solution magique à tous les problèmes. On l’a dit, l’appel des soixante-neuf organisations est très modéré puisqu’il demande seulement une ouverture à des tiers. Si cette demande se traduisait par une loi obligeant à cette interopérabilité, tout ne serait pas résolu.

D’abord, il existe beaucoup de moyens pour respecter la lettre d’un protocole tout en violant son esprit. On le voit pour le courrier électronique où Gmail, en position dominante, impose régulièrement de nouvelles exigences aux serveurs de messagerie avec lesquels il daigne communiquer. Le courrier électronique repose, contrairement à la messagerie instantanée, sur des normes ouvertes, mais on peut respecter ces normes tout en ajoutant des règles. Ce bras de fer vise à empêcher les serveurs indépendants de communiquer avec Gmail. Si une loi suivant les préconisations de l’appel était adoptée, nul doute que les GAFA tenteraient ce genre de jeu, et qu’il faudrait un mécanisme de suivi de l’application de la loi.

Plus subtil, l’entreprise qui voudrait « tricher » avec les obligations d’interopérabilité peut aussi prétendre vouloir « améliorer » le protocole. On ajoute deux ou trois choses qui n’étaient pas dans la norme et on exerce alors une pression sur les autres organisations pour qu’elles aussi ajoutent ces fonctions. C’est un exercice que les navigateurs web ont beaucoup pratiqué, pour réduire la concurrence.

Jouer avec les normes est d’autant plus facile que certaines normes sont mal écrites, laissant trop de choses dans le vague (et c’est justement le cas d’ActivityPub). Écrire une norme est un exercice difficile. Si on laisse beaucoup de choix aux programmeuses et programmeurs qui créeront les logiciels, il y a des risques de casser l’interopérabilité, suite à des choix trop différents. Mais si on contraint ces programmeuses et programmeurs, en imposant des règles très précises pour tous les détails, on empêche les logiciels d’évoluer en réponse aux changements de l’Internet ou des usages. La normalisation reste donc un art difficile, pour lequel on n’a pas de méthode parfaite.

Conclusion

Voilà, désolé d’avoir été long, mais les concepts de protocole et d’interopérabilité sont peu enseignés, alors qu’ils sont cruciaux pour le fonctionnement de l’Internet et surtout pour la liberté des citoyen·ne·s qui l’utilisent. J’espère les avoir expliqués clairement, et vous avoir convaincu⋅e de l’importance de l’interopérabilité. Pensez à soutenir l’appel des soixante-neuf organisations !

Après

Et si vous voulez d’autres informations sur ce sujet, il y a :

• Si vous aimez le son plutôt que l’écrit, le podcast de l’APRIL a parlé de l’interopérabilité.

We have less than 60 days to finance Mobilizon. Less than 60 days to promote our project of a free and federated alternative to Facebook events ; and to know how much we need to invest ourselves in it.

Change the software of the people who change the world?

From climate walks on Facebook to free software hackathons using Meetup: to change the world, utopians (like us!) too often organize themselves on the centralized platforms of web giants.

We are not going to repeat here how clicking on « I join » in a Facebook event « Vegan Barbecue for Social Justice » raises many issues: it says much more about you than you can imagine, it gives a significant power to Facebook advertisers and locks the event community into a tool that will prevent it from being self-organized and thus from enduring. And that’s without mentioning the rules of use of these platforms, which can lead to a closing, without the least justification, from one day to the next, of a group or a communtiy, and of which the centralized structure forms a potentially unique portal for security services and pirates with bad intentions.

Mock-up of an Event page in Mobilizon

At Framasoft, we thought it was important to take the time to think about an alternative that could change the situation. We have just spent a few months, with the help of two designers (Marie-Cécile Paccard and Geoffrey Dorne) who haved interviewed many activists so as to better understand their digital practices. We looked at what a tool that would really empower individuals and groups could look like.

The tool that surveillance capitalism companies will not make

If you think about it, it’s massively constraining to create a tool that is just good for sucking up and selling data from all over the world…. As long as we do not need (or want) to track people or maintain an unfair economic model, we can imagine a tool that makes a difference.

1. A tool that, even if basic, sets us free

The last thing Meetup, Eventbrite or Facebook want is for us to do without them, take their place and create our own event publishing platform. This is the first of the freedoms Mobilizon will offer: to free people from those money-, data- and attention-grabing companies.

Of course, you might not be able to install it on a server yourself and create your own Mobilizon instance. But the fact that a community, a trade union, an NGO, a movement, a federation, that is, any collective can freely emancipate itself from data-hungry platforms, feels essential to us.

Along these lines, making the source code, the « cooking recipe » of the software, public is paramount to us: not everyone can read it, but it is a guarantee of transparency and openness. If the team that develops it makes choices that do not suit me, I can set up my own team to experiment with different design choices and another governance system.

2. A tool that emancipates by federating

But here’s the thing: if my university creates its MobilizedCollege instance on the one hand, and my climate movement creates its EcoMobilized instance on the other, do I need to create an account on each site to keep up with the planned gatherings?

No: it would be a huge strain on end-users. This is why we want Mobilizon to be federated: each instance (event publication site) powered by Mobilizon will then be able to choose to exchange with other instances, to display more events than « just its own », and to promote interactions. The federation protocol, based on the most widespread standard (called ActivityPub), will also allow, in the long term, to build bridges with Mastodon (the free and federated alternative to Twitter), PeerTube (alternative to YouTube), and many other alternative services.

However, the concept of federation is not a magic wand. On the contrary, it requires even more effort: displaying your moderation policy, communicating with the people registered on your server, choosing with whom you can federate or not, applying your legal obligations (or practicing civil disobedience)… An emancipatory Mobilizon should, in our opinion, facilitate these relationships between the people who open their instance to registrations, and those who entrust them with their data.

3. A tool that is, ideally, user-friendly

Ideally, Mobilizon not only frees us from Facebook events, but also frees us from its groups. And to have user-friendly groups, you have to imagine messaging tools, moderation tools, in short: many features that make us autonomous.

Because a user-friendly tool is a tool that gives us power, that gives us control. Thus, it is a tool that allows each group to organize itself as it wishes. Ideally, Mobilizon offers groups a space to display links to its digital collaboration tools, whatever they are, even google docs (but honestly, Framapad: it’s even better :p).

Another example of empowerment: if I want my family, who invites me to the youngest child’s birthday, to see my militant commitment (say for a pride march), but not my cultural activities (say folk dance), I must be able to control it. Ideally, Mobilizon allows each account to create multiple identities to partition its groups and activities as desired.

4. A tool that is sustainable and resilient in the long run

Software is a constantly evolving tool. Of course, producing a first stable version is a challenge in itself. But it is also the first step in a longer process, where we discover uses and practices that were not anticipated, that we can support.

There are already many possible evolutions for Mobilizon: facilitate geolocation and mapping, develop a mobile application, improve ergonomics and interfaces… What other ideas will our collective intelligence produce when Mobilizon is operational and used?

But here it is, maintaining and growing a commons requires care, time and attention. We must give ourselves the means, and at Framasoft, we hope that the support given to this project will show an enthusiastic supportive public, thanks to which we will be able to plan for the long term.

What resources are being used to produce Mobilizon?

Creating such a tool, with no other goal than to build a digital commons, requires time, involvement and resources. At Framasoft, we are convinced of the importance that Mobilizon can have, in the long term, for many communities. But we are already working on many projects and lack the time and money to do everything…. Thus, we will not get involved without a strong signal that this tool is desired.

We have just opened a collection on joinmobilizon.org. We have given ourselves less than 60 days to know how well our approach will be supported. In concrete terms, the more you give, the more we will be involved in Mobilizon‘s development in the long term.

We have defined the following budgets:

• 20 000 € – Free and basic Mobilizon, where we will cover our expenses and deliver the code and design work to the community, after the release of version 1;
• 35 000 € – Emancipatory and federated Mobilizon, where we will also be able to implement the ActivityPub federation protocol, and all the tools that go with it, including a test instance, for demonstration;
• 50,000 € – Ideal and user-friendly Mobilizon which, in addition to the rest, will directly include all the features we dream of for version 1 (groups, messaging, multi-identity, external tool displays).
• Further – Sustainable and resilient Mobilizon, which development will be maintained by Framasoft beyond the V1 release, with advanced features.

From now on, and until July 10th, any donation made to Framasoft via the Joinmobilizon.org page will be attributed to the Mobilizon project. On July 10th, depending on the amount that has been reached, we will focus on developing the Mobilizon that you have supported. We plan to release a beta version in the fall of 2019, and a version 1 in the first half of 2020.

Mock-up of a Group page in Mobilizon

You have les than 60 days to determine our involvement

So we need your help. Together, we have less than 60 days to propose and explain this project to the associative, cultural and militant communities in France and abroad. Less than 60 days to convince them of the importance of supporting Mobilizon, without falling into the trap of easy shorthand like « it will replace Facebook » or otherwise « this is a revolution ».

It will therefore be necessary to take the time to speak, to exchange, to listen… to convince without marketing bullshit or claiming to be an authority. Because Mobilizon will not be a miracle instantaneous recipe: it is a first step towards more independence, an adventure that will evolve over time, and one that we wanted to start with you.

How far will we go? It is now in your hands… let’s Mobilize!

Nous avons moins de 60 jours pour financer Mobilizon. Moins de 60 jours pour faire connaître notre projet d’alternative libre et fédérée aux événements Facebook ; et pour savoir à quel point nous devons nous y investir.

Changer le logiciel de celles et ceux qui changent le monde ?

Des marches pour le climat organisées sur Facebook aux hackathons de logiciels libres qui se font grâce à Meetup : pour changer le monde, les utopistes (comme nous !) s’organisent bien trop souvent sur les plateformes centralisées des géants du web.

On ne va pas répéter ici à quel point cliquer sur « Je participe » à un événement Facebook « Barbecue végan de la justice sociale » pose de nombreux problèmes : cela en dit bien plus sur soi qu’on ne l’imagine, donne un pouvoir conséquent aux publicitaires qui paient Facebook et enferme la communauté de l’événement dans un outil qui l’empêchera de s’auto-gérer et donc de perdurer.

Et c’est sans compter sur les règles d’utilisation de ces plateformes, qui peuvent mener à une fermeture, du jour au lendemain, sans aucune justification, d’un groupe ou d’une communauté, et dont la structure centralisée forme un potentiel guichet unique pour les agences de renseignement et des pirates mal intentionnés.

Maquette d’une page « événement » dans Mobilizon

Chez Framasoft, on s’est dit qu’il fallait prendre le temps de réfléchir à une alternative qui puisse changer la donne. Nous venons de passer quelques mois, avec l’aide de deux designers (Marie-Cécile Paccard et Geoffrey Dorne) à écouter des militant·e·s pour mieux cerner leurs pratiques numériques. Nous avons cherché à quoi pourrait ressembler un outil qui rendrait vraiment le pouvoir aux personnes, aux groupes.

L’outil que les entreprises du capitalisme de surveillance ne feront pas

Si on y réfléchit, c’est hyper contraignant de créer un outil juste pour aspirer et vendre les données du monde entier… À partir du moment où l’on n’a pas besoin (ni envie) de pister les gens ou de maintenir un modèle économique inéquitable, on peut imaginer un outil qui fait la différence.

1. Un outil qui, même basique, nous rend libres

La dernière chose dont Meetup, Eventbrite ou Facebook ont envie, c’est que nous nous passions d’eux, que l’on puisse prendre leur place, et que l’on crée notre propre plateforme de publication d’événements. C’est la première des libertés qu’offrira Mobilizon : échapper à l’emprise de ces plateformes à but lucratif.

Bien entendu, tout le monde ne va pas aller l’installer sur un serveur informatique, et monter son propre Mobilizon. Mais il est essentiel qu’une communauté, un syndicat, une ONG, un mouvement, une fédération… que n’importe quel collectif puisse s’émanciper librement des plateformes avides de données.

C’est comme le fait de rendre public le code source, la « recette de cuisine » du logiciel : tout le monde ne sait pas le lire, mais c’est un gage de transparence et d’ouverture. Si l’équipe qui le développe fait des choix qui ne me conviennent pas, je peux monter ma propre équipe pour expérimenter d’autres choix, et une autre gouvernance.

2. Un outil qui émancipe en fédérant

Seulement voilà : si mon université crée son instance MobilizTaFac d’un côté, et que mon mouvement pour le climat crée son instance ÉcoMobilizés de l’autre, est-ce que je dois créer un compte sur chaque site, histoire de me tenir au courant des rassemblements prévus ?

Non : ce serait, selon nous, un gros frein à l’usage. C’est pour cela que nous souhaitons que Mobilizon soit fédéré : chaque instance (site de publication d’événements) propulsée par Mobilizon pourra alors choisir d’échanger avec d’autres instances, d’afficher plus d’événements que « juste les siens », et de favoriser les interactions. Le protocole de fédération, basé sur le standard de communication le plus répandu (nommé ActivityPub), permettra en plus, à terme, de tisser des ponts avec Mastodon (l’alternative libre et fédérée à Twitter), PeerTube (alternative à YouTube), et bien d’autres outils similaires.

Cependant, le concept de fédération n’est pas une baguette magique. Au contraire, l’adopter demande encore plus d’efforts : afficher sa politique de modération, communiquer avec les personnes inscrites sur son serveur, choisir avec qui on se fédère ou non, appliquer ses obligations légales (ou pratiquer la désobéissance civile)… Un Mobilizon émancipateur devrait, à notre sens, faciliter ces relations entre les personnes qui ouvrent leur hébergement aux inscriptions, et celles qui leur confient leurs données.

3. Un outil qui, dans l’idéal, est convivial

Dans l’idéal, Mobilizon ne nous libère pas seulement des événements Facebook : il nous libère aussi de ses groupes. Et pour avoir des groupes conviviaux, il faut imaginer des outils de messagerie, des outils de modération, bref : de nombreuses fonctionnalités qui nous rendent autonomes.

Car un outil convivial est un outil qui nous laisse le pouvoir, qui nous rend le contrôle. C’est un outil qui laisse chaque groupe s’organiser comme il le souhaite. Dans l’idéal, Mobilizon offre aux groupes un espace pour afficher des liens vers ses outils de collaboration numérique, quels qu’ils soient, même des google docs (mais franchement, nous on pense que Framapad, c’est mieux :p).

Un autre exemple de reprise de pouvoir : si je veux que ma famille, qui m’invite à l’anniversaire du petit dernier, voie mon engagement militant (disons pour une marche des fiertés), mais pas mes activités culturelles (disons de danse folklorique), je dois pouvoir le maîtriser. Dans l’idéal, Mobilizon permet à chaque compte de se créer plusieurs identités pour cloisonner ses groupes et ses activités comme on le désire.

4. Un outil qui, à terme, est durable et résilient

Un logiciel est un outil en perpétuelle évolution. Certes, produire une première version stable est un défi en soi. Mais c’est aussi le premier pas d’un cheminement plus long, où l’on découvre des usages et pratiques qui n’étaient pas anticipées, que l’on peut accompagner.

Il existe, d’ores et déjà, de nombreuses évolutions possibles pour Mobilizon : faciliter la géolocalisation et la cartographie, développer une application mobile, améliorer l’ergonomie et les interfaces… Quelles autres idées l’intelligence collective produira-t-elle quand Mobilizon sera opérationnel et utilisé ?

Seulement voilà, entretenir et faire grandir un commun, cela demande du soin, du temps et de l’attention. Si vous nous en donnez les moyens, la somme récoltée au-delà des 50 000 € nous permettra de nous projeter sur le long terme et d’envisager les développements après la sortie de la version 1.0.

Quels moyens se donne-t-on pour produire Mobilizon ?

Créer un tel outil, sans autre but que celui de construire un commun numérique, cela demande du temps, de l’implication et des moyens. Chez Framasoft, nous sommes persuadé·e·s de l’importance que Mobilizon peut avoir, à terme, pour de nombreuses communautés. Mais nous travaillons déjà sur de très nombreux projets et manquons de temps et d’argent pour tout faire… Ainsi, nous ne nous lancerons pas sans avoir un signal fort que cet outil est désiré.

Nous venons d’ouvrir une collecte sur joinmobilizon.org. Nous nous sommes donné 60 jours pour savoir à quel point notre démarche sera soutenue. Concrètement, plus vous donnerez, plus cela nous impliquera durablement dans le développement de Mobilizon.

Nous avons défini les budgets suivants :

• 20 000 € – Mobilizon libre et basique, où nous rentrerons dans nos frais et livrerons le code et les travaux de design à la communauté après la sortie de la version 1 ;
• 35 000 € – Mobilizon émancipateur et fédéré, où nous pourrons en plus implémenter le protocole de fédération ActivityPub et tous les outils qui vont avec, dont une instance de test pour démonstration ;
• 50 000 € – Mobilizon idéal et convivial qui, en supplément du reste, inclura directement l’ensemble des fonctionnalités dont nous rêvons pour la version 1 (groupes, messagerie, multi-identité, affichages d’outils externes) .
• au-delà – Mobilizon durable et résilient, dont le développement pourra être maintenu et amélioré par Framasoft au delà de la version 1, avec des fonctionnalités avancées.

Dès aujourd’hui, et jusqu’au 10 juillet, tout don fait à Framasoft via la page joinmobilizon.org sera comptablement attribué au projet Mobilizon. Au 10 juillet, suivant le montant qui aura été atteint, nous nous consacrerons à développer le Mobilizon que vous aurez soutenu. Nous prévoyons la sortie d’une version bêta pour l’automne 2019, et une version 1 pour le premier semestre 2020.

Maquette d’une page « groupe » dans Mobilizon

Vous avez moins de 60 jours pour déterminer notre implication

Nous avons donc besoin de votre aide. Ensemble, nous avons moins de 60 jours pour proposer et expliquer ce projet aux communautés associatives, culturelles et militantes en France et à l’étranger. Moins de 60 jours pour les convaincre de l’importance de soutenir Mobilizon, sans tomber dans le piège des raccourcis faciles des « ça va remplacer Facebook » (cela peut remplacer la gestion d’évènements de Facebook) et autres « ceci est une révolution » (nous ne sommes pas une startup, et n’avons pas pour vocation de remplacer tous les usages !).

Il va donc falloir prendre le temps de parler, d’échanger, d’écouter… pour convaincre sans charmer ni imposer une quelconque autorité. Car Mobilizon ne sera pas une recette miracle et instantanée : c’est un premier pas vers plus d’indépendance, une aventure qui va évoluer sur la durée, et que nous avons souhaité démarrer avec vous.

Jusqu’où irons-nous ? C’est désormais entre vos mains… à vous de vous Mobilizer !

Il n’est pas si fréquent que l’équipe Framalang traduise un article depuis la langue italienne, mais la récapitulation bien documentée de Cagizero était une bonne occasion de faire le point sur l’expansion de la Fediverse, un phénomène dont nous nous réjouissons et que nous souhaitons voir gagner plus d’amplitude encore, tant mieux si l’article ci-dessous est très lacunaire dans un an !

Article original : Mastodon, il Fediverso ed il futuro decentrato delle reti sociali

Traduction Framalang : alainmi, Ezelty, goofy, MO

Mastodon, la Fediverse et l’avenir des réseaux décentralisés

par Cagizero

Peu de temps après une première vue d’ensemble de Mastodon il est déjà possible d’ajouter quelques observations nouvelles.

Tout d’abord, il faut noter que plusieurs personnes familières de l’usage des principaux médias sociaux commerciaux (Facebook, Twitter, Instagram…) sont d’abord désorientées par les concepts de « décentralisation » et de « réseau fédéré ».

En effet, l’idée des médias sociaux qui est répandue et bien ancrée dans les esprits est celle d’un lieu unique, indifférencié, monolithique, avec des règles et des mécanismes strictement identiques pour tous. Essentiellement, le fait même de pouvoir concevoir un univers d’instances séparées et indépendantes représente pour beaucoup de gens un changement de paradigme qui n’est pas immédiatement compréhensible.

Dans un article précédent où était décrit le média social Mastodon, le concept d’instance fédérée était comparé à un réseau de clubs ou cercles privés associés entre eux.

Certains aspects exposés dans l’article précédent demandent peut-être quelques éclaircissements supplémentaires pour celles et ceux qui abordent tout juste le concept de réseau fédéré.

1. On ne s’inscrit pas « sur Mastodon », mais on s’inscrit à une instance de Mastodon ! La comparaison avec un club ou un cercle s’avère ici bien pratique : adhérer à un cercle permet d’entrer en contact avec tous ceux et celles qui font partie du même réseau : on ne s’inscrit pas à une plateforme, mais on s’inscrit à l’un des clubs de la plateforme qui, avec les autres clubs, constituent le réseau. La plateforme est un logiciel, c’est une chose qui n’existe que virtuellement, alors qu’une instance qui utilise une telle plateforme en est l’aspect réel, matériel. C’est un serveur qui est physiquement situé quelque part, géré par des gens en chair et en os qui l’administrent. Vous vous inscrivez donc à une instance et ensuite vous entrez en contact avec les autres.

2. Les diverses instances ont la possibilité technique d’entrer en contact les unes avec les autres mais ce n’est pas nécessairement le cas. Supposons par exemple qu’il existe une instance qui regroupe 500 utilisateurs et utilisatrices passionné⋅e⋅s de littérature, et qui s’intitule mastodon.litterature : ces personnes se connaissent précisément parce en tant que membres de la même instance et chacun⋅e reçoit les messages publics de tous les autres membres.
Eh bien, chacun d’entre eux aura probablement aussi d’autres contacts avec des utilisateurs enregistrés sur difFerentes instances (nous avons tous des ami⋅e⋅s qui ne font pas partie de notre « cercle restreint », n’est-ce pas ?). Si chacun des 500 membres de maston.litterature suit par exemple 10 membres d’une autre instance, mastodon.litterature aurait un réseau local de 500 utilisateurs, mais aussi un réseau fédéré de 5000 utilisateurs !
Bien. Supposons que parmi ces 5000 il n’y ait même pas un seul membre de l’instance japonaise japan.nuclear.physics dont le thème est la physique nucléaire : cette autre instance pourrait avoir peut-être 800 membres et avoir un réseau fédéré de plus de 8000 membres, mais si entre les réseaux « littérature » et « physique nucléaire » il n’y avait pas un seul ami en commun, ses membres ne pourraient en théorie jamais se contacter entre eux.
En réalité, d’après la loi des grands nombres, il est assez rare que des instances d’une certaine taille n’entrent jamais en contact les unes avec les autres, mais l’exemple sert à comprendre les mécanismes sur lesquels repose un réseau fédéré (ce qui, en se basant justement sur la loi des grands nombres et les principes des degrés de séparation, confirme au contraire l’hypothèse que plus le réseau est grand, moins les utilisateurs et instances seront isolés sur une seule instance).

3. Chaque instance peut décider volontairement de ne pas entrer en contact avec une autre, sur la base des choix, des règles et politiques internes qui lui sont propres. Ce point est évidemment peu compris des différents commentateurs qui ne parviennent pas à sortir de l’idée du « réseau social monolithique ». S’il y avait sur Mastodon une forte concentration de suprémacistes blancs en deuil de Gab, ou de blogueurs porno en deuil de Tumblr, cela ne signifie pas que ce serait l’ensemble du réseau social appelé Mastodon qui deviendrait un « réseau social pour suprémacistes blancs et porno », mais seulement quelques instances qui n’entreraient probablement jamais en contact avec des instances antifascistes ou ultra-religieuses. Comme il est difficile de faire comprendre un tel concept, il est également difficile de faire comprendre les potentialités d’une structure de ce type. Dans un réseau fédéré, une fois donnée la possibilité technique d’interagir entre instances et utilisateurs, chaque instance et chaque utilisateur peut ensuite choisir de façon indépendante l’utilisation qui en sera faite.

Supposons qu’il existe par exemple :

• Une instance écologiste, créée, maintenue et soutenue financièrement par un groupe de passionnés qui veulent avoir un lieu où échanger sur la nature et l’écologie, qui pose comme principe qu’on n’y poste ni liens externes ni images pornographiques.
• Une instance commerciale, créée par une petite entreprise qui dispose d’un bon serveur et d’une bande passante très confortable, et celui ou celle qui s’y inscrit en payant respecte les règles fixées auparavant par l’entreprise elle-même.
• Une instance sociale, créée par un centre social et dont les utilisateurs sont surtout les personnes qui fréquentent ledit centre et se connaissent aussi personnellement.
• Une instance vidéoludique, qui était à l’origine une instance interne des employés d’une entreprise de technologie mais qui dans les faits est ouverte à quiconque s’intéresse aux jeux vidéos.

Avec ce scénario à quatre instances, on peut déjà décrire quelques interactions intéressantes : l’instance écologiste pourrait consulter ses utilisateurs et utilisatrices et décider de bannir l’instance commerciale au motif qu’on y diffuse largement une culture contraire à l’écologie, tandis que l’instance sociale pourrait au contraire maintenir le lien avec l’instance commerciale tout en choisissant préventivement de la rendre muette dans son propre fil, laissant le choix personnel à ses membres d’entrer ou non en contact avec les membres de l’instance commerciale. Cependant, l’instance sociale pourrait bannir l’instance de jeu vidéo à cause de la mentalité réactionnaire d’une grande partie de ses membres.

En somme, les contacts « insupportables/inacceptables » sont spontanément limités par les instances sur la base de leurs différentes politiques. Ici, le cadre d’ensemble commence à devenir très complexe, mais il suffit de l’observer depuis une seule instance, la nôtre, pour en comprendre les avantages : les instances qui accueillent des trolls, des agitateurs et des gens avec qui on n’arrive vraiment pas à discuter, nous les avons bannies, alors que celles avec lesquelles on n’avait pas beaucoup d’affinités mais pas non plus de motif de haine, nous les avons rendues muettes. Ainsi, si quelqu’un parmi nous veut les suivre, il n’y a pas de problème, mais ce sera son choix personnel.

4. Chaque utilisateur peut décider de rendre muets d’autres utilisateurs, mais aussi des instances entières. Si vous voulez particulièrement éviter les contenus diffusés par les utilisateurs et utilisatrices d’une certaine instance qui n’est cependant pas bannie par l’instance qui vous accueille (mettons que votre instance ne ferme pas la porte à une instance appelée meme.videogamez.lulz, dont la communauté tolère des comportements excessifs et une ambiance de moquerie  lourde que certains trouvent néanmoins amusante), vous êtes libres de la rendre muette pour vous seulement. En principe, en présence de groupes d’utilisateurs indésirables venant d’une même instance/communauté, il est possible de bloquer plusieurs dizaines ou centaines d’utilisateurs à la fois en bloquant (pour vous) l’instance entière. Si votre instance n’avait pas un accord unanime sur la manière de traiter une autre instance, vous pourriez facilement laisser le choix aux abonnés qui disposent encore de ce puissant outil. Une instance peut également choisir de modérer seulement ses utilisateurs ou de ne rien modérer du tout, laissant chaque utilisateur complètement libre de faire taire ou d’interdire qui il veut sans jamais interférer ou imposer sa propre éthique.

La Fediverse

Maintenant que nous nous sommes mieux concentrés sur ces aspects, nous pouvons passer à l’étape suivante. Comme déjà mentionné dans le post précédent, Mastodon fait partie de quelque chose de plus vaste appelé la Fediverse (Fédération + Univers).

En gros, Mastodon est un réseau fédéré qui utilise certains outils de communication (il existe plusieurs protocoles mais les principaux sont ActivityPub, Ostatus et Diaspora*, chacun ayant ses avantages, ses inconvénients, ses partisans et ses détracteurs), utilisés aussi par et d’autres réalités fédérées (réseaux sociaux, plateformes de blogs, etc.) qui les mettent en contact pour former une galaxie unique de réseaux fédérés.

Pour vous donner une idée, c’est comme si Mastodon était un système planétaire qui tourne autour d’une étoile (Mastodon est l’étoile et chaque instance est une planète), cependant ce système planétaire fait partie d’un univers dans lequel existent de nombreux systèmes planétaires tous différents mais qui communiquent les uns avec les autres.

Toutes les planètes d’un système planétaire donné (les instances, comme des « clubs ») tournent autour d’un soleil commun (la plate-forme logicielle). L’utilisateur peut choisir la planète qu’il préfère mais il ne peut pas se poser sur le soleil : on ne s’inscrit pas à la plateforme, mais on s’inscrit à l’un des clubs qui, avec tous les autres, forme le réseau.

Dans cet univers, Mastodon est tout simplement le « système planétaire » le plus grand (celui qui a le plus de succès et qui compte le plus grand nombre d’utilisateurs) mais il n’est pas certain qu’il en sera toujours ainsi : d’autres « systèmes planétaires » se renforcent et grandissent.

[NB : chaque plate-forme évoquée ici utilise ses propres noms pour définir les serveurs indépendants sur lesquels elle est hébergée. Mastodon les appelle instances, Hubzilla les appelle hubs et Diaspora* les appelle pods. Toutefois, par souci de simplicité et de cohérence avec l’article précédent, seul le terme « instance » sera utilisé pour tous dans l’article]

Sur Kumu.io on peut trouver une représentation interactive de la Fediverse telle qu’elle apparaît actuellement. Chaque « nœud » représente un réseau différent (ou « système planétaire »). Ce sont les différentes plateformes qui composent la fédération. Mastodon n’est que l’une d’entre elles, la plus grande, en bas au fond. Sur la capture d’écran qui illustre l’article, Mastodon est en bas.

En sélectionnant Mastodon il est possible de voir avec quels autres médias ou systèmes de la Fediverse il est en mesure d’interagir. Comme on peut le voir, il interagit avec la plupart des autres médias mais pas tout à fait avec tous.

En sélectionnant un autre réseau social comme GNU Social, on observe qu’il a différentes interactions : il en partage la majeure partie avec Mastodon mais il en a quelques-unes en plus et d’autres en moins.

Cela dépend principalement du type d’outils de communication (protocoles) que chaque média particulier utilise. Un média peut également utiliser plus d’un protocole pour avoir le plus grand nombre d’interactions, mais cela rend évidemment leur gestion plus complexe. C’est, par exemple, la voie choisie par Friendica et GNU Social.

En raison des différents protocoles utilisés, certains médias ne peuvent donc pas interagir avec tous les autres. Le cas le plus important est celui de Diaspora*, qui utilise son propre protocole (appelé lui aussi Diaspora), qui ne peut interagir qu’avec Friendica et Gnu Social mais pas avec des médias qui reposent sur ActivityPub tels que Mastodon.

Au sein de la Fediverse, les choses sont cependant en constante évolution et l’image qui vient d’être montrée pourrait avoir besoin d’être mise à jour prochainement. En ce moment, la plupart des réseaux semblent s’orienter vers l’adoption d’ActivityPub comme outil unique. Ce ne serait pas mal du tout d’avoir un seul protocole de communication qui permette vraiment tout type de connexion !

Mais revenons un instant à l’image des systèmes planétaires. Kumu.io montre les connexions techniquement possibles entre tous les « systèmes planétaires » et, pour ce faire, relie génériquement les différents soleils. Mais comme nous l’avons bien vu, les vraies connexions ont lieu entre les planètes et non entre les soleils ! Une carte des étoiles montrant les connexions réelles devrait montrer pour chaque planète (c’est-à-dire chaque « moustache » des nœuds de Kum.io), des dizaines ou des centaines de lignes de connexion avec autant de planètes/moustaches, à la fois entre instances de sa plateforme et entre instances de différentes plateformes ! La quantité et la complexité des connexions, comme on peut l’imaginer, formeraient un enchevêtrement qui donnerait mal à la tête serait graphiquement illisible. Le simple fait de l’imaginer donne une idée de la quantité et de la complexité des connexions possibles.

Et cela ne s’arrête pas là : chaque planète peut établir ou interrompre ses contacts avec les autres planètes de son système solaire (c’est-à-dire que l’instance Mastodon A peut décider de ne pas avoir de contact avec l’instance Mastodon B), et de la même manière elle peut établir ou interrompre les contacts avec des planètes de différents systèmes solaires (l’instance Mastodon A peut établir ou interrompre des contacts avec l’instance Pleroma B). Pour donner un exemple radical, nous pouvons supposer que nous avons des cousins qui sont des crétins, mais d’authentiques crétins, que nous avons chassés de notre planète (mastodon.terre) et qu’ensuite ils ont construit leur propre instance (mastodon.saturne) dans notre voisinage parce que ben, ils aiment bien notre soleil « Mastodon ». Nous décidons de nous ignorer les uns les autres tout de suite. Ces cousins, cependant, sont tellement crétins que même nos parents et amis proches des planètes voisines (mastodon.jupiter, mastodon.venus, etc.) ignorent les cousins crétins de mastodon.saturne.

Aucune planète du système Mastodon ne les supporte. Les cousins, cependant, ne sont pas entièrement sans relations et, au contraire, ils ont beaucoup de contacts avec les planètes d’autres systèmes solaires. Par exemple, ils sont en contact avec certaines planètes du système planétaire PeeeTube: peertube.10287, peertube.chatons, peertube.anime, mais aussi avec pleroma.pizza du système Pleroma et friendica.jardinage du système Friendica. En fait, les cousins crétins sont d’accord pour vivre sur leur propre petite planète dans le système Mastodon, mais préfèrent avoir des contacts avec des planètes de systèmes différents.

Nous qui sommes sur mastodon.terre, nous ne nous soucions pas moins des planètes qui leur sont complaisantes : ce sont des crétins tout autant que nos cousins et nous les avons bloquées aussi. Sauf un. Sur pleroma.pizza, nous avons quelques ami⋅e⋅s qui sont aussi des ami⋅e⋅s de certains cousins crétins de mastodon.saturne. Mais ce n’est pas un problème. Oh que non ! Nous avons des connexions interstellaires et nous devrions nous inquiéter d’une chose pareille ? Pas du tout ! Le blocage que nous avons activé sur mastodon.saturne est une sorte de barrière énergétique qui fonctionne dans tout le cosmos ! Si nous étions impliqués dans une conversation entre un ami de pleroma.pizza et un cousin de mastodon.saturne, simplement, ce dernier ne verrait pas ce qui sort de notre clavier et nous ne verrions pas ce qui sort du sien. Chacun d’eux saura que l’autre est là, mais aucun d’eux ne pourra jamais lire l’autre. Bien sûr, nous pourrions déduire quelque chose de ce que notre ami commun de pleroma.pizza dira, mais bon, qu’est-ce qu’on peut en espérer ? 😉

Cette image peut donner une idée de la façon dont les instances (planètes) se connectent entre elles. Si l’on considère qu’il existe des milliers d’instances connues de la Fediverse, on peut imaginer la complexité de l’image. Un aspect intéressant est le fait que les connexions entre une instance et une autre ne dépendent pas de la plateforme utilisée. Sur l’image on peut voir l’instance mastodon.mercure : c’est une instance assez isolée par rapport au réseau d’instances Mastodon, dont les seuls contacts sont mastodon.neptune, peertube.chatons et pleroma.pizza. Rien n’empêche mastodon.mercure de prendre connaissance de toutes les autres instances de Mastodon non par des échanges de messages avec mastodon.neptune, mais par des commentaires sur les vidéos de peertube.chatons. En fait, c’est d’autant plus probable que mastodon.neptune n’est en contact qu’avec trois autres instances Mastodon, alors que peertube.chatons est en contact avec toutes les instances Mastodon.

Essayer d’imaginer comment les différentes instances de cette image qui « ne se connaissent pas » peuvent entrer en contact nous permet d’avoir une idée plus précise du niveau de complexité qui peut être atteint. Dans un système assez grand, avec un grand nombre d’utilisateurs et d’instances, isoler une partie de celui-ci ne compromettra en aucune façon la richesse des connexions possibles.
Une fois toutes les connexions possibles créées, il est également possible de réaliser une expérience différente, c’est-à-dire d’imaginer interrompre des connexions jusqu’à la formation de deux ou plusieurs réseaux parfaitement séparés, contenant chacune des instances Mastodon, Pleroma et Peertube.

Et pour ajouter encore un degré de complexité, on peut faire encore une autre expérience, en raisonnant non plus à l’échelle des instances mais à celle des utilisateurs⋅rices individuel⋅le⋅s des instances (faire l’hypothèse de cinq utilisateurs⋅rices par instance pourrait suffire pour recréer les différentes situations). Quelques cas qu’on peut imaginer :

1) Nous sommes sur une instance de Mastodon et l’utilisatrice Anna vient de découvrir par le commentaire d’une vidéo sur Peertube l’existence d’une nouvelle instance de Pleroma, donc maintenant elle connaît son existence mais, choisissant de ne pas la suivre, elle ne fait pas réellement connaître sa découverte aux autres membres de son instance.

2) Sur cette même instance de Mastodon l’utilisateur Ludo bloque la seule instance Pleroma connue. Conséquence : si cette instance Pleroma devait faire connaître d’autres instances Pleroma avec lesquelles elle est en contact, Ludo devrait attendre qu’un autre membre de son instance les fasse connaître, car il s’est empêché lui-même d’être parmi les premiers de son instance à les connaître.

3) En fait, la première utilisatrice de l’instance à entrer en contact avec les autres instances Pleroma sera Marianne. Mais elle ne les connaît pas de l’instance Pleroma (celle que Ludo a bloquée) avec laquelle ils sont déjà en contact, mais par son seul contact sur GNU Social.

Cela semble un peu compliqué mais en réalité ce n’est rien de plus qu’une réplique de mécanismes humains auxquels nous sommes tellement habitué⋅e⋅s que nous les tenons pour acquis. On peut traduire ainsi les différents exemples qui viennent d’être exposés :

1) Notre amie Anna, habituée de notre bar, rencontre dans la rue une personne qui lui dit fréquenter un nouveau bar dans une ville proche. Mais Anna n’échange pas son numéro de téléphone avec le type et elle ne pourra donc pas donner d’informations à ses amis dans son bar sur le nouveau bar de l’autre ville.

2) Dans le bar habituel, Ludo de Nancy évite Laura de Metz. Quand Laura amène ses autres amies Solène et Louise de Metz au bar, elle ne les présente pas à Ludo. Ce n’est que plus tard que les amis du bar, devenus amis avec Solène et Louise, pourront les présenter à Ludo indépendamment de Laura.

3) En réalité Marianne avait déjà rencontré Solène et Louise, non pas grâce à Laura, mais grâce à Stéphane, son seul ami à Villers.

Pour avoir une idée de l’ampleur de la Fediverse, vous pouvez jeter un coup d’œil à plusieurs sites qui tentent d’en fournir une image complète. Outre Kumu.io déjà mentionné, qui essaie de la représenter avec une mise en page graphique élégante qui met en évidence les interactions, il y a aussi Fediverse.network qui essaie de lister chaque instance existante en indiquant pour chacune d’elles les protocoles utilisés et le statut du service, ou Fediverse.party, qui est un véritable portail où choisir la plate-forme à utiliser et à laquelle s’enregistrer. Switching.software, une page qui illustre toutes les alternatives gratuites aux médias sociaux et propriétaires, indique également quelques réseaux fédérés parmi les alternatives à Twitter et Facebook.

Pour être tout à fait complet : au début, on avait tendance à diviser tout ce mégaréseau en trois « univers » superposés : celui de la « Fédération » pour les réseaux reposant sur le protocole Diaspora, La « Fediverse » pour ceux qui utilisent Ostatus et « ActivityPub » pour ceux qui utilisent… ActivityPub. Aujourd’hui, au contraire, ils sont tous considérés comme faisant partie de la Fediverse, même si parfois on l’appelle aussi la Fédération.

Tant de réseaux…

Examinons donc les principales plateformes/réseaux et leurs différences. Petites précisions : certaines de ces plateformes sont pleinement actives alors que d’autres sont à un stade de développement plus ou moins avancé. Dans certains cas, l’interaction entre les différents réseaux n’est donc pas encore pleinement fonctionnelle. De plus, en raison de la nature libre et indépendante des différents réseaux, il est possible que des instances apportent des modifications et des personnalisations « non standard » (un exemple en est la limite de caractères sur Mastodon : elle est de 500 caractères par défaut, mais une instance peut décider de définir la limite qu’elle veut ; un autre exemple est l’utilisation des fonctions de mise en favori ou de partage, qu’une instance peut autoriser et une autre interdire). Dans ce paragraphe, ces personnalisations et différences ne sont pas prises en compte.

Mastodon (semblable à : Twitter)

Mastodon est une plateforme de microblogage assez semblable à Twitter parce qu’elle repose sur l’échange de messages très courts. C’est le réseau le plus célèbre de la Fediverse. Il est accessible sur smartphone à travers un certain nombre d’applications tant pour Android que pour iOS. Un de ses points forts est le design bien conçu et le fait qu’il a déjà un « parc d’utilisateurs⋅rices » assez conséquent (presque deux millions d’utilisateurs⋅rices dans le monde, dont quelques milliers en France). En version bureau, il se présente comme une série de colonnes personnalisables, qui montrent les différents « fils », sur le modèle de Tweetdeck. Pour le moment, Mastodon est la seule plateforme sociale fédérée accessible par des applications sur Android et iOS.

Pleroma (semblable à : Twitter et DeviantArt)

Pleroma est le réseau « sœur » de Mastodon : fondamentalement, c’est la même chose dans deux versions un peu différentes. Pleroma offre quelques fonctionnalités supplémentaires concernant la gestion des images et permet par défaut des messages plus longs. À la différence de Mastodon, Pleroma montre en version bureau une colonne unique avec le fil sélectionné, ce qui le rend beaucoup plus proche de Twitter. Actuellement, de nombreuses instances Pleroma ont un grand nombre d’utilisateurs⋅rices qui s’intéressent à l’illustration et au manga, ce qui, comme ambiance, peut vaguement rappeler l’ambiance de DeviantArt. Les applications pour smartphone de Mastodon peuvent également être utilisées pour accéder à Pleroma.

Misskey (semblable à : un mélange entre Twitter et DeviantArt)

Misskey est une sorte de Twitter qui tourne principalement autour d’images. Il offre un niveau de personnalisation supérieur à Mastodon et Pleroma, et une plus grande attention aux galeries d’images. C’est une plateforme qui a eu du succès au Japon et parmi les passionnés de manga (et ça se voit !).

Friendica (semblable à : Facebook)

Friendica est un réseau extrêmement intéressant. Il reprend globalement la structure graphique de Facebook (avec les ami⋅e⋅s, les notifications, etc.), mais il permet également d’interagir avec plusieurs réseaux commerciaux qui ne font pas partie de la Fediverse. Il est donc possible de connecter son compte Friendica à Facebook, Twitter, Tumblr, WordPress, ainsi que de générer des flux RSS, etc. Bref, Friendica se présente comme une sorte de nœud pour diffuser du contenu sur tous les réseaux disponibles, qu’ils soient fédérés ou non. En somme, Friendica est le passe-partout de la Fediverse : une instance Friendica au maximum de ses fonctions se connecte à tout et dialogue avec tout le monde.

Osada (semblable à : un mélange entre Twitter et Facebook)

Osada est un autre réseau dont la configuration peut faire penser à un compromis entre Twitter et Facebook. De toutes les plateformes qui rappellent Facebook, c’est celle dont le design est le plus soigné.

GNUsocial (semblable à : un mélange entre Twitter et Facebook)

GNUsocial est un peu le « grand-père » des médias sociaux listés ici, en particulier de Friendica et d’Osada, dont il est le prédécesseur.

Aardwolf (semblable à : Twitter, éventuellement)

Aardwolf n’est pas encore prêt, mais il est annoncé comme une sorte d’alternative à Twitter. On attend de voir.

PeerTube (semblable à : YouTube)

PeerTube est le réseau fédéré d’hébergement de vidéo vraiment, mais vraiment très semblable à YouTube, Vimeo et d’autres services de ce genre. Avec un catalogue en cours de construction, Peertube apparaît déjà comme un projet très solide.

Pixelfed (semblable à : Instagram)

Pixelfed est essentiellement l’Instagram de la Fédération. Il est en phase de développement mais semble être plutôt avancé. Il lui manque seulement des applications pour smartphone pour être adopté à la place d’Instagram. Pixelfed a le potentiel pour devenir un membre extrêmement important de la Fédération !

NextCloud (semblable à : iCloud, Dropbox, GDrive)

NextCloud, né du projet plus ancien ownCloud, est un service d’hébergement de fichiers assez semblable à Dropbox. Tout le monde peut faire tourner NextCloud sur son propre serveur. NextCloud offre également des services de partage de contacts (CardDAV) ou de calendriers (CalDAV), de streaming de médias, de marque-page, de sauvegarde, et d’autres encore. Il tourne aussi sur Window et OSX et est accessible sur smartphone à travers des applications officielles. Il fait partie de la Fediverse dans la mesure où il utilise ActivityPub pour communiquer différentes informations à ses utilisateurs, comme des changements dans les fichiers, les activités du calendrier, etc.

Diaspora* (semblable à : Facebook, et aussi un peu Tumblr)

Diaspora* est un peu le « cousin » de la Fediverse. Il fonctionne avec un protocole bien à lui et dialogue avec le reste de la Fediverse principalement via GNU social et Friendica, le réseau passe-partout, même s’il semble qu’il circule l’idée de faire utiliser à Diaspora* (l’application) aussi bien son propre protocole qu’ActivityPub. Il s’agit d’un grand et beau projet, avec une base solide d’utilisateurs⋅rices fidèles. Au premier abord, il peut faire penser à une version extrêmement minimaliste de Facebook, mais son attention aux images et son système intéressant d’organisation des posts par tag permet également de le comparer, d’une certaine façon, à Tumblr.

Funkwhale (semblable à : SoundCloud et Grooveshark)

Funkwhale ressemble à SoundCloud, Grooveshark et d’autre services semblables. Comme une sorte de YouTube pour l’audio, il permet de partager des pistes audio mais au sein d’un réseau fédéré. Avec quelques fonctionnalités en plus, il pourrait devenir un excellent service d’hébergement de podcasts audio.

Plume, Write Freely et Write.as (plateformes de blog)

Plume, Write Freely et Write.as sont des plateformes de blog assez minimalistes qui font partie de la Fédération. Elles n’ont pas toute la richesse, les fonctions, les thèmes et la personnalisation de WordPress ou de Blogger, mais elles font leur travail avec légèreté.

Hubzilla (semblable à : …TOUT !!)

Hubzilla est un projet très riche et complexe qui permet de gérer aussi bien des médias sociaux que de l’hébergement de fichiers, des calendriers partagés, de l’hébergement web, et le tout de manière décentralisée. En bref, Hubzilla se propose de faire tout à la fois ce que font plusieurs des services listés ici. C’est comme avoir une seule instance qui fait à la fois Friendica, Peertube et NextCloud. Pas mal ! Un projet à surveiller !

GetTogether (semblable à : MeetUp)

GetTogether est une plateforme servant à planifier des événements. Semblable à MeetUp, elle sert à mettre en relation des personnes différentes unies par un intérêt commun, et à amener cet intérêt dans le monde réel. Pour le moment, GetTogether ne fait pas encore partie de la Fediverse, mais il est en train de mettre en place ActivityPub et sera donc bientôt des nôtres.

Mobilizon (semblable à : MeetUp)

Mobilizon est une nouvelle plateforme en cours de développement, qui se propose comme une alternative libre à MeetUp et à d’autres logiciels servant à organiser des réunions et des rencontres en tout genre. Dès le départ, le projet naît avec l’intention d’utiliser ActivityPub et de faire partie de la Fediverse, en conformité avec les valeurs de Framasoft, association française née avec l’objectif de diffuser l’usage des logiciels libres et des réseaux décentralisés. Voir la présentation de Mobilizon en italien.

Plugin ActivityPub pour WordPress

Plugin activityPub pour WordPress

On trouve plusieurs plugins pour WordPress qui en font un membre à part entière de la Fédération ! Il existe également des plugins comme Mastodon AutoPost, Mastodon Auto Share, mais aussi Mastodon Embed, Ostatus for WordPress, Pterotype, Nodeinfo et Mastalab comments.

Prismo (semblable à : Pocket, Evernote, Reddit)

Prismo est une application encore en phase de développement, qui se propose de devenir un sorte de version décentralisée de Reddit, c’est-à-dire un média social centré sur le partage de liens, mais qui pourrait potentiellement évoluer en quelque chose qui ressemble à Pocket ou Evernote. Les fonctions de base sont déjà opérationnelles.

Socialhome

Socialhome est un média social qui utilise une interface par « blocs », affichant les messages comme dans un collage de photos de Pinterest. Pour le moment, il communique seulement via le protocole de Diaspora, mais il devrait bientôt mettre en place ActivityPub.

Et ce n’est pas tout !

Il existe encore d’autres applications et médias sociaux qui adoptent ou vont adopter ActivityPub, ce qui rendra la Fediverse encore plus structurée. Certains sont assez semblables à ceux déjà évoqués, alors que d’autres sont encore en phase de développement, on ne peut donc pas encore les conseiller pour remplacer des systèmes commerciaux plus connus. Il y a cependant des plateformes déjà prêtes et fonctionnelles qui pourraient entrer dans la Fediverse en adoptant ActivityPub : NextCloud en est un exemple (il était déjà constitué quand il a décidé d’entrer dans la Fediverse) ; le plugin de WordPress est pour sa part un outil qui permet de fédérer une plateforme qui existe déjà ; GetTogether est un autre service qui est en train d’être fédéré. Des plateformes déjà en place (je pense à Gitter, mais c’est juste un exemple parmi tant d’autres) pourraient trouver un avantage à se fédérer et à entrer dans une grande famille élargie. Bref : ça bouge dans la Fediverse et autour d’elle !

… un seul Grand Réseau !

Jusqu’ici, nous avons vu de nombreuses versions alternatives d’outils connus qui peuvent aussi être intéressant pris individuellement, mais qui sont encore meilleurs quand ils collaborent. Voici maintenant le plus beau : le fait qu’ils partagent les mêmes protocoles de communication élimine l’effet « cage dorée » de chaque réseau !

Maintenant qu’on a décrit chaque plateforme, on peut donner quelques exemples concrets :

Je suis sur Mastodon, où apparaît le message d’une personne que je « suis ». Rien d’étrange à cela, si ce n’est que cette personne n’est pas utilisatrice de Mastodon, mais de Peertube ! En effet, il s’agit de la vidéo d’un panorama. Toujours depuis Mastodon, je commente en écrivant « joli » et cette personne verra apparaître mon commentaire sous sa vidéo, sur Peertube.

Je suis sur Osada et je poste une réflexion ouverte un peu longue. Cette réflexion est lue par une de mes amies sur Friendica, qui la partage avec ses followers, dont certains sont sur Friendica, mais d’autres sont sur d’autres plateformes. Par exemple, l’un d’eux est sur Pleroma, il me répond et nous commençons à dialoguer.

Je publie une photo sur Pixelfed qui est vue et commentée par un de mes abonnés sur Mastodon.

En somme, chacun peut garder contact avec ses ami⋅e⋅s/abonné⋅e⋅s depuis son réseau préféré, mêmes si ces personnes en fréquentent d’autres.

Pour établir une comparaison avec les réseaux commerciaux, c’est comme si l’on pouvait recevoir sur Facebook les tweets d’un ami qui est sur Twitter, les images postées par quelqu’un d’autre sur Instagram, les vidéos d’une chaîne YouTube, les pistes audio sur SoundCloud, les nouveaux posts de divers blogs et sites personnels, et commenter et interagir avec chacun d’eux parce que tous ces réseaux collaborent et forment un seul grand réseau !

Chacun de ces réseaux pourra choisir la façon dont il veut gérer ces interactions : par exemple, si je voulais une vie sociale dans un seul sens, je pourrais choisir une instance Pixelfed où les autres utilisateurs⋅rices peuvent me contacter seulement en commentant les photos que je publie, ou bien je pourrais choisir une instance Peertube et publier des vidéos qui ne pourraient pas être commentées mais qui pourraient tourner dans toute la Fediverse, ou choisir une instance Mastodon qui oblige mes interlocuteurs à communiquer avec moi de manière concise.

Certains détails sont encore à définir (par exemple : je pourrais envoyer un message direct depuis Mastodon vers une plateforme qui ne permet pas à ses utilisateurs⋅rices de recevoir des messages directs, sans jamais être averti du fait que le/la destinataire n’aura aucun moyen de savoir que je lui ai envoyé quelque chose). Il s’agit de situations bien compréhensibles à l’intérieur d’un écosystème qui doit s’adapter à des réalités très diverses, mais dans la majorité des cas il s’agit de détails faciles à gérer. Ce qui compte, c’est que les possibilités d’interactions sont potentiellement infinies !

Connectivité totale, exposition dosée

Toute cette connectivité partagée doit être observée en gardant à l’esprit que, même si par simplicité les différents réseaux ont été traités ici comme des réseaux centralisés, ce sont en réalité des réseaux d’instances indépendantes qui interagissent directement avec les instances des autres réseaux : mon instance Mastodon filtrera les instances Peertube qui postent des vidéos racistes mais se connectera à toutes les instances Peertube qui respectent sa politique ; si je suis un certain ami sur Pixelfed je verrai seulement ses posts, sans que personne m’oblige à voir toutes les photos de couchers de soleil et de chatons de ses ami⋅e⋅s sur ce réseau.

La combinaison entre autonomie des instances, grande interopérabilité entre celles-ci et liberté de choix permet une série de combinaisons extrêmement intéressantes dont les réseaux commerciaux ne peuvent même pas rêver : ici, l’utilisateur⋅rice est membre d’un seul grand réseau où chacun⋅e peut choisir :

• Son outil d’accès préféré (Mastodon, Pleroma, Friendica) ;
• La communauté dans laquelle il ou elle se sent le plus à l’aise (l’instance) ;
• La fermeture aux communautés indésirables et l’ouverture aux communautés qui l’intéressent.

Tout cela sans pour autant renoncer à être connecté à des utilisateurs⋅rices qui ont choisi des outils et des communautés différents. Par exemple, je peux choisir une certaine instance Pleroma parce que j’aime son design, la communauté qu’elle accueille, ses règles et la sécurité qu’elle procure mais, à partir de là, suivre et interagir principalement avec des utilisateurs⋅rices d’une instance Pixelfed particulière et en importer les contenus et l’esthétique dans mon instance.

À cela on peut ajouter que des instances individuelles peuvent littéralement être installées et administrées par chaque utilisateur individuel sur ses propres machines, ce qui permet un contrôle total du contenu. Les instances minuscules auto-hébergées « à la maison » et les instances de travail plus robustes, les instances scolaires et les instances collectives, les instances avec des milliers d’utilisateurs et les instances avec un seul utilisateur, les instances à l’échelle d’un quartier ou d’un immeuble, toutes sont unies pour former un réseau complexe et personnalisable, qui vous permet de vous connecter pratiquement à n’importe qui mais aussi de vous éviter la surcharge d’information.

C’est une sorte de retour aux origines d’Internet, mais un retour à un âge de maturité, celui du Web 2.0, qui a tiré les leçons de l’expérience : être passé par la centralisation de la communication entre les mains de quelques grands acteurs internationaux a renforcé la conviction que la structure décentralisée est la plus humaine et la plus enrichissante.