Cela ouvre une autre question : si on n’a plus besoin de passer en sr25519 pour la v2, je propose que les clients (anciens et nouveaux) permettent de se connecter via la méthode d’authentification par “identifiant secret / mot de passe” (pour les comptes existants uniquement, pas pour les nouveaux comptes).
En effet, actuellement si un utilisateur lambda (je ne parle pas des forgerons) veut tester un autre client que Cesium (exemple : Gecko, l’extension de @ManUtopiK , etc.) sans avoir compris le concept de migration de compte vers une authentification par mnémonique (et ce que cela implique s’il veut continuer d’utiliser Cesium), alors il risque d’accepter la migration (pensant uniquement tester un nouvel outil), puis se retrouver perdu lors de son retour à son client historique.
À mon avis, une migration devrait lisser les changements impactant dans le temps, et faire d’abord une migration iso-fonctionnelle + ajouts fonctionnels, plutôt que de retirer des fonctionnalités.
Par exemple, on pourrait envisager de communiquer sur la dépréciation de l’authentification par “Login/pwd“ après la migration Duniter v1/v2, en donnant une deadline (genre 6 mois) avant l’arrêt total du support de cette méthode…
Dis autrement, il faut à mon avis favoriser l’interopérabilité des clients, dans leurs méthodes d’authentification. Sinon, il faudra assumer que “Tester un nouvel outil = Changer sa manière de s’authentifier pour tous les autres clients”. Personnellement, j’aurais du mal à le faire…
Je ne suis pas d’accord avec cette analyse.
De mon point de vue, il est plus simple d’expliquer aux gens que la mise à jour v2 s’accompagne d’un changement de format de génération de portefeuille.
Rien que la phrase :
porte à confusion si l’utilisateur pouvait déjà utiliser son id/pwd sur la blockchain g1v2. Que signifie « compte v2 » dans ce cas-là ?
Dans Gecko, j’ai tout mis en œuvre pour proposer un tunnel d’onboarding cohérent pour les junistes actuels.
L’app les informe que pour utiliser leur compte g1v1, ils doivent d’abord créer un coffre (tunnel).
Puis, une fois dans leur coffre, un bouton bien visible leur permet de migrer leur compte id/pwd vers l’un de leurs portefeuilles.
Une fois cette étape passée, on est sur de bonnes bases.
Ainsi, pour les gens : id/pwd = v1 (ancienne façon de faire), et phrase de restauration = v2.
Si on propose d’utiliser le « mode v1 » sur la v2, je trouve ça bien plus confusant que ce que je propose.
Étant donné les adresses ss58, dans tous les cas, leur « RIB » va changer.
Continuer à montrer les pubkeys en plus des ss58 ne fait, selon moi, qu’ajouter à la confusion de ce mélange. Votre proposition induit une migration à plusieurs étages pour le user, étalé dans le temps. Il devra migrer deux fois en quelque sorte, car même au début, sont RIB va changer dans tous les cas.
Enfin, dans Gecko par exemple, l’architecture entière ainsi que l’UX sont construites autour des coffres, qui sont des phrases de restauration dérivées des wallets.
Permettre ce que vous proposez dans Gecko serait un énorme chantier, un edge case à gérer en dehors de l’architecture actuelle, sans compter l’UX hors coffre du coup.
Mais j’insiste : ce point reste secondaire comparé à la simplification du flow d’onboarding v2.
Pour rappel, cette architecture a été pensée avant le choix de migration sur Substrate, à l’époque de GVA, quand Gecko était encore branché à la v1.
Il s’agit donc de choix totalement agnostiques par rapport à la migration v2. Seules des adaptations ont été faites pour rendre l’onboarding v2 cohérent dans cet environnement.
Nous ne sommes donc pas d’accord sur ce qui me semble être l’approche la plus claire et la plus simple pour les junistes actuels dans cette migration.
Pas si tous les clients proposent au moins l’authentification par phrase de restauration, ce qui est déjà le cas actuellement.
J’ai aussi réfléchi à cela, et ma conclusion a été que l’utilisateur doit d’abord être à l’aise avec le mnemonic et le code pin, avant de migrer. Si tu l’empêche d’'utiliser son compte V1, le temps de cette adaptation au nouveau paradigme, tu vas les obliger à migrer dans l’urgence car ils auront besoin de leur Junes rapidement. Cela va se traduire par des personnes qui vont tout perdrent s’ils ont migré à l’arrache sur leur téléphone dans un gmarché en notant juste le code PIN.
Le tunnel que tu proposes part du postulat que les utilisateurs sont compétents, rationels et maîtrisent la gestion de mot de passe (2 nouveaux), ce qui est loin d’être le cas.
Moi je suggère un entre deux. Que certaines applications comme Gecko et d’autres obligent à la migration, mais que d’autres comme Césium gardent une compatibilité V1.
Les outils développeurs comme gcli, ou détaillé comme Tikka, permettant de dépanner les retardataires ou les incidents, en ayant accès aux comptes V1.
Avec une communication constante à passer en mnémonique, bien évidemment.
C’est possible mais l’app demande de tapper un des mots de la phrase avant de continuer, ça limite quand même ces cas.
Je peux ajouter une autre confirmation d’un des mots de la phrase au moment de la migration de compte à la limite.
L’urgence de devoir vite payer à son gmarché me semble quand même assez limité dans l’état actuel du réseau.
Je suis d’accords que cette partie constitue une zone de friction pour l’utilisateur.
Le tout étant de choisir le mode de friction le plus doux. L’approche de migration de compte obligatoire me semble plus simple pour éviter de devoir gérer un cycle de vie de l’option “login id/pwd”, et que le user se retrouve à devoir soit migrer sont compte 6 mois plus tard quoi qu’il arrive, soit se retrouver ad vitam sur un type de wallet legacy.
Je ne sais pas trop ce que vous comptez faire pour “habituer le user à être à l’aise avec les mnemoniques” 6 mois après la migration, je ne comprends pas trop ce que ça change.
Hormis poper le user régulièrement pour le faire quand il le veut, certe, mais bon ça me semble une mécanique compliqué pour si peu.
En vous lisant, je me permets de décaler un peu le débat et de poser une question qui, je pense, est la clé pour l’adoption de masse.
Pourquoi avons-nous si peur de faire confiance à l’administrateur de notre propre nœud?
Dans la pratique, nous faisons déjà confiance à quelqu’un. On fait confiance à à Google, à notre hébergeur “CHATONS”, on fait confiance à l’admin de ce forum pour ne pas effacer nos messages. On ne connaît pas vraiment celui qui gère nos données ! Et si, au lieu de nier cette relation de confiance, on l’utilisait pour rendre le système 1000 fois plus simple et plus sûr pour l’utilisateur final ?
A mons sens, et si on veut être rigoureux, il n’y pas de “compte V1”, “compte v2”.
Ni d’ailleurs de “Compte Cesium”.
Il s’agit bel et bien de méthodes d’authentification, utilisées ou non en V1.
(On pourrait par exemple déjà implémenter l’authentification par mnémonique dans Cesium v1, dès maintenant, non ?)
Comme j’ai écrit plus haut, il s’agit :
de permettre la création de nouveaux portefeuille via un ménonique (comme cela il peuvent s’entrainer, et voir de quoi il s’agit);
Pour les comptes existants v1 (non migrés) : afficher un message (bien visible) avertissant que le support de l’authentification par “identifiant /mot de passe” prendra fin dans l’outil le xx/xx/2026, indiquant qu’il faut migrer avant.
Ainsi, l’utilisateur peut prendre connaissance de ce que cela va changer pour lui, et faire la démarche tranquillement, quand il a le temps.
C’est exactement comme cela que tous les platformes web ont fait pour forcer petit à petit leurs utilisateurs à une authentification à 2 facteurs (2FA). Sauf effectivement quand les mots de passe était compromis : dans ce cas il forcait la main. On fera de même après la deadline.
Hors sujet.
Mon message s’adresse avant tous aux développeurs (client et noeuds Duniter v2s). Je le fais ici étant doné qu’il est impossible d’avoir des débats en réunion de visio (qu’on appelle a tord “dev talk”)
Je trouve bizarre de vouloir forcer à migrer un compte pour changer sa méthode d’auth.
OK pour déprécier l’ancienne méthode et la cacher dans des menus moins évidents. OK pour inciter fortement à migrer tous les comptes.
Mais dans le cas où quelqu’un reviendrait dans 2 ans sur un vieux compte contenant un pactole, voulant tout transférer à quelqu’un d’autre, on l’obligerait à migrer son compte et faire tout le processus de création de mnemonic, juste pour vider son compte ?
Il faut aussi penser au fait que socialement, la migration de compte n’est pas atomique : un commerçant migre son identité et ses Ğ1 vers une nouvelle adresse, mais les clients continuent pendant un temps à payer à l’ancienne adresse qu’ils connaissent et qui est déjà enregistrée. Le commerçant doit pouvoir continuer à utiliser son ancien compte. Les deux comptes doivent pouvoir être utilisés simultanément. Et non, un annuaire centralisé des migrations ne suffira pas.
C’est ce qui me gêne avec le concept d’UX. On ne sait jamais tout ce que les gens peuvent vouloir faire, donc on restreint les possibilités et rend difficiles les usages impensés, qui auraient été faciles avec un logiciel “boîte à outils”. Il y a un équilibre à trouver entre tunnels guidés d’UX et commandes GNU.
Merci pour ces argumentaires.
Désolé pour le pavé qui suit, mais il y a des choses à dire.
Pas nécessairement. Tel qu’implémenté dans Gecko, l’utilisateur peut migrer un compte id/pwd vers un de ses wallets autant de fois qu’il le veut. Donc si des sous arrivent dessus, il suffit de remigrer, c’est une opération bénigne. Lorsqu’il n’y a pas d’identité associée au compte, dans les coulisses il s’agit simplement d’un transferAll.
On pourrait très bien imaginer des mécanismes plus sophistiqués pour rediriger automatiquement les sous d’un compte id/pwd déjà migré vers l’adresse de destination, mais ce serait inutilement complexe.
Ce point est donc important à relever, merci de l’avoir fait, mais n’est donc aucunement bloquant pour moi
Cette approche invite l’utilisateur à créer différents wallets unitaires avec un mnémonique différent à chaque fois, dans la même logique d’UX que Cesium v1 propose déjà avec les id/pwd.
Il n’y a rien de mal à ça, je ne dis pas que c’est un problème.
Simplement, comprenez que ce n’est pas du tout l’approche de Gecko. Je pars du principe que garder et gérer un seul mnémonique est déjà une opération coûteuse pour l’utilisateur.
C’est en partant de ce constat que la logique de coffre a été introduite : ce n’est pas juste pour faire joli, il y a des conséquences techniques qui en découlent ainsi qu’une expérience UX qui diffère de l’invitation à créer un wallet indépendant à la légère, pour le moindre besoin.
Pour cette raison, ce que tu proposes là me semble aller à l’encontre de la “sacralité” (le mot est un peu fort mais c’est tout ce qui me vient sur le coup) du processus de génération de phrase de restauration.
Ce processus est central, une porte d’entrée dans l’univers G1. Une fois cette opération cruciale effectuée, tous les voyants sont au vert et tous les usecases sont débloqués. Il s’agit d’un investissement sur le long terme pour l’utilisateur.
Faire cohabiter des wallets id/pwd + d’autres mnémoniques me semble être une gymnastique qui certes, sur le papier, paraît triviale, mais qui, quand on creuse un peu, débouche sur des frictions d’UX que je n’ai pas réussi à satisfaire convenablement de mon côté, dans mon coin. Peut-être trouverez-vous une solution plus adaptée que moi à ce sujet, mais de mon côté ça fait bien longtemps que j’ai dépassé cette question.
On entre donc dans la gestion d’un cycle de vie legacy que je décris plus haut et que j’aimerais éviter, car je peine à en voir l’intérêt profond.
Cette analogie est séduisante aux premiers abords. Mais j’aimerais souligner une différence notable avec nos cas : l’ajout du 2FA est une couche qui vient s’ajouter à un compte existant, qui lui ne change pas.
Aussi, nous sommes dans un contexte particulier de migration de protocole amenant des formats de RIB nouveaux. Je maintiens donc mon argument de profiter de ce changement de RIB pour faire le transfert de clé, au lieu d’imposer une migration à 2 étages pour l’utilisateur, étalée dans le temps. Et je ne suis pas pour mélanger pubkey et ss58 dans les apps grand public, pour éviter toute confusion et rester le plus simple possible au niveau de l’UI. Sinon, les gens se retrouvent avec 2 RIB par compte, c’est trop compliqué.
J’ai l’impression que les devs back qui sont d’avis de ne rien toucher aux générations de wallets pour la migration afin de rester “ISO” n’ont pas suffisamment conscience de ce changement de RIB côté apps, de ce que ça induit pour les gens, et de l’opportunité de faire les choses le plus simplement possible pour tout le monde dans ce moment de migration (pas d’étages).
Je ne sors pas tous ces éléments de mon chapeau, tout ceci a été mûrement réfléchi de mon côté étant donné que j’ai eu l’occasion de travailler pendant quelque temps à temps plein sur Gecko au début de la migration v2s, il y a maintenant 3 ans de ça. Et que ma réflexion a continué d’évoluer depuis.
Pendant ce temps, @kimamila, tu ne travaillais pas encore sur Cs2 (sans rancune hein, mais je tiens simplement à remettre les pendules à l’heure. C’est bien beau d’appeler à la “légitimité des dev de Duniter v1” dans un topic annexe, mais entre temps il s’est passé 2/3 trucs).
Je ne mélangerais pas rigueur technique et justesse de vocabulaire grand public.
C’est par exemple pour ça qu’on préfère parler de “mise à jour v2” au lieu de “migration v2”. Comme je le disais, utiliser ce vocabulaire compte v1/v2 permet de largement simplifier la communication auprès du public june actuel. Ce n’est peut-être pas rigoureusement juste techniquement, mais ça permet d’offrir une cohérence claire dans les apps, à condition de s’accorder sur ces changements de wallets bien sûr.
Oui oui on pourrait. On pourrait.
On pourrait.
Je tiens à dire pour finir que je ne souhaite pas m’accrocher bec et ongles à ma position actuelle, je ne suis pas dogmatique, je suis prêt à changer d’avis et à évoluer sur cette question.
Simplement, pour le moment, je ne suis pas encore convaincu par votre position.
@kimamila si tu veux, on peut se faire un call pour discuter de ce sujet spécifiquement, qui a de quoi occuper toute une visio à lui tout seul aisément, et ainsi rester focus.
Je me permets d’extrapoler légèrement la discussion dans ce message à part, car le premier est déjà bien long, et il s’agit d’une ouverture du sujet sur autre chose.
J’anticipe déjà les arguments de dérives sécuritaires suivants :
Utiliser le même mnémonique pour son compte membre ainsi que tout le reste est dangereux, ça ouvre un peu plus la porte à une corruption du secret de l’identité en augmentant la surface d’attaque
Argument pertinent, mais que je souhaite réfuter également (oui je sais, je suis en train de m’autoréfuter moi-même, on est plusieurs dans ma tête laissez-moi tranquille).
Je pense que le risque de perte d’un ou plusieurs mnémoniques, induit par la multiplication de ces derniers, est plus grand que le risque d’une surface d’attaque augmentée par l’usage d’un unique mnémonique pour tous ses comptes.
Demander aux gens de garder précieusement 1 mnémonique est déjà un défi de taille, alors les inviter dans la pratique à en gérer plusieurs l’est d’autant plus.
Des garde-fous existent déjà côté Duniter v2s en cas de fuite du secret de l’identité, avec par exemple la possibilité de révoquer son identité avec son ancien secret pré-migration.
Je peux développer plus cette partie si besoin.
Oui mais dans de nombreux cas on aimerait pouvoir mutualiser un wallet entre plusieurs personnes ou groupes de personnes. On ne peut donc pas simplement créer une dérivation de son coffre principal pour ces cas-là.
Très juste, on sent là un esprit fulgurant, bravo.
C’est pour ça que d’une part, une app comme Gecko permet également de gérer plusieurs coffres au sein de la même session (d’où la notion de coffre justement : un objet qui contient une multitude d’objets, mais qui peut lui-même être multiple).
Mais d’autre part, et c’est là le plus intéressant, il y a quantité d’options cryptographiques que nous n’exploitons pas encore mais dont je connais l’existence sans les maîtriser pour le moment, et qui permettraient soit de mutualiser l’usage d’un wallet sans en partager le secret pour autant, soit, avec un système de proxy, de déléguer des droits d’usage d’un wallet à d’autres personnes.
Ces mécanismes, une fois maîtrisés et implémentés, devraient, je pense, pouvoir combler une partie des besoins de wallets partagés.
Désolé, je sais que ça fait beaucoup de texte, mais j’ai l’impression que toutes ces réflexions sont restées en partie dans mon esprit et qu’il est nécessaire de les partager avant de pouvoir continuer le débat, et ainsi partir sur des bases communes.
Saches que je lève ces questions car mon expérience me dit qu’il y a un loup, et que vous ne semblez pas le voir… après vous ferez bien comme vous voulez. Et on en reparlera tranquillement dans 6 mois ou un an…
De mon point de vue, la clé publique (sans préfixe) reste un “RIB” 100% valide en v2 et continuera d’être affiché et d’être utilisable (pour les paiements, etc). Ce format est toujours parfaitement valide.
L’adresse SS58 est le nouveau format de RIB. Comme on a vu apparaître l’IBAN par exemple, a côté des RIB au format français.
La migration v2 ajoute simplement un nouveau format, mais n’annule pas l’ancien. C’est important car les gens ont mémorisé leur clé publique, et ils leur faudra du temps pour se rappeler leur nouvelle adresse SS58.
C’est un approche qui me paraît difficilement tenable, lorsqu’un périphérique veut gérer plusieurs comptes (membres par exemple). Admettons que je gère celui de ma femme et de mes enfants. Comment je fais avec un seule mnémonique ?
Cette notion de coffre est d’un intérêt réel, mais dans les cas d’utilisation élémentaires. Elle n’est pas nécessaire à la migration et va embrouiller les utilisateurs lambda, tel que c’est fait aujourd’hui.
Je travaille sur des SI non stop depuis 15 ans, et ne compte plus les migrations auxquelles j’ai participé..et qui sont en prod, hein, pas en mode PoC sans usagers réels derrière. Je crois que ça suffit pour écouter déjà ce que je dis, et au moins y réfléchir avant de rejetter l’idée.
Si tu veux je peux vous lister les trucs sur lesquels j’ai déjà averti et que vous semblez entendre ou prendre en compte 6 mois après ou même seulement maintenant…
Les frais, le scan réseau/vs tirage au sort, etc. Je ne parle pas même pas des data pod… qu’il paraissait facile pour certains de remplacer. Bref.
Je ne répondrai pas aux arguments d’autorité, je trouve ça petit et, entre nous, un peu ridicule (surtout quand on sait ce qui s’est vraiment passé ces 10 dernières années suite à certaines décisions techniques problématiques très discutables, entraînant tout un bordel pour réparer ces bêtises derrière).
Je suis là pour parler du fond.
Et bien écoute, tu as gagné. Je ne souhaite pas me battre seul à défendre un point de vue.
Te connaissant, étant à cours d’argument valides, voici ce qui va se passer : tu vas partir en croisade pour imposer ta vision de la migration partout où tu le peux, quitte à aller à l’encontre des tests utilisateurs qui ont déjà été effectués. Tu n’en as rien à faire, étant frustré par ce désaccord technique, tu vas te replier sur toi et couper toute tentative de compromis.
Suite à quoi, la mise en avant du mode legacy de CS2 entraînera une confusion dans le reste de l’écosystème technique, car les gens ne comprendront pas pourquoi il est possible de se connecter à un mode “v1” dans une app “v2” et pas ailleurs. Là où il n’y aurait aucun problème si l’ensemble des apps restaient cohérentes.
Mais non, il fallait que tu imposes ta vision, quitte à casser tout le travail effectué jusqu’alors, pour ensuite venir faire ton bilan 6 mois après : “vous voyez, c’est le bordel, je vous l’avais bien dit !”.
Depuis le début, tu auras été le spécialiste pour dénigrer les approches qui ne correspondaient pas à ta vision, profitant du fait que tu étais le premier à proposer une UX, te servant de cette situation pour asseoir une autorité technique infondée.
Je pense pourtant avoir été assez patient depuis 5 ans, au vu du contexte de migration à rallonge ayant forcé les changements de plans techniques côté Gecko de multiples fois, empêchant la livraison de quelque chose qui est prêt depuis 3 ans.
J’ai même commencé à contribuer à Cesium 1 pour proposer une mise à jour forcée vers CS2 (non mergé, non déployé), et à CS2 (je comptais continuer à contribuer mais je change mes plans, et tu sembles retrouver du temps), étant donné que j’ai bien conscience qu’il est préférable pour les utilisateurs de proposer une transition fluide vers un outil qu’ils connaissent déjà.
Mais je ne vais pas pouvoir tenir tous ces bouts bien longtemps quand, en face, il y a aussi peu de volonté de faire équipe et de s’entraider.
J’ai pris sur moi assez longtemps, maintenant ça suffit, je jette l’éponge.
Au vu de tout ça, j’ai donc décidé d’introduire un mode legacy dans Gecko par défaut, permettant d’importer un wallet legacy (identifiants + mot de passe), hors coffre donc.
Une option permettra de très facilement désactiver cette possibilité dans le code, mais je vais l’activer par défaut. On verra pour la gestion du cycle de vie de ce mode plus tard.
Je déplace alors cette décision technique vers une décision politique pouvant être prise par des non-dev, par tous les testeurs bêta de l’écosystème v2s.
Ne prends pas la mouche. On discute. Il n’y a d’ailleurs pas que ton avis qui compte, mais aussi ceux des autres dev de clients (@vit, @ManUtopiK , @cgeek@HugoTrentesaux etc)
Quand au jugement sur ma personne, cela me déplaît. Ne recommence plus s’il te plaît.
Je me suis contenté d’argumenter, ici dans ce fil. Et je me suis défendu quand tu as lancé un pic en lien avec l un autre post, sur le dev talk (qui d’ailleurs ne te visait pas). Je n’ai pas utilisé d’arguments d’autorité, sauf pour dire qu’il faut au moins écouté mes arguments. Mais pas pour les appliquer sans discuter. C’est tout ce que je demande. Relis moi.
Je ne vois pas pourquoi je n’aurai pas le droit d’aborder ici ce sujet central, qui a été présenté comme indispensable à la migration, à tord.
Soit la nouvelle authentification par mnémonique est indispensable à la migration, soit ça ne l’est pas. Il n’y a pas d’entre deux.
J’ai déjà répondu dans un message juste au-dessus du tien en anticipant cet argument. Il faut croire que j’avais vu juste. Étonnant, c’est comme si ça faisait 5 ans qu’on parlait de ce sujet, dis donc.
Mais personne n’a dit le contraire. C’est d’ailleurs ce que tu fais, non ?
Mais on sait très bien comment ça va finir. J’ai déjà suffisamment vécu ça.
Chacun argumente, et à la fin, tu vas partir sur ta vision, quels que soient les arguments en face, sans même avoir pris le temps de tester les alternatives proposées.
Une fois en place, tous les problèmes v1 perdureront sur la v2 et on en sera exactement au même point, à devoir manœuvrer pour changer tout ce foutoir.
Puis plus tard quand le hasard fera que tu tombes sur d’autre façon de faire, tu fera du cherry picking pour Cesium.
Tu présupposes que forcer la migration de secrets est trop compliqué pour les gens.
C’est un point de vue qui n’est peut-être pas partagé par les gens eux-mêmes.
Et c’est sûr que sans tester, à juste demander aux gens, les non-initiés vont préférer le non-changement, c’est évident. Il faut tester pour pouvoir juger si oui ou non c’est si insurmontable que ça.
J’ai donné suffisamment d’éléments de réponse dans ce thread, je ne vais pas les répéter. Je ne pense pas qu’on puisse dire que tu n’as pas pu exprimer ton point de vue, que d’autres partagent aussi d’ailleurs, ce n’est pas la question.
Eh bien jusqu’à présent, si.
Il y avait Gecko qui propose une migration forcée guidée. Prêt pour la suite, en restant idiomatique de l’approche initiale.
Et Cs2 qui propose toujours d’importer des “comptes v1”, en plus des mnemonics. Comme Cs2 scan les dérivations lors d’import de mnemonic, il reste entièrement compatible avec les coffres de gecko. C’était une condition préalable. Heureusement elle est implémenté. Ouf.
Cette solution n’était pas idéale pour des éléments que j’ai expliqués plus haut (notion de “compte v1” utilisables sur la v2), mais elle avait le mérite d’être une sorte de compromis acceptable.
Les junistes actuels mettent à jour leur Cesium de manière sûre grâce à cette MR, et les autres choisissent une app, car ils ont la chance désormais d’avoir le choix.
Mais étant donné que tu vas communiquer sur la dangerosité des coffres, que ça aurait pu être fait en v1 (vrai, mais ça n’a juste pas été fait — tu voudrais une MR à ce sujet sur Cs1 ?), alors cette approche semble très compliquée pour les gens. Ça sent la cata assurée, causée par la dissonance des propos ici et là, le bordel.
Donc je prends les devants et, une fois de plus, je m’adapte à toi. On fera ainsi.
Les autres peuvent donner leur avis, avec plaisir, mais ça ne changera de toute façon pas les enjeux derrière.
Pour éviter la confusion, ne serait-il pas mieux d’afficher principalement le nouveau format, avec dans un premier temps l’ancien avec un message visible qui explique la différence (“l’adresse de votre compte change de format, l’ancien format disparaîtra bientôt”), puis caché dans un menu ?
L’ancien format n’aurait besoin d’être affiché directement que pour les comptes id/mdp. Les nouveaux comptes mnemonic n’en ont pas besoin (mais l’option pour l’afficher, cachée dans un menu, peut toujours être utile à certains).
Quant à la compatibilité avec l’ancien format (l’utilisateur entre une clé publique ou scanne un QR code), il suffit de le convertir en SS58 avant de le traiter (et d’afficher un avertissement “adresse XXX à l’ancien format, nouveau format YYY, il est conseillé d’utiliser le nouveau format”).
On peut en effet afficher les deux formats seulement pour les comptes id/pwd. En revanche existe t il un moyen, lorsque l’utilisateur se connecte seulement par un adresse SS58 ou une pubkey, de savoir si c’était un compte existant en v1 ?
On peut regarder le solde au bloc 0 de la v2, ou utiliser un indexeur pour agréger tous les comptes ayant existé en v1… je ne vois pas de meilleur moyen. (un compte portefeuille n’ayant jamais reçu de Ğ1 ne sera pas détecté)
Peut-être qu’il suffirait de supposer que “compte v1” = “pubkey v1”, comme heuristique de base ? De toute façon ce mécanisme sert à faciliter la transition aux gens qui n’y comprennent pas grand chose, et ceux qui ont un usage plus complexe et qui vont oser faire joujou avec les différents formats comprendront mieux même si cette heuristique n’est pas parfaite.
