Fédérer l'informatique décentralisée

Dans le cadre de notre évènement de lancement de notre projet européen NGI Pointer, nous avons eu l’occasion d’échanger sur de nombreux points avec Drave Développement. Drave Développement se définit comme :

Un organisme à but non lucratif (OBNL) rassemblant une communauté d’individus mobilisée pour répondre aux besoins numériques du Québec, par la promotion des données ouvertes et du logiciel libre afin d’atteindre la souveraineté numérique.

Ce compte-rendu a pour objectif de retracer le plus fidèlement possible nos échanges. Étaient présents de Drave Développement Ricky, François et Mathieu et de Deuxfleurs Quentin, Alex, Jill, Éric, Maximilien, Vincent et Adrien.

~

Le Fediverse est la plateforme formée par des communautés indépendantes qui choisissent de s’interconnecter. C’est à travers cet idéal commun que Drave Développement et Deuxfleurs ont été amenées à échanger et collaborer pour créer des communautés souveraines et autonomes puis les interconnecter.

Construire des communautés résilientes

Un enjeu majeur pour une structure comme Deuxfleurs est de pouvoir assurer la disponibilité de ses services et l’intégrité de ses données dans le temps, y compris lors de l’évolution du nombre de ses usager-es. Pour Deuxfleurs, ce problème de disponibilité et d’intégrité est notre premier chantier. Nous en discutons plus longuement dans notre billet Traversée en dehors des clouds.

Pour limiter nos développements et la réécriture de logiciels, nous tentons d’intégrer nos solutions dans des écosystèmes logiciels existants. Il nous est vite apparu que les fournisseurs d’infonuagique comme Amazon, Google, Microsoft, etc. ont également eu à résoudre ce même problème et que nous pouvions bénéficier de la part open-source voire libre de l’écosystème qu’ils ont participé à créer.

Il y a un an et demi, nous avons identifié que l’élément le plus critique de notre infrastructure était notre solution de stockage d’objets (le système qui stocke les photos, vidéos, audio, documents de bureautique, etc. de nos usagères et usagers). Avant de se lancer dans le développement d’un nouveau logiciel, nous avons étudié différentes alternatives possibles, comme Ceph. Nous n’avons pas retenu ces solutions, car pour beaucoup elles supposent que les échanges réseaux sont rapides pour utiliser des algorithmes comme Raft, et donc confine le déploiement de ces solutions à un seul centre de données.

En réponse, nous avons développé Garage qui implémente l’API S3 REST initialement conçue par Amazon, et étant un standard de fait dans l’industrie. De ce fait, Garage est déjà compatible avec de nombreux services comme Matrix, Mastodon, Nextcloud ou Peertube.

Un standard “de fait” a tout de même quelques limites car il est basé sur un consensus vague entre les différents partis qui l’implémentent. À ce sujet, il est noté plusieurs points : que la gestion des ACL (liste de contrôle d’accès) est en évolution rapide chez Amazon mais les autres aspects sont plus stables, que le protocole évolue à travers les années mais qu’Amazon ne peut pas non plus décider de casser la compatibilité. Nous concluons que notre objectif est de supporter un sous-ensemble stable et commun de l’API S3 sans viser une compatibilité parfaite avec Amazon mais de supporter au mieux les logiciels libres utilisant ces API.

Pour favoriser l’adoption de Garage, Drave nous recommande de documenter et/ou d’écrire la “colle” pour l’intégrer avec d’autres logiciels à l’image de ce que fait IPFS avec d’autres projets.

Nous notons aussi que beaucoup de logiciels ont besoin, en plus d’une solution de stockage d’objet, d’une base de données, qui pour l’instant n’est pas distribuée chez nous. Nous échangeons sur les différentes solutions existantes : PostgreSQL Citus, CorckroachDB, YugabyteDB, PrestoDB, Megastore, etc. Nous faisons remarquer aussi que l’architecture de Garage est très proche de Cassandra.

Nous aurons probablement un compromis à réaliser : distribuer PostgreSQL est compliqué à cause de son architecture mais est compatible avec un très grand nombre d’applications, alors qu’un système à la Cassandra (et DynamoDB dont elle est inspirée) est beaucoup plus facile à distribuer mais implique d’adapter les logiciels existants.

Interconnecter les communautés entre elles

Si Deuxfleurs se focalise sur la construction de communautés résilientes, Drave et ses partenaires se focalisent aussi sur les questions d’interconnexion des communautés.

Un certains nombre d’entre eux sont simplement des “protocoles” qui spécifient comment les communautés doivent communiquer entre elles mais ne précisent pas comment, en interne, la communauté doit gérer son service. Dans cette catégorie, on peut citer Solid soutenu par Tim Berners Lee, inventeur du web, Activity Pub, Matrix ou même SMTP.

Parce que le plus populaire de ces protocoles est SMTP, Deuxfleurs souhaite investir de l’énergie dans la construction d’un service email performant et libre. Bien que souvent perçu comme vieux et dépassé, certains initiatives comme le protocole JMAP et le client LTT.RS récentes permettent d’améliorer l’expérience utilisateur-ice. Drave nous fait remarquer qu’il est très complexe de proposer de l’email, que ce soit sur les questions de livraison ou de convaincre les usager-es de changer leurs habitudes et qu’il y a probablement des cibles plus faciles.

Matrix et Activity Pub qui sont des protocoles plus récents, et qui ont donc des logiciels plus récents, peuvent s’intégrer d’ores et déjà avec Garage, à l’image de (Mastodon, Peertube, etc.). Ce sont, pour Deuxfleurs, probablement les cibles les plus faciles.

Enfin, le protocole Solid, très récent, ne propose que quelques implémentations libres. Si elles ne s’intègrent pas encore avec notre logiciel, il est tout à fait envisageable de créer une interface entre Garage et une partie du protocole Solid. En effet, Solid est un protocole qui dépasse la gestion de fichier, car il propose aussi aussi un système d’authentification ou encore un mécanisme de publication (pubsub). Ces parties dépassent le périmètre de Garage, mais nous pourrions alors considérer interfacer nos autres composants, comme Bottin pour la partie authentification.

Toutes les solutions d’interconnexions de communauté ne sont pas simplement des protocoles, mais parfois des solutions complètes, à l’image des projets d’authentification souveraine (Self-Sovereign Identity) Hyperledger Indy, de stockage de fichier IPFS ou de la solution de visioconférence Jami (précédemment Ring). Pour ces systèmes, il faudra une réflexion plus profonde pour savoir si et comment il serait possible de les interfacer avec nos projets d’infrastructures.

Créer un contexte favorable à l’émergence de l’informatique décentralisée

En comparant nos expériences, nous notons aussi qu’en fonction des offres Internet proposées, les fournisseurs d’accès à Internet façonnent notre rapport à Internet, rendant l’auto-hébergement compliqué dans certains cas (par exemple en ADSL, co-axial, ou en présence d’un Carrier Grade NAT).

Chez Deuxfleurs, nous avions commencé à référencer les différents points de blocage pour créer notre réseau décentralisé, avec des exemples : congestion sur la distribution ou les interconnexions (peering), adressage (ipv4 publique, support d’ipv6, dynamique ou statique), ports bloqués, fonctionnalités des routeurs fournis et possibilité d’en changer, etc.  Nous avons mis en perspective nos expériences des deux côtés de l’Atlantique et identifié les pratiques opérées par les fournisseurs.

Nous notons que l’accès internet via ADSL ou coaxial, pour des raisons techniques, doit partager sa capacité entre émission et réception. Nous constatons que les opérateurs font toujours le choix de favoriser la réception sur l’émission car elle serait plus adaptée à nos usages. Reste à savoir si ce ne sont pas nos usages qui se sont adaptés à cet état de fait…

Sur une note positive, nous observons que les limites d’envois n’ont pas été reportées sur la fibre optique, moyen technique qui a permis à notre hébergeur de voir le jour. Nous notons aussi que nombre de ces fonctionnalités ont été rendues possibles suite à des batailles juridiques sur la régulation des télécoms en France. Pour continuer sur le sujet, je recommande ces documentaires de FFDN sur Pourquoi s’intéresser à la régulation des télécom. Nous n’oublions pas non plus que chaque territoire à ses propres caractéristiques, et que par exemple la densité de population est bien plus importante en France qu’au Canada, ce qui explique des différences également dans la gestion et le prix des télécoms.

Nous n’avons pas défini d’objectifs particuliers sur ce point, mais il serait possible de retravailler notre liste de critère, la rendre plus exhaustive et l’élargir avec les informations du Canada.

Penser aux usagères et usagers

Notre réunion était orientée sur la technique mais il a été rappelé que le but final était de fournir des services adaptés à un grand nombre d’usagères et usagers, et qu’il fallait penser également en fonction du besoin. Sur ces questions, Drave travaille actuellement avec des spécialistes du Living Lab en Innovation Ouverte (LLio) sur les questions d’expérience utilisateur.

Lors de notre discussion sur internet, il a également été soulevé que 8% de la population au Québec accède encore à internet via une connexion bas-debit (56kbit/s). En France, la situation est à peine meilleure : en 2019, 10% de la population accédait à Internet à travers une connexion de 3Mbit/s ou moins. Il nous parait important d’intégrer cette dimension dans nos choix de développement.

François, qui est formateur sur le déploiement et l’utilisation de logiciels libres, nous précise le cadre dans lequel Nextcloud est souvent déployé. Il vise beaucoup de petites structures qui peuvent se contenter de louer une machine virtuelle pour leurs besoins. Pour la question de la disponibilité et de l’intégrité de ces données, Nextcloud étant utilisé comme outil de synchronisation, une copie des fichiers est également conservée sur l’ordinateur de chaque collaborateur-ice. En conclusion, Garage ne semble pas apporter une plus value importante dans ce cas d’usage.

Pour le cas de Peertube, les cas d’usages sont différents : les vidéos prennent rapidement beaucoup de place, et en plus nécessitent beaucoup de bande passante pour être partagées. Garage pourrait alors répondre à ce besoin en répartissant la charge sur les différents noeuds de son cluster. Il a été noté que, bien que Peertube propose WebTorrent (et HLS+p2p) pour réduire la consommation de bande passante du serveur, il pouvait être tout de même nécessaire d’avoir beaucoup de bande passante.

Les initiatives québécoises

Depuis longtemps, des organisations comme FACiL et LinuQ oeuvrent au Québec depuis longtemps à l’adoption, l’usage et la démocratisation de l’informatique libre. À ces organisations ce joignent plus récent Drave Développement, une organisation qui s’est donné pour but de bâtir un écosystème du libre prospère et pérenne.

Plusieurs projets en cours pourront servir de pont pour les initiatives du décentralisé du côté du Québec. D’abord, l’initiative du Projet Collectif dont l’assemblée de fondation de l’organisme sans but lucratif a eu lieu le 28 Septembre, elle se veut une initiative fédératrice pour fournir des outils informatique à des communautés. Drave Développement est membre organisationnel et encourage l’utilisation de logiciels libre pour sa réalisation.

Des communautés physiques comme «La Console interface humaine» héberge des organisations comme Drave Développement. Ces cantines numériques pourront faire avancer la maîtriser des technologies de l’informatique distribuée au service des communautés locales.

Les actions que nous souhaitons mettre en place

À la suite de nos échanges, nous avons défini trois axes pour prolonger cette réunion :

• Nous allons entrer en contact prochainement avec François pour tester ensemble Nextcloud et Peertube avec Garage

• Nous allons mettre en place des listes de diffusion et créer un canal de communication pour resserer les échanges entre Drave et Deuxfleurs

• Nous allons co-organiser les “Rencontres de l’Infonuagique Décentralisé Francophone” une fois par mois pour générer des connexions, des collaborations et des discusssions sur ce sujet.

• Inviter d’autres organisations à co-développer et à faire avancer l’infonuage décentralisé

La photo de la bannière est sous licence CC-BY-SA 3.0 et a été prise par Claude Bouchet. Elle a été d’abord envoyée sur Wikimedia. Le monument en photo est l’Homme-rivière qui rend hommage aux draveurs. Il est situé entre le 67 et le 71, rue Sainte-Anne, à côté de l’Édifice Price, dans le Vieux-Québec. Inauguré en 2002, le monument est une oeuvre de Catherine Sylvain et Lucienne Payan-Cornet.