Files

Yvv 25437f24e3 Sprint 1 : scaffolding complet de Glibredecision

Plateforme de decisions collectives pour Duniter/G1.
Backend FastAPI async + PostgreSQL (14 tables, 8 routers, 6 services,
moteur de vote avec formule d'inertie WoT/Smith/TechComm).
Frontend Nuxt 4 + Nuxt UI v3 + Pinia (9 pages, 5 stores).
Infrastructure Docker + Woodpecker CI + Traefik.
Documentation technique et utilisateur (15 fichiers).
Seed : Licence G1, Engagement Forgeron v2.0.0, 4 protocoles de vote.
30 tests unitaires (formules, mode params, vote nuance) -- tous verts.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

2026-02-28 12:46:11 +01:00

25 KiB

Raw Blame History

Recherche Forum Duniter -- Donnees de reference pour Glibredecision

Date de recherche : 2026-02-28

TABLE DES MATIERES

Licence G1 -- Texte complet
Acte d'engagement des forgerons (Engagement Forgeron v2.0.0)
Acte d'engagement du comite technique (Engagement Comite Tech v2.0.0)
G1vote -- Fonctionnement, formule et mecanisme
Processus de validation par vote nuance (1000i100)
Contributions d'Yvv sur les forums
Sources et liens

1. Licence G1 -- Texte complet

Version : v0.3.0 (2017-04-04, modifiee le 2025-02-11)

Source : https://monnaie-libre.fr/licence-g1/ Depot Git : https://git.duniter.org/documents/g1_monetary_license/-/blob/master/g1_monetary_license_fr.rst

Preambule

Licence de la monnaie et engagement de responsabilite.

Toute operation de certification d'un nouveau membre de la monnaie G1 doit prealablement s'accompagner de la transmission de cette licence de la monnaie G1 dont le certificateur doit s'assurer qu'elle a ete etudiee, comprise et acceptee par la personne qui sera certifiee.

Toile de confiance G1 (TdC G1)

Avertissement : Certifier n'est pas uniquement s'assurer que vous avez rencontre la personne, c'est assurer a la communaute G1 que vous connaissez suffisamment bien la personne que vous vous appretez a certifier et que vous saurez ainsi la contacter facilement, et etre en mesure de reperer un double compte effectue par une personne certifiee par vous-meme, ou d'autres types de problemes (disparition...), en effectuant des recoupements qui permettront de reveler le probleme le cas echeant.

Conseils fortement recommandes :

Connaitre la personne par plusieurs moyens de contact (physique, electronique, etc.)
Connaitre d'autres personnes qui la connaissent aussi bien
Ne jamais certifier seul ; travailler avec au moins un autre membre de la TdC
Verifier si le compte a deja des certifications existantes avant de proceder
Confirmer que le futur membre controle bien son compte (transfert test)
S'assurer que les contacts ont etudie la licence G1 en vigueur

Verifications obligatoires pour le certificateur :

De suffisamment bien connaitre la personne qui declare gerer cette cle publique
Verifier personnellement la bonne cle publique avec elle
Confirmer qu'elle a genere son document de revocation de compte Duniter

4a. Rencontre physique en personne preferee, OU 4b. Verifier a distance le lien personne / cle publique en contactant la personne par plusieurs moyens de communication differents

Regles abregees de la TdC

Chaque membre : 100 certifications possibles ; 1 certification par 5 jours
Validite de certification : 2 mois pour les nouveaux membres
Nouveau membre : 5 certifications requises + distance <= 5 pas de 80% des membres referents
Seuil de membre referent : Y[N] = plafond de N^(1/5)
Certifications membres etablis : valides 2 ans
Renouvellement : accord tous les 12 mois ; maintenir >= 5 certifications valides

Monnaie G1

Production du Dividende Universel (DU) : 1 DU par personne et par jour

Code monetaire : Le DU journalier reste constant jusqu'a l'equinoxe, puis est reevalue selon :

DUjour(equinoxe suivant) = DUjour(equinoxe) + c^2 * (M/N)(equinoxe) / (182,625 jours)

Parametres :

c = 4,88% par equinoxe
DU(0) = 10,00 G1
M = masse monetaire totale
N = nombre de membres

Logiciels et licence

Les logiciels G1 permettant aux utilisateurs de gerer leur utilisation de G1 doivent transmettre cette licence avec le logiciel ainsi que l'ensemble des parametres techniques de la monnaie G1 inscrits dans le bloc 0.

Regles de modification du document

Proposants, soutiens et votants doivent etre membres de la TdC
Finaliser : creer des comptes portefeuille pour chaque option (pour/contre) ; poster la proposition avec les cles publiques dans la categorie dediee du forum
Mecanisme de vote : les membres transferent des fonds vers le compte de l'option choisie ; transferts multiples vers le meme compte = un vote ; transferts vers les deux comptes = nul
Resultats apres 30 jours : Si la proposition a recolte au moins 20 votes/virements "pour" et aucun vote "contre", elle est adoptee. Pour chaque vote "contre", 5 votes "pour" supplementaires sont necessaires.

2. Acte d'engagement des forgerons

Document : Engagement Forgeron v2.0.0-fr (date : 2026-01-07) Statut : ADOPTE (vote du 7 janvier au 6 fevrier 2026)

Source : https://forum.monnaie-libre.fr/t/vote-engagement-forgeron-v2-0-0/33165 Depot Git : https://git.duniter.org/documents/g1_monetary_license (MR #30 par 1000i100)

Resultats du vote

97 votes POUR (dont 8 forgerons)
23 votes CONTRE (dont 3 forgerons)
19 votes invalides/nuls
Seuil atteint exactement a 97 votes POUR
Total WoT : 7 224 membres (1,66% de participation)

Intention et enjeux

Avec la V2, une sous-toile de confiance pour les forgerons est proposee pour s'assurer que les forgerons qui gerent l'ecosysteme technique le font avec competence, rigueur, securite et reactivite. Le document etablit les standards pour les operateurs de noeuds Duniter V2.

L'engagement vise a eviter les dependances centralisees -- qu'elles soient techniques ou humaines.

Savoirs-faire requis (competences techniques)

Les candidats doivent demontrer :

Administration systeme Linux en ligne de commande
Configuration reseau et pratiques de securite
Protocoles de gestion de cles cryptographiques et mots de passe
Fondamentaux de cybersecurite (modelisation de menaces, surfaces d'attaque)
Comprehension des mecanismes de consensus blockchain Duniter
Gestion de conteneurs Docker (recommande)

Savoirs-etre (engagements comportementaux)

Rigueur : Les operateurs doivent comprendre en profondeur les configurations de leurs noeuds. "Un faux sentiment de securite erode la confiance et met le reseau en danger." Connaitre ses limites et savoir demander de l'aide.

Reactivite : Repondre dans les 24 heures aux alertes, restaurer les services rapidement, escalader les problemes de maniere appropriee.

Responsabilite : Les certificateurs garantissent la competence des candidats et fournissent un accompagnement continu.

Clauses de l'aspirant forgeron

Securite et conformite (~9 engagements) :

Utiliser des phrases de recuperation generees aleatoirement
Separer les comptes (membre vs forgeron)
Maintenir des sauvegardes physiques multiples
Operer des noeuds synchronises et a jour
Ne pas exposer d'API non securisees
Declarer hors-ligne si indisponible
Repondre dans les 24 heures quand en ligne

Contact : Pouvoir joindre 3+ forgerons certificateurs par au moins 2 canaux de communication (telephone/SMS, email, XMPP, Matrix).

Connaissances : Acceptation de tous les engagements, comprehension des regles du graphe de confiance, mecanismes de consensus blockchain.

Clauses pieges : Exclusions pour harcelement, recherche de pouvoir ou infiltration de l'ecosysteme.

Clauses du forgeron certificateur

Securite et conformite (~8 exigences) :

Verification de l'intention du candidat
Evaluation des pratiques de securite
Validation de la phrase de recuperation
Verification du noeud
Documentation de la configuration

Contact : Maintien de canaux de communication et engagement de reponse maximale de 24 heures pour les defauts lies aux noeuds.

Connaissances : Verification que les candidats comprennent les implications de l'engagement et les delais operationnels du graphe de confiance.

Clauses pieges : Rejet des certifications sous contrainte ou motivees commercialement.

Regles de la toile de confiance des forgerons

Necessite l'adhesion a la toile de confiance principale
Necessite une invitation de forgeron
Necessite 3 certifications de forgerons
Pas d'expiration directe ; adhesion perdue via sortie de la TdC principale ou 6 mois hors-ligne en tant que validateur
Seuil d'inactivite des forgerons : 3 mois avant perte du statut de forge

Mise en oeuvre

Les certifications presentent toutes les clauses d'engagement dans un ordre aleatoire. Les candidats doivent repondre correctement a chaque clause (affirmative/negative selon le type) ou recommencer la procedure.

Formule de vote

votesPour >= ceil(WotSize^0.1 + (0.5 + (1 - 0.5) * (1 - (TotalVotes/WotSize)^0.2)) * TotalVotes)

votesSmithPour >= ceil(SmithWotSize^0.1)

Actions post-vote

Ajout des listes de verification dans g1cli, duniter-vue, cesium2, et developpement des workflows de certification UI.

3. Acte d'engagement du comite technique

Document : Engagement Comite Tech v2.0.0-fr Vote : 4 fevrier -- 6 mars 2026 (en cours au moment de la recherche)

Source : https://forum.monnaie-libre.fr/t/vote-engagement-comite-tech-2-0-0-fr/33293

Objectif principal

Le comite technique a pour role de proteger la souverainete de la communaute G1 sur les mises a jour de la blockchain. Ses missions :

Auditer le code
Detecter le code malveillant
Verifier les fonctionnalites annoncees
Deployer uniquement les mises a jour servant la communaute

Engagements des membres

Les membres s'engagent a :

Respecter les regles decrites dans la version en vigueur du document
Demissionner s'ils sont en desaccord avec les regles en vigueur
Voter pour retirer le mandat des collegues qui violent visiblement les directives

Gouvernance des modifications

L'adoption necessite :

Seuil de vote unani-majoritaire
Support minimum des membres du comite

Formule :

votesPour >= ceil(WotSize^0.1 + (0.5 + (1 - 0.5) * (1 - (TotalVotes/WotSize)^0.2)) * TotalVotes)

votesCoTecPour >= ceil(CoTecSize^0.1)

Composition actuelle du comite

L'entree/sortie necessite l'approbation des 2/3 des membres existants (modifiable uniquement par mises a jour runtime avec validation des 2/3).

Methode de vote

0,01 G1 envoyes aux adresses designees (POUR ou CONTRE) Suivi via : g1vote-view (talk: 32960; mode: D30M50B.1G.2T.1)

4. G1vote -- Fonctionnement, formule et mecanisme

Description generale

Depot : https://git.duniter.org/tools/g1vote-view Licence : GNU AGPLv3 Technologie : Vue.js + TypeScript + Vite 131 commits, cree le 16 fevrier 2025

G1vote est une application web qui affiche le statut des votes G1 pour une proposition specifique. L'outil lit les transactions blockchain G1 pour compter les votes.

Acces

URL : https://g1vote-view-237903.pages.duniter.org/#/vote/[TOPIC_ID]

Le TOPIC_ID correspond a l'identifiant du sujet sur le forum monnaie-libre.fr qui contient les deux cles publiques (POUR et CONTRE) dans le premier message.

Modes de validation

Deux approches de validation configurables via parametres URL :

Mode ratio : ?validation=ratio&custom=B20-5N
Mode unani-majoritaire : ?validation=unani-majority&custom=M50

Codes des parametres (ModeParams)

Code	Signification	Exemple
D	Duree du vote en jours	D30 = 30 jours
M	Seuil de majorite en %	M50 = 50%
N	Multiplicateur ratio (alternatif a M)	N5
B	Exposant de base	B1 = exposant 1
G	Exposant de gradient	G.5 = gradient 0.5
C	Base constante	C10 = constante 10
S	Critere Smith (exposant)	S.5
T	Critere Comite Tech (exposant)	T.3
R	Indicateur mode ratio	R

Exemple complet : D30M50B1G.5C10 = vote de 30 jours, majorite 50%, exposant base 1, gradient 0.5, constante base 10.

Formule centrale de seuil (WotMembersThreshold)

La formule principale pour determiner le nombre de votes "pour" necessaires :

Resultat = C + B^W + (M + (1-M) * (1 - (T/W)^G)) * max(0, T-C)

Ou :

C = constantBase (base constante)
B = baseExponent (exposant de base)
W = corpus (taille de la WoT, nombre de membres inscrits)
T = total des votes (pour + contre)
M = majorityRatio (ratio de majorite = majority/100)
G = gradientExponent (exposant de gradient)

Mecanisme d'inertie

Le mecanisme d'inertie est encode dans le terme (1 - (T/W)^G) de la formule :

Quand la participation est faible (T/W proche de 0), le terme (T/W)^G est proche de 0, donc (1 - (T/W)^G) est proche de 1. Le seuil d'adoption est alors quasi-unanime (proche de 100% des votants).
Quand la participation augmente (T/W s'approche de 1), le terme (1 - (T/W)^G) diminue vers 0. Le seuil baisse vers le ratio de majorite M (par exemple 50%).
Le parametre G (gradient) controle la vitesse de transition entre quasi-unanimite et majorite simple.

En pratique : Avec peu de votants, il faut quasi l'unanimite pour adopter une proposition. Plus il y a de votants, plus le seuil se rapproche d'une majorite simple. C'est le mecanisme d'"inertie" : une faible mobilisation ne doit pas permettre a une petite minorite de decider pour tous.

Seuils specifiques

SmithThreshold (forgerons) :

votesPour >= ceil(SmithWotSize^exponent)

TechCommThreshold (comite technique) :

votesPour >= ceil(CoTecSize^exponent)

Architecture technique

Threshold.ts : Contient les classes WotMembersThreshold, SmithThreshold, TechCommThreshold
formulaTex.ts : Genere les formules en LaTeX pour affichage
ModeParams.ts : Parse les codes de parametres (D30M50B, etc.)
SimuParams.ts : Gere les parametres de simulation
reactiveVote.ts : Couche reactive Vue.js autour de la logique metier
techCommittee.ts : Resolution d'identite des membres du comite technique

5. Processus de validation par vote nuance

Source : https://forum.monnaie-libre.fr/t/processus-de-validation-licence-par-vote-nuance/31729

Echelle d'adhesion a six niveaux

Au lieu d'un vote binaire pour/contre, le systeme propose une echelle :

Niveau	Montant G1	Signification
CONTRE	0,01 G1	Opposition viscerale
PAS DU TOUT D'ACCORD	0,1 G1	Plusieurs points de desaccord
PAS D'ACCORD	0,2 G1	1-2 points problematiques
NEUTRE	0,3 G1	Ni pour ni contre
D'ACCORD	0,4 G1	Ameliorations mineures possibles, globalement acceptable
TOUT A FAIT D'ACCORD	0,5 G1	Alignement parfait

Formule d'adoption

Une proposition passe quand : la somme des votes NEUTRE + D'ACCORD + TOUT A FAIT D'ACCORD represente au moins 80% de la totalite des votes, avec au moins 59 personnes differentes exprimees.

Rejet si les votes d'opposition depassent strictement 20% des votes totaux.

Regles de validite

Votes avec montants hors de l'echelle prescrite : annules
Votes negatifs sans commentaire de transaction expliquant les points de desaccord : invalides
Fenetre de vote standard de 30 jours, prolongeable si participation inferieure a 59 membres

Concepts avances proposes par 1000i100

Vote par procuration quadratique : Le poids du vote augmente par racine carree du nombre de procurations (avec 3 procurations, poids = racine de 4 = 2), empechant la domination par des figures populaires
Vote sous pression : Mecanisme permettant aux votants de signaler une contrainte indue, declenchant une intervention communautaire
Distinction consensus vs consentement : Le systeme vise le consentement (absence d'opposition/risques identifies) plutot que le consensus (accord universel)

Seuil de participation

Le seuil de 59 votants reference les membres fondateurs du reseau, etablissant un mecanisme de verification de presence empechant les decisions par des noyaux inactifs.

6. Contributions d'Yvv sur les forums

Roles institutionnels

Secretaire du Bureau d'Axiom Team (2023) Source : https://forum.monnaie-libre.fr/t/membres-bureau-et-ca-axiom-team-2023/26650
Membre du Conseil d'Administration d'Axiom Team (2025/26) Source : https://forum.monnaie-libre.fr/t/bureau-conseil-dadministration-axiom-team-2025-26/32967
Product Owner (PO) pour le developpement Cesium2 et l'ecosysteme G1

Posts sur forum.duniter.org

a) Strategie et coordination V2 (post #24, 12 sept 2024)

Source : https://forum.duniter.org/t/visio-strategie-et-coordination-v2-lundi-25-mars-13h/12087/24

Yvv a decrit l'organisation de la migration V2 :

Version 1.10 = symbolique, pour la synchronisation reseau
V2.0 = vrai redemarrage blockchain avec premieres decisions on-chain
Equipes specialisees : communication, enquete de proximite, integration forgerons, traduction, developpement
"Les modalites de deploiement ne sont pas definies"
Equipe pivot : Hugo, Cgeek, Kimamila, Poka

b) Entretiens forgerons -- rapport d'enquete (26 avril 2025)

Source : https://forum.duniter.org/t/entretiens-forgerons-rapport-denquete/13080

Yvv a dirige une enquete aupres des forgerons (decideurs cles pour la migration V2) :

Equipe de 5 personnes
27 entretiens initiaux
Questions : experience de V1, reception de V2, besoins d'information pour la prise de decision
Rapport PDF publie : "Les entretiens Forgerons -- Rapport d'enquete" (234,4 KB)

c) Wish Ticket : UX Certification (11 janvier 2026)

Source : https://forum.duniter.org/t/wish-ticket-ux-certification-alleger-la-pratique-du-qcm/13531

Yvv a identifie un probleme UX avec les QCM de certification :

Le QCM systematique est vecu comme infantilisant
Proposition : frequence configurable
- Basee sur les certifications : afficher tous les 3, 5, 8, ou 13 certifications (defaut : 5)
- Basee sur le temps : afficher tous les 2-5 mois (defaut : 3 mois)
Pour les renouvellements : alerte confirmant que la personne est toujours joignable
Anticipation des pratiques de certification en lot avec la V2

d) Fonction "queue list" pour les certifications (16 decembre 2025)

Source : https://forum.duniter.org/t/fonction-queue-list-pour-les-certifs-dans-les-clients/13496

Yvv a propose une specification complete pour la gestion de file d'attente des certifications :

File d'attente locale sans synchronisation inter-appareils
Ordonnancement chronologique avec reordonnancement manuel
Certification automatique a l'expiration des delais de 5 jours
Notifications externes (push ou daemon local)
Distinction entre nouvelles certifications et renouvellements
Processus de renouvellement simplifie (verification de statut vital uniquement)
Poka a developpe cette fonctionnalite dans Cesium2 au hackathon de Lodeve

e) Schema / diagramme de la crypto (janvier 2026)

Source : https://forum.duniter.org/t/schema-diagramme-de-la-crypto/13509

Yvv a propose la creation d'un diagramme pedagogique simplifie :

Vocabulaire : coffre, comptes membres, comptes portefeuilles
Acronymes : BIP39 -> seed, ED255-19 -> paire de cles, derivations BIP32
Approche modulaire : version technique precise d'abord, puis simplification par design
Collaboration communautaire via Excalidraw ("GlobalChart")

f) Gestion des enveloppes et projets (19 septembre 2025)

Source : https://forum.duniter.org/t/petit-point-sur-les-enveloppes-et-les-projets/13325

Yvv, en tant que "Pedro, ange gardien des dons", a organise des reunions avec les porteurs de projets :

Revue des enveloppes ouvertes
Appels de 5-10 min par enveloppe, le double ou triple pour une campagne
References au site Axiom pour la section projets

g) Hackathon Axiom #5 -- Preparation lancement V2 (janvier-fevrier 2026)

Source : https://forum.duniter.org/t/hackathon-axiom-5-preparation-lancement-v2/13523

Yvv a contribue en tant que facilitateur :

Conversion du sujet en mode wiki pour organiser le backlog
"La decision appartient de facto aux geniteurs"
Position strategique : mobiliser les ressources la semaine apres le lancement (vs 1000i100 : la semaine avant)
Backlog : finaliser les elements V2, tester le genesis local, runtime upgrades, infrastructure
Definition du scope et du calendrier de G1Vote (mentionne comme tache future)
Distinction "bugfixes" vs "changements necessitant reflexion collective"
Jalons post-migration : SSO, IPFS datapods, messagerie, API Glib

h) Preparation passage V2 (commentaires de janvier 2026)

Source : https://forum.duniter.org/t/preparation-au-08-03-2026-passage-a-la-v2/13538

Proposition de lancement a minuit : "branle-bas le 7 au soir", T0 a "8 a 0h00m01s"
Ceremonie le samedi soir a minuit avec travail technique la nuit, puis soutien communication le dimanche

i) Hackathon Toulouse (novembre 2025)

Source : https://forum.duniter.org/t/hackathon-25sem47-capitole-prepa/13424

Yvv a organise deux sprints :

Sprint Toulouse : crash test sur Gtest, preparation production, livraison G1 Companion
Sprint Lodeve : lancement production V2 vise le 16 decembre (reporte a mars 2026)
Liste des bloquants : confirmation technique/fonctionnelle, variables runtime upgrade, clients web/mobile, killswitch V1

Posts sur forum.monnaie-libre.fr

j) IA open source en Monnaie Libre (post #29)

Source : https://forum.monnaie-libre.fr/t/ia-open-source-en-monnaie-libre/29970/29

Yvv a contribue a la discussion sur l'IA open source dans l'ecosysteme Monnaie Libre.

Note sur les CDC (cahiers des charges)

Aucun document formel intitule "cahier des charges" n'a ete trouve sous ce nom exact. Cependant, les contributions d'Yvv en tant que Product Owner constituent de facto des specifications fonctionnelles, notamment :

La specification de la file d'attente de certifications (point d)
Le wish ticket UX certification (point c)
Le diagramme pedagogique crypto (point e)
L'organisation du backlog au hackathon Axiom #5 (point g)

7. Sources et liens

25 KiB Raw Blame History