Rédiger ce post me permet de découvrir que j’avais déjà réfléchi à la question en 2021 : Étendre la toile de confiance | chaîne de certificats. Je reviens à la charge avec un peu plus de bagage dans le cadre du financement NGI déjà annoncé ici Interopérabilité des systèmes crypto. Notamment après une discussion avec @aya pour présenter un projet réalisable (de grandes ambitions, mais il faut d’abord une PoC).
Un peu de recul sur blockchain et décentralisation
On a tendance à mettre dans le même panier “décentralisé” et “distribué”, mais il est important de distinguer ces concepts. Voici des définitions réductrices mais qui seront utilisées dans ce post
- centralisé : s’exécute sur une infrastructure contrôlée par un acteur unique. Il peut y avoir une forme de distribution (load balancing, redondance…) mais c’est essentiellement pour augmenter la résilience du service. C’est une distribution technique, pas politique.
- décentralisé : s’exécute sur une diversité d’infrastructures gérées par des acteurs indépendants. Des protocoles et des API permettent aux différentes instances de se fédérer.
- distribué : s’exécute sur un ensemble de machines gérées par des acteurs indépendants qui sont tous d’accord pour s’aligner sur le consensus défini par un protocole commun.
Le centralisé est généralement plus simple à développer mais ne nous intéresse pas ici. Les choses pour lesquelles il faut trancher ont plus leur place sur du distribué, alors que celles pour lesquelles on souhaite laisser coexister plusieurs versions correspondent plus à du décentralisé, éventuellement fédéré.
Si on applique ça à la Ğ1, on a besoin d’un consensus pour :
- la toile de confiance, l’identité unique, le statut membre
- le dividende universel, le montant des comptes
Vous remarquerez que je ne fais pas figurer les transactions. En effet, celles-ci n’ont pas toutes besoin d’être soumises au consensus, on pourrait en déplacer la plupart sur des lightning networks (cf lightning-network pour plus de détails) ou des supports papier.
Par contre, on a besoin de laisser plusieurs versions coexister pour :
- les discussions sur le forum (actuellement on est sur du centralisé donc la modération a un pouvoir de censure qui n’est pas souhaitable)
- les places de marché (pareil, un responsable d’instance a un pouvoir de supprimer une annonce Ğchange cf Ventes illégales sur Ğchange, est-ce bien raisonnable? - Expression libre - Forum Monnaie Libre pour des exemples)
- le stockage de données de manière générale (Réflexion sur les datapods décentralisés)
Pour cela, il faut développer des solutions hors chaîne.
Le problème de l’authentification et de la confiance
L’authentification des utilisateurs et la confiance en eux est un problème récurrent des systèmes, qu’ils soient centralisés ou fédérés.
exemple du spam sur notre gitlab
Capture d’écran des posts admin sur le forum qui montrent le problème du spam de gitlab, notamment à cause de l’authentification avec github.
exemple du spam sur le mail
La gestion du mail est rendue extrêmement pénible par le spam, de nombreuses contre-mesures doivent être mises en place, pour un résultat toujours très imparfait et souvent invasif (par exemple Google/Microsoft lisent vos mails).
Or c’est un grand atout de la toile de confiance Ğ1 : on a une base sérieuse pour l’authentification, ce serait intéressant de l’étendre au delà. On résoudrait un problème commun à beaucoup de systèmes pour lequel aucune bonne solution n’existe pour l’instant. Mais il n’est pas possible d’imposer les règles de la toile de confiance Ğ1 nécessaires à notre cohésion et qui ne correspond pas à tous les usages. Au contraire, il faudrait un moyen de fédérer les autres toiles de confiance existantes. Notre conclusion est qu’il manque un système décentralisé pour la fédération des toiles de confiance et l’authentification des utilisateurs.
Proposition
L’idée est de concevoir un système générique de toile de confiance qui ne repose pas sur une infrastructure centralisée comme les serveurs de clés. Elle ferait intervenir plusieurs éléments techniques :
- un UDID avec registraire et résolveur comme uniresolver.io
- le format JWK, structure de donnée standard pour représenter une clé RFC 7517: JSON Web Key (JWK)
- IPLD, un format d’adressage conçu pour l’interopérabilité et la décentralisation ipld.io
- UCAN, est un système d’autorisation (comme un ACL) décentralisé et adapté au monde crypto
Par exemple, un membre de la Ğ1 pourrait “certifier” une clé ssh qui ne correspond pas à un compte Ğ1 comme lui appartenant. Pour cela il émettrait un document doté d’une preuve qui sera stocké sur un réseau IPFS intéressé par ce genre de documents. Un autre utilisateur de la Ğ1 pourrait installer un plugin sshd permettant de se connecter à un serveur sous réserve d’être dans sa toile de confiance “N+2”.
Autre exemple, un hébergeur d’instance ActivityPub (par exemple peertube) pourrait autoriser l’ouverture de compte sur son instance à un utilisateur dont la clé fait partie d’une chaîne de confiance venant de multiples sources (identity BrightID, ou toile de confiance Ğ1).
Des réseaux pourraient se monter pour stocker de manière distribuée des toiles de confiance suivant des critères communs (par exemple toile d’admin sys debian / Ğ1, autohébergeurs yunohost / Ğ1…). Il pourrait s’agir de réseaux privés ou public interconnectés par IPFS.
L’objet du financement NGI sera de spécifier ces comportements et implémenter une PoC. @Maxma et @aya aident à la rédaction du dossier (interne à l’asso Axiom-Team).