Utilisateur:Hugotrentesaux

De Resilience Territoire
avatar
Paris, France
April 13th

gecko.png
Ğecko
La [[monnaie libre]] ğ1 est une expérimentation de la monnaie comme commun, fondée sur la [[Théorie Relative de la Monnaie (TRM)]]. Aujourd'hui la ğ1 a besoin de se doter d'un moyen de paiement adapté aux ğmarchés, des marchés locaux où les paiements se font en ğ1. Le projet d'application mobile Ğecko apporte une réponse à ce problème et nécessite des financements pour en faire un outil pleinement fonctionnel. Ce projet est complémentaire du développement des [[Coupons d’échanges V.I.E. (matérialisation de la monnaie libre)]] (matérialisation de la monnaie libre). == Contexte == === Situation actuelle === Aujourd'hui, les paiements en ğ1 sont majoritairement effectués via l'application Césium, qui gère environ 10 000 transactions par mois. Cette application gère également les certifications de la toile de confiance et constitue un outil historique et important de l'écosystème ğ1. Césium n'a pas vocation à disparaître à court terme, mais ne répond pas au besoin de fluidité dans les transactions ciblé par Ğecko. En effet, l'utilisation d'une API ''legacy'' et une implémentation monolithique l'empêchent de passer à l'échelle et imposent une limite absolue sur sa réactivité. Selon Benoît Lavenier, son développeur principal, faire évoluer Césium serait complexe et inefficace, et corriger ces problèmes nécessiterait un lourd chantier de ré-écriture (Césium v2) chiffré à 240 000 € de développement. La communauté a donc choisi de développer un nouveau client léger dédié aux paiements tirant parti de cinq éléments techniques fondamentaux : # l'avènement de la nouvelle API client (GVA) réduit la durée des requêtes de ~2.5 secondes à <200 ms pour atteindre la sensation d'instantanéité # l'utilisation d'une bibliothèque client commune (en Rust) partage les coûts de développement avec les clients en ligne de commande existants et les clients futurs (''futureproof'') # le stockage sécurisé des clés privées ([https://git.duniter.org/documents/rfcs/blob/master/rfc/0013_Duniter_Encrypted_Wallet_Import_Format.md dewif]) augmente le niveau de sécurité tout en diminuant la complexité pour l'utilisateur (code secret court) # la gestion multi-nœuds met à profit la résilience du réseau blockchain # l'utilisation du framework Flutter de Google limite l'empreinte mémoire d'un facteur vingt ouvrant la voie vers du matériel low-tech Ğecko est la réponse optimale au problème rencontré qui permettra à la ğ1 de se développer sur le long terme. === Différences par rapport à Césium === Césium est aujourd'hui l'application la plus utilisée dans la monnaie libre pour tous les usages : création de compte, certification, transactions, données additionnelles... Alors pourquoi ne pas se contenter de modifier Césium pour améliorer le support mobile ? Cette question légitime trouve sa réponse dans les éléments techniques. Sans rentrer dans le détail, l'écosystème Duniter a été conçu comme une preuve de concept, loin d'un premier jet. De nombreuses briques de base allant de la procédure de génération de compte à l'API client nécessitent une réécriture complète pour se mettre à l'épreuve du futur. Faire évoluer pas à pas un logiciel dans une direction connue est une démarche bien plus longue et fastidieuse que de repartir sur des bases nouvelles en tirant des leçons des erreurs précédentes et de réaliser une migration progressive. Césium va continuer à évoluer de son côté par opérations de maintenance successives pour corriger certains bugs, ce qui permettra à Ǧecko d'atteindre un bon niveau d'utilisabilité sans avoir dès le début à gérer une large communauté d'utilisateurs. Bien entendu, Ğecko assurera une compatibilité totale avec toutes les données Césium+. On notera également que les nouveaux développements côté Duniter Rust se font désormais de pairs avec le développement du client Ğecko. === Nécessité d'un moyen de paiement performant === Le manque de moyen de paiement performant sur les événements tels que les ğmarchés constitue un frein au développement local de la ǧ1. En effet, sur ce genre d'événement, il est nécessaire de pouvoir enchaîner rapidement plusieurs petits paiements. Considérons le cas d'usage suivant : « Un client arrive au stand d'un vendeur, consulte les prix des produits, ajoute ceux qui l'intéressent à son panier sur un téléphone ''low-cost'', et valide la transaction ; celle-ci est immédiatement envoyée, une preuve de paiement est produite et le vendeur peut vérifier instantanément sa réception. » Une application mobile de paiement est une solution simple à mettre en place et qui répond bien à cette problématique. Elle doit donc remplir les points suivants : * Application largement compatible, notamment avec du matériel ancien et low-cost (il est facile de prêter un terminal aux personnes qui n'en ont pas lors des événements) * Temps de réaction inférieur à 300 millisecondes [https://uxplanet.org/7-laws-of-ux-design-and-what-happens-when-you-break-them-f61325989342 bien connu des concepteurs UX] * Support de charge d'une centaine de personnes en simultané * Rapidité du paiement de A à Z (scan QR-code, saisie code secret court, validation de la prise en compte) * Fiabilité des transactions (taux de succès avoisinant les 100%) * Fonctionnalité de '"panier"' (payer plusieurs ''items'' en une seule transaction) Un premier benchmark nous permet de nous rendre compte des améliorations en performance de Ğecko par rapport à Cesium: * La requête pour voir l'historique d'un compte ğ1 prend environ entre '''8 et 12 secondes''' à s'effectuer avec Césium * La requête pour voir l'historique d'un compte ğ1 prend environ entre '''120 et 150 millisecondes''' à s'effectuer avec Ğecko === Une preuve de concept déjà appréciée === Nous avons déjà développé Ğecko à l'état de preuve de concept. Les choix technologiques faits se révèlent pertinents notamment pour les raisons suivantes : * le framework Dart/Flutter permet de compiler le code en application native bien plus rapide et légère qu'une webapp (Césium est en Ionic) * l'intégration de bibliothèques client écrites en Rust permet de mutualiser les efforts de développement avec d'autres projets dans une vision long terme * la communication avec les nœuds Duniter se fait en langage GraphQL qui permet de diminuer largement le trafic réseau et accélérer significativement les opérations pour un ressenti instantané même sur une connexion à faible débit * l'utilisation des HDWallets et du format dewif permet de gagner en sécurité des comptes et l'utilisateur doit seulement retenir un code à six lettres. Un gros travail d'expérience utilisateur a déjà été fait et maquetté (sur [https://www.figma.com/file/G0CEs58bbUo3zGjG9ZEHf3/Gecko-polyvalent?node-id=242%3A0 Figma]) qui permettra une prise en main sécurisée pour des utilisateurs non technophiles. Une communauté de testeurs ainsi que des tests automatisés ont déjà été mis en place, ce qui accélère le développement futur de l'application. === Intégration à l'écosystème existant === Une crainte légitime pour tout utilisateur d'outils privateurs (comme ceux des GAFAM) est la création d'un nouvel espace fermé indépendant des autres. Bien au contraire, dans la démarche du logiciel libre et fédéré, Ğecko sera une porte d'entrée supplémentaire sur les interfaces existantes et garantira '''l'interopérabilité''' des services. Nous nous inscrivons ainsi dans la réflexion légale sur l'interopérabilité, menée en ce moment en France par la [https://www.laquadrature.net/2019/05/21/pour-linteroperabilite-des-geants-du-web-lettre-commune-de-45-organisations/ Quadrature du Net] et aux État-Unis par l'[https://www.eff.org/deeplinks/2021/06/access-act-takes-step-towards-more-interoperable-future Electronic Frontier Foundation]. Ğecko pourra interagir aussi bien sur les données en blockchain que sur Césium+, Ğchange, et même les forums Discourse, ce qui laissera à l'utilisateur la liberté de choisir son application et sa plateforme favorite pour manipuler ses données. == Projet == === Chronologie de la v1.0 === Le financement du projet permettrait d'ajouter les fonctionnalités nécessaires à la sortie d'une '''version 1.0''' stable pour l'ouverture au grand public et de poser les bases pour une version 2.0. Nous décrivons ci-dessous le découpage de ces versions. * v0.1.0 ('''déjà financée, en cours de développement bénévole''', sortie prévue mi-août) ** Réorganisation des données persistantes ** Implémentation complète de la maquette Figma (réalisée par Boris) ** Gestion des comptes (création, sécurité) ** Paiement (génération/lecture de QR-code, formulaire) ** Affichage de l'historique de transactions ** Finalisation des tests d'intégrations et des tests unitaires ** Finalisation du scan réseau au démarrage de l'application ** Publication F-Droid * v1.0 ('''à financer''', livrable du projet présenté à l'ADEME, détaillé dans la ''timeline'') ** Gestion multi-coffre ** Importation Césium ** Recherche avancée ** Gestion de panier d'item ** Suivi des transactions ** Contacts/Messagerie ** Compatibilité iOS ** Sharding (partage de fragments de clés) ** Publication Apple AppStore et Google PlayStore ** Maquettage et UX design des fonctionnalités futures * v2.0 ('''postérieur au financement''') ** Dérivation opaques ** Paiement NFC ** Compatibilité Desktop ** Gestion toile de confiance (certifications, promesses de certifications) ** Calendrier / communauté === Personnes référentes === Afin de donner un point de vue différent sur le projet, nous proposons de se référer aux personnes suivantes : * Matthieu Latapy, directeur de recherche CNRS, http://latapy.complexnetworks.fr/ * Bertrand Sajus, chargé d’études documentaires, ministère de la Culture et de la Communication
avatar

Hugo Trentesaux