Duniter v2 ⁉ Faut-il copier Ğ1 ou permettre la création de multiples toiles de confiance?

Salut à tous,

Je lance cette discussion pour aborder une question fondamentale concernant l’avenir de Duniter et la migration de v1 à v2. Le scénario qui semble envisagé par les développeurs est celui d’une migration où tout le monde passerait de la v1 à la v2, impliquant “d’arrêter tous les nodes Duniter v1” — une hypothèse qui semble déjà audacieuse. Méthode d'authentification supportées par les app client v2 : migration obligatoire vers les mnémoniques?

Dans cette vision, les états de la Ğ1v1 seraient “photocopiés” sur la Ğ1v2. Si une telle opération a l’avantage de conserver la toile de confiance (WoT) existante, elle aurait pour effet de doubler la masse monétaire, un point qui soulève de nombreuses questions et problèmes.

Le problème de la décohérence des DU

Un des problèmes les plus immédiats et précurseurs d’une telle migration est la potentielle décohérence des Dividendes Universels (DU). Si la transition ne se fait pas de manière absolument instantanée pour tous les membres, nous aurons deux systèmes coexistant temporairement. Le “DUv2” (calculé avec M2/N2) commencerait inévitablement à diverger du “DUv1” (calculé avec M1/N1), créant une confusion et des inégalités problématiques.

Les limites d’une WoT unique et la dislocation de la Ğ1

Au-delà de la complexité technique, il y a une question de fond sur la scalabilité d’une unique toile de confiance. Nous constatons déjà qu’autour de 7000 membres, la WoT de la Ğ1v1 se disloque et montre ses limites, alors même que de nouvelles communautés (Amérique du Sud, Espagne) cherchent à y entrer.

Mettons cela en perspective : la plus grande toile de confiance jamais créée, celle de PGP réunissant les développeurs de Debian, a montré des failles de sécurité vers le million d’utilisateurs, malgré un contrat moral fort incluant des compétences techniques et une vision commune. Le fait que la WoT Ğ1, qui n’impose aucune compétence ni vision idéologique commune, rencontre des blocages à seulement 7000 membres est extrêmement révélateur. Monnaie libre et dérive sectaire : une mort de la Ğ1 inévitable? - Expression libre - Forum Monnaie Libre

Cela suggère le besoin non pas de renforcer une unique WoT, mais de permettre la création de plusieurs WoT. Celles-ci laisseraient émerger des “Nations d’États d’Esprit”, chacune démarrant avec son propre bloc 0 et sa propre toile.

Proposition : Duniter v2 comme outil d’essaimage

Face à ces constats, la question se pose : la finalité de Duniter v2 est-elle vraiment de se charger de la copie de la v1 ? Ou ne devrait-il pas plutôt fournir les outils permettant à des groupes de créer leurs propres monnaies ?

On pourrait imaginer un système où un groupe de, par exemple, 5 membres minimum de la v1 pourrait initier le lancement d’une nouvelle monnaie “v2.N”. Pour initialiser la valeur de son DU, on pourrait imaginer une règle simple : le DUv2.N initial serait la moyenne des DU des autres monnaies v2 déjà existantes.

La question fondamentale est donc : Duniterv2 doit-il être l’outil d’une copie forcée de la v1, avec les risques que cela comporte, ou doit-il devenir une technologie permettant à des groupes de lancer leur propre monnaie v2.N à partir de la v1 ?

J’ouvre ce fil pour débattre de cette vision alternative.


1 Like

On a déjà dit qu’au démarrage de la V2 la V1 serait stoppée.
Donc le problème de double masse monétaire ne se pose pas !

Et pour préciser le moyen de l’arrêt : une version de Duniter programmée pour s’arrêter à la date de la migration, des messages dans les clients, et un comité de communication pour propager la nouvelle.

Une Ğ1 parallèle pourra exister si des gens en veulent, tant pis pour eux. C’est libre, on ne peut pas les en empêcher.

La réponse est… 42 !

Ou plus sérieusement, “les deux mon capitaine !”.

La Ğ1 V2 sera :

  • une copie de la Ğ1 pour conserver notre communauté de WoT qui est un atout considérable.

Duniter V2 sera :

  • un outil plus simple et solide (grâce à Substrate et Docker) pour lancer de zéro des Ğn partout dans le monde (mais pas à partir de la Ğ1). Il “suffira” de faire un fork de Duniter V2, de créer les fichiers du genesis et de demander un peu d’aide ici. J’ai dit un peu ! :wink:
1 Like

Je souhaite partager une perspective humble issue de notre expérience sur le terrain, qui pourrait enrichir la discussion sur l’avenir de la Ğ1 et la migration vers la v2.

Le constat de terrain : pourquoi la Ğ1 peine dans le monde professionnel

À Toulouse, qui est pourtant un bastion historique de la Ğ1, nous avons observé une réalité difficile : les entreprises qui ont tenté d’intégrer la Ğ1 dans leur comptabilité, comme Djoliba ou les paniers bio de Joao, ont dû faire marche arrière. Les membres les plus actifs et créateurs de valeur sont revenus à l’euro.

La raison est simple : la Ğ1, par sa nature même (avec de plus en plus de créateurs monétaires), a tendance à perdre de la valeur. Pour une entreprise, il est très compliqué d’utiliser une monnaie qui n’est pas une réserve de valeur stable. La Ğ1 est souvent perçue comme un jeton pour des “vides-greniers” (les GMarchés), ce qui est formidable pour l’échange local, mais insuffisant pour construire une autonomie économique réelle pour les professionnels.

Une solution qui passe en production : l’architecture UPlanet

Pour répondre à ces défis, a été développé une architecture nommée UPlanet, qui fonctionne déjà avec la Ğ1v1. Il semble que ses potentialités, notamment pour les entreprises, ne soient pas encore bien connues dans les discussions techniques sur la v2.

Voici ce qu’elle apporte de différent :

  • Flexibilité : UPlanet n’est pas limité à un seul type de jeton. Actuellement, nous utilisons la Ğ1v1, mais il est conçu pour être agnostique.

  • Infrastructure décentralisée : Nos “DATAPods” sont des relais NOSTR, permettant des communications et services décentralisés.

  • Des cas d’usages concrets ignorés par la migration v2 : L’architecture UPlanet / Astroport.ONE est pensée pour des applications professionnelles essentielles :

    • Création de stablecoins pour la comptabilité.
    • Jeton de registre de propriété (pour du matériel, par exemple).
    • Jeton de location de services.
    • Fonctions comptables intégrées. ♥️BOX : ẐEN Economic Dashboard

    Stockage IPFS géolocalisé.

CopyLaRadio et le Ẑen

Le projet porté par le G1FabLab, CopyLaRadio, est une coopérative (SCIC) qui s’appuie sur cette architecture et qui fonctionne déjà sur la Ğ1v1. Une de nos innovations majeures est de séparer l’identité du membre de ses portefeuilles financiers. 🌱 Le Ẑen, un outil de stabilité sur Ğ1 pour nos projets en commun - Communication - Forum Monnaie Libre

Pour cela, nous avons créé deux outils distincts :

  1. Le MULTIPASS : C’est une identité sociale, le passeport numérique d’un membre dans notre réseau. Il n’est pas directement un portefeuille de monnaie.
  2. La ZEN Card (ẐEN) : C’est la représentation de parts de capital dans la coopérative. C’est un actif stable, car il est adossé à la valeur réelle de l’infrastructure (serveurs, etc.). Le Ẑen nous sert d’unité de compte stable, un peu comme un “stablecoin” interne, pour notre comptabilité.

Et appliquons Astroport.ONE/RUNTIME/ZEN.ECONOMY.readme.md at master · papiche/Astroport.ONE · GitHub

Ce système permet d’établir une confiance : une première transaction depuis le compte membre certifié d’un utilisateur sert à l’identifier comme administrateur de son “relais” (son nœud), et cela rend possible la délégation de gestion de portefeuilles, ce qui est crucial pour des services automatisés.

Notre position et notre invitation

Notre startup combine l’infrastructure physique décentralisée (DePIN) et la finance décentralisée (DeFi). Pour continuer à fonctionner et à offrir ces services, nous avons besoin de la stabilité et des fonctionnalités que nous avons construites sur la Ğ1v1. C’est pourquoi nous nous assurerons de maintenir la Ğ1v1 en ligne tant que la migration vers la v2 ne prendra pas en compte ces cas d’usage réels et ne sera pas totalement validée.

Par exemple ce fork de gcli qui permet de créer un profil nostr et assurer les output json nécessaire aux traitements batch des MULTIPASS : Files · nostr · clients / Rust / Ğcli-v2s · GitLab

Mon message n’est pas une critique, mais une main tendue. Nous avons une réalité fonctionnelle, qui rentre en production, qui répond à des problèmes concrets rencontrés par les professionnels. Nous invitons humblement la communauté technique à regarder ce qui a été construit avec Astroport.ONE et à en discuter.

Merci de m’avoir lu.

Je ne vois pas ce que tu attends des développeurs de Duniter V2 ?

Ta plateforme est agnostique, alors tu peux déjà lui ajouter le support de Duniter V2. Et continuer ainsi à supporter la communauté Ğ1 qui passera en V2.

What else ?

1 Like