Non, as-tu un exemple stp ? J’ai peut être juste oublié un filtre quelque part.
Si il faut que tu regardes tout en bas du json, il est très gros…
Il y a un bloc wallets après le bloc identities.
J’ai oublié de préciser qu’il y a 6 wallets en moins, ce sont en fait 6 pubkey qui font plus de 32 bytes, je ne sais pas comment les traiter pour les convertir en address ss58 du coup:
Ce n’est pas un bug, mais un design voulu, il ne sera possible de migrer que les membres de la wot Ğ1v1 qui sont effectivement membres au moment du snapshot, donc qui ont déjà 5 certifications ou plus.
Toutes les identités ayant moins de 5 certifications ne doivent pas être incluses, c’est pourquoi le paramètre genesis_certs_min_received doit être réglé sur 5, afin que duniter-v2s détecte les cas invalides et retourne la bonne erreur.
En bref, ce n’est pas un bug, mais une mauvaise configuration de ta part, car tu a fixé genesis_certs_min_received à zéro.
Pour quoi faire ? Il me semble que DuniterV2S n’empêche pas de réutiliser une adresse ou un pseudo dont l’identité a déjà été révoquée. (d’après mes souvenirs, une recherche dans le code et un test cucumber fait à l’arrache)
Je ne suis pas d’accord avec ça. Exemple concret :
Alice reçoit cinq certifications et devient membre
une année après, Alice certifie Bob
une année après, les certifications reçues Alice expirent et Alice perd le statut de membre
deux mois après on souhaite migrer la Ğ1 (il faut compter la certification de Alice vers Bob)
Donc pour le genesis Ğ1v2 il faut :
créer l’identité Alice (identity index = 1)
créer l’identité Bob (identity index = 2)
ajouter la certification Alice vers Bob (1 → 2) qui expire dans dix mois
retirer l’identité Alice (ses métadonnées et le nom “Alice”).
Autrement dit, les identités non membre ayant moins de 5 certifications actives reçues au moment de la migration (mais ayant émis des certification) doivent être incluses puis exclues.
Il faut filtrer les certifications dont la date d’expiration est antérieure à la date de migration (ne garder que celles toujours actives).
J’ai renommé ce repo, déplacé dans le groupe tools, ajouté licence et copyright.
Cela dit, je me demande si je vais pas recréer le dépôt de zero (init commit) car:
J’ai ajouté le build dex qui fait 29 Mo, je peux l’enlever du dépôt et faire en sorte de le télécharger automatiquement depuis quelque part lors de l’exécution de generate_dex_data.sh si le build n’existe pas localement.
Je pourrais déplacer le json final output/gtest.json (5.3Mo) ailleurs, genre dans output/default/ pour ne pas interférer avec les build générés au niveau du git.
Je veux que ce json soit présent simplement pour que chacun puisse y accéder comme Maaltir le fait, sans avoir à cloner ni exécuter quoi que ce soit. Je sais que normalement pour bien faire, ces fichiers générés ne devraient pas être présent dans le repo, mais avez-vous une meilleurs idée ?
Je peux déplacer intput/*json (74Mo) dans input/default/, également pour ne pas interférer avec les build locaux et le git. Je veux aussi que ces json soient présent de manière a pouvoir skip l’étape 1 pour ceux qui n’ont pas de profile Duniter localement.
Je peux fermer ce topic brouillon et en ouvrir un nouveau « Ğ1 data migration » qui présente mieux la chose et puisse ouvrir des discutions plus concrètes sur le format de données genesis v2s.
Je dis tout ça car le .git fait déjà 111Mo inutilement.
Qu’en pensez-vous ?
Je suis preneur d’avis et conseils sur ces sujets de design de repo (tout en prenant en considération mon besoin de garder les json générés par defaut quelque part comme je l’ai expliqué).
Je ne connaissais pas, ça à l’air super, j’ai essayé un peu, mais le soucis pour moi avec ça est qu’on se retrouve avec des fichiers du type:
$ cat input/blocs.json
version https://git-lfs.github.com/spec/v1
oid sha256:c9a89582cc2273240c46dbc4439e4d6c2caca44199662ee37e20573dfb3ddf95
size 28742754
et le fait que:
Il ne faut pas oublier que chaque personne qui interagira sur le projet devra suivre la procédure d’installation de Git LFS sur son environnement.
Tu peux générer le JSON avec la CI Gitlab en tant que fichier de Release. La CI de Gitlab se chargerait de télécharger Dex et de générer le JSON dans une Release.
Ou bien le téléverser manuellement sur le wiki Gitlab ou dans les Releases.
En effet ça me semble une meilleur approche étant donnée que ce sont effectivement des artefacts de release.
Pour le build dex par contre je pense garder mon idée de juste wget depuis un de mes serveurs dans le bash script qui va bien, c’est 2 lignes.
par contre faut que je comprenne comment config la CI gitlab… J’avoue que si quelqu’un qui connait un peu pouvais contribuer là dessus j’aimerai beaucoup. Sinon je mettrais les mains dedans.
Mais je rappel que pour le step 1 avec dex, ça nécessaite d’avoir le dossier ~/.config/duniter/duniter_default/ « à jours » localement, ça me semble difficile depuis la CI gitlab non ?
Ou a la limite c’est ce dossier qu’il faudrait ajouter en git LFS peut être ?
On peut bien sur définir un chemin custom de ce dossier avec l’option ./dex -p /path/to/duniter/profile
Après @vit si t’es chaud pour te réapproprier ce projet de manière générale sens toi libre
Ah oui, j’ai peur que recréer les données d’un nœud en CI soit long et gourmand en ressources… Je n’avais pas pensé à ça.
Mais je pense que les besoins d’exposer le JSON en public pour analyse et tests doivent être séparer du dépôt git. Un dépôt Git doit contenir que le nécessaire à compiler puis exécuter. Faisons cela, puis ensuite voyons comment publier le JSON. Si on peut automatiser sa génération en CI c’est bien. Sinon on devra le générer localement puis le téléverser quelque part pour publication.
Bon je regarde ça demain et ferai des propositions.
Je pense qu’un cron dex qui sort les json une fois par jour et les publie sur un serveur peut faire l’affaire. Je peux m’en occuper un de ces jours. Ensuite py-g1-migrator fait sa tambouille à partir de ces json. CI gitlab ou script cron, ça me paraît à peu près équivalent en terme de résultat.
Pas en terme de coût, on va pas lancer un noeud duniter, attendre qu’il sync avant de continuer chaque CI !
Ta proposition de publier les JSON Dex me semble idéal.
Il ne reste que le json genesis final à traiter en CI, et pas besoin de Dex pour ça, juste python
Bah écoutez c’est cool, @HugoTrentesaux fait ça, comme ça @vit peut virer dex et le dossier intput (le step 1 en fait) du repo, et juste config la CI pour ./main.py
Comme ça après ça, on pourra recréer le dépot git, fermer ce topic de forum et en ouvrir un nouveau
Pas nécessairement, du moins ce que tu proposes n’est pas le plus simple en termes d’implémentation coté duniter-v2s.
Je vous recommande plutôt d’ajouter simplement au genesis des “extra certs” sans identités associées, mais qui réservent quand même un identityIndex pour être prises en compte dans la règle de distance.
Ça permet de ne pas avoir à gérer d’identités bizarres coté blockchain que le runtime actuel ne sait pas gérer, et puis intégrer quelque chose au genesis pour le retirer juste après (au bloc 1) me semble être un très mauvais design, pas du tout compatible avec l’esprit de substrate.
Le plus simple coté runtime est de modifier le genesis build de la pallet identity pour autoriser le IdtyIndex à commencer à un nombre configurable (au lieu de zéro actuellement). vous pourriez alors configurer ce nombre au nombre d’identités qui n’existe plus mais qui ont encore des émises actives.
