Dans le but de rendre cette migration le plus agréable à vivre pour les utilisateurs, nous pouvons tout à fait anticiper beaucoup d’étapes avant le jour J.
A partir du moment où les clients comme gecko, tikka ou cesium² ouvrent leurs portent aux beta-testeurs sur ĞTest, des fonctionnalités de “pré-réservation” (ce n’est pas le bon terme, ce n’est pas une réservation mais plutôt une déclaration d’adresse) d’adresse v2s peuvent êtres implémentés côté client.
Il suffit pour cela de proposer de réserver un portefeuille de son coffre pour son actuel compte membre Ğ1 ou simple portefeuille Ğ1. Le client signe un document avec les 2 clés (v1 et v2) et envoi ce document quelque part (pas forcément en blockchain, sur un serveur, je sais pas encore, peu importe).
Je vois 2 effets de bords non bloquants:
Les prefix ss58 ne seront pas les mêmes entre ĞTest et Ğ1v2. Il suffit alors d’afficher la bonne address avec prefix Ğ1 à l’utilisateur sur l’écran de pré-migration. Ce n’est que de l’affichage, UX.
Nous prévoyons une continuité dans l’historique des transactions de chaque pubkey Ğ1. Il suffira de prévoir ces swaps d’adresse côté genesis indexers.
Je suis persuadé qu’ouvrir les beta-tests ĞTest au grand publique le plus tôt possible ne peut qu’être bénéfique pour nous (les dev). Ca nous permettra de nous projeter beaucoup plus facilement, et d’imaginer des choses de ce type dans l’optique de lisser un maximum cette migration dans le temps.
Un autre avantage de faire ça est d’éviter que des milliers de personnes migrent leurs comptes Ğ1 d’un coup juste après la migration, avec réservation de idtyindex et transactions en BC qui peuvent être évités (bon c’est un bien maigre avantage, je veux bien vous l’accorder).
Si cette proposition convient à tout le monde après discutions, je veux bien me charger de:
Concevoir (avec vous) ce système, finir de cadrer les effets de bords.
Intégrer ce parsing de document côté py-g1-migrator (swap d’adresses genesis à partir de la liste des réservations signés)
Je me demande si ce n’est pas un poil prématuré.
Pour les tests et le debug, je n’hésiterai pas à communiquer ma phrase de récupération, si cela doit être celle de mon compte final, cela me semble problématique.
non non, tu ne dévoiles rien, tu signes un document dans le logiciel client (en qui tu dois avoir confiance car tu lui donnes tes identifiants v1 et v2).
Ce document électronique signé est envoyé sur une base de données.
Lors de la migration, ton compte v2 « réservé » sera automatiquement créé avec ton identité et ton solde issus du compte v1.
Les personnes qui n’ont pas fait cela auront un compte « v1 » sur la v2 avec la même clef publique qu"en v1, ce qui empêche de faire plein de choses (dont les dérivations) et avec les vieux identifiants souvent faibles. Il devront créer un compte v2 puis transférer le compte v1 sur le v2 dans le client, pour bénéficier de la sécurité du mnémonique et des dérivations.
Ce que je voulais dire c’est qu’en phase de test et debuging j’ai pu donner ma phrase de récupération à Poka pour qu’il puisse tenter de reproduire un Bug. Parce que je sais que cela ne sera pas ma phrase de récupération réelle.
Cela me semble plus problématique si cette phrase devait être la phrase que j’utiliserais dans la Ğ1V2.
C’est pour cela que je dis que cela me parais prématuré. Mais si c’est possible jusqu’au dernier moment de changer de clé destinataire (au cas où je l’aurais fourni pour un debug), cela me convient.
Effectivement, il faudra bien préparer cela, et communiquer sur les adresses à réserver lorsque le système sera en place sur les serveurs et les clients. Et je pense qu’il faut complètement le dissocier des phases de debug pour moins de confusion, avec si possible le numéro dédié à la June en entête de l’adresse v2.
Oui vous avez raison, il faut totalement dissocier les alpha-test GDev des bêta-test GTest.
On ne permettra cette pré-migration côté client uniquement quand tout sera carré de notre côté, et claire côté client (plus de mnemonic de test, code secret de production…)
En réalité cet écran de pré-migration pourrait aussi se faire côté Césium V1 dès maintenant.
Après, ça peu aussi ne pas être intégré à Ğecko, mais plutôt dans un outils de migration (une page web connecté à G1Compagnon) dédié à ça uniquement, en microservice.
Ca aurait l’avantage de:
Beaucoup moins de boulo d’intégration
Ne pas confondre mnemonic de test et de prod
Être plus clair en terme de communication, cette page peut détailler tout le truc sans que ça soit trop dense au milieu d’un client complet
Cette page pourrait très bien aussi accueillir tout un tas d’informations complémentaires concernant la migration, être tenu à jours avec son évolution, ect …
@ManUtopiK Ğ1Compagnon serait en faite hyper pratique pour ce cas là, car il permettrait de signer directement un document reçus d’une page web avec les 2 clés v1 et v2 en même temps, vue que tu le conçois ainsi de base
Je trouve que c’est une fausse bonne idée, sauf à inviter seulement les utilisateurs les plus avertis et uniquement sur les forums voir uniquement le forum technique.
La communication “tout utilisateur” doit rester la plus simple possible, avec un seul appel à l’action à la fois. Toute complexité supplémentaire dans ce que l’on demande à l’utilisateur lambda doit être justifié par une nécessité technique non contournable. Or ici l’étape supplémentaire proposée n’est pas du tout requise techniquement (sauf pour les forgerons au genesis).
Ca ne sert à rien de vouloir éviter ce traffic blockchain tout à fait absorbable, il y aura de toute façon bien pire dans la vie de la G1v2
C’est une très mauvaise idée, qui amène de nombreux inconvénients pour rien, ne perdez pas plus de temps de conception là-dessus, vous avez déjà bien assez de boulot
Qu’est-ce qui te fait dire ça ? De quoi parles-tu exactement, je vois que ce n’est pas clair de ton côté.
Oui, et donc ?
Dans ce cas j’arrête gecko, les gens n’auront cas utiliser polkadot.js directement.
C’est con parce-que le but de tout ça est justement d’effacer la complexité pour l’utilisateur, tu ne te rends pas compte de ce que tu demandes aux gens en disant “Créer un coffre à gecko, vous avez une nouvelle address, maintenant migrer votre ancien compte g1 vers cette address”.
Moi je propose beaucoup plus simple ici.
Et oui, et oui.
Propos tronqué.
Peux tu nous citer au moins 1 inconvénient à cette idée avant de dire ça ? Je n’en vois absolument aucun dans ta réponse très vague.
Veux-tu qu’on s’appel pour que je t’explique plus en détail ce que tu n’as pas compris ?
Rien de rhétorique là dedans, vraiment, je suis pas du tout faché contrairement à ce que mes écrits pourraient laisser croire
Juste fatigué de devoir répéter toujours les même choses, surtout quand on se prends ce genre d’invective infondé dans la tronche, sans aucune volonté d’essayer de mieux comprendre le point de vue en face. Plus simple et rapide à l’orale.
Sinon attends quelques semaines que ce soit en place, je comprends qu’on puisse avoir besoin de voir pour comprendre, je suis pareil parfois.
Par contre ce n’est pas dans le top de mes priorités actuelles donc tu vas attendre un peu.
Sinon quelqu’un d’autre veut bien expliquer à @elois ce qu’il ne semble pas avoir compris ?
J’ai déjà perdu trop de temps à essayer de lui expliquer, c’est trop chronophage pour moi.
Rien d’urgent hein, pas pressé tout ça.
D’après ce que je comprend l’utilisateur lamba pourrait
. réserver à l’avance sa clé Ğ1V2
Cela implique qu’il se crée une phrase de restauration, qu’il devra utiliser au moment de l’installation de son client Ğ1V2 pour récupérer son compte
. Se connecter avec cette phrase de restauration/récupération et son id et mdp Ğ1V1 pour signifier le transfert entre les deux pour la future migration.
Après la migration, il vas devoir utiliser la phrase de récupération préalablement mémorisée, il faudra insister sur le fait que cette phrase est celle définitive (même si on est encore enphase de test). Avec le risque que certain ne l’ayant pas bien compris ai oublié perdu cette phrase, avec le risque que les personnes ayant fait plusieurs fois la manip ne sachent plus quelle est la bonne phrase.
Avec le risque que pendant la phase de test, l’utilisateur communique sa phrase de récupération pour aider au débug.
L’utilisateur lambda ne fait pas la différence entre alpha-test, bêta-test et pré-prod…
Je trouve que cela fait beaucoup de risques, pour le seul avantage que je vois : éviter la surcharge du réseau juste après la migration. Et comme le fait remarquer Elois j’espère que le futur réseau sera assez solide pour absorber cette surcharge, s’il doit durer dans le temps, il faut qu’il soit capable “d’encaisser”. Maintenant, je ne sais pas de quel niveau de surcharge on parle, donc je vous laisse discuter entre spécialiste.
Mais je ne vois pas en quoi cette “pré-migration” soulage le travail des développeurs, puisque de toute façon l’outil de transfert de compte devra exister après la migration.
La question est plutôt faut-il que cet outil de transfert de compte soit intégré dans les applis de gestion de wallet ou totalement à part, car quelques années après la migration, il sera devenu inutile.
Comme d’hab, ceci est le point de vue d’un utilisateur benêt qui ne connait peut-être pas tous les enjeux du truc.
Non il n’a jamais été question de soulager le travail des dévellopeurs
Mais celui des utilisateurs, qui une fois la migration effectué, n’auront juste aucune action a effectuer
Et niveau taf côté dev, c’est 3 jours grand max, pas grand chose
Oui ça ça vaut avec ou sans prémigration.
Il ne faut pas demander aux gens de mémoriser leurs phrases de restauration @Maaltir , mais bien demander de la noter précieusement, comme l’app le suggère.
Tout à fait, à partir du lancement de gecko mobile, finit les mnemonic de tests et le code “triche”
Il faudra communiquer dès lors sur le fait que les phrases de restauration, ça se garde précieusement, c’est de la prod.
J’arrive (un peu) après la bataille, mais je ne sais pas pourquoi nous souhaiterions “migrer” les clés de Duniter v1 pour Duniter v2 ? Les clés publiques restent Ed25519, les clés actuelles de la Ğ1 sont donc compatibles avec Duniter V2. Les “adresses” ne sont qu’un emballage calculable à la volée fonction du réseau visé.
En réalité ce n’était pas dû à la migration substrate en elle même, mais du fait qu’on profiterait de cette migration pour proposer un changement de génération de clés côté clients pour des raisons de sécurité et de praticité: les mnemonics (avec ou sans dérivations).
Il convient donc en effet de bien distinguer les deux. Côté Gecko, pour le moment l’app propose de migrer les données associés à ses identifiants Cs (solde et identité) vers une dérivations générés à partir de mnemonic, donc l’idée était d’éviter que tout le monde fasse cela au même moment sur le réseau au moment de la migration. Mais avec le recule c’était trop de travail pour pas grand chose.
Vit a repris ce système de mnemonic, il me semble que Benoit avait commencé à calquer à peu prêt le même comportement sur Cs² en proposant une génération par mnemonic par défaut, mais en proposant toujours de générer par salt/password.
Depuis, je ne sais pas si les réflexions ont évolués de votre côté au sujet des mnemonics ou des methodes de générations de wallets, je vois que g1nkgo plait beaucoup dans sa manière de générer la seed sans présenter d’identifiant, donc je ne sais pas. Je ne participe plus à ces réflexions depuis un moment.
En bref c’est une question côté clients et non Duniter (d’où le titre, peut être dans la mauvaise catégorie du coup).
Un aspect pénible (client) du changement de clé associé à une identité est l’affichage de l’historique de transaction du compte. Exemple :
un utilisateur Ğ1v1 a comme clé publique A
les DU sont versés sur A, il effectue des transactions depuis A
au passage Ğ1v2, il garde son identité sur A et fait un virement à un compte B pour expérimenter la nouvelle méthode de génération de clé (mnemonic)
il utilise son compte B pendant un moment et, lassé de rentrer ses identifiants Cesium pour les certifications, décide de migrer son identité vers B
à partir de ce moment, les DU sont réclamés vers B
Quand il regarde l’historique de son compte B, il ne voit pas l’historique de son compte A.
C’est une problématique à la fois au niveau des indexeurs et des clients. Ce n’est pas grave, et de toute façon il faut prévoir un moyen d’afficher le changement de clé d’une identité si on veut le permettre, mais l’idée de permettre le changement de clé au genesis était d’améliorer l’expérience utilisateur dans la transition v1→v2 et identifiant Cesium → mnemonic.
Mais effectivement, on peut mettre de côté ce point et inciter les gens à continuer de gérer leur identité dans une appli compatible avec les identifiants Cesium et leurs comptes portefeuille comme ils le souhaitent.
En plus le changement de clé ne fait que bouger le DU, mais l’ancien compte reste exploitable en tant que portefeuille, donc à part les clients je ne vois pas bien qui serait compétent pour agréger le tout.
En effet ChangeOwnerKey ne concerne que l’identité, pas l’historique des transactions.
L’indexeur devrait juste conserver le changement d’identité sur les deux comptes concernés, et un client zélé pourrait aller chercher les transactions sur le compte précédent, mais plutôt dans une vue orientée identité avec comptes agrégés, que la simple vue portefeuille qui devrait rester simple et sans magie noire.
