Dans le cadre de la migration v2, une visio aura lieu le 2024-03-25T12:00:00Z pour définir la stratégie et coordonner les actions en vue de la version 2 de Duniter.
Le lien : https://meet.open.us.org/group/Axiom-Team/ (pas besoin de création de compte, il suffit de s’identifier)
Le pad : Visio 2024-03-25 - CodiMD
À destination des devs et utilisateurs avancés. Je ne m’occupe pas de l’ODJ mais laisse ce post en mode wiki
À qui s’adresse cette visio ? Développeurs, utilisateurs investis, tous ?
Salut !
Ça tient toujours la visio aujourd’hui ? C’est à 13h ?
Je pense que oui, @ManUtopiK ! Je serai là à 13h aussi…
OK, moi je vais essayer de suivre ça en conduisant. En fait je suis sur la piniche à Toulouse. Ma femme est à l’hosto (rien de grave) et je dois la prendre à midi…
Mettez le lien de la visio ici ou sur un autre topic !
Wala :
Note : Benoit sera absent.
Nous sommes connectés maintenant
Voici le pad de compte rendu : Visio 2024-03-25 - CodiMD
On a identifié des points concrets sur lesquels ils fallait travailler, mais on a également identifié les problèmes de raison d’être et de gouvernance du groupe de travail sur la communication.
Trop galère, je viens de rentrer. Désolé, pas pu être là. Je vais lire les pads…
Merci pour votre motivation !
Hello, à la suite des différentes vidéos publiés sur TG, des questions des utilisateurs/trices commencent à arriver…
J’ai donc ouvert ce PAD CodiMD - Collaborative markdown notes où je mettrai (en vrac, mode brouillon) toutes les questions et les réponses que j’essaye d’y apporter (quand je sais…).
Si ce n’est pas une bonne idée je peux supprimer 
Edit : autres idées pour ne pas perdre les questions qui arrivent ?
ola @italpaola , j’ai corrigé et complété ton PAD
Salut la bande,
Désolé d’avoir raté les 2 premières visios du lundi, alpagué par mon retour après 2 semaines déconnectées. J’ai lu les posts et les pads, bravo et merci.
En ce qui concerne ma contribution, voici ce que je peux vous proposer :
. de la rédaction à la demande, passez vos commandes si vous le souhaitez.
. une mobilisation sur “objectif lune : consensus sans fork”.
[ j’ai bien noté dans le pad du 25.3 que ce ne devait pas constituer le leitmotiv de comm, je comprends cette recommandation dans les règles de l’art, mais perso c’est cet objectif d’hugo qui me plait le plus et c’est pour moi le vif de sujet ].
Ma démarche peut être satellitaire (c’est-à-dire perso plus que vs. axiom), mais il y aura des convergences. Je propose par exemple :
. le lancement et le maintien d’une FAQ façon wiki (qui me semble être une bonne façon de répondre à la question de Paola et l’outil pourra potentiellement évoluer vers une sorte de “kowleddge center” après migration).
. un “cahier de doléances” pour traiter les craintes et les espoirs, les objections et les wishlists.
. un “panorama”, outil d’aide à la décision pour les forgerons, visuel.
RQ : le cahier de doléances recueille les expressions libres et toute la matière (sujets à craintes, polarités, échelles de priorités, …) permettant de “dessiner” le panorama. Cette matière première permet de concevoir des sondages puisés dans le réel, pour mesurer le poids et l’intensité de chaque tendance, position, préoccupation.
Ça peut démarrer par un post de type témoignage.
Brouillon :
RLM 18 - Migration v2s
Témoignage d’utilisateur
Le sujet de ces RML18 est la migration de duniter v1 dans un environnement plus solide et structuré, un framework du nom de substrate. On s’en approche doucement mais surement. Il est évoqué, avec grande prudence, une ligne de mire au 1er trimestre 2025.
Il y avait une quinzaine de devs et une demi-douzaine de junistes touristes comme moi, dont quelques piliers du groupe local de Mayenne. C’était donc une édition très studieuse, “entre devs”, ce à quoi aspirait pas mal Kimamila qui était le « porteur » de cette édition. L’heure est en effet aux calages et aux plans d’action.
Les devs ont tous des profils très différents, des positions et des postures variées, j’ai trouvé cette séquence de 3 jours à la fois amusante et instructive sur le paysage de notre écosystème technique. J’ai trouvé un équilibre relativement magique, entre les réflexions et les intentions. Je vais vous en donner plus loin un ou deux exemples très concrets.
Sans plus de préambule, je passe directement aux sujets qui peuvent fâcher certaines personnes, ceux qui peuvent inquiéter d’autres personnes.
Les devs ont choisi en 2017 de créer un réseau propre à nos 2 blockchains, donc de ne pas utiliser un réseau déjà existant comme polkadot ou solana. Ils choisissent aujourd’hui de continuer sur cette voie pour la v2. Substrate facilite et structure le dev et l’administration, mais on conserve notre propre réseau maison. Ce sont les fameux nœuds, avec derrière ces machines qui créent et signent nos blocks, les forgerons.
Aujourd’hui, les forgerons v1 ont tout pouvoir. En effet ce sont eux qui décident de mettre à jour leur nœud, ou pas. Dès que 2/3 des nœuds ont effectué la mise à jour, le réseau switche, les clients (Cesium, G1nkgo, Silkaj) se connectent aux nœuds à jour, tout le monde tourne sur la mise à jour.
Aujourd’hui il peut y avoir, et il y a eu plusieurs fois, des forks involontaires du fait que les forgerons zappent une mise à jour et qu’il faut donc « courir après ».
Première conclusion perso :
Quoi que l’on pense, dise ou fasse, la décision de migrer sur V2 appartient aux forgerons, à 100%.
=> l’idée selon moi est donc de leur donner les moyens … de décider.
Que leur faut-il ?
. Un document de référence, exhaustif et transparent de ce que contient le runtime upgrade.
. Une lecture fine et claire des positions, craintes et désirs de la communauté.
Comment produire cela ?
. Le document de référence doit être fait par les devs évidemment, mais dans un langage prosaïque. D’autant plus que ce document doit être compris par tous les curieux, car il est également le socle qui permet à tout un chacun de forger son jugement, donc à la communauté de se positionner.
[ l’intérêt d’un doc de référence est d’autant plus utile que les posts, les capsules vidéos, visios filmées, et autres formats vont être très nombreux, et qu’il sera facile de se noyer un peu, ou seulement craindre de rater de l’info ].
Les forgerons doivent réaliser par exemple, que cette migration a pour effet de distribuer le pouvoir. Leur abstention vaudra dorénavant validation (alors qu’elle était jusque là bloquante). Ils pourront toujours refuser une mise à jour, mais il devront le faire volontairement. Sinon, le collectif des devs pourra opérer la mise à jour des nœuds automatiquement. C’est d’ailleurs tout le propos et ce qui donnera un gage de fiabilité et de longévité à notre réseau.
Les forgerons doivent aussi réaliser que ce sera dans la symbolique version v1.10.1 que leur décision sera prise, car elle embarquera le killswitch qui permettra aux nœuds de basculer de concert, donc une migration instantanée de tout le réseau pour éviter bugs ou interruptions de service.
Cette distribution des pouvoirs techniques entre les forgerons et les devs est plutôt claire, elle tient dans le protocole du “runtime upgrade”, IN or OUT, c’est le cœur de ce pouvoir technique ou toute modif mineure comme essentielle est possible.
Mais au fait, c’est qui … les devs ?
A cet endroit c’est moins clair, et pour cause, nous quittons ici le code et la technique pour rentrer dans a belle nébuleuse de l’organisation … humaine.
Aujourd’hui “les devs”, c’est ledit "collectif des devs’', qui rassemble dans une belle indéfinition les codeurs et les admins présents, en fonction de leur mobilisation du moment, leur dispo, leur légitimité technique. C’est le collectif des devs qui a par exemple tenu le premier “cercle de répartition” pour affecter les euros collectés de nos dons (crowdfunding, helloasso axiom).
Aujourd’hui, émerge doucement le terme “Comité technique” pour donner corps à cette entité protéiforme, lui donner une figure plus institutionnelle, plus familière, plus reconnue. Rien n’est vraiment formalisé dans ce registre, mais il me semble qu’il va s’imposer puisque le gros changement de la v2 est cette distribution de pouvoir technique.
Comme je vois ce terme “Comité technique” s’inviter dans les CR et les Pads, je me demande s’il serait possible et préférable de continuer en mode “Collectif des devs” et d’institutionnaliser davantage un “Cercle de décisions” qu’un “Comité technique”, un protocole davantage qu’un organe statutaire. Je ferme la digression 
. Le second chapitre, brosser le paysage des positions de la communauté, est plus ambitieux encore. Car il ne s’agit pas de simplement trouver un format de vote pour dire oui ou non, il s’agit ici de brosser un paysage pour nourrir les décisionnaires, qui seront seul(e)s face à leur décision.
Le monde idéal est pour beaucoup d’éviter une sorte de schismo-genèse de la June. La communauté semble encore si petite et fragile que ce serait un coup dur ; cela apporterait en effet complication et confusion.
[ Toutes les personnes qui ont fait des présentations de la june verront bien de quoi je parle 
]
Parmi les devs, le plus fervent défenseur de la recherche d’un consensus, c’est Hugo pour ne pas le citer. Il est évidemment lucide sur le fait que rien ne puisse remporter une unanimité, et en vient donc à se demander quelle proportion de refus serait « cool », « acceptable », « contrariante » ou « rédhibitoire » (ces termes sont les miens, pas les siens ;-). Et c’est là que ça se complique évidemment, comment poser des chiffres là-dessus ? C’est déjà difficile de le faire pour soi, alors se mettre d’accord collectivement… mission impossible. Pire encore, une forte proportion des utilisateurs s’en fiche royalement, probablement ; le fameux biais de ladite majorité silencieuse.
Quelques devs pensent que c’est une impasse, que la communauté leur a fait confiance sur la v1, et qu’il n’y a pas de raison pour qu’elle ne suive pas sur la v2. Ce sont les mêmes personnes après tout.
Et voici un exemple très précis d’équilibre entre les différentes tendances et nuances, d’où émerge l’idée par exemple de produire de l’information structurée pour qu’on puisse tous s’y retrouver, celle de procéder à des sondages, mais aussi celle de donner les moyens à ceux qui veulent reprendre et poursuivre une v1.9, de le faire. Paquet cadeau pour que la liberté de choisir ne soit pas factice, même si ce choix leur parait étrange et illusoire.
Il ne m’appartient pas de commencer à structurer les différentes positions et arguments, même si j’en ai déjà identifié un bon nombre. On le fera à plusieurs à partir d’un cahier de doléances.
L’idée de ce cahier est de nous exprimer librement sur 3 questions :
. Ce que je ne comprends pas.
. Ce que je crains.
. Ce que je souhaite.
A partir de là on extraira tous les sujets, les polarités, les échelles de priorités, et on cherchera à restituer ça de façon visuelle (phase qualitative).
Dans un second temps, en plus de répondre aux interrogations, on procédera à des sondages pour visualiser le poids des sujets et des tendances (phase quantitative). L’idée serait de pouvoir changer ses réglages, ses positions, de voir ce panorama évoluer, jusqu’au moment de la décision par les forgerons.
L’idée de ce panorama est de présenter une image vivante de notre consensus, dans toutes ses nuances.
[ ouverture d’un cahier de doléances ]
[ ouverture d’une FAQ Wiki ]
[ expérimentation d’un panorama ]
[ recrutement dev dataviz (ManUtopik ?) ]
[ recrutement relais canaux ]
=> à lundi
ça vient d’ où cette info ? il ya au moins cinq versions qui tournent ensembles actuellement, elles sont compatibles sans fork
il faut aussi rappeler que tout les membres peuvent forger la v1 et détenir le pouvoir dont tu parles, ce qui donne au final une absence de pouvoir structurel
C’est une bonne remarque. Ces 3 versions dont tu parles ont été conçus pour fonctionner en parallèle sans changement cassant de protocole. Ce qui signifie sans hardfork.
Ce dont Yves parles, ce sont de mises à jours de noeud entraînant un hard fork, donc un changement de réseau.
a t on des exemple de telles versions de duniter
perso j’ en vois cinq concomitantes .9 .6 .7 .5 puis celles de tor aussi qui a son propre reseau et qui ne s’ accordent qu’ a un protocole commun non forké à ma connaissance (certaines ayant plus de six ans)
Non. C’est justement parceque les forgerons ont toujours mis à jours leur noeud sans poser de questions lorsqu’il y a eu des mise à jour cassante, pour débloquer la blockchain par exemple, c’est arrivé plusieurs fois.
Les forgerons font une confiance aveugle au code produit par les dev. Encore et toujours une histoire de confiance.
casser une version beta et forker sont différents ( on voit bien les versions qui tournent dans cesium en mode expert dans l’ onglet reseau )
ps/ @Yvv lorsque tu parle de fork à 2/3 c’est bien un fork, oui, ça signifie qu’ il y a une ou plusieurs transactions qui sont refusées par plusieurs mineurs ou bien un protocole ne permettant plus l’ interopérabilité qui émerge de la version mère sans y être compatible. dans la BC duniter il y une fonction pour résoudre les forks involontaires dûs à divers aléa du réseau et qui reprend la branche mère automatiquement. s’ il s’ avère que ce n’ est pas un fork involontaire, là tu peux parler de fork de version or ce n ‘est pas le cas, le protocole est le même pour tous les noeuds et les transactions/certifs aussi. j’ ajoute que lorsqu’ un client enregistre une transaction dans le cache de l’ appli ou du navigateur car il n’ est pas connecté réellement à la BC en direct, ce n’ est pas non plus duniter qui fork, c’ était dû au fait que le client ne changeait pas de noeud automatiquement et donc restait souvent sur de fausses données hors ligne
Coucou @ness, sois un chouïa patient.
Ce n’est pas dans ce topic que l’on va traiter les questionnements.
Lundi on avise sur la pertinence sur les modalités de mes propositions ; et si le cahier de doléances est validé, tu pourras poser clairement toutes tes questions, craintes et souhaits dans le cahier de doléances. Nous ferons le maximum pour tout traiter.
Ensuite tu pourras pondérer ce qui est très important, tu feras partie du “panorama” qui permettra aux forgerons de décider, en connaissance de causes et en coresponsabilité.
ok pour toi ?
je reformule donc. s’est on assuré depuis le début que tout le monde sache forger s’ il le souhaite et ainsi faire partie des décisionnaires de migration/modification tel que tu l’ exposes? non, pourtant faire tourner un noeud n’ est qu’ un wget et un duniter start donc que se soit en ayant freiné le déploiement de l’ usage de la BC ou en n’ ayant pas suffisemment publié en ce sens de montrer cette réelle simplicité, je sais pas mais visiblement les forgerons décisionnaires ne représentent qu’ eux même et pas du tout la communauté; c’est navrant mais c’est ainsi, nous avons mystifié la technique et du coup même poka se rend compte plus haut que les techniciens forgerons ne décident pas de leurs choix de façon exhaustive. face à celà perso je donne des noeuds à des membres en fracture numérique, ils s’ en sortent très bien pour taper les trois commandes avec la fleche du haut dans le shell d’ un viel android mais qui d’ autre que moi agit dans ce sens ? pour démocratiser réellement et démystifier tout ça
jte donne un exemple de priorité technique aujourd’ hui; transmettre la licence pour éviter que les gens tombent dans la piscine et le cas échéant empécher que le client le permette