La Fée diverse déploie ses ailes

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 logo de 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] La structure d’ensemble de la Fediverse Les interactions de Mastodon avec les autres médias

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. Les interactions de Gnu social avec les autres médias

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éseauxsemblent 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 laFediverse , 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) Copie d’écran, une instance de Mastodon, Framapiaf

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) Copie d’écran, Pleroma

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) Copie d’écran, Misskey

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) Image animée, réponse à un commentaire sur Osada

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) Copie d’écran : GNUsocial avec une interface en suédois.

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)

Copie d’écran : logo et slogan d’Aardwolf

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

PeerTube (semblable à : YouTube) Capture d’écran, une instance de PeerTube, aperi.tube

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) Copie d’écran, Pixelfed

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) Logo de Owncloud

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) Copie d’écran, un « pod » de Diaspora*, Framasphere

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) Copie d’écran, Funkwhale

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) Copie d’écran, Write freely

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 !!)

Page d’accueil de Hubzilla 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)

Copie d’écran, GetTogether

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) Copie d’écran, Prismo

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 Capture d’écran, 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 ! Les recommandations du W3C pour ActivityPub, page d’accueil

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.

Rejoignez la fédération !

Funkwhale : Eliot franchit le pas

Quand un développeur choisit de se consacrer à plein temps au logiciel libre qu’il a créé, ça nous intéresse. Quand en plus il s’agit d’un logiciel fédéré qui fait appel au protocole activityPub…

Lecteurs et lectrices de ce blog, vous connaissez sans doute le papa de Funkwhale, Eliot Berriot, déjà longuement interviewé par Narf. Dans l’article qu’il vient de faire paraître sur le nouveau blog consacré au projet, il fait le bilan de ce qui s’est passé, évoque le succès présent de Funkwhale et surtout envisage l’avenir. Son projet a commencé à rallier une communauté de contributeurs et contributrices et suscite un intérêt grandissant, mais qu’en sera-t-il sur le long terme, pourra-t-il s’appuyer sur des contributions solides et nombreuses, et avec quelles ressources financières peut se poursuivre le développement ?

N’hésitez pas à contribuer de toutes les façons possibles (code, documentation, traduction, bêta-tests, signalement de bugs, communication, don financier, messages de soutien et de remerciement…) au succès de Funkwhale !

Funkwhale : passé, présent… et avenir ?

Par Eliot Berriot billet original en anglais sur le nouveau blog de Funkwhale

Funkwhale a débuté comme un projet personnel il y a trois ans, en réponse à la fermeture de Grooveshark. À partir d’aujourd’hui, de nouvelles instances apparaissent chaque semaine, le projet prend de l’ampleur et attire des contributions extérieures. Que peut-on attendre de l’avenir du projet ?

Passé

Au début, en 2015, il n’y avait que moi, Eliot, qui travaillais sur mon temps libre sur ce « truc », en réaction à la disparition de Grooveshark. À cette époque, Funkwhale n’avait pas de logo, pas de documentation, pas de site web, l’interface utilisateur était malcommode, buguée, et le seul déploiement était… le mien. Ça fonctionnait, et c’était satisfaisant d’être indépendant des grandes plateformes de streaming, mais l’effort n’en valait vraiment pas la peine, d’autant plus que l’interface n’était pas fameuse. Cependant, en 2017 (ou était-ce 2016 ?), j’ai découvert une nouvelle super technologie, appelée VueJS, que j’ai utilisée pour reconstruire le front-end du projet, à partir de zéro. Soudain, tout est devenu à la fois plus facile et plus satisfaisant du point de vue de l’utilisateur et du développeur, et je me sentais assez confiant pour montrer le projet à des amis proches et à la famille. En utilisant leurs commentaires, j’ai pu améliorer le projet et ajouter progressivement de nouvelles fonctionnalités. La première fois que j’en ai parlé publiquement, c’était probablement ici, en juillet 2017. Mais le vrai coup d’envoi du projet a été avec ce pouet, où j’ai invité des gens sur ma propre instance pour une bêta fermée, fin février 2018.

Cela a attiré quelques dizaines de nouveaux venus, désireux d’essayer (et de casser) l’application. Là encore, leurs commentaires m’ont beaucoup aidé, et le projet doit beaucoup à leurs contributions. Dans l’ensemble, je dirais que le feedback a été très positif, et pour moi, c’était un de ces moments de la vie où l’énergie et les idées sont au rendez- vous !

De mars à aujourd’hui, les choses se sont accélérées. Beaucoup de choses : • Sean Tilley a écrit un excellent article sur le projet, attirant plus de gens. • D’autres personnes ont commencé à héberger des instances de Funkwhale. Gled, en particulier, a commencé la première instance publique : https://funkwhale.mastodon.host/ • Les contributions externes ont été ajoutées à la base de données et à la documentation par pas moins de 20 personnes. • Les gens ont commencé à donner de l’argent au projet sur Liberapay et Duniter. • J’ai ouvert un compte Mastodon dédié au projet : https://mastodon.eliotberriot.com/@funkwhale. • J’ai ouvert des canaux de discussion avec Matrix pour rassembler les membres de la communauté, discuter du développement, accueillir les nouveaux arrivants et s’amuser ensemble. • La fédération de base des bibliothèques musicales a été mise en place. • J’ai été interviewé par Narf, de Framasoft, et Guénaël Pépin, de NextINpact sur le projet. • J’ai présenté ActivityPub et l’implémentation de Funkwhale aux RMLL à Strasbourg, en juillet. • Funkwhale a été internationalisé et dechouettes contributeurs l’ont traduit dans plus de 10 langues. • Jibec a créé et maintenu un paquet YunoHost pour le projet. • J’ai passé une semaine en juillet avec d’autres développeurs, designers et contributeurs à des projets fédérés lors du « fédérathon », organisé par Nathanaël. Les utilisateurs et utilisatrices ont testé l’interface de Funkwhale, et de nombreux commentaires ont été recueillis. • Nous sommes passés de la version 0.6 à la version 0.16, avec littéralement des dizaines de corrections de bogues, de nouvelles fonctionnalités, des améliorations, etc. • Curator a lancé Open.audio, une instance ouverte pour les créateurs et créatrices qui souhaitent partager leur contenu sur Funkwhale. • Toutes les autres choses que j’ai oubliées…

Je ne dis pas ça pour être prétentieux ou en obtenir les lauriers. En fait, beaucoup de ces réalisations et jalons ont impliqué d’autres personnes que moi, et même si je suis toujours le principal développeur et contributeur du code, le projet dans son état actuel va bien au-delà de ce que je pourrais faire par moi-même. Merci donc à toutes les personnes qui ont aidé, apporté du plaisir, des idées, des commentaires, de la conception, du design, des traductions, qui ont parlé du projet et l’ont amélioré.

Funkwhale semble plus réel maintenant qu’il y a un an, et c’est grâce à vous !

Capture de l’interface de Funkwhale

Présent

Donc, nous voilà, l’été est terminé, et nous devons parler de ce qui se passera ensuite. Parce que toutes les bonnes choses qui se sont passées avaient aussi un prix et, malheureusement, les choses ne peuvent pas continuer comme ça pour toujours. En tant que responsable de projet et contributeur principal, j’ai encore beaucoup de choses à faire :

• Recueillir les commentaires • Aider les propriétaires d’utilisateurs et d’instances à résoudre les problèmes d’installation ou d’utilisation. • Maintenir la documentation à jour et l’améliorer. • Accueillir de nouvelles personnes dans la communauté et répondre aux questions sur le projet. • Répondre aux questions sur le projet, sa feuille de route, ses caractéristiques, etc. • Gérer l’outil de suivi des problèmes : répondre aux nouveaux problèmes, commentaires, les classer par ordre de priorité d’une version à l’autre. • Revoir les contributions aux codes : vérifier que les changements suggérés fonctionnent et respectent les lignes directrices, aider leur auteur à les finaliser. • Discuter des nouvelles fonctionnalités avec les utilisateurs • Implémenter de nouvelles fonctionnalités / corriger des bogues • Etc.

Comme vous l’avez probablement deviné, cela prend beaucoup de temps, et tout cela doit se faire pendant mon temps libre, puisque je travaille à plein temps. A ce stade, vous ne voulez probablement pas savoir combien de week-ends et de soirées j’ai passé à travailler sur Funkwhale Je n’insinue pas que je suis épuisé : ce n’est pas le cas. Cependant, à long terme, persister de cette façon est la voie vers le désastre. Vous avez peut-être remarqué que le développement du Funkwhale a ralenti pendant l’été, eh bien, c’est en partie à cause de cela : J’ai dû prendre du recul et profiter d’un peu de temps libre.

Maintenant, que puis-je faire à long terme ? Avenir

Aujourd’hui, je peux l’annoncer, puisque les négociations avec mon employeur sont terminées : je quitte mon emploi chez PeopleDoc pour travailler sur Funkwhale. À partir du 1er décembre, je pourrai travailler à plein temps sur le projet et lui accorder l’attention qu’il mérite.

J’aimerais remercier mon employeur et mes collègues, car ils me soutiennent beaucoup et ont accepté de me laisser partir !

Je suis très enthousiaste à l’idée de commencer ce nouveau chapitre de la vie du projet et je suis persuadé que cela m’aidera à trouver de nombreuses solutions aux défis actuels auxquels nous sommes confrontés : • rendre le projet plus accessible aux utilisateurs et aux contributeurs • simplifier les processus d’installation, de maintenance et de mise à niveau • permettre un soutien financier et non financier aux créateurs de contenu qui publient leurs travaux sur Funkwhale. • mettre en place une structure adéquate autour du Funkwhale pour recevoir les dons, payer les contributeurs (comme moi), gérer les espaces communautaires, etc. • travailler sur des fonctionnalités plus importantes Feu vert pour Funkwhale !

Merci d’avoir lu, on va faire des choses géniales ensemble !

PS : vous avez peut-être remarqué qu’il s’agit d’un nouveau blog. Nous n’allons pas arrêter de publier sur Mastodon, mais un blog est mieux adapté pour les longs messages et les annonces, et apportera aussi plus de visibilité au projet. Vous pouvez suivre ce blog en utilisant RSS / Atom, mais aussi sur la Fediverse, en suivant @[email protected], grâce au travail incroyable deBaptiste et d’autres contributeurs de Plume !

Liens utiles

Le site officiel https://funkwhale.audio/ Où trouver des instances https://join.funkwhale.audio/ Code source : https://code.eliotberriot.com/funkwhale/funkwhale Le chat du projet #funkwhale:matrix.org (https://riot.im/app/#/room/#funkwhale:matrix.org) Le compte Mastodon de Funkwhale : https://mastodon.eliotberriot.com/@funkwhale le compte Mastodon d’Eliot : https://mastodon.eliotberriot.com/@eliotberriot Soutenir financièrement : https://liberapay.com/funkwhale

Funkwhale, les baleines mélomanes libres et décentralisées

Aujourd’hui nous laissons bien volontiers les commandes à Narf, une étudiante actuellement en stage chez Framasoft. Sa mission porte sur la vulgarisation des concepts de « fédération », notamment au travers de PeerTube, mais aussi plus largement du protocole ActivityPub. Afin de découvrir cet univers (ou ce fediverse ;)), nous lui avons proposé d’interviewer des personnes travaillant ou réfléchissant autour de cette problématique.

Comme beaucoup d’entre vous, je me pose de nombreuses questions sur l’avenir d’un internet où des géants monopolisent et centralisent l’espace public sans nous demander notre avis. La construction de nos propres médias sociaux semble être une belle manière de s’émanciper, tout en chérissant notre réseau social. Celui avec lequel nous aimons partager nos pensées, des bribes de nos joies ou tristesses, des vidéos qui nous ont fait rire, réfléchir, des musiques qui nous font frissonner. L’enjeu est de taille, vous ne trouvez pas ?

Cependant, contrairement au modèle que les géants cherchent à nous imposer, il faudra que chaque personne puisse, si elle le souhaite, poser sa pierre pour construire les villages de ce nouvel univers appelé le fediverse. Pour ce faire, il ne suffit pas d’avoir une pierre à poser, il faut aussi pouvoir la tailler, savoir pourquoi et comment la poser. On sait bien ça chez Framasoft ! Lors de ces quelques mois que je vais passer dans l’asso, je vais apprendre sur les concepts de « fédération » et essayer de transmettre au maximum ce que j’aurai appris afin qu’ensemble nous rendions plus facile l’accès à cet univers !

Avec le projet Funkwhale, Eliot Berriot participe, à sa manière, à la construction du fediverse. Nous avons voulu en savoir plus sur son parcours et sur ce projet : on apprend une nouvelle fois que technique et vision de société ne vont pas aller l’un sans l’autre.

Salut Eliot, est-ce que tu pourrais te présenter brièvement ?

Alors je m’appelle Eliot, j’ai 25 ans, et je suis tombé dans le développement de façon assez tardive / inhabituelle (je pense) : à la base, j’ai fait un bac L et des études pour devenir libraire ! Au cours de mes études supérieures, j’ai commencé à faire de la programmation en python pour le plaisir (sur le site du zéro, à l’époque), et petit à petit j’ai fait des sites web pour les amis, la famille etc. À tel point qu’à un moment, j’ai fini mon cursus (en licence pro) et je me suis établi à mon compte en tant que développeur web freelance. J’ai fait ça pendant 1 an ou 2, puis j’ai rejoint une SCOP, Au Fond À Gauche, où j’ai travaillé pendant plus de deux ans en tant que développeur / chef de projet technique. Après quoi, j’ai rejoint ma boite actuelle, People Doc où je me trouve depuis Octobre 2017, toujours comme développeur.

Super intéressant ce parcours en auto-formation !

Complètement en autoformation, oui. C’est un truc qui me plaît énormément dans ce monde là : la possibilité d’apprendre a son rythme, avec les ressources disponibles.

Nous, on t’a connu grâce à ton projet Funkwhale. Est-ce que tu pourrais le présenter aux lecteurs du Framablog ?

Le concept de Funkwhale est assez similaire à Grooveshark, d’où le nom d’ailleurs. Pour ceux qui ne connaissent pas, Grooveshark était un service de streaming musical, un peu comme Deezer ou Spotify, très axé sur les interactions entre utilisateurs, le côté social. L’expérience utilisateur était vraiment bonne, avec un player web de qualité, et la possibilité d’écouter de la musique pendante des heures sans pub. Le service a été fermé il y a quelques années suite à des soucis avec les ayants-droit.

Le logo de Funkwhale

Il y a cependant des différences qui sont : le développement sous licence libre, la possibilité d’installer et de gérer son instance Funkwhale sur son serveur, en autonomie, comme avec Mastodon, par exemple. Et bien entendu, on n’est pas encore à parité fonctionnelle avec Grooveshark. Il y a certaines fonctionnalités qui étaient présentes (et aussi sur d’autres services de streaming, j’imagine), qui ne sont pas encore réimplémentées dans Funkwhale. Par exemple, les broadcast, une fonctionnalité que j’aimais beaucoup : un utilisateur peut live-streamer des musiques de son choix et ceux qui le souhaitent peuvent se connecter sur ce stream et écouter la même musique, au même moment un peu comme une radio. Ça permet de partager et de découvrir de la musique sur un mode très fun.

Effectivement, c’est sympa comme fonctionnalité, ça met plus d’interaction dans le partage. Ça fait sens si tu as envie de créer une vraie communauté autour de la musique !

Tout à fait : chaque broadcast avait aussi un chat, et les utilisateurs pouvaient suggérer des chansons à jouer ensuite, c’était très participatif. Je crois même que certaines personnes faisaient des broadcasts à temps plein et en tiraient des revenus.

Qu’est ce qui t’as motivé à faire ce projet ?

C’est le résultat d’un parcours perso assez long. En parallèle de ma découverte du développement, je me suis beaucoup intéressé aux questions d’auto-hébergement. J’essaie depuis environ 5 ans d’héberger le plus possible mes données et de ne pas me reposer sur des services tiers / fermés (pour les mails, la synchro de fichiers, etc). Quand les solutions existantes ne me satisfaisaient pas, il m’est arrivé de développer des outils perso (par exemple, mon premier gros projet web était un lecteur de flux RSS / moteur de blog). A un moment, Grooveshark que j’utilisais beaucoup a fermé, et j’ai commencé à me dire « tiens, et ça, si je l’hébergeais ? ». Malheureusement, les solutions existantes ne me satisfaisaient pas, principalement pour deux raisons : Soit je les trouvais peu agréables d’utilisation, Soit elles étaient mono-utilisateur, alors que je voulais quelque chose qui puisse permettre à des personnes de se retrouver autour de la musique, comme sur Grooveshark.

Du coup, j’ai retroussé mes manches, et j’ai commencé à travailler sur Funkwhale. Ça remonte à deux ans et demi / trois ans, à peu près. La première version était assez… pas terrible, disons-le. Mais ça marchait quand même, je pouvais importer mes artistes préférés et jouer ma musique sans dépendre de personne et sans pub, et ça, c’était cool ! Ensuite l’année dernière, j’ai entrepris une réécriture complète de l’interface (qui était ce qui posait le plus problème), pour arriver en gros sur ce que l’on a maintenant. Comme ça devenait utilisable et assez riche fonctionnellement, j’ai commencé à en parler sur Mastodon, en début d’année, et puis cela a pas mal pris

Qu’est-ce qui différencie Funkwhale d’un autre site de partage comme Soundcloud ?

N’utilisant pas Soundcloud, j’aurais un peu plus de mal à être juste je pense. Mais pour ce que j’en ai vu, Soundcloud semble s’adresser plutôt aux personnes qui créent de la musique. Grooveshark (et Funkwhale) sont plus axés « auditeur » (du moins pour le moment :D)

Mais si les utilisateurs ne sont pas, a priori, « créateurs de contenu », comment ça se passe pour les droits d’auteurs ? C’est quand même ce qui a fait fermer Grooveshark. Qui est-ce qui va gérer ça ?

Je l’attendais, celle là ! Il faut évidemment aborder ces questions, d’autant que ça peut effrayer certaines personnes ! Tout d’abord, il faut bien distinguer Funkwhale en tant que logiciel, ce qui permet de faire tourner une instance, d’une instance Funkwhale, qui est un serveur qui fait tourner le logiciel Funkwhale. C’est exactement le même principe que PeerTube. Funkwhale, en soi, c’est un logiciel qui permet d’importer de la musique et de la mettre à disposition des utilisateurs d’une instance (ou potentiellement d’autres instances, avec la fédération). Aucune musique n’est livrée avec, donc le projet en lui même est une coquille vide.

Ce sont les personnes qui gèrent une instance et qui vont mettre en ligne de la musique qui sont responsables du volet « respect de la propriété intellectuelle ». D’ailleurs, dans son mode par défaut, une instance Funkwhale et la musique qu’elle contient sont uniquement accessibles aux personnes inscrites sur l’instance (et les inscriptions sont fermées par défaut).

Du point de vue de la loi, à ma connaissance, il n’y a pas d’interdiction a mettre en ligne de la musique que l’on a achetée légalement, pour pouvoir l’écouter sur d’autres supports / machines. Ce qui est réprimé, c’est le partage hors du cercle familial amical, par exemple avec des inconnus via torrent. Héberger une instance Funkwhale pour les copains et/ou la famille me semble (mais je ne suis pas juriste) globalement dans les clous. C’est une plateforme d’hébergement de contenus donc les personnes gérant la plateforme auront à répondre des infractions s’il y en a, si leur plateforme est publique et accessible à n’importe qui.

Tu parles d’un cercle familial mais la fédération, que tu as récemment mise en place, ne rentre plus dans ce cadre, si ?

La question se pose, oui. Depuis peu, Funkwhale permet de fédérer les catalogues musicaux de différentes instances pour les rendre accessibles à d’autres instances. Pour essayer de limiter les problèmes potentiels et leurs conséquences, sur Funkwhale, la fédération se fait par défaut sur un mode très restrictif. Les catalogues musicaux des instances ne sont pas accessibles sans autorisation. Donc une instance A doit demander l’accord d’une instance B pour accéder à son catalogue. Cela permet de révoquer l’accès en cas de besoin, par exemple. D’autre part, par défaut, les fichiers musicaux ne sont pas répliqués d’une instance à l’autre (hors pour du cache sur une période assez courte). Ainsi, on pourrait imaginer avoir des grosses instances hébergeant de la musique libre partageant leurs contenus avec de petites instances possédant du contenu protégé.

Ouh là là, certains lecteurs assidus du Framablog t’ont sûrement suivi sur ce coup mais, pour les autres, pourrais-tu expliquer simplement ce qu’est la fédération ?

Alors la fédération, tel que je le conçois, c’est un mécanisme qui permet à différents intervenants sur un réseau de s’échanger des messages, de se comprendre. L’intérêt de la fédération, c’est également de réduire le développement de SPOF (single point of failure, les endroits ou si ça pête, tout pête) puisque dans un réseau fédéré, la chute d’un acteur n’affecte pas les autres acteurs outre mesure. Ainsi, si le fournisseur e-mail d’un·e de vos amis ne fonctionne plus et que vous êtes chez un autre fournisseur, vous pouvez continuer à lire vos mails, car l’e-mail fonctionne sur un mode décentralisé et fédéré.

À l’inverse, sur des services centralisés, en silos, comme YouTube ou Spotify, si le service devient indisponible ou disparaît, plus aucun utilisateur ne peut en bénéficier. C’est ce qui fait que Funkwhale ne disparaitra jamais à la manière de Grooveshark : si l’on ferme une instance, les autres continueront de fonctionner et, même si l’on fait disparaître le projet et les sources, les instances existantes continueront de fonctionner. Là encore, on est sur un concept assez proche de PeerTube, dont le fonctionnement parle probablement plus aux lecteurs et lectrices de ce blog.

Pour une personne non initiée pourrait-on simplifier en disant : une instance = Funkwhale auto-hébergé / les messages = la musique que l’on met sur Funkwhale ? À l’heure actuelle plus ou moins oui. En fait une instance va notifier ses « followers » (les instances qui ont accès à son catalogue) quand elle importe de la musique. Celles-ci, en fonction de leurs paramétrages, vont pouvoir la rendre accessible immédiatement et en temps réel dans leur catalogue. Mais à terme, la fédération ira plus loin, et inclura aussi le contenu des utilisateurs. Typiquement, si tu crées une playlist sur ton instance A et que je te follow sur mon instance B, je pourrai écouter ta playlist ou bien la partager avec mes followers. Je pourrais également envoyer un message à un·e ami·e sur une instance C pour lui conseiller d’écouter telle ou telle chanson.

Interface officielle de Funkwhale

Est-ce que tu avais développé Funkwhale en ayant déjà la fédération derrière la tête ?

En fait je voulais que les instances communiquent, mais je n’avais aucune idée du comment. Très concrètement, c’est grâce à mon année passée sur Mastodon et aux discussions que j’ai vu passer régulièrement sur ActivityPub que je me suis rendu compte que c’était faisable. Auparavant, je voyais ça comme une fonctionnalité extrêmement complexe, ça me refroidissait beaucoup. Est-ce que tu peux expliquer aux lecteurs du framablog ce qu’est ActivityPub ? À quoi ça sert, comment ça marche ?

Alors tout à l’heure je disais que la fédération, c’était le mécanisme qui permettait a des acteurs d’un réseau de s’échanger des messages. ActivityPub, qui est maintenant un standard du W3C, c’est un protocole qui permet de faire de la fédération, et qui définit notamment la structure des messages, leur contenu possible, l’endroit où il faut les envoyer, etc. Ça permet à ceux qui l’implémentent [les différents logiciels] de parler la même langue et donc de communiquer. Une des grandes forces du protocole, c’est qu’il réutilise des choses qui existaient déjà (HTTP pour l’envoi des messages, Json-LD pour la structure, Activity Streams pour les vocabulaires, c’est-à-dire le contenu des messages). Il rajoute finalement assez peu de choses ce qui permet de réutiliser plein d’outils déjà existants.

Pourquoi as-tu choisi ce protocole ?

Je l’ai choisi principalement parce que je ne suis pas hyper calé sur la question, qu’il était relativement récent, et qu’il permettait potentiellement de communiquer avec le fediverse. On peut imaginer que si un jour Mastodon ou Pleroma intègrent un player audio, un utilisateur de Funkwhale puisse recommander de la musique à un utilisateur de Mastodon, et que celui-ci pourra lire la musique en question directement dans Mastodon.

Tu dis que tu n’es pas hyper calé sur la question mais tu l’as quand même implémenté rapidement ! Quels sont tes retours pour l’instant sur la fédération des différentes instances Funkwhale ?

Les retours sont assez positifs, il y eu quelques couacs et bugs dus à des problèmes de tuyauterie, mais sinon ça fonctionne, ce qui fait plaisir. Ce qui manque principalement, à mon avis, ce sont des instances avec lesquelles fédérer mais il y en a régulièrement de nouvelles, donc le problème va disparaître avec le temps !

Tu m’as dit être émerveillé que ce projet intéresse tant de monde : on pourrait dire que le projet prend bien, alors ? Comment cela se fait d’après toi ?

Est-ce que ça prend bien ? Je dirais que oui : le chan matrix (#funkwhale:matrix.org) est assez vivant, il y a régulièrement des nouvelles idées, demandes, et des instances qui ouvrent (il doit y en avoir une petite dizaine je dirai). J’ai également quelques personnes qui contribuent sur des fonctionnalités spécifiques. J’espère arriver à réduire la difficulté d’accès pour les contributions externes, parce que le projet étant quand même assez complexe, ce n’est pas toujours évident. En ce moment je rédige beaucoup de documentation (installation, contribution, etc).

Pour moi, si le projet prend bien, c’est d’une part parce que le public auquel je me suis adressé jusqu’à maintenant (sur Mastodon) est assez sensible aux questions d’auto-hébergement, de décentralisation. C’est aussi grâce à la hype, à mon avis tout à fait justifiée, autour de PeerTube. Il y a deux mois, avant l’arrivée de la fédération dans Funkwhale, la question de la fédération était quasi systématique : « est-ce que Funkwhale peut se fédérer comme PeerTube ? ». J’ai passé beaucoup de temps sur cette fonctionnalité, parce que j’ai vu qu’il y avait une vraie demande et le fait d’y répondre en partie a contribué à susciter l’intérêt je crois

Pour les technos qui nous lisent : quels sont les conseils que tu pourrais donner à d’autres développeurs qui souhaiteraient implémenter de la fédération dans leurs logiciels ?

Aux personnes qui veulent se lancer dans de la fédération je dirai :

1. Définissez bien en amont ce que vous voulez, et commencez par quelque chose de petit, dans le doute, 2. N’ayez pas peur de demander de l’aide, car il n’y a pas encore beaucoup de ressources sur le sujet (sur Mastodon, il y a des tas de personnes prêtes à vous répondre dont moi-même).

Le 1. est important car c’est beaucoup plus dur de faire évoluer une fédération une fois qu’elle est lancée.

Quand tu conseilles de commencer par quelque chose de petit, tu parles de ce qui est fédéré ?

Je veux dire petit sur le plan fonctionnel. Par exemple, pas la peine d’essayer de ré-implementer Mastodon du premier coup. Mais peut-être juste une fonctionnalité qui permette de favoriser un toot du fediverse et de notifier son auteur que l’on a favorisé. Cela évite de se confronter à tous les problèmes d’un coup. Quand j’ai commencé sur la fédération, j’ai juste fait un bot coté Funkwhale qui pouvait recevoir des follows et répondre « pong » quand on lui envoyait le message « /ping ».

Tu as utilisé la doc de W3C ou tu considères que c’est vraiment en échangeant sur Mastodon que tu as pu avancer ?

Non, la spécification m’a énormément servi ! Le principal souci, c’est que la partie « gestion de l’authentification et des autorisations » n’est absolument pas spécifiée, donc là il a fallu aller creuser dans le code de Mastodon / PeerTube.

Est-ce que c’est important pour toi que le logiciel que tu as développé soit libre ?

C’est une question très importante pour moi. Je me suis fixé comme contrainte avec Funkwhale et depuis le début de ne bosser qu’avec des composants libres, et autant que possible, auto-hébergés. Ceci est valable tant pour la partie développement pure (le projet en lui même utilise des langages / bibliothèques libres), que pour la partie infrastructure autour du projet, qui est souvent complètement oubliée quand on pense « logiciel libre ». Ainsi, Funkwhale est développé sur mon Gitlab perso (en attendant un Gitlab dédié au projet ?), je communique dessus exclusivement sur des réseaux libres (Matrix, Mastodon…), l’intégration continue est également sur mes serveurs perso, etc. J’essaie de réfléchir, mais je ne vois pas une seule brique non-libre ou centralisée qui intervient dans le processus de développement du projet ou dans son fonctionnement au sens large.

Le principal souci que je vois avec ce montage, c’est que Funkwhale est du coup très lié à mon infrastructure d’auto- hébergement perso. Si le projet continue, il faudra mettre en place une structure administrative et des outils et moyens dédiés au projet je pense. Quant au projet lui-même, il est sous licence BSD, qui est une licence extrêmement permissive et que j’ai choisie un peu au hasard. J’avoue ne pas être très calé sur la question des licences et je suis ouvert à l’idée d’utiliser une autre licence plus adaptée au projet et à sa pérennité s’il le faut.

Pourquoi t’être donné toutes ces contraintes ?

Des raisons de placer le projet sous licence libre, j’en vois plein ! En vrac :

m’assurer que le projet puisse continuer même si j’arrête ou que je disparais,

permettre à d’autres personnes de participer et d’enrichir Funkwhale, ce dont je profiterai directement, étant utilisateur de l’outil et qui ne serait pas possible sur un modèle fermé,

rendre dans une certaine mesure une petite partie de ce que j’ai « pris » à la communauté. J’utilise Seafile, Mailcow, Firefox, Debian, et des centaines d’autres logiciels libres, chaque jour. Je ne contribue pas forcément à ces logiciels, mais si je peux enrichir ce patrimoine commun avec quelque chose qui répond à un besoin tant mieux ! cela m’a servi au cours de ma vie pro, pour montrer ce sur quoi je bosse facilement, pour que des personnes puissent lire du code que j’ai écrit

Et sur l’utilisation du libre dans le cadre du projet, je dirai que c’est par esprit de cohérence. Je me sens toujours très mal à l’aise de contribuer sur des projets libres sur Github, par exemple. Je n’ai rien contre Github en particulier, c’est une entreprise qui fournit un service de qualité, mais c’est devenu un SPOF énorme. Si Github tombe un jour, pour une raison ou une autre, le logiciel libre prendra un sacré coup ! Idem, je ne me vois pas faire un compte Twitter pour Funkwhale. Enrichir des publicitaires ? Très peu pour moi ! C’est aussi un moyen de garder le contrôle sur les moyens de production. Si je n’aime pas quelque chose dans Gitlab, je peux forker Gitlab, ou contribuer au projet pour le faire évoluer dans un sens qui me convient. Ce n’est tout simplement pas possible avec Github.

J’applique le même raisonnement pour les contributions financières. J’aurai pu ouvrir une page Patreon, par exemple, mais j’aurais été constamment tributaire de leurs décisions, de leur business-model etc. Avec Liberapay, je sais que je peux participer à l’évolution du projet, que ça ne sera pas racheté du jour au lendemain pour faire des sous.

Tout ça, ça donne de la tranquilité d’esprit, permet de travailler d’une façon plus posée, en accord avec ses principes. C’est important pour moi, même si du coup cela prend un certain temps pour mettre les pièces du puzzle en place, trouver et configurer des alternatives, etc. Mais je crois qu’il faut plus le voir comme un investissement que comme un coût. C’est une vision de la société, des interactions humaines et de ce qu’elles pourraient être. J’ai envie de participer à l’émergence de ça, une société qui soit basée sur le don, la bonne volonté, le positif en fait. Pour moi, cela passe notamment par le fait de développer Funkwhale sur ce mode, et d’utiliser Funkwhale comme levier pour mettre en valeur / utiliser d’autres projets qui fonctionnent sur ce même mode, pour créer un écosystème.

D’ailleurs, c’est développé en quel langage ?

Funkwhale est un projet découpé en deux composants : la partie API, autrement dit le back-end, qui gère les données, la musique, etc, et le front-end, qui est l’interface officielle du projet. Ce découpage complique certaines choses, mais a aussi énormément d’avantages. Premièrement, il est totalement possible d’utiliser Funkwhale avec d’autres clients (Desktop, Android, etc.), ou même avec une interface web différente de l’interface fournie avec le projet.

Quand on parle de contribuer à Funkwhale, on va donc parler généralement de contributions à l’un ou l’autre de ces composants. Le back-end est écrit en Python 3 avec Django (c’est un framework web sur lequel je suis très à l’aise et productif). Le front-end est écrit en VueJS, un framework Javascript assez simple à prendre en main mais très puissant. Et j’utilise la bilbiothèque Semantic UI pour les styles, car je la trouve très complète et jolie (c’est un peu le même principe que Bootstrap, ça fourni des composants et des outils pour obtenir une interface cohérente et fonctionnelle).

Le fait que Funkwhale soit séparé en plusieurs composants permet donc aux personnes voulant contribuer de participer sur le volet qui les intéresse. Jusqu’à maintenant, c’est la partie front qui a reçu le plus de contributions externes, avec par exemple un travail qui a été mené par Baptiste sur l’internationalisation et le design de la sidebar. Une autre personne a récemment contribué à la rédaction de la documentation pour permettre l’installation de Funkwhale avec le serveur web Apache. Je sais qu’une autre personne a également commencé à travailler sur la prise en charge du format Flac. Je demeure toujours le principal contributeur du projet, comme tu peux le voir ici. Néanmoins, j’espère que cela bougera dans les mois à venir, avec l’arrivée de nouveaux utilisateurs et utilisatrices et l’amélioration de la documentation.

Tu dis que l’auto-hébergement t’es venu par l’envie de recontrôler tes données : cette préoccupation semble traverser de plus en plus de personnes en ce moment. Cependant, installer Funkwhale sur son serveur, ça ne s’adresse pas à tout le monde, si ?

Effectivement il faut avoir un minimum de compétence et de curiosité pour installer une instance Funkwhale (ou PeerTube, ou Mastodon…). Ce n’est donc pas à la portée de tout le monde, mais cela reste malgré tout à la portée de beaucoup de personnes, je pense. D’autre part, chacun n’a pas besoin d’avoir son instance. Funkwhale étant multi-utilisateur, on peut envisager des déploiements par famille, par collectif, par CHATONS…

Enfin, une des grandes nouveautés de ces dernières années, c’est à mon avis Docker qui réduit grandement les difficultés à installer un service tel que Funkwhale. Tout le monde n’est pas forcément convaincu par cette techno, qui a aussi ses problèmes, mais la simplicité pour les déploiements est quand même un atout assez fort. Très concrètement, si tu consultes la doc d’installation de Funkwhale sur Docker, tu pourras constater qu’il suffit d’une dizaine de commandes à exécuter pour installer Funkwhale sur son serveur.

Ceci étant, oui, il y a un travail de pédagogie à faire pour rendre l’installation de ce genre de services plus simple, moins effrayante. Et aussi du boulot à faire pour intégrer ça avec les systèmes de packaging existant (Yunohost, Cloudron, etc.). D’ailleurs, un dernier mot sur l’auto-hébergement, mais un utilisateur a réussi à installer et à utiliser Funkwhale sur Raspberry Pi ! Je pense que c’est un bon indicateur du fait qu’une instance Funkwhale peut tourner sur des systèmes pas forcément hyper puissants, donc avec un coût réduit.

Est-ce qu’il existe un endroit où l’on peut être mis en relation avec des personnes qui hébergent leur instance (un peu comme joinmastodon.org ou joinpeertube.org) ?

Oui, c’est par ici.

Join Funkwhale

Comment est-ce que tu arrives à t’en sortir avec ce projet et ton boulot ?

En termes d’organisation, c’est vrai que c’est assez chronophage. En trois ans, je pense que j’ai consacré plusieurs centaines d’heures à ce projet, probablement aux alentours de 500 ou 600. Cela se fait sur mon temps libre, puisque je suis également salarié à temps plein. Fort heureusement, c’est avant tout un plaisir pour moi de faire évoluer cet outil et de l’utiliser au quotidien. C’est un travail entièrement bénévole, même si j’ai récemment ouvert une page Liberapay sur laquelle les contributeurs et contributrices du projet peuvent recevoir des dons.

À moyen terme, si je reçois suffisamment de dons via ce biais, j’envisage de réduire mon temps de travail salarié pour consacrer plus de temps au projet.

Autrement, un message à faire passer aux personnes intéressées par le projet et qui voudrait y contribuer ?

Oui : les contributions peuvent être de toutes sortes, et pas seulement financières ! Corriger une erreur typographique, remonter un bug, faire le tri dans les tickets, commenter des discussions pour apporter des compléments d’information, ce sont des contributions valables qui vont faire avancer le projet. Le code ne fait pas tout, loin de là. Le simple fait de parler du projet, comme tu le fais, ou de dire merci, c’est également une contribution qui booste le moral et la motivation, attire d’autres contributeurs, etc. Bref c’est un cercle vertueux !

Et si une personne est intéressée pour contribuer au code, je maintiens également une liste d’issues « faciles »sur le Gitlab. Ce sont des issues faciles pour une première contribution, pour découvrir le projet. Je n’ai pas spécialement d’expérience en gestion de projet libre, Funkwhale est mon premier projet avec cette ampleur, donc je découvre chaque jour, j’essaie d’améliorer ce qui peut l’être pour réduire la barrière à l’entrée pour de nouvelles personnes.

Tu me disais qu’on pourrait te retrouver aux Rencontres Mondiales du Logiciel Libre (RMLL) ?

Tout à fait ! Suite aux nombreux échanges qui ont eu lieu après l’annonce de l’arrivée de la fédération dans Funkwhale, je suis entré en contact avec Jérémie qui m’a proposé de venir présenter le travail effectué dans Funkwhale aux RMLL 2018 qui auront lieu à Strasbourg début juillet. La présentation a pour titre « Web fédéré avec ActivityPub et WebFinger » et sera une introduction au fonctionnement concret de ces deux protocoles qui permettent de construire des applications fédérées. J’en profiterai également pour faire le lien avec ce qui a été fait dans Funkwhale, partager les techniques employées, les soucis rencontrés, etc. Les modalités pratiques et la date ne sont pas encore définies mais je pense que le programme définitif sera diffusé prochainement sur le site des RMLL.

Merci pour tes réponses Eliot ! Comme de coutume, on te laisse le mot de la fin :

Tout d’abord, merci de m’avoir consacré du temps pour parler de ce projet. Cela me touche énormément, d’autant plus que je me sens assez proche de l’état d’esprit Framasoft, dont je suis les actions depuis plusieurs années: essayer de travailler avec les gens, de faire émerger autre chose, d’accompagner les personnes, plutôt que d’être en mode « Lis le fichu manuel!!!! ». Si vous souhaitez vous impliquer ou tout simplement en savoir plus, je voudrais donc vous dire ceci : n’ayez pas peur de venir discuter sur Matrix ou sur Mastodon. Je prends personnellement énormément de plaisir à accueillir les nouveaux et nouvelles venu et à répondre aux questions, techniques ou non. Et si vous souhaitez mettre la main à la pâte mais n’êtes pas sûr⋅e de savoir comment faire, on vous aidera !

Liens utiles

Le site officiel https://funkwhale.audio/ Où trouver des instances https://join.funkwhale.audio/ Code source : https://code.eliotberriot.com/funkwhale/funkwhale Le chat du projet #funkwhale:matrix.org (https://riot.im/app/#/room/#funkwhale:matrix.org) Le compte Mastodon de Funkwhale : https://mastodon.eliotberriot.com/@funkwhale le compte Mastodon d’Eliot : https://mastodon.eliotberriot.com/@eliotberriot Soutenir financièrement : https://liberapay.com/funkwhale

Comment réparer les médias sociaux (et faire encore mieux)

Le récent scandale Cambridge Analytica semble avoir brièvement remis au goût du jour la question du siphonnage de données par les médias sociaux. Il est bon de se rappeler que la collecte de données n’est pas une simple pratique de Facebook, mais bien leur modèle économique : que cette entreprise – parmi les plus cotées en bourse au monde – n’existe qu’en se nourrissant de nos Likes, photos et autres interactions sociales.

Vol de données privées, manipulation de masse, matraquage publicitaire, exploitation de nos faiblesses psychologiques, … il y a beaucoup à dire sur les pratiques néfastes des médias sociaux centralisés. Mais aujourd’hui tournons-nous vers une solution et découvrons ensemble un moyen de lutter contre ces derniers avec des alternatives plus éthiques. Non, mieux : une fédération d’alternatives plus éthiques.

Nos ancêtres les Gaulois ?

L’an dernier, nous annoncions vouloir tourner la page de Dégooglisons Internet, avec laquelle se tourne aussi la métaphore des camps gaulois libres qui luttent contre l’invasion romaine propriétaire.

Ce que nous avons omis de préciser, c’est que n’en déplaise à Goscinny, l’histoire ne s’est pas réellement passée comme nous avons l’habitude de la lire dans ses albums. Ce que nous appelons les gaulois est en réalité un terme un peu générique inventé par les romains pour désigner les nombreux petits peuples qui vivaient en Gaule.

Même s’il pouvait y avoir quelques alliances entre plusieurs peuples, en aucun cas tous ces villages gaulois étaient unis pour former un seul grand peuple gaulois. Ces derniers étaient bien indépendants : ils se faisaient beaucoup la guerre entre eux et parlaient leurs propres patois locaux.

Maintenant imaginez que vous êtes un peuple gaulois vivant à cette époque : vous voyez débarquer la grande armée romaine, qui envahit un à un d’autres villages gaulois. Bon, vous n’avez pas spécialement beaucoup d’affinités, mais on peut quand même vous trouver une petite larme à l’œil, ne serait-ce que parce que les Romains ne respectent pas vos principes.

Comment faire, donc, pour que ces braves Gaulois continuent paisiblement leurs bagarres de poissonniers et leurs concours de moustache ? Peut-être essayer d’améliorer l’entente entre ces différents peuples. Hmm, mais ce n’est pas si évident, les peuples gaulois parlent chacun leur propre patois, la barrière de la langue pose rapidement un gros frein à tout arrangement.

Les libristes, ces grands relous

Vous l’aurez compris, les logiciels libres sont comparables à un ensemble de villages gaulois : bien sûr, beaucoup souhaitent lutter contre l’invasion de Google, Apple et autres GAFAM, mais ils veulent toutefois garder une certaine indépendance : il n’y a qu’à regarderle nombre de distributions Linux pour se rendre compte de la diversité qu’apporte la possibilité de modifier à loisir un système.

On pourrait penser que c’est bien dommage, que tous ces libristes feraient mieux d’unir leurs forces pour lutter ensemble contre leurs ennemis communs au lieu de se diviser ainsi. Mais ce serait mettre fin à ce qui motive justement cette soif de créer des projets libres : la possibilité de pouvoir les modifier et les partager librement.

Au contraire, on se contente d’être fiers de voir autant de diversité dans les logiciels libres, comme on peut aujourd’hui être amusé à l’idée de savoir que nous sommes les descendants d’une grande diversité de peuples de la Gaule et non pas d’un seul grand peuple gaulois.

L’effet de réseau

En somme, le meilleur moyen de lutter contre la centralisation d’Internet dans d’immenses silos à données que sont les GAFAM, serait de faire des silos plus petits. On a en tête le projet Chatons : ce collectif d’hébergeurs indépendants, qui proposent des services – les mêmes qu’on trouve chez Framasoft, pour la plupart – alternatifs à ceux fournis gracieusement par Google et consorts (dans ce dernier cas, c’est en échange de quelques informations personnelles et d’un peu de temps de cerveau disponible, hein, rien de méchant).

Pour certains logiciels comme Framadate ou Framapad, qui remplacent rapidement leurs équivalents propriétaires, c’est plutôt facile : on peut même choisir encore autresd’ alternatives selon nos préférences. C’est surtout de nouvelles habitudes à prendre, mais rien de vraiment bloquant.

En revanche, pour les logiciels qui permettent aux gens de communiquer ensemble, notamment les médias sociaux (qu’on appelle à tort les réseaux sociaux – parce que oui, le réseau, c’est vos amis ), c’est plus compliqué.

Par exemple il est bien difficile de remplacer Facebook par son équivalent libre, car la plupart des gens sont sur Facebook : il faudra donc les convaincre de franchir le pas, ce qu’ils hésiteront à faire car… il n’y a pas assez de monde, et qu’il faudrait aussi convaincre les amis de vos amis et ainsi de suite. Ah, et avant que vous ne posiez la question : oui, c’est compliqué de dire à 2 milliards d’utilisateurs : « allez à trois on s’en va tous pour aller sur telle autre plateforme, vous êtes prêts ? ».

Ce problème s’appelle l’effet de réseau. C’est le principal problème des alternatives libres aux sites impliquant des interactions sociales et il n’est pas spécifique aux médias sociaux : par exemple le projet Covoiturage Libre, malgré ses valeurs éthiques, peine à se développer face au monopôle de son équivalent propriétaire.

Dans le monde du libre, l’effet de réseau est empiré par le fait qu’il y a souvent plusieurs alternatives et que, comme nous l’avons vu, les logiciels libres sont des villages gaulois : un peu divisés, ils aiment leur indépendance et leurs spécificités.

Cela ne facilite pas la tâche à un éventuel romain qui voudrait tout plaquer pour élever des chèvres en Gaule : quel village choisir ?

Et si on parlait la même langue, ça n’irait pas mieux ?

La communication est la clé d’une bonne entente entre peuples : une solution pour assurer la pérennité de nos villages gaulois serait de les aider à mieux communiquer entre eux. Autrement dit, de se mettre d’accord sur une langue qui serait comprise par tous les peuples gaulois, une sorte d’Espéranto visant à améliorer la communication. Ce qui bien sur, ne les empêche pas de parler leur patois quand ils sont entre eux.

Le fait de définir un langage commun permet donc aux petits villages d’échanger ensemble tout en gardant leur indépendance. Ils deviennent une sorte de fédération de peuples indépendants : ils ont chacun leurs us et coutumes, mais se comprennent bien, ce qui par exemple peut faire avancer le commerce et créer une sorte de synergie gauloise qui les rend d’une certaine manière plus unis pour repousser l’invasion romaine.

Bon, on ne va pas vous mentir, l’idée d’une langue fédératrice pour les médias sociaux ne date pas d’hier. Il y en avait déjà plusieurs depuis de nombreuses années, on peut donc relativiser sur le fait qu’une nouvelle venue arrive pour tout arranger.

Un langage pour les fédérer tous …

Le nouvel Espéranto des logiciels libres se nomme ActivityPub : c’est une nouvelle langue pour mettre d’accord les médias sociaux alternatifs. La très bonne nouvelle c’est qu’il y a quelques mois, ActivityPub a été validé par leW3C . Le W3C, c’est l’équivalent de l’Académie Française pour le web : à l’instar de celle-ci, dont le but est d’uniformiser la langue de Molière en établissant certaines normes, le W3C valide quels sont les mots que les langages d’Internet devraient utiliser.

Rien ne nous oblige bien sûr à respecter cette convention si l’on préfère notre patois local, mais le fait de valider un langage permet aux villages – notamment les nouveaux venus – de moins se poser de questions sur le choix de la langue à utiliser pour se comprendre.

Par exemple, le logiciel Mastodon est une alternative à Twitter basée sur ActivityPub. Comme nous aimons décentraliser Internet, il y a plusieurs villages Mastodon un peu partout, qui communiquent entre eux. L’utilisateur du village Framapiaf peut échanger avec son cousin vivant dans le village Mamot, sans que ce dernier ne s’aperçoive qu’il est en train de parler à un lointain voisin.

… et dans les internets les lier.

Là où cela devient intéressant, c’est que Mastodon est un logiciel libre et donc que chaque village Mastodon peut l’adapter à ses besoins :

– chaque village a son propre jeu d’emojis personnalisés ; – le village Framapiaf a donné un coup de peinture sur l’interface ; – d’autres villages ont fait leur petite cuisine interne en repoussant par exemple la limite des 500 caractères par message, car ils la trouvaient trop contraignante. Aucun problème : quelles que soient ces personnalisations, tout le monde continuera de communiquer à travers les villages, car ils parlent toujours la même langue, ActivityPub.

Le fait d’utiliser un média social basé sur le principe de fédération vous rend libre. Si le village Mastodon sur lequel vous vous trouvez change un jour ses conditions d’utilisation, vous être libre de déménager dans un autre village qui vous correspond mieux.

Mieux : si un jour le logiciel Mastodon ne respecte plus du tout les utilisateurs, il y a fort à parier que des défenseurs du libre reprendront le logiciel et en feront une autre version (cela s’appelle un fork) et que petit à petit, les villages migrent vers cette nouvelle version plus respectueuse, sans que les utilisateurs soient fortement impactés. Cela nous permet de revenir aux valeurs essentielles du libre : c’est l’utilisateur qui a contrôle sur le logiciel, et non l’inverse.

D’ailleurs, quelqu’un pourrait se dire un jour que l’interface de Mastodon est trop compliquée et décide d’en faire une totalement différente, plus proche de celle de Twitter. Ce n’est pas grave. Il n’y a pas tout à refaire, toute une base d’utilisateurs à reprendre. C’est juste des villages un peu différents qui apparaissent et avec qui on continuera de communiquer. Cela peut même faciliter l’adoption d’ActivityPub par le grand public : si une personne n’aime pas Mastodon, on peut lui présenter un tout autre logiciel qui lui convient mieux et permettra de communiquer avec les mêmes personnes.

Là où cela devient très, très intéressant, c’est qu’en fait les villages peuvent être complètement différents et avoir leurs propres spécialités. Revenons à nos Gaulois : on peut supposer que les villages proches des côtes vivent de la pêche et fassent du commerce de poisson entre eux, tandis que ceux vivant dans les montagnes soient davantage occupés par l’élevage de chèvres et le commerce de fromages.

Notre Espéranto permet à notre village de pêcheurs de Bordeaux de se fédérer à un village savoyard pour récupérer du Beaufort en échange de poissons, pour le transmettre à d’autres pêcheurs Bretons, tandis qu’ils profitent du vin venant d’un autre village voisin.

De la même manière, Mastodon peut communiquer avec d’autres logiciels fédérés mais complètement différents : par exemple FramaTube, l’alternative à Youtube. Il vous est alors possible d’être notifié des nouvelles vidéos qui sortiront sur cette plateforme et même de répondre aux commentaires d’une vidéo depuis Mastodon et inversement. Idem si vous mettez une vidéo en favori sur Mastodon, cela apparaîtra sur PeerTube (vous pouvez retrouver cet exemple sur cette démonstration).

La genèse d’une diversité numérique

ActivityPub va probablement faire beaucoup de bien à Internet. De nombreuses alternatives fédérées vont sortir prochainement. En tendant un peu l’oreille, on peut déjà entendre parler de blogs fédérés ou d’alternatives à Instagram ou Deezer, basées sur ActivityPub.

Cela va amener un peu de diversité dans notre paysage numérique : diversité qui ne peut pas, par essence, se retrouver dans les services centralisés, car ces derniers parlent leurs propres langues. Vous ne pourrez jamais lire et partager des Tweets depuis Facebook, ou bien répondre à un commentaire Youtube depuis Instagram. Avec la fédération, cela devient possible et cela donne à ActivityPub un avantage compétitif face aux médias sociaux propriétaires.

Ce qui est bien, c’est que cela ne concerne pas seulement les personnes soucieuses de l’usage qui est fait de leurs données personnelles : les moldus du libre pourront trouver en ActivityPub un outil avant tout pratique. Les technophiles apprécieront la possibilité d’interconnecter toutes leurs plateformes numériques entre elles. Ceux qui trouvent que leurs médias sociaux sont monotones aimeront amener un peu de diversité à leurs fils d’actualité. Les blogueurs trouveraient intéressant le fait de permettre à leurs lecteurs de recevoir et commenter un article très facilement via leurs média social favoris. C’est également le cas du côté des développeurs d’application, qui trouveront en ActivityPub un moyen d’atteindre très rapidement un grand nombre d’utilisateurs. En effet la fédération est un formidable terrain d’expérimentation : si quelqu’un a une bonne idée, il peut la développer en la connectant à la fédération.

Supposons par exemple que vous vous lanciez dans le développement d’un site de partage de recettes de cuisine fédéré. Vous en parlez à vos amis, dont certains sont déjà sur Mastodon. Comme tous aiment bien l’idée, ils s’abonnent à votre site depuis Mastodon pour être notifiés de vos meilleures recettes. Lorsqu’ils recevront votre dernier clafoutis aux fraises, ils pourront le partager directement à tous leurs abonnés, lesquels seront intrigués par ce nouveau village récemment apparu dans la fédération, et pourront s’abonner à leur tour. En utilisant ActivityPub, nous participons à cette prise de conscience globale dans laquelle nous découvrons tous le point faible de ces silos à données : étant centralisés, ils sont vulnérables face à la fédération. Si nous arrivons à promouvoir suffisamment ces alternatives au grand public, nous pouvons amener ces plateformes centralisées à se confronter à un combat qui leur est perdu d’avance.

En utilisant ActivityPub, vous faites un pied-de-nez à tous ces soi-disant réseaux sociaux proclamant vouloir réunir les gens… mais dans un système cloisonné. Vous les laissez au profit d’alternatives qui ont pu voir le jour parce qu’elles ont réussi, elles, à se réunir, à se fédérer les unes aux autres.

Pour résumer

1. ActivityPub est un Espéranto qui permet aux médias sociaux alternatifs de se comprendre entre eux (se fédérer) ; 2. cela permet à deux utilisateurs de se suivre l’un et l’autre, même s’ils habitent dans des villages différents (qu’on appelle instances) ; 3. ça fonctionne bien même s’ils sont totalement différents : le village de pêcheurs peut échanger avec le village de fromagers (comme si depuis Facebook on pouvait liker un tweet) ; 4. tous ces échanges entre villages s’appellent la fédération et de nouveaux logiciels peuvent la rejoindre n’importe quand (et ça va être très cool).

Envie d’essayer maintenant ?

Vous voulez être les pionniers de cette nouvelle ère numérique qu’est la fédération ? Libre à vous de choisir votre village. Pour commencer, nous vous conseillons ceux sous la bannière Mastodon (qui a fêté son 1er anniversaire il y a quelques mois), car le logiciel est bien abouti.

Vous trouverez sur le site Join Mastodon d’autres explications sur son fonctionnement, ainsi que la liste des villages disponibles (et nous laissons bien sûr la porte denotre propre village ouverte aux nouveaux venus).

Crédits images :

Image d’entête : Are you lost in the world like me ? – Steeve Cuts How standards proliferate ? : XKCD – Randall Monroe Vous allez vous fédérer les uns les autres ? : Jesus II Le Retour – Les inconnus les autres : Wikipédia et sites officiels.