Avec la V2, une sous toile de confiance forgeron est proposée pour s’assurer que les forgerons qui gèrent les nœuds Duniter V2 le font avec : compétence, rigueur, sécurité et réactivité.
C’est pour cette raison que nous avons créé un engagement forgeron.
Ce ne sera pas parfait du premier coup, mais mieux que rien actuellement. C’est le moment de voter pour confirmer ou infirmer ça collectivement.
Nous vous proposons un système de vote unani-majoritaire via votre compte monnaie libre pour exprimer votre accord ou désaccord sur l’adoption de l’engagement forgeron. Ouverture des votes : du 7 janvier au 6 février 2026.
Texte complet de l’engagement forgeron en 1er commentaire.
Listes des actions mises en oeuvre à l'issue du vote si la proposition est adoptée
Ajouter l’engagement forgeron au dépot charte/license (via merge request avec 1 validation minimum)
Ajouter les checklist smith et certSimth dans g1cli
Ajouter les checklist smith et certSimth dans duniter-vue
Ajouter les checklist smith et certSimth dans cesium2
Développer l’UI de checklist lors des certif smith pour les app qui ne l’ont pas.
Concrètement, pour voter entre le 07/01/2026 et le 06/02/2026, envoyez 0.01 Ǧ1 depuis votre compte membre vers :
Mieux que rien (POUR/OUI) : 5UkkPtV7TEbVL11ztGHQkYKeobnMhh4k3FJXsdSaX84S:7G1
Pire que rien (CONTRE/NON) : Cwpmov6D2XZsiRya5ZVsYFVWy94sjatcgwAntQndzLz:786
S’assurer en tant que communauté que les forgerons qui gèrent l’écosystème technique le font avec : compétence, rigueur, sécurité et réactivité.
La majorité des noeuds forgeron déclarés « online » doivent être effectivement en bon état de fonctionnement et accessible en ligne.
Pour résister aux attaques, les noeuds doivent éviter au maximum les dépendances centralisées, quelles soient techniques ou humaines. Les dépendances centralisées tolérées devraient l’être uniquement si leur altération nuit suffisament à l’attaquant pour le dissuader d’attaquer par ces dépendances.
Concrètrement, gérer un noeud forgeron Duniter nécessite des savoirs faire et des savoirs être.
Savoirs-faire
Globalement il s’agit des compétences générales d’administrateur système linux.
Savoir installer et administrer une machine linux en ligne de commande.
Configurer réseau & sécurité exposer son noeud en ligne.
Connaître et appliquer des bonnes pratiques de gestion de clef de chiffrement et autres mots de passe.
Bases de cybersécurité (modèle de menaces, surface d’attaque, type d’attaques communes).
Comprendre les mécanismes de consensus de la blockchain Duniter (TdC Smith, autorités online associées, epoch, babe, grandpa, offenses).
Maniement de Docker recommandé.
Savoirs-être
Rigueur
Lancer son nœud sans comprendre son fonctionnement ne suffit pas pour le maintenir sur le long terme. Il est nécéssaire de maîtriser sa configuration, pour savoir comment réagir en cas de problème.
Une fausse sécurité érode la confiance et met le réseau en danger.
Il est important de :
Connaître ses limites.
Savoir demander de l’aide ou se documenter dès qu’il y a doute.
Réactivité
En cas de problème, il faut pouvoir rapidement :
Alerter les forgerons concernés (donc être joignable).
Rétablir le service. En cas de besoin, faire appel à l’aide des autres (sur le forum tech ou groupe forgeron Telegram).
Signaler les problèmes aux personnes abilitées ou impactées.
Responsabilité
Pour répondres aux enjeux précédent, certifier un forgeron c’est aussi :
Se porter garant que votre certifié dispose des compétences suffisantes et à respecter les protocoles listés ci-dessus.
Répondre à ses questions et compléter sa formation au besoin.
Vous assurer qu’il ait pris connaissance des informations cruciales pour assurer son rôle.
Compenser ses éventuelles lacunes.
Clauses d’engagement de l’aspirant forgeron
Catégorie Sécurité & conformité :
J’ai clarifié ce qui me motive à devenir forgeron, j’en assume les raisons et les indiquerai à qui me les demande.
Je fais de la veille pour maintenir mes pratiques de sécurité système et réseau à la hauteur des enjeux Duniter actuels.
J’ai activé les notifications sur forum.duniter.org pour être alerté des sollicitations perso et smiths.
Je confirme que ma phrase de récupération a été générée aléatoirement et que je l’utilise uniquement pour mon compte membre.
J’utilise un autre compte pour mes transactions courantes. (Je m’authentifie sur mon compte membre seulement pour les opérations nécessitant les droits non délégables, et depuis mon propre matériel).
J’ai stocké ma phrase de récupération sur plusieurs supports physiques (numérique ou non), récupérables indépendamment. En cas de vol, incendie, panne, oubli… J’aurai accès à au moins une des copies pour reprendre la main.
Je gère déjà un nœud à jour (version logiciel), correctement synchronisé (état blockchain) et joignable (peer réseau).
J’ai veillé à ne pas exposer publiquement l’api unsafe de mon noeud smith.
Je fournis à la demande d’un autre forgeron, mes choix techniques et si je change d’approche, je préviens les forgerons qui m’ont certifié (pour être alerté des éventuels soucis associés).
Je me déclare offline en cas de doute sur la sécurité ou la continuité de service de mon noeud.
Je m’engage à répondre en moins de 24h aux forgerons quand je suis déclaré online. Sinon, je me déclare offline.
Catégorie Contact :
Je sais joindre efficacement et rapidement 3 des forgerons qui comptent me certifier (Cela par au moins 2 canaux : tel/sms + email, xmpp, matrix…).
Catégorie Connaissance :
J’ai lu et j’accepte de respecter l’ensemble des engagements forgerons et j’en comprend les implications et raisons d’être.
J’ai pris connaissance des règles et délais associé au fonctionnement de la TdC forgeron. [^2]
J’ai bien compris le fonctionnement d’un réseau blockchain, en particulier les enjeux de sécurité liés aux mécanismes de consensus de la blockchain Duniter. [^1]
Catégorie Piège :
J’insiste, harcèle ou fait pression d’une autre manière pour être certifié.
Je veux être forgeron pour la gloire et le pouvoir.
Je cherche à nuire à l’écosystème Ǧ1 en m’infiltrant parmis les forgerons.
Clauses d’engagement du forgeron certificateur
Catégorie Sécurité & conformité :
J’ai questionné l’intention du certifié à rejoindre les forgerons et je reste prêt à le certifier.
J’ai demandé au certifié quelles étaient ses pratiques de sécurité et je les estime suffisantes pour le réseau actuel.
Le certifié m’assure que son compte est issu d’une phrase de récupération générée aléatoirement.
Le certifié m’assure avoir stocké sa phrase de récupération sur plusieurs supports physiques (numérique ou non), récupérables indépendamment. En cas de vol, incendie, oubli de mot de passe… au moins une des versions lui est accessible.
J’ai vérifié que le certifié gère déjà un nœud à jour qui est correctement synchronisé.
J’ai noté le style de configuration (paquet debian, docker-compose…) que le certifié utilise pour son nœud (cette configuration n’a pas de faille connue, notamment n’expose pas l’api unsafe publiquement).
Le certifié s’est engagé auprès de moi à m’informer de tout changement significatif de sa config (pour pouvoir transmettre les infos de manière ciblée en cas de problème).
J’ai vérifié avec le certifié qu’il connait les risques pour lui et le réseau d’être offline sans l’avoir annoncé, et qu’il se considère en mesure d’assurer un uptime suffisant.
Catégorie Contact :
Je sais joindre efficacement et rapidement les forgerons que j’ai certifiés (téléphone généralement).
Je peux les joindre par au moins 2 canaux (sms, email, xmpp, matrix…).
Je m’engage à contacter sous 24h max ce forgeron si j’apprends qu’un défaut concerne son nœud validateur (désynchronisé, pas à jour, inaccessible…).
Catégorie Connaissance :
J’ai vérifié que le certifié a accepté les engagements forgerons dans son intégralité.
J’ai vérifié que le certifié savait où consulter les règles détaillées de la TdC forgeron.[^3]
J’ai vérifié que le certifié connait les délais de passage en ligne/hors ligne de son nœud validateur.
Catégorie Piège :
Je certifie sous la menace ou autre forme de pression.
Je tire un avantage personnel en échange de ma certification.
Gouvernance pour faire évoluer le présent document
Non contractuels, modifiable sans vote pour clarifier le contenu de l’engagement.
Lexique
Phrase de récupération : séquence de mots générée aléatoirement (mnémonic) dont est dérivée la graine cryptographique (seed, clef privée)
Nœud validateur, smith node : nœud autorisé et configuré pour écrire des blocs dans la blockchain. Chaque compte forgeron peut autoriser un seul nœud simultanément à être validateur.
Noeud validateur (forgeron) hors ligne pendant 6 mois
Notice d’implémentation
À destination des développeurs de logiciels permettant de certifier :
À chaque certification, l’ensemble des Clauses d’engagements forgeron sont présentées une à une au certificateur, dans un ordre aléatoire.
. Il peut répondre <-non ou oui-> à chaque clause.
. Le document de certification n’est émis qu’après avoir répondu correctement à chaque clause.
. Les clauses cochées ci-dessous doivent recevoir pour réponse oui-> pour que le document de certification soit émis.
. Les clauses non cochées ci-dessous doivent recevoir pour réponse <-non pour que le document de certification soit émis.
. Toute réponse invalide interrompt la procédure de certification et présente le message suivant :
« Attention vous n’avez pas répondu correctement à la question. Nous vous invitons à relire l’ensemble des engagements forgerons et à en discuter avec d’autres forgerons avant de retenter de certifier. »
Globalement, dans le principe ça me va de mettre en place un tel document d’engagement.
Ce qui m’embête, qui est également vrai pour la « licence Ğ1 », c’est l’implémentation dans les logiciels :
Pour moi ça devrait être un document unique avec ce à quoi s’engage l’être humain. Pas de questions piège. Le document lui est proposé, il le consulte ou pas, mais doit tout accepter d’une traite. Pas une implémentation avec des questions aléatoires auxquelles il faut répondre positif ou négatif selon la question, autrement tu es bloqué pour aller plus loin et tu dois recommencer la procédure. Comme lorsqu’on accepte les Terms of Condition (ToC), on coche une case est c’est fini.
Il y a deux grandes sections. Engagement forgeron et engagement certificateur forgeron. Je pense que ça devrait une et même chose. Ça duplique quelques points que j’ai zappés, car c’est déjà assez long. Être forgeron et parrainer de nouveaux forgerons sont deux droits distincts, mais au final c’est globalement la même chose, deux faces du même objet, les mêmes responsabilités. Ça permettrait de raccourcir le document.
Dans le cas où la personne est intéressée par le contenu, elle préfèrera lire un texte cours et résumé. Pour ma part, j’ai bien voulu lire le contenu pour apprendre des choses sur le fonctionnement et les bonnes pratiques.
Je vote positif, car ça apporte quelque chose. Cependant, j’aimerais que mes points soient considérés à l’avenir pour l’évolution de l’engagement. Je ne compte pas m’occuper de porter ces changements.
Merci de demander une review et d’obtenir une approbation sur la MR en plus du vote avant de merger. Note, cette MR inclut le document comité technique et est assez bordélique.
Je te rejoins sur la duplication qui n’est forcément très heureuse.
Je suis plus mitigé sur le coté ToC sans checklist, mais on pourra en rediscuter.
En tout cas totalement ok pour considérer tes points pour faire évoluer l’engagement forgeron.
Je viens de clôturer la MR, elle était en effet obsolète et bordélique.
Ok pour demander une review et attendre une approbation sur la MR en plus du vote (sauf s’il n’y a aucune remarque non prise en compte pendant + d’une semaine), afin que l’intégration de l’engagement forgeron soit proprement fait sur le dépôt.
Je pense que les 150 votants ne sont pas représentatifs de toute la toile de confiance.
Ainsi ma requête serait :
Commençons ainsi en V2 mais, par exemple au mois de juin, refaisons un vote sur cet engagement forgeron, avec une large information auprès de la toile de confiance.
Une fois les junistes adaptés à la V2, ils seront plus disponibles pour comprendre cet engagement forgeron.
Merci
Si tu ne considère valable que des décision validé par plus de 50% des membres de la toile de confiance, (ou plus de 80%, je ne sais pas quels sont tes convictions à ce sujet), je te laisse essayer.
Personnellement, si je veux rendre des processus davantage démocratique que technocratique, je fait avec l’existant : une communauté dont le pourcentage de membre impliqué est faible et dont les plus actifs s’épuisent à tenter le moindre changement, et des cannaux de communication qui ne permette de contacter qu’une petite fraction de la communauté.
Si tu es capable de proposer et mettre en place mieux, fait donc, j’en serai sincèrement ravi, et je te suivrai probablement.
Pour ma part, j’ai essayer de concevoir un système de vote qui à défaut d’avoir beaucoup de votant, implique un pourcentage d’adhésion important parmis le votant, pour que s’il y a danger à valider une proposition, l’effort nécessaire pour bloquer avec des votes contre soit bien plus faible que l’éffort de trouver suffisament de personne pour noyer les contres.
Alors ne me fais pas dire ce que je n’ai pas dit.
Je ne fais que présenter des chiffres, un angle de vue objectif.
Sinon, et bien qu’ayant voté pour, je ne suis généralement pas partisan du moins pire ou du mieux que rien. Et c’est peut-être la raison pour laquelle il y a si peu de participation, la vraie majorité préferant probablement s’abstenir, plutôt que de donner du credit à quelque chose qui n’a rien de démocratique.
Je t’invite à experimenter le liquid feedback, qui a l’avantage d’avoir été éprouvé depuis des années. Bien qu’imparfait, il permet de réduire les risques de dictature des « actifs » car une proposition n’a de chance d’être soumise au vote que si elle est reconnue pertinente par, par exemple, 10% de la communauté.
