Mais qu’utilises-tu sur la ĞT qui ne serait déjà disponible sur la Ğ1 ?
Sauf à vouloir tester les documents de WoT sans utiliser sa vraie clé membre, il me semble que tout est déjà faisable dans la Ğ1. Et même pour ces documents de WoT, il y en a déjà largement assez sur la monnaie de prod. De plus, l’hétérogénéité des données est censée y être plus élevée vu le nombre d’utilisateurs.
Pour la durée de synchro, il suffit sur la Ğ1 de limiter celle-ci à un certain nombre de blocs.
Sur la migration des clefs, Ğ1 ou ĞT, il me semble qu’il n’y a pas grand-chose à faire justement : les clefs sont réutilisées telles quelles, il y a toutefois un travail côté wallets pour permettre de parler le « langage » Substrate avec la notion d’adresses (c’est un format qui associe à une clé publique une adresse, dérivable à tout moment par n’importe qui).
Je peux me tromper, mais je ne vois pas ce qui poserait problème
Je pense qu’il veut parler des format de génération de clés salt/password contre mnémonique non ?
Ça fait plusieurs semaines que j’y pense, je ne vois pas de moyen simple de faire si on est tous d’accord pour passer au mnémonique.
On pourrait n’autoriser que les comptes membres dans le client, avec une UX pour ne pas renouveler son adhésion mais plutôt la renouveler sur un nouveau compte dérivé mnémo.
Pour les portefeuilles on peut interdire l’import mais permettre le transfert vers un portefeuille dérivé local.
Pour le moment j’ai juste désactivé les salt/password en attendant qu’on se mette d’accords sur une marche à suivre.
Je pense justement que Elois compte sur e fait qu’on ai plein de Fake clé membre en GT pour tester les comportements, et aussi que les durées y sont compressés.
Il a calqué certains paramètres de la gdev sur ceux de la GT en prévision de la migrer en premier.
Ça fait partie de sa roadmap.
Perso je suis toujours ceinture et bretelle sur tout mes projets (certain diront parano ).
Mais je pense que à part renouveller les certifs, mon noeud gtest n’est pas une charge à maintenir sur mon serveur perso. Donc je garderai tout en attendant la migration, sait-on jamais ce qui peut arriver, un Ǧproblème sur la Ğ1 ?
Pour la conversion des compte Ğ1, c’est déjà géré dans Tikka comme ceci :
On rentre nos identifiants qui crée une seed.
Je crée une keypair V2S à partir de la seed, en ED25519.
La clef privée est stockée chiffrée et protégée par un mot de passe, comme les comptes V2S.
La seule différence est SR25519 pour les nouvelles clefs V2S et ED25519 pour les clefs issues de Ğ1.
Les identifiants ne servent que comme le mnémonique pour réimporter son compte.
Comme vous voulez pour garder la ĞT ou non. Si on la garde je testerai d’abord les migrations dessus.
Mais de toute façon je serait obliger de tester sur la Ğ1 dans tout les cas.
C’est vrai que moins on à de réseaux à maintenir mieux c’est, mais si certains sont motivés pour maintenir des nœuds sur la ĞT ça peut être utile oui
@poka en termes d’UX tu peux proposer un menu “importer un compte Ğ1v1”, pour gérer l’import des comptes existants.
Mais pour la création de nouveaux comptes, ne proposer que le mnemonic, c’est une bonne manière de rendre deprecated l’ancienne méthode de génération de seed.
Oui mais dans les faits ce sont plutôt la Ğ1 elle-même que je scrute, puis j’utilise les tests automatisés pour reproduire l’anomalie avant de la corriger. La ĞT ne m’a jamais servi sur ce point.
Oui voilà, c’est une histoire de wallet et d’éventuel import de l’ancienne version qui reste compatible.
Oui perso je me concentre sur la Ğ1 et la ĞDev, j’ai déjà plusieurs serveurs sur ces 2 réseaux, je ne peux pas en plus maintenir un serveur sur la ğ1-test, ça me fait trop.
Et je suis d’accord avec @cgeek sur l’utilité toute relative de cette monnaie désormais, si d’autres ont l’énergie de la maintenir je testerai peut-être la migration dessus, mais ça n’apportera pas plus de fiabilité car je testerai de toute façon la migration sur la Ğ1 de très nombreuses fois jusqu’à maîtriser parfaitement le processus, avec vers la fin une « marche en double » de plusieurs mois.
Mes nœuds utilisent le strict minimum de CPU, c’est pour ça qu’ils ne forgent que très peu de blocs. Je peux augmenter un peu au besoin. Perso, je préfère garder la GT jusqu’à ce qu’on ait migré en v2 (ceinture, bretelles et ). Ça permet des tests parfois un peu « osés », « pour voir ». Il me semble que matograine l’avait utilisé une fois à cette fin. J’ai 6 identités dessus, au pire je peux continuer tout seul si personne n’est motivé, c’est en place, ça ne me coûte pas grand-chose. Et si ça peut permettre à Éloïs de faire des premiers tests pour la migration, tant mieux. Va falloir que je me mette au jus pour mettre en place des nœuds v2 mais là je suis vraiment sous l’eau, ça va attendre un peu.
Comme le dit Elois, c’est pas vraiment utile pour gdev, par contre on sait jamais si une autre tuile surgit sur la g1, avant l’arrivée de la V2. C’est juste pour ça que je continue (tant que c’est pas trop d’efforts, hein ! )
Pareil, pas spécialement d’effort pour maintenir mon nœud GT, alors je le laisse tourner.
Pini, tu peux réduire la puissance de ton nœud, jytou et moi les faisons tourner avec peu de ressources.
Il y avait de la concurrence avant le retrait de cgeek et autres, c’est apparemment plus le cas.
J’ai un cœur à 5 %. Un redémarrage devrait le relancer un peu la PoW, car pour une raison que j’ignore, la PoW s’embourbe avec le temps qui passe, c’est ainsi que fonctionne duniter v1.
Mes nœuds sont à 1 % (ils étaient à 0,03 % avant, d’où le peu de blocs forgés ). Sinon j’ai un cron pour arrêter chacun de mes nœuds chaque jour (chacun à une heure différente) car j’ai aussi constaté que sans ça ils finissent par s’embourber (et accessoirement manger un peu plus de mémoire).
Ah si ça a eu une sacrée incidence sur le nombre de blocs que mes nœud forgent… ils n’en forgeaient quasiment pas avant, maintenant ils en forgent presque trop… je vais peut-être redescendre un peu le paramètre…
).
). Sinon j’ai un cron pour arrêter chacun de mes nœuds chaque jour (chacun à une heure différente) car j’ai aussi constaté que sans ça ils finissent par s’embourber (et accessoirement manger un peu plus de mémoire).