Ğecko
Application de paiement pour la monnaie libre ğ1
Description : 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).
Note de mise-à-jour 2024-11-14
Les développements dans le cadre du projet Ğecko sont terminés, et la date de mise en production est prévue pour le 8 mars 2025. En effet, les modifications effectuées côté Duniter impliquent de développer une nouvelle version de Cesium, l'application la plus utilisée. Finalement, seuls 22 k€ ont été financés par l'ADEME, soit un auto-financement de 56%. La version 2 de Cesium verra le jour grâce à un financement participatif en cours (cf HelloAsso).
Note de mise-à-jour 2024-07-11
Le projet de mise-à-jour de la Ğ1 sur la version 2 de l'écosystème Duniter continue. Les briques essentielles sont stabilisées (Duniter v2, duniter-squid) et la communauté se met en marche pour adopter cette nouvelle version. Cela implique des efforts de vulgarisation et d'accompagnement coordonnés via des visio hebdomadaires et un suivi sur le forum monnaie libre (https://forum.monnaie-libre.fr/c/communication/mise-a-jour-v2/131). La partie client de Ğecko est prête, il ne reste plus qu'à mettre en marche le réseau. C'est pourquoi le reste du budget et dirigé vers les fonctionnalités backend nécessaires au fonctionnement de Ğecko. La mise en production se profile vers mi-2025.
Note de mise-à-jour 2023-09-21
Le projet de migration de la Ğ1 sur la version 2 de Duniter continue, et Ğecko est toujours destiné à la v2. En attendant, une partie du code de Ğecko, le paquet logiciel "Durt" développé grâce au financement de l'ADEME a servi à construire le logiciel Ğinkgo, développé bénévolement. C'est un magnifique exemple de comment le financement d'un logiciel libre permet de faire émerger de nouvelles contributions bénévoles importantes !
retrouvez la liste des logiciels de l'écosystème sur la page https://duniter.fr/logiciels/
Note de mise-à-jour 2023-03-06
Ceci est une note de mise-à-jour par rapport au budget du projet. Pour rappel, voici le budget prévisionnel :
- développeur front : 24 000€
- développeur back : 20 000 €
- prestataire UI/UX : 4 000 €
- prestataire illustrateur : 1 500 €
- abonnements divers : 500 €
Voici à quoi ressemble le budget maintenant :
- développeur front Flutter : 10 000 € (terminé) → Poka
- développeur full-stack Flutter/Typescript : 8 000 € (en cours) → Poka
- développeur back Rust : 18 000 € (en cours) → Benjamin
- stagiaire Flutter : 6 000 € (en cours) → Guenoel
- prestation JavaScript : 5000 € (en cours) → 1000i100
- prestation audit code : 2400 € (dépensé) → Volune (Nicolas et Julien)
- prestation UX : 450 € (dépensé) → Repliq (Baptiste)
On note l'apparition d'un poste de dev full stack qui travaille sur le logiciel duniter-indexer. En effet, tel que formulé au début, l'API GVA devait répondre aux problématiques d'indexations. Ces fonctionnalités sont maintenant découplées de Duniter et gérées par un logiciel dédié.
Note de mise-à-jour 2022-12-26
Ğecko est rentré en phase de test beta. Toutes les informations sont disponibles sur le forum : https://forum.monnaie-libre.fr/t/devenez-testeur-sur-gecko/25694
Note de mise-à-jour 2022-05-18
Le dossier qui suit a été rédigé en juin 2021, et, bien que le projet reste globalement dans la même ligne, certains détails techniques ont évolué. Ils sont listés ici :
API GVA → API Substrate
L'API GVA devait venir avec la version 1.9 de Duniter. Mais ce dernier va être complètement ré-écrit sur les bases du framework Substrate. L'API utilisée sera donc un mélange entre les indexeurs et l'API RPC Substrate. Cela retarde la mise en production de Ğecko mais maintient toutes les exigences en terme de rapidité.
Briques Rust → natif
Les briques Rust seront remplacées par des briques natives pour la connexion à Substrate. Cela sera invisible pour l'utilisateur mais facilitera grandement le déploiement sur les différentes plateformes (Android, iOS) mais surtout Web, Desktop.
Internationalisation
Le projet Duniter prenant une dimension internationale plus rapidement que prévu, des équipes de traduction notamment vers l'espagnol et l'anglais seront mises en place.
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 (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 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 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 Quadrature du Net et aux État-Unis par l'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
Organisations utilisatrice ou intéressée par utiliser la ressource :
Contributeurs : Hugotrentesaux, Poka
Défi auquel répond la ressource : 4- Modèle économique
Autre commun proche : Coupons d’échanges V.I.E. (matérialisation de la monnaie libre), Monnaie libre
Richesse recherchée : Financement
Compétences recherchée :
Communauté d'intérêt : Communauté ğ1
Type de licence ? GNU Affero General Public License
Niveau de développement : Preuve Concept & 1er client
Cloud / Fichiers :
Indiquer la localisation pour voir la carte
Tags : application, logiciels libres, Monnaie libre, Commun numérique
Catégories : Logiciel
Thème : Vulnérabilités/Sociale, Facteurs de résilience/Economie, Facteurs de résilience/Infrastructure, Regénération/Innovation
Candidat Appel à Communs :
Référent ADEME : Gabriel.plassat
Référent du commun : Poka
Les 5 parties ci dessous sont à remplir obligatoirement pour analyser le commun et vous conseiller
Candidat Appel à Communs : sélectionné
Montant Aide souhaitée (en Euro) à l'Appel à Communs Sobriété et Résilience : 49650
1.Détails du Financement :
Financement
Observables et indicateurs de réussite
Le financement portera sur le passage de la version 0.1.0 à la version 1.0 telle que résumée ci-dessus et détaillée sur le dépôt GitLab du projet. La réussite du projet pourra être mesurée par la quantité de fonctionnalités implémentées à la sortie de la version 1.0.
Détail des observables
- une personne non technophile a réussi à se servir de l'app pour réaliser des tâches élémentaires
- un utilisateur peut réaliser un paiement même si certains nœuds du réseau sont en panne
- le réseau est capable de supporter le trafic généré par une utilisation massive de l'application (test de charge)
Répartition des postes de financement
- 1 poste développeur front pour 10 mois (Étienne) : 10 × 2400 = 24 000€
- 1 poste développeur back pour 8 mois (Éloïs) : 8 × 2500 = 20 000 €
- 1 prestataire UI/UX (Boris) : 4 000 €
- 1 prestataire illustrateur (Chopp): 1 500 €
- abonnement Apple AppStore 100€ / an
- abonnement Google PlayStore
- abonnement Figma deux éditeurs 24€ / mois
- abonnement Sentry 26€ / mois
Calendrier
Le calendrier ci-dessous permet de se rendre compte du travail à fournir pour sortir une version 1.0. Elle est séparée en quatre phases qui marquent des étapes importantes du projet. La durée des phases correspond au temps maximal que peuvent occuper les tâches qui la composent, en activité à temps partiel (2/3 temps) environ. Chaque tâche est chiffrée en jour de travail temps plein (7h) ou en semaine (35h). Les tâches relatives au développement frontend de l'application sont plus faciles à estimer que les tâches backend. De plus, elles sont les seules limitantes pour la clôture des quatre phases et par conséquent mieux détaillées.
phase 1 "création de matière" (4 mois)
- Implementation "flat" maquette existante (pure UI, sans anim)
- Refaire les écrans d'onboarding (3j)
- Implémentation restauration portefeuille (4j)
- Refaire vue scan de portefeuille Césium (4j)
- Refonte graphique de la vue "Mon Coffre" (1j)
- Refonte graphique de la vue "Mon Portefeuille" (1j)
- Implémentation nouvelle vues gestion du coffre (3sem)
- Portefeuille par défaut
- Retirer portefeuille
- Changer code secret
- Vue sharding (l'UI reste à prototyper)
- Implémentation nouvelle vue changement de coffre
- Réimplémentation complète menu général de l'application (1sem)
- Réimplémentation vue "faire un virement" (2j)
- Implémentation drag&drop pour les virements entre portefeuilles (1sem)
- Réimplémenter totalement vue et logique l'historique des transactions (1sem)
- Transactions en attente (piscine)
- Gestion de panier lors du scan de QR-code d'item Ğchange (gros bout)
- Implémentation vue "mon panier"
- Faire la vue ajouter au panier
- Réimplémenter "choix du coffre / portefeuille" lors du paiement
- Vue confirmation de paiement
- Implémentation recherche (1 mois)
- Vue recherche
- Vue résultat
- Historique
- Blockchain
- Ğchange
- Césium+
phase 2 "prise de recul" (1 mois)
- Phase de testage et re-maquettage, prestation UX
- Implémentation de la logique des vues (1sem)
- Lancement de v0.5
- Sondage auprès des alpha-testeurs
- Correction des bugs remontés par les utilisateurs
- Grosse prestation UX par Boris (2sem)
- Prestation d'illustration par Chopp
phase 3 "complétion" (3 mois)
- Toute la logique de la gestion de panier d'item Ğchange (3 semaines)
- Compatibilité iOS (Éloïs)
- Lancement de la v0.9 publique, et suivi des retours utilisateurs, et corrections de bugs (2 semaines)
- Lancement sur le PlayStore et AppStore (1j)
- Carnet d'adresse (1 semaine)
- Messagerie (1 semaine)
- Import de portefeuille Césium (3j)
- Gestion multi coffres (1 semaine)
- Sharding (2 semaines)
- Notification de proposition de partage d'un fragment de phrase de restauration
- Suivi et gestion de mes partages de phrase de restauration
- Suivi en temps réel des paiements effectués (1 semaine)
- 1 semaine pour finir la requête GVA côté Duniter
- 1 semaine pour prototyper et implémenter cette partie
- Notifications des paiements validés (2j)
- Scan réseau avancé (4j)
- Suivi des transactions, et notifications des transactions reçues (5j)
- Petite presta UX Boris (1sem)
phase 4 "bouclage et polissage" (2 mois)
- Ajout des animations, déco, ombrage (2sem)
- Ajout indications didacticiel (1sem)
- Sortie de la V1
- Correction des bugs remontés par les utilisateurs
Travail déjà réalisé
La réalisation du projet jusqu'à l'état de preuve de concept a été pratiquée sur du temps bénévole. Elle s'élève à un total de 6 mois ETP côté frontend et 4 mois ETP côté bibliothèques client Rust. Pour un salaire de développeur de 3000€ / mois, cela revient à 30 000€ déjà investis dans le projet (sans compter la partie côté serveur pour l'API GVA qui peut être chiffrée à 2 mois ETP soit 6000 €).
Scénario sans financement
Les deux développeurs principaux liés à Ğecko arrivent à terme de leur durée de "chômage" et doivent reprendre un emploi salarié. Cela revient à investir moins de 7h/semaine dans le projet et donc à le prolonger d'un facteur 4 au moins. Ainsi, la sortie d'une version 1.0 verrait le jour dans quatre ans dans le meilleur des cas, ce qui correspond à la durée totale de la ğ1 depuis son commencement.
2.Détails Sobriété et/ou Résilience des Territoire :
Résilience et territoire
Les ğmarchés sont des événements de nature profondément locale, qui ont un fort impact sur le tissu social et économique du territoire. Ces événements permettent de relancer l'activité économique d'une zone rurale ou de recréer de l'activité en zone urbaine en dehors des lieux de la société de consommation. En tant qu'application mobile destinée aux ğmarchés, Ğecko participe à cela.
En recréant du lien social et économique, le ğmarché participe à renforcer le tissu associatif et humain indispensable à la prise de décision collective et à l'organisation militante. De plus, l'économie en ğ1 contribue à lui donner les moyens de ses ambitions, par exemple par la location de matériel ou l'organisation de repas pour accompagner les événements.
L'ambition de Ğecko n'est pas de créer une n-ième application mobile qui emprisonne l'utilisateur via son écran mais au contraire, de faciliter au maximum le paiement pour laisser plus de place à la rencontre et à l'échange entre les individus. Ǧecko sera entièrement compatible F-Droid pour aider à la dégooglisation, mais également Google PlayStore et iOS AppStore pour accompagner son public dans la démarche.
Cas d'usage
Ğecko doit être une application "tout-terrain", c'est-à-dire se conformer à plusieurs cas d'usage. Elle doit être facile à utiliser dans le cadre de transactions de particulier à particulier mais également être pratique lors de ğmarchés. C'est ce dernier cas d'usage qui nous intéresse particulièrement dans le cadre résilience et territoire. C'est pourquoi nous détaillons ici la mise en œuvre sur un marché :
- les commerçants préparent le marché en imprimant des QR-codes correspondant à leurs produits (TODO illustration d'un étal avec un QR-code)
- les clients arrivent au marché avec l'application sur leur téléphone ou l'installent depuis un dépôt F-Droid local si aucune connexion Internet n'est disponible
- les clients parcourent les stands et scannent les QR-codes d'articles qu'ils achètent
- dans le cas d'une connexion Internet, le commerçant reçoit une notification de l'émission de la transaction sur son terminal
- dans le cas d'absence de connexion Internet, il doit scanner à son tour un QR-code sur l'écran du client
- en cas d'absence de connexion lors du marché, les transactions sont automatiquement publiées dès que l'une des parties retrouve une connexion
La mise en œuvre sur des dépôts de circuits courts est sensiblement identique. Il faut toutefois noter que l'utilisation de Ğecko est davantage pensée du point de vue de l'acheteur. Pour un logiciel plus complet doublé d'un outil de comptabilité permettant le suivi des stocks, un commerçant pourra également s'équiper d'un outil tel que Tikka (cf page logiciels https://duniter.fr/ecosysteme/).
3.Détails Impacts environnementaux :
Impacts environnementaux
Impact indirect
À l'heure où l'impact environnemental du numérique atteint des dimensions préoccupantes (cf rapport https://theshiftproject.org/), nous croyons qu'il est nécessaire de nous responsabiliser sur l'utilisation de telles technologies. Au lieu de prendre part à la course à la puissance, nous nous inscrivons dans une logique low-tech. La ğ1 est pensée sur toute la ligne pour réduire la consommation de bande passante, de ressource processeur, de mémoire vive, et même de limiter le temps passé sur l'écran au profit du temps passé en personne. Avec Ğecko, nous cherchons même à aller plus loin en permettant le fonctionnement en zone blanche et en visant spécifiquement les vieux smartphones pour prolonger leur durée de vie (un peu à la postmarket OS https://postmarketos.org/).
Nous pensons que les impacts environnementaux indirects liés à l'utilisation de la ğ1 surpassent le coût d'une application mobile. En effet, la réduction mécanique des inégalités permet de sortir des logiques d'exploitation/consommation, l'encouragement de l'économie locale permet de limiter les besoins de transports, le développement du marché de réutilisation/réparation limite le recours au neuf.
Impact direct
Du point de vue de l'impact direct, des machines puissantes (500W) seront utilisées tout au long du développement de l'application, une chaîne d'intégration (CI) sera exécutée sur des serveurs pour chaque commit du projet. Une connexion Internet sera fréquemment mobilisée lors des phases de test. Des individus vivant dans des pays développés auront recours à des voitures pour se rencontrer. Ces détails montrent que l'essentiel de l'impact environnemental de Ğecko est indirect.
Impact lié à l'utilisation de Duniter
Les règles de la blockchain de Duniter et sa communauté visent à empêcher une personne d'acquérir plus de monnaie ou de part de gouvernance par le simple fait de posséder une puissance de calcul très importante. Cela décourage fortement l'utilisation démesurée d'énergie pour le minage, à l'inverse des autres cryptomonnaies comme le Bitcoin. Un petit ordinateur consommant 5W peut donc participer ce qui le rend très économe en énergie (cf article Duniter est-il énergivore ?)
Publication de certaines données environnementales en open data
La nature décentralisée d'une blockchain rend impossible la mesure précise de sa consommation énergétique. Il est cependant possible de l'estimer grâce aux données publiées en temps réel dans la blockchain par la plupart des nœuds du réseau, notamment une estimation de la quantité de nœuds qui calculent et de leur puissance.
4.Synthèse du projet de Commun :
Synthèse
L'association Axiom Team a déjà montré sa compétence dans l'organisation du développement informatique de la ğ1. Elle assure la coordination de plusieurs des principaux contributeurs techniques à l'écosystème Duniter. Les logiciels libres produits sont utiles à des milliers d'utilisateurs quotidiens de la ğ1. Cependant, la progression de la communauté est trop rapide par rapport aux développements techniques. Nous avons du mal à maintenir les logiciels existants et à développer les applications nécessaires sur la base du bénévolat. Le financement d'une année de développement à plein temps donnerait un coup d'accélération considérable permettant au commun monnaie libre de prendre un essor sur l'ensemble des territoires concernés, et en particulier les zones rurales grâce à Ğecko.
Une conséquence attendue de l'arrivée de Ğecko est l'augmentation de l'activité économique locale mesurée par la quantité de transactions (cf carte de densité de transactions). Cette économie locale remplace une économie globale dont les conséquences sont désastreuses sur la planète. Lorsque l'économie locale est suffisamment dense, il devient intéressant d'augmenter la part de temps travaillé en monnaie libre, ce qui enclenche un cercle vertueux. Aujourd'hui, cet effet n'est atteint que dans certaines régions très actives, notamment en raison d'un effet de seuil lié à la complexité des outils.
Les développements de Duniter/Ğecko sont pensés pour être réutilisés le plus simplement et efficacement possible pour les futurs outils de la Ğ1. En ce sens, nous considérons que les avancées techniques réalisées pour Ğecko participent activement à l’intérêt général. Par ailleurs, Ğecko participant au déploiement du commun monnaie libre, il contribue indirectement aux effets sur l'intérêt général de celle-ci. Merci de consulter cette section sur ce sujet.
Le livrable du projet est une v1.0 de Ğecko disponible sur les bibliothèques d'applications. Le projet est découpé en phases successives qui permettent de suivre l'avancement du projet.
5.Autodiagnostic :
AutoDiagnostic
La particularité du projet Ğecko est de s'inscrire dans le cadre de la monnaie libre, un projet de commun de longue haleine, déjà en cours depuis plus de quatre ans. Tout ce qui a trait à ce projet est expliqué dans la page dédiée, et ce qui suit concerne donc uniquement le projet Ğecko.
Le problème de la création monétaire sous forme de dette et centralisée a été identifié par l'équipe de Duniter depuis 10 ans maintenant. Le développement des outils d'utilisation de la monnaie libre a pour objectifs finaux de faciliter l'utilisation de cette monnaie centrée sur l'humain de par sa création monétaire, et ainsi répondre aux problèmes structurels de la monnaie actuellement utilisée en France. Le retour d'expérience de 4 ans d'utilisation de la ğ1 en France et dans le monde nous montre à quel point cette dernière facilite les échanges, renforce le lien social entre ses utilisateurs, crée de nouvelles richesses inattendues qui n'auraient certainement jamais vu le jour sans l’existence de cette monnaie.
Ğecko existe déjà à l'état de preuve de concept et ne fait que répondre aux exigences des utilisateurs de la ğ1. Il est installable depuis les livrables distribués sur un fil du forum Duniter. Une version 0.1.0 est prévue pour l'été 2021 et servira de base à la v1.0.
L'accès à ces financements nous permettra de réaliser ce projet dans le temps imparti. Les développements de Ğecko par l'association Axiom-Team ouvrent déjà la porte aux futurs développements d'outils divers et variés dont la ğ1 aura besoin pour répondre aux exigences de ses utilisateurs.
Autres pistes envisagées
D'autres pistes intéressantes sont envisageables :
- Imprimer une monnaie papier spécifique à l'événement disponible à un stand de change, mais cela nécessite une logistique assez contraignante et n'est pas une solution à long terme
- Développer des terminaux de paiements combinés à des cartes de débit, mais cela nécessite de gros investissements et un matériel spécifique, pour l'instant hors de portée
Le développement d'une application mobile constitue une solution intermédiaire relativement simple à mettre en place et qui répond bien à la problématique.
La réalisation du projet de commun sélectionné :
6.Réalisation du projet de commun:
Liste des CR d'atelier en lien avec ce Commun Ğecko: aucun pour le moment
