Super ces graph, très intéressants, merci beaucoup pour ce suivi. 
J’imagine que les migrations vont se faire tout doucement, en attente de la stabilisation des apps et surtout, je regrette un peu, " nous n’avons pas assez communiqué sur l’importance de migrer". Nous ferons mieux pour la V3 
En partie dû a des campagnes de désinformation opposant transitions douces (rester en legacy) vs migration, sous entendant que migrer serait compliqué, et permettant aux gens de garder de mauvaises habitudes sans aucune raison valable.
Nous nous retrouvons donc avec un cycle de vie des wallets legacy à devoir gérer en v2.
Il faudra clairement faire mieux à l’avenir oui.
Donc, pour les besoins de ma com, c’est super chiant pour les devs de garder des wallet legacy?
Genre même celui-ci qui a été ressuscité ?
g1PzCJ1wYexbdkToEuU8suLu3mtzg3WehJCWmADa8xWVs2
Ou alors des wallet legacy comprenant des identités membre plutôt ?
Des legacy tout court, il n’y a aucune raison de rester en legacy, dans aucun cas de figure, ça ne fait que reporter le problème à plus tard, vraiment.
Surtout, je le répète a nouveau, le sujet de la sécurité des comptes n’est pas lié (factuellement) à la migration Duniter v2s, puisque Substrate supporte n’importe quelle clef publique v1 nativement, et que la génération des clefs est portée exclusivement par les App clientes. C’est un sujet distinct qu’on a voulu faire passer en même temps que la migration, pour raison sécuritaire et opportuniste (a tord ou a raison - je ne juge pas).
Rien n’empêche donc de faire cette montée de sécurité dans les prochains mois, paisiblement et sereinement. En avertissant bien les utilisateurs qu’ils ont un délai pour le faire. Ce sera avant tous un problème de pédagogie interne a chaque app (messages, tuto, etc.).
Aussi, mieux vaut ne pas cumuler tous les sujets en même temps. Il y avait assez a faire avec la migration, côté technique, sans rajouter une contrainte tout de suite côté utilisateurs.
On a déjà débattu longuement sur ce sujet et je heureux pour les utilisateurs que le bon sens l’ai emporté.
Voici, pour illustrer mes propos, l’avis de grok la veille de la migration v2s, au sujet des risques pour la communauté :
D’un point de vue communautaire (forum.duniter.org, monnaie-libre.fr, discussions locales Ğ1), la migration vers Duniter v2 risque surtout d’échouer pour des raisons humaines et d’usabilité, bien plus que pour des bugs purement techniques.
Risque n°1 : Friction UX énorme et « migration forcée » des wallets/comptes (le risque n°1)
Beaucoup d’utilisateurs (surtout les plus âgés ou les moins tech) ont mémorisé leur identifiant + mot de passe v1, imprimé leurs clés publiques b58 partout (gchange, girala, Telegram, murs d’atelier, comptes collectifs de crowdfunding, etc.).
Une migration qui oblige à passer à des adresses ss58 + phrases BIP39 (ou même un simple « transfert vers nouveau compte » comme le propose Ğecko) est vécue comme « changer tous les numéros de téléphone du carnet d’adresses ».
La communication v2 n’a pas été claire car tout a été mélangé dès le départ : entre ce qui est nécessaire et ceux qu’on aimerait en bonus et que l’on pourra faire plus tard.
C’est tout à fait paisible de migrer jour 1, cette affirmation est fausse, je suis désolé que tu bloques là dessus.
La confusion actuelle réside justement dans le fait qu’on offre aux gens 2 choix possible d’import de wallet, tout comme montrer encore les pubkey b58 en plus des ss58, c’est confusant, et ça remonte doucement, paisiblement, au support.
Ton propre bon sens n’est pas nécessairement un bon sens absolu, tu sais ?
C’est sûr qu’en demandant aux gens si ils préfèrent changer ou ne rien toucher, ils vont choisir l’option 2. Mais si on ne les déranges même pas a se poser ce genre de question, dans la bon tunnel, tout se passe à merrveille.
On aurait donc pu totalement s’épargner:
Qui sera expéditif côté Gecko étant donné que tout a déjà été préparé à ça.
Je parle pour les utilisateurs : ils doivent se pauser pour noter correctement leur phrase, comme lors d’une inscription en v1 et le choix d’un id/pwd.
Je ne bloque pas du tout. Je constate simplement que personne ne peut savoir à quel moment un utilisateur peut avoir le temps de le faire, calmement et tranquillement.
On aurait effectivement pu coder dans Cesium2 l’accompagnement vers la migration dès la version du jour 1, sauf qu’on avait plein d’autres trucs à finir, et d’ailleurs qui ne sont toujours pas finies…
Mais dans tous les cas, cet accompagnement dans Cesium2 n’aurait pas pu être forcé.
Il existe des gens qui par exemple sont loin de chez eux le jour 1, mais néanmoins veulent faire un virement ou une certification. Et qui veulent simplement noter la phrase de retour a la maison.
Comme moi déjà. 
Ah oui, tu affirmes que tu veux absolument faire un virement ou une certification là, pendant que tu es en vacances, que c’est absolument nécessaire pour toi avant de pouvoir trouver 5 minutes pour noter un mnemonic ? Vraiment ?
Dis autrement, cela ça se faire vite fait bien dans la v2.2 de Cesium et ceux qui veulent que ça arrive vite peuvent aider, comme toujours, par un MR 
C’est même une évolution qui me paraît assez simple à réaliser, non ?
Et enfin, il me.semble.qu’on a des tickets sur la compatibilité de phrase de restauration. Tout n’est pas encore 100% opérationnel de ce point de cue. Donc inutile de s’énerver. c’est un sujet qui avance, mais en dehors de la migration.
Oups … je ne voulais pas relancer le débat, pardon pour cela si cela gène on peut supprimer mon post
A titre personnel j’ai fait tout ce qui était en mon pouvoir et je m’aperçois que ce n’est pas si facile que ca pour les utilisateurs/trices d’utiliser le wallet legacy. C’est pour cela que je me suis exprimée
La différence de point de vue est une évidence. La V2 a été lancée ainsi. Comme tu le dis
Super, merci pour ca
Pour revenir au sujet de la migratio’n, @poka sais tu si le profile CS+ est migré également ? Je n’ai pas l’impression…
Voilà également pourquoi je trouve qu’il est trop tôt pour forcer les utilisateurs de Cesium.
Et qu’en ai t’il des autres fonctionnalités Cs+ (messages, abonnements, invitation a certifier, signalement, etc ?) tout repose sur les clefs publique s v1..Or tout n’a pas été encore été repensé pour la v2.
Moi, je préfère réfléchir à une solution technique plus tranquillement, surtout quand RIEN techniquement ne m’y oblige. Tant pis si ça froisse certains (Ce n’ est pas le but. Et chacun est responsable de ses émotions, après tout)
Oui sur Gecko il est migré sans aucun problème.
Il y a peut être un bug sur Cs2 à ce niveau, et si c’est de ma faute je m’en excuse, mais c’est rapide à corriger.
Il y avait aussi des bugs sur les fields id/password legacy (utf8 par exemple), qui ont été corrigés, les bugs ne sont pas réservés aux mnemonic ou au flow dde migration, il suffit de prioriser les bons flow lors des dev pour s’épargner d’un maximum de bug.
Bien sûr. Il y a des bugs partout potentiellement. Traitons déjà ceux la. Et reevaluons la situation ensuite pour une migration d’identité forcée.
Je n’avais testé que sur la Gtest, et j’avais constaté ce problème. Mais j’avais trop de choses a faire (c’était quelques jours avant la migration v2). Peut-être que c’était volontaire car le Pod Cs+ était un pod de prod ?
En fait ca fait 6 mois que Gecko migre les profiles Cs+ de prod sur la gtest, ce qui a causé quelques infortunes aux testeurs qui voyaient leur profiles g1 prod migrés.
Mais nous n’avions pas eu le temps de monter une stack Cs+ de test, donc j’ai préféré ce mal pour un bien, me disant que ce n’était pas très grave que quelques profiles Cs+ de testeurs v2 soient migrés en prod.
J’avais il me semble implémenté cette migration de profile dans Cs2 également, mais je l’ai peut être oublié j’avoue que je ne me souviens plus bien, on peut vérifier.
Dracaufeu a migré un compte révoqué.
Il s’est excusé d’avoir envoyé des messages pour certification sur des groupes nationaux. Il a pourtant beaucoup de certifs de gens qu’il a rencontré, et a à coeur de booster la monnaie libre, aimerait pouvoir mieux participer aussi sur le plan informatique.
On m’a dit que son compte révoqué g1N9HaaPWFAqxaNHDNHc9R7VVcHhv11udDteakPKT67qZaFtj est certifiable, aurait été récupéré.
Je n’y arrive pas.
Donc si la révocation est bien faite et stable on peut certifier le compte g1KhbX6L7CvdkLPyQT6SNS8AdHGwLM54BtVv2TXLqzTPkUD6J
L’auto-certification qu’il a eu pose un problème de licence, mais étant donné que l’autre compte est révoqué, qu’on sera bien plus que 4 personnes à le certifier, et qu’au final il aura bien un seul compte membre, c’est ok?
J’attends le feu vert, au cas où la révocation sauterait, et pour ne pas avoir 2 comptes membres à la fin.
Oui c’est un bug de Duniter, un compté révoqué ne devrais pas pouvoir être migré, une prochaine version du runtime va interdire cela.
La blockchain interdit bien la certification d’un compte révoqué, même si une interface utilisateur peut laisser croire le contraire. Je viens de vérifier : l’adresse g1N9HaaPWFAqxaNHDNHc9R7VVcHhv11udDteakPKT67qZaFtj est bien révoquée dans la blockchain. Ce compte ne pourra donc jamais être certifié ni redevenir membre.
Oui, étant donné que l’ancien compte est révoqué, la licence est bien respectée ici.
salut Hugo tu peux nous mettre le suivis des transferts et/ou migrations a ce jour ?
sinon tu trouves cela ou ?
merci
claire
