Les évolutions à intégrer pendant la migration

Bien que dans l’idéal j’aurais préféré migrer le protocole Duniter tel quel dans Substrate par simplicité et pour éviter des régressions dues à des nouveautés, j’ai identifié quelques sujets pour lesquels nous pourrions faire exception.

J’aimerais votre avis.

En préambule : je précise que de toute façon la migration implique un changement du format des données (blocs, identités, certifications, etc.) et que donc la migration se traduira par un hard-fork et une réécriture complète par rapport à Duniter v1 (à l’exception du module de calcul de WoT déjà écrit en Rust dans Duniter 1.8).

Qui dit réécriture, dit occasion de faire mieux : et à ce jeu-là, certains pans de Duniter v1 peuvent être suffisamment problématiques pour vouloir les abandonner à l’occasion de la migration.

Voici ceux que j’ai identifié :

8 « J'aime »

Un message a été scindé en un nouveau sujet : La gouvernance du Runtime (bis)

Merci pour cette liste, j’ai donné un premier avis à chaud sur chacun des sujets :slight_smile:

Il me semble qu’il manque quelques points qui doivent être discutés si on veut que cette migration devienne effective:

  • La rémunération des créateurs de blocs ? Est-ce qu’on recode un remuniter, ou est-ce qu’on l’intègre au protocole ? Remuniter c’est centralisé, le propriétaire du bot remuniter peut partir avec la caisse. Et techniquement c’est assez simple d’intégrer la rémunération au protocole, on peut même conditionner cette rémunération aux dons sur un compte dédié pour garder le même « comportement apparent » (mais sans le risque qu’un opérateur central se barre avec la caisse).
  • Le UsedID: est-ce qu’on le garde ou on le supprime ?
  • Les commentaires de transaction ? Par défaut il n’y en a pas dans substrate, on peut les ajouter, ou décider que c’est enfin l’occasion de les stocker offchain ?
  • Le stockage des données de profil Cesium+ ? Est-ce qu’on gère ça coté nœud substrate ou est ce que l’on code un autre logiciel dédié pour ça ? comment on architecture ça ? DHT publique globale ? Comment on évite le spam ? Service payant ?
  • L’indexation (ou historisation) des données ? Est ce qu’on utilise Hydra ? Si oui qui s’occupe de mettre en place des indexers Hydra ? Qui s’occupe de coder des processors typescript ? Voici des parties essentielles ou l’on a besoin de contributeurs!

Certains points ne concernent pas directement le protocole du cœur, mais ils sont tout de même nécessaires à la migration, c’est tout l’éco-système technique de la Ğ1 qu’il faut migrer, notre réflexion doit être globale :slight_smile:

1 « J'aime »

Oui il y a @slaivyn qui avait commencé à s’y atteler, mais il est en attente de réponse depuis le 27 septembre.

1 « J'aime »

Merci du rappel, je viens de lui répondre, mieux vaut tard que jamais :yum:

2 « J'aime »

Ce serait bien de pouvoir faire des commentaires UTF-8, pouvoir mettre ou associer un/des liens ou un json, ajouter des metadata…

Avec les frais de transaction, je ne suis pas sûr qu’on ai encore besoin d’un Remuniter. Si toutefois c’était le cas, oui, je préférerais un automate onchain.

Mon avis est qu’il vaudrait mieux le garder.

Je ne suis plus tellement favorable à leur présence.

Quel est le problème ?

Réflexion globale oui, migration totale non. On a une contrainte matérielle forte : la main d’œuvre.

Par contre on voit qu’il commence à nous manquer des outils pour suivre cette migration et n’oublier aucun élément. Quand j’aurai terminé le cadrage, je vais m’atteler à ce point avec notre GitLab.

1 « J'aime »

Il y a aussi une fonctionnalité inutilisée jusqu’à maintenant de Duniter v1 : l’AtomicSwap.

J’ai vu qu’il existait déjà une palette toute faite, je serai d’avis de l’intégrer dès la migration vu qu’elle est très simple et livrée clés en main.

1 « J'aime »

Je ne vois pas le rapport, les éventuels frais ne rémunèrent pas forcément les créateurs de bloc, ils peuvent alimenter une trésorerie commune gérée par les membres, ou encore être purement brûlés, ou tout autre traitement.

On avait discuté avec @kimamila cet été et il me semble qu’il ne souhaite pas migrer les pod cesium+ pour supporter la migration sur substrate, mais en profiter pour trouver une meilleure solution pour le stockage des profils des utilisateurs, c’est une fonctionnalité qui me semble essentielle, la migration ne peut pas être effective tant que l’on ne sait pas comment on fait pour gérer ce type de données.

Personnellement j’utilise le « issues board » de dépôt duniter-v2s, j’y ajoute les taches au fur et à mesure: Development · Boards · nodes / rust / Duniter v2S · GitLab

Je compte utiliser ce board de plus en plus, il devrait justement permettre de « suivre cette migration et n’oublier aucun élément »

Hop, je viens d’ajouter une tache pour ça dans le board.

Oui enfin c’est quand même l’idée de base pour motiver la présence de producteurs de blocs dans toutes les blockchains où le minage est/devient minoritaire.

Ce n’est pas mon cas, en tout cas je ne trouve pas que ça justifie un blocage du déploiement de la migration sur la Ğ1.

D’accord, ça va aller si je rajoute 100 tickets dedans par exemple ? Et puis savoir comment ça peut se passer au niveau découpage.

J’aimerais bien qu’on planifie davantage, d’abord ce ne devrait pas être si difficile et en plus ça peut permettre de faire rentrer de nouveaux développeurs en leur offrant de la visibilité et un cadre, afin de ne pas laisser s’éroder le courage ou la motivation.

Personnellement j’ai eu 1 mois de dispo pour creuser beaucoup de choses pour cette migration, mais je n’aurai pas davantage. Ma stratégie c’était de réaliser la conception de ce qu’il y avait à faire, et de consigner tout cela à travers :

  1. Le protocole en tant que référence générale
  2. Des tickets formant un backlog

Mais là tu arrives et sembles vouloir tout faire, tout en admettant avoir une disponibilité toute relative.

Donc, on s’organise comment ?

1 « J'aime »

Pour moi ça le justifie, mais d’ici qu’on soit prêt à migrer de l’eau aura coulée sous les ponts, et j’ai bon espoir que ce point aura été résolu entre temps, il faut toutefois en parler dès maintenant :slight_smile:

Hum 100 tickets ça me semble un peu trop fin comme découpage, et bien trop tôt pour découper si fin, on ne va pas s’y retrouver, je préfère que ça reste regrouper en quelques gros tickets, avec éventuellement des détails au soin de chaque ticket.

En fait on ne fonctionne pas pareil, je trouve que tu veux trop fixer les détails trop tôt, moi j’ai besoin de d’abord expérimenter, avancer suffisamment sur une implémentation avec à peu près toutes les fonctionnalités essentielles, lancer une monnaie de test, avoir vos retours, et en fonction de vos retours, on affine, on précise, on refactor le code.

Je ne suis pas en capacité de planifier aussi précisément que tu le voudrais, et je pense même que c’est une mauvaise pratique. Il me semble préférable d’avancer avec un cône d’incertitude, donc avoir uniquement le gros des idées, les axes principaux, et préciser au fur et à mesure qu’on avance, en tout cas c’est comme ça que le travaille, et c’est comme ça que je vais avancer, au rythme de mes dispo.

Tu rigoles ? C’est exactement comme ça que j’ai codé Duniter v1. :slight_smile:

Mais justement, je l’ai codé pratiquement tout seul. Et là tu es parti pour faire la même chose. C’est curieux car il y a un an ou deux, tu faisais et disais l’opposé, en voulant tout comprendre avant d’agir.

Ce que je crains avec ta nouvelle approche, c’est que tu ne tombes dans le même piège que moi, à savoir ne pas créer les conditions permettant à d’autres de contribuer.

Alors oui, c’est sûr que si tu es là il n’est pas décisif que je planifie un maximum de choses au plus tôt.

Néanmoins quand je vois que j’ai mis 3 semaines à correctement rentrer sur Substrate et voir comment articuler Duniter dessus, je me dis qu’il faut mettre tout de suite en place de quoi aider d’autres contributeurs à nous rejoindre, au risque de nous isoler.

Je ne sais pas, n’as-tu pas cette impression ? D’être dans un niveau d’expertise élevé ?

3 « J'aime »

Je ne veux pas tout faire, de toute façon je ne pourrais pas, j’ai besoin d’aide, mais ce dont j’ai besoin c’est de gens motivés pour mettre les mains dans le code, que je les forme à substrate, et qu’il puisse apporter leur pierre à l’édifice, comme l’a déjà fait un peu @tuxmain, et j’espère qu’il continuera :slight_smile:

je ne peux pas dire à un contributeur tout ce qu’il devra faire dans les moindres détails, car le seul moyen pour moi de le savoir, c’est de le coder, je ne peux donner que l’idée générale, et des pistes sur quelles briques utilisées, mais les contributeurs doivent ensuite réfléchir par eux-mêmes et puis discuter, échanger, avec moi et les autres contributeurs, au fur et à mesure, pour préciser.

Je veux toujours tout comprendre avant d’agir, mais comprendre ne signifie pas spécifier ultra précisément. Je ne code pas dans le vide, je comprends tout ce que je fais, mais je ne découvre les détails d’implémentation que au fur et à mesure que j’écris le code.

Pour moi cela venait de plusieurs raisons, dont ton manque de disponibilité ou de disposition, à faire des visio avec les nouveaux contributeurs pour les onboarder, pour les former, et un code trop difficile à cerner.
Dans mon cas, je serais ravie de passer du temps en visio avec les intéressés pour les former et les onboarder, comme je l’ai déjà fait un peu avec tuxmain, je préfère former en one to one que coder, et je préfère coder que discuter par écrit ici.
Aussi, il me semble qu’il est beaucoup plus facile d’entrer dans le code de duniter-v2s que dans celui de duniter v1, car c’est normalisé selon le framework substrate, qu’il y a beaucoup de doc sur ce framework et beaucoup d’autres projets qui l’utilisent.
un développeur qui connait déjà substrate pourra entrer facilement dans duniter-v2s, ce qui n’était pas possible pour duniter v1.

Si tu penses que le manque de contributeurs à duniter v1 était lié à un manque de planification, je pense que tu te trompes totalement dans le diagnostic.

Je pense que les discussions que tu ouvres sur le forum sont utiles pour la plupart, c’est bien de commencer à discuter de tout ces points, par contre je suis opposé à l’idée de commencer à spécifier formellement un nouveau protocole, j’en serais capable si je codais tout from scratch, mais là on ne fait pas tout comme on veut, on dépend de substrate.

Et comme je veux que notre implémentation de duniter-v2s soit la plus simple possible, ça impliquera parfois (voir souvent), de spécifier en fonction de la manière la plus simple de faire dans le cadre de substrate, et ça je ne peux le savoir précisément qu’après avoir codé.

je pense que la bonne manière de faire c’est de partir des usages cotés utilisateur, de commencer par savoir qu’est-ce qu’on veut comme expérience utilisateurs, comme fonctionnalités métier, après on implémente ces fonctionnalités métier, ensuite on teste et on intègre les retours jusqu’à avoir quelque chose de satisfaisant.
Et enfin en dernier on spécifie formellement le comportement effectif de l’implémentation, ce qui permet de lever les ambiguïtés et de rédiger des tests plus poussés pour s’assurer que l’implémentation fait exactement ce qu’on pense qu’elle fait, c’est la phase de stabilisation, pour moi c’est la dernière phase, pas la première.