Résumé
Depuis cet été, grâce à une subvention de NLnet obtenue dans le cadre du programme NGI0 Entrust Fund, nous travaillons sur la version 2.0 d’ActivityPods, avec une sortie prévue au printemps 2024. Cet article a pour objectif d’expliquer ce travail de fond et ses enjeux.
Billet
En préambule, il nous semble important de préciser que, lors du développement de la première version d’ActivityPods, nous avons dû faire des choix que nous savions ne pas être “scalables” ou sécurisés. Mais notre volonté à ce moment était de sortir des applications fonctionnelles dans un temps relativement court. La v1 a en effet été développée bénévolement fin 2021 sur une durée de 3 mois, et nos finances ne nous permettaient pas, à ce moment, d’en faire plus.
Cette stratégie fut un succès: sur la région de Compiègne, les applications Bienvenue chez moi et L’Entraide sont aujourd’hui utilisées par une communauté d’environ 500 personnes, qui ont chacune un Pod – parfois sans le savoir ! Depuis 2 ans, les performances ont toujours été bonnes, il n’y a eu que quelques bugs, et surtout cela a permis de tester l’architecture avec un cas concret.
Néanmoins il reste quelques problèmes fondamentaux qu’il est important de régler, comme nous allons le voir maintenant.
Des applications externalisées
Dans la v1, les applications ActivityPods sont uniquement frontend, et elles comptent sur du code backend se trouvant dans l’hébergeur de Pods (donc dans le dépôt principal d’ActivityPods) pour gérer correctement certains “effets secondaires” qui ne peuvent être gérés par le frontend.
Par exemple, lorsqu’un événement sur Bienvenue chez moi atteint le nombre de participants maximum, il est marqué comme “fermé” et les invités ne peuvent plus s’inscrire. Autre cas de figure: pour une application Open Badges que nous avons développée dans le cadre du projet ActivityBadges, la génération d’Open Badges ne peut se faire que côté backend. Pour le moment, c’est donc à l’hébergeur de Pod de gérer ça.
Cette solution n’est clairement pas scalable puisque, si une nouvelle application est déployée (ou mise à jour), il faut impérativement que tous les hébergeurs de Pods mettent à jour ActivityPods. Cela implique une coordination et une confiance qui est possible sur un petit terrain d’expérimentation, mais inenvisageable à plus grande échelle.
Dans la v2, les applications auront toutes une partie backend où se trouvera le code qui leur est spécifique. Cette partie backend comprendra a minima un acteur ActivityPub pour l’application, qui pourra ainsi communiquer avec les Pods (également acteurs ActivityPub).
Nous allons utiliser une partie de la spec interopérabilité de Solid pour permettre aux applications de s’enregistrer auprès du Pod et déclarer leurs besoins d’accès. Pour le moment, l’enregistrement passera par ActivityPub car c’est le plus simple avec notre architecture actuelle. Nous attendons que cette spec soit terminée pour nous y conformer entièrement.
La partie backend aura la possibilité d’écouter ce qui se passe sur le Pod et d’y réagir. En passant par les notifications Solid et des canaux websocket, elle pourra écouter l’inbox et l’outbox ActivityPub de l’utilisateur. Lorsque l’utilisateur créera ou mettra à jour une donnée sur son Pod, cela sera indiqué dans le flux d’activité de son outbox afin de faciliter cette écoute.
Finalement, la partie backend pourra envoyer des notifications à l’utilisateur, en réaction à certaines activités (p.ex. la réception d’une invitation à un événement). Cette notification sera simplement une Note envoyée via ActivityPub à l’utilisateur, qui pourra être transformée en un email ou une notification web push.
Des containers et collections plus flexibles
Dans la v1, les containers LDP contenant les ressources ne pouvaient pas être créés par les applications ou les utilisateurs: il fallait que l’hébergeur de Pods déclare les containers. C’est un problème similaire au précédent, qui était dû à l’architecture trop rigide de SemApps, la boîte à outils sémantique sur laquelle s’appuie ActivityPods.
Le problème a été fixé cet automne côté SemApps, qui est maintenant capable de détecter les containers à la volée selon les données présentes dans le triple store. Cela va permettre une gestion plus flexible des containers LDP, qui pourront être créés dynamiquement selon les besoins.
Ce qui est prévu pour le moment, c’est que les applications déclareront, lors de leur enregistrement, le type de ressources qu’elles souhaitent utiliser (en lecture et/ou en écriture). Cela créera automatiquement un container correspondant, si le container n’existe pas déjà, et les permissions adéquates seront données aux applications concernées. L’utilisateur devra donner son consentement via un écran dédié.
L'écran d'autorisation dans ActivityPods 2.0
Concernant les collections ActivityStreams, très utilisées par ActivityPub et que nous trouvons très pratiques pour indexer des données, le problème est similaire: dans la v1, les applications peuvent déclarer des collections “custom” qui vont s’attacher automatiquement à certains type de ressources, mais la déclaration se fait dans l’hébergeur de Pod grâce à un service interne.
La solution envisagée pour le moment est de développer une API permettant aux applications (désormais externes) de créer elles-mêmes des collections et d’y ajouter ou enlever des éléments. Cette API n’existe pas dans la spécification ActivityPub, mais il y a des propositions qui vont dans ce sens et nous avons l’intention d’y contribuer.
Des token spécifiques et une authentification plus sécurisée
Le dernier gros point noir de la v1 concerne la sécurité. Chaque token émis actuellement donne accès à l’ensemble des données de l’utilisateur, en lecture et écriture. Si une application malicieuse (ou un hacker) récupère ce token, elle peut prendre le contrôle du Pod de l’utilisateur, et potentiellement tout y effacer.
Nous n’étions également pas satisfaits de la manière non-standard et peu sécurisée dont on gérait l’authentification. Les token JWT que nous générions fonctionnaient bien dans une architecture simple de type backend-frontend, mais la sécurité pour une architecture multi-applications était insuffisante.
Cet automne, nous avons donc pris le temps d’étudier les standards OAuth 2.0 et OIDC, notamment grâce à un excellent cours en ligne. Cela nous a permis de mieux comprendre la spécification Solid-OIDC, que nous avions ignorée jusqu’à maintenant faute de temps-cerveau disponible.
Une petite partie de Solid-OIDC …
Il manque encore l’utilisation du protocole DPoP pour la requête de données. En attendant, nous utilisons l’ID token retourné par le serveur. C’est une mauvaise pratique mais l’intérêt est qu’il contient l’identifiant de l’utilisateur ET de l’application, ce qui permet de limiter l’accès aux données que l’application a le droit de manipuler (pour requêter des resources sur un serveurs distants, il faut toujours passer par un endpoint proxy).
Si le temps et les moyens le permettent, nous finaliserons l’implémentation de Solid-OIDC pour la sortie de la v2, ce qui permettrait à n’importe quelle application Solid de se connecter sur les Pods ActivityPods. L’autre avantage est que les composants frontend de SemApps deviendraient ainsi compatibles Solid, ouvrant leur usage à toute sa communauté !
Le bonus: Mastopod
L’équipe de NLnet a accepté d’inclure dans le financement un développement que nous souhaitons faire depuis longtemps: une application compatible avec toutes les instances Mastodon, mais qui aura la particularité d’héberger les données sur un Pod. Cette application a un nom tout trouvé: Mastopod.
Un Mastopod, d’après l’AI générative
Nous pensons que Mastopod suscitera beaucoup d’intérêt au sein de la communauté ActivityPub. Les développeurs réaliseront qu’avec l’aide du framework ActivityPods, il est très facile de créer des applications compatibles ActivityPub puisque tout le fonctionnement de base (inbox, outbox, authentification, etc.) est déjà géré par le backend. Il n’y a plus qu’à s’occuper de ce qui est spécifique à l’application.
Et surtout, l’utilisateur n’a pas à se recréer un profil et retrouver ses contacts à chaque fois qu’il utilise un nouvel outil, comme c’est le cas actuellement (il faut un compte pour Mastodon, un compte pour Peertube, un compte pour Pixelfed…) Grâce à l’architecture en Pod, il pourra retrouver immédiatement toutes ses données et ses contacts.
L'histoire de SemApps... et le futur d'ActivityPods
L'histoire de SemApps... et le futur d'ActivityPods
Publié le
29.11.2023
Résumé
SemApps (pour Semantic Applications) a été imaginé au sein de l’Assemblée Virtuelle, une association loi 1901 fondée en 2011, qui était initialement conçue comme un think-tank citoyen contributif.
Billet
Le premier projet de l’association, Idées-Mix, avait pour ambition de valoriser 21 idées proposées par 21 acteurs, et de les transformer en projets concrets grâce à la mise en relation avec d’autres acteurs et ressources. Mais très vite la petite équipe du début fut confrontée aux difficultés techniques de ce projet.
La découverte du web sémantique et, surtout, la rencontre en 2013 avec Henry Story (contributeur historique de Solid, malheureusement décédé cet automne) ont permis de donner une toute nouvelle perspective au projet. L’objet de l’association fut alors réorienté vers la création de solutions logicielles décentralisées, vues comme des moyens de faciliter la coopération.
SemApps allait devenir le projet emblématique de l’association. Il fut initialement conçu, non comme une boîte à outil mais comme une application aidant les organisations à coopérer, en ouvrant leurs données en lecture et en écriture. La v1 fut essentiellement développée par Sébastien Lemoine et Romain Weeger qui se sont appuyés sur Semantic Forms, un logiciel développé par un autre membre de l’Assemblée Virtuelle, Jean-Marc Vanel.
La première instance de SemApps fut déployée pour un gigantesque tiers-lieu éphémère à Paris : les Grands Voisins. Il permettait de rendre visible la myriade d’organisations et d’individus qui occupaient le lieu, et de les aider à mieux coopérer. C’était une grande base de données coopérative.
La première instance de SemApps pour les Grands Voisins
Bien entendu les données étaient enregistrées au format sémantique. Il y avait également des fonctionnalités propre au web sémantique, comme la possibilité d’importer son profil d’une autre instance ou d’ajouter des liens entre ressources d’instances distantes. L’association Assemblée Virtuelle disposait aussi de sa propre instance.
Malheureusement, après le départ de Sébastien Lemoine vers d’autres aventures, le développement du projet s’arrêta. Les instances ont continué d’être maintenues quelques années, mais à un moment elles ont cessé de fonctionner et plus personne n’était capable de les relancer. Cela a coïncidé avec la fermeture du tiers-lieu des Grands Voisins.
La renaissance
Fin 2019, le projet a été ravivé par un petite équipe au sein de l’Assemblée Virtuelle :
Guillaume Rouyer, le fondateur de l’association et porteur de la vision ;
Pierre Bouvier-Muller, UX designer passionné de coopération ;
Simon Louvet, développeur historique de l’AV et créateur du Bus Sémantique ;
Sébastien Rosset, développeur fraîchement débarqué dans l’Assemblée Virtuelle.
Sébastien Rosset était particulièrement intéressé par le protocole ActivityPub, qui avait été standardisé par le W3C l’année précédente et permettait de faire du réseau social décentralisé. Ayant développé un premier serveur sous Symfony, il souhaitait lui donner une nouvelle dimension en enregistrant les données au format sémantique (ActivityPub est intrinsèquement lié au web sémantique, même si de nombreuses applications compatibles ActivityPub ignorent cette dimension).
Il fallait repartir de zéro, le code de la v1 étant inexploitable. Lorsqu’il a fallu faire les premiers choix technologiques, la petite équipe bénéficia de l’expertise de Niko, développeur émérite.
Grâce à son apport, il fut décidé d’utiliser Moleculer pour le backend. Ce framework basé sur NodeJS permet de créer facilement des microservices, qui peuvent rester sur la même machine ou se déployer sur plusieurs machines. L’architecture collait bien avec notre volonté de rendre SemApps modulaire. Ainsi les usagers pourraient n’activer que les services dont ils ont besoin, ou bien développer leurs propres services, qui pourraient se connecter aux services existants.
Les services Moleculer dans SemApps
Un autre choix important fut d’utiliser Jena Fuseki comme triple store. Bien qu’il soit possible de faire du web sémantique sans triple store, l’avantage d’un triple store est que les données sont enregistrées directement en sémantique. On peut donc les requêter facilement avec le langage SPARQL. Comme il s’agissait de développer de larges bases de données collaboratives, la possibilité de faire des requêtes SPARQL était cruciale.
Apache Jena Fuseki fut choisi parmi les triple stores existants car il était possible de développer des extensions. Nous souhaitions en effet proposer des endpoints SPARQL publics qui respectent les permissions accordées sur les ressources (appelées WAC en web sémantique), et Fuseki le permettait grâce aux extensions. Cela devait faire l’objet d’un important chantier dont Niko allait être le maître d’oeuvre.
Déploiement de SemApps v2
Après 6 mois de travail intensif (le premier confinement ayant bien aidé à accélérer le développement !), la v2 de SemApps était prête.
Parmi les premiers services développés, il y en avait un pour créer un serveur LDP (API de type REST permettant de lire et écrire des données sémantiques) et un autre pour gérer le protocole ActivityPub. Ces deux services pouvaient intégrer les permissions WAC (mais pouvaient aussi faire sans). Petit à petit, des services furent ajoutés pour faciliter l’interopérabilité entre les instances.
L’Assemblée Virtuelle souhaitait utiliser SemApps pour un usage similaire à la celui de la v1 : gérer une base de données ouverte et interopérable. Le framework React-Admin fut choisi pour créer une interface de type backoffice se connectant à un backend SemApps. Comme il s’agissait d’un produit à part entière, il fut choisi de le nommer Archipelago et de garder le nom SemApps pour la boîte à outils.
Des composants pour React-Admin furent néanmoins intégrés à cette boîte à outils, afin de faciliter le développement d’interfaces avec des données sémantiques. A l’usage, React-Admin se révéla pouvoir faire beaucoup plus que du backoffice et de nombreux sites l’utilisèrent. Bien entendu les développeurs étaient libres d’utiliser d’autres types de framework, le frontend étant complètement découplé du backend.
L'instance Archipelago de l'Assemblée Virtuelle
Au fil des années, des instances furent déployées pour de nombreux acteurs qui souhaitaient mettre la coopération au cœur de leur infrastructure informatique. Citons par exemple Colibris, un acteur majeur de la transition sociale et écologique en France, les Chemins de la Transition, un projet visant à créer des parcours de formation nomade, ou encore Destination Oasis, un site web permettant de trouver des hébergements dans des éco-lieux.
Vers les Pods
Lorsque le projet Solid a été lancé en 2016, la communauté de l’Assemblée Virtuelle y a immédiatement porté un vif intérêt, y voyant la concrétisation de la vision qu’Henry Story avait partagé en 2013.
Avec Solid, l’utilisateur est invité à se créer une base de données personnelle (Pod, pour Personal Online Datastore) sur l’hébergeur de son choix. Ensuite, lorsqu’il utilise une application compatible, celle-ci va enregistrer toutes ses données personnelles sur son Pod. C’est un renversement de l’architecture du web telle que nous la connaissons actuellement.
Jusqu’à maintenant, l’orientation de l’équipe SemApps était plutôt vers la création d’outils favorisant le partage et la coopération entre organisations. Au lieu de Personal Online Datastore (Pods), ce sont plutôt des Collective Online Datastores (Cods) qui étaient déployés (du moins c’est ainsi que l’Assemblée Virtuelle avait choisi de les nommer dans cet article).
Le focus était ainsi sur le partage facilité des informations (avec le protocole LDP, mais aussi ActivityPub) plutôt que sur la préservation des données personnelles, même s’il y avait naturellement un intérêt pour le second. Cela restait néanmoins deux objectifs très différents, voire opposés, qui pouvaient parfois faire émerger des conflits en termes des fonctionnalités proposées.
La situation évolua fin 2021 lorsque Sébastien Rosset eut l’idée de proposer des Pods intégrant nativement ActivityPub. Nommé ActivityPods, ce nouveau projet s’appuyait également sur SemApps. En quelques mois, le code de SemApps fut adapté pour permettre de déployer des hébergeurs de Pods, chaque Pod disposant de son propre dataset sur Jena Fuseki.
Des applications virent rapidement le jour, comme Bienvenue chez moi, qui permet de proposer des rencontres à domicile sur invitation, ou l’Entraide, une application de petites annonces. Dans les deux cas, l’utilisateur devrait d’abord se créer un Pod sur l’hébergeur de son choix et ensuite l’application utilisait ce Pod pour stocker ses données.
Quoique ActivityPods n’était pas 100% compatible avec le standard Solid (Solid-OIDC est en cours d’implémentation), le projet généra beaucoup d’intérêt des développeurs, au point d’être présenté en mars 2022 à Solid World, le rendez-vous mensuel de la communauté Solid. Le projet obtint également en juin 2023 un financement de NLnet pour consolider l’existant. Ce travail en cours permet également d’améliorer SemApps.
Le futur : Pods et Cods
Au sein de l’Assemblée Virtuelle, l’architecture en Pods a convaincu au point d’être une évidence. Or jusqu’à maintenant c’était plutôt des “Cods” qui étaient déployés, et les utilisateurs créaient leurs comptes sur les Cods. Mais pourquoi leurs données personnelles devraient être liées à un Cod en particulier ? Ne pourraient-ils pas créer leur profil sur leur Pod, puis le partager avec la ou les organisations auxquelles ils participent ?
En allant plus loin, nous avons réalisé qu’Archipelago lui-même pourrait devenir une application compatible ActivityPods. Chaque organisation, au lieu de déployer une instance sur son serveur, choisirait un hébergeur pour ses données. Et elle utiliserait ensuite l’application Archipelago (mais aussi d’autres applications) pour gérer ses données et les partager avec d’autres organisations.
Pour avoir des vrais Cods qui peuvent être créés “à la volée” et fonctionner comme des Pods, il suffirait d’affiner l’interface de gestion des droits. Un utilisateur avec un Pod pourrait créer un Cod pour une organisation, et il deviendrait administrateur de ce Cod. Il pourrait ensuite accorder des droits d’administration à d’autres utilisateurs.
L’Archipel des Low-Tech en France. Voyez-vous les Pods et les Cods ?
On aurait ainsi une constellation de Cods et de Pods, tous interopérables entre eux. Les données communautaires seraient sur des Cods, les données personnelles sur des Pods. On resterait dans une perspective d’échange et d’ouverture, tout en préservant la souveraineté sur les données. Ces deux objectifs, qui semblaient si éloignés au début, se trouveraient ainsi atteints dans cette nouvelle architecture au potentiel révolutionnaire.
Il y a encore du travail, mais ces perspectives sont réjouissantes. Malgré le peu de moyens, nous sommes confiants que les rêves portés par l’Assemblée Virtuelle depuis bientôt 15 ans (et aussi, à l’international, par la communauté Solid et ActivityPub) vont pouvoir se réaliser dans les prochaines années, et changer radicalement notre usage du web.
Résumé
En attendant la sortie au printemps de la v2.0, nous sommes ravis d’annoncer la disponibilité immédiate d’ActivityPods v1.5, qui inclus deux fonctionnalités demandées depuis longtemps: les liens d’invitation simplifiés et les groupes de contacts. Ce petit post a pour but de vous les faire découvrir.
Billet
Liens d’invitation simplifiés
Jusqu’à présent, inviter une personne dans son réseau demandait de passer par 3 étapes: l’invité devait se créer un compte, faire une demande de mise en relation avec l’identifiant de l’utilisateur, puis ce dernier devait accepter la demande. C’était fastidieux (surtout si on avait pas encore de compte) et il était assez courant que l’une ou l’autre personne oublie une étape, ce qui interrompait la mise en relation.
Désormais, les liens d’invitations (que l’on peut trouver sur la page “Mon réseau”, mais aussi dans “Mes paramètres”) permettent de voir immédiatement la personne qui nous invite.
Des liens d'invitation plus sympa
Une fois qu’on s’est connecté ou qu’on a créé son compte, la mise en relation est effectuée automatiquement et l’inviteur reçoit simplement un message lui annonçant que la personne a été ajoutée à son réseau via un lien d’invitation.
Ces fonctionnalités sont possibles grâce à des capabilities. Ce sont des liens uniques qui fonctionnent à la manière d’une clé de voiture: connaître ce lien suffit pour donner l’autorisation qu’il renferme. C’est sur ce principe que fonctionne le partage des Google docs, notamment.
Nous avons développé une première version très simple des capabilities qui est décrite ici et nous sommes déjà en train de réfléchir à comment nous pourrions les utiliser plus largement, par exemple pour donner le droit de partager. Nous sommes en cela très inspirés par OcapPub, proposé par Christine Lemmer-Webber.
Groupes de contacts
La deuxième amélioration majeure de la v1.5 consiste à pouvoir regrouper ses contacts, par exemple tous ceux qui font partie d’un projet ou d’u collectif. Ce groupe est strictement personnel, il permet simplement de mieux organiser ses propres contacts (les personnes ne sauront pas qu’elles ont été “placées” dans tel ou tel groupe).
Dans l’onglet “Mon réseau”, il y a maintenant un bouton “Mes groupes” qui permet de facilement gérer ses groupes. De plus, sur chaque page de contacts, il est possible d’ajouter la personne à un groupe, et même de créer un groupe.
Ajouter un contact à un groupe
Surtout, cela permet de plus facilement inviter les personnes à un événement (p.ex. sur Bienvenue chez moi), puisqu’on peut sélectionner directement le groupe. Tous les membres du groupe seront automatiquement sélectionnés.
Remerciements
L’ajout de ces deux fonctionnalités majeures, mais aussi d’un grand nombre de petites améliorations (voir la release Github), a été rendu possible grâce à la contribution de Laurin Weger, qui a été fait en partie bénévolement. Un grand merci à lui !
Laurin travaille actuellement sur la possibilité de recommander un contact à un autre contact, toujours avec l’aide de capabilities. Cette nouvelle fonctionnalité fera peut-être l’objet d’une v1.6, ou sera intégré directement dans la v2.0
