Les mnemonics multilingues prennent-ils le hash de la phrase dans la langue, ou font-ils une bijection avec les mots anglais ?
Dans le deuxième cas c’est bon, tout mnemonic peut être traduit sans perte.
Dans le premier cas rien ne nous oblige à suivre BIP39, puisque de toute façon tous les wallets grand public qui seront compatibles et bien intégrés seront spécifiques à Duniter. On peut définir une bijection entre les dictionnaires français et anglais et prendre le hash de la phrase en anglais. Si quelqu’un veut utiliser un wallet BIP39 pur, il lui suffira de convertir la phrase.
et si tu regardes les wordlists qui font toutes 2048 lignes (mots) dans toutes les langues, chaque mot représente un chiffre entre 0-2047.
Le dernier mot est constitué du checksum (4 bits du début du hash256 de la seed).
Donc il me semble que c’est la bijection dont tu parles. Chaque mot d’une langue correspond à un chiffre selon sa position dans la wordlist donc ils devraient être parfaitement interchangeables sans perte.
Mais patatra, sur cet outil en ligne, les mots représentants les mêmes valeurs en anglais et français génère une seed différente !
(BIP39)
To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic sentence (in UTF-8 NFKD) used as the password and the string “mnemonic” + passphrase (again in UTF-8 NFKD) used as the salt.
Donc c’est bien le hash de la phrase, et non de leurs indices. (NFKD c’est la forme normalisée d’UTF-8)
Du coup on peut décider d’utiliser la phrase anglaise avec les mots correspondants ?
Peux-tu préciser les specs techniques qui en découle même si elles te paraissent très simple ?
Concrètement comment on génère un mnemonic FR à partir d’un mnemonic EN ? Peux-tu mettre un exemple générique en python ?
C’est pour être sûr de bien se comprendre.
En tout cas des libs comme polkadot.js ne permettent pas la génération multilang, mais ce n’est pas ce qui est proposé ici si je comprends bien.
Mais la génération de wallet via la lib polkadot.js ne fonctionnera pas avec un mnemonic non BIP39.
A chaud comme ça je ne suis pas pour faire une “boite noire” qui génère une “fausse” seed pour un mnémonique non anglais, dérivée à la sauce Duniter sous le capot, sans rien dire…
C’est une information cachée qui fera que les clients de Duniter ne seront pas dans les standards des autres applications de wallets.
Cela risque de foutre le bordel pour les gens qui vont utiliser sérieusement et intensément des comptes avec des applications mutil-wallets (donc en anglais). Ceux-là savent que s’ils veulent basculer leur compte dans l’écosystème d’application BIP-0039 standard ce sera avec un compte au mnémonique anglais.
Je propose qu’on laisse par défaut pour l’utilisateur novice le français comme dans Tikka. Et les utilisateurs experts se feront un compte en mnémonique anglais si ça coince dans une appli qui ne supporte que l’anglais en mnémonique.
Ma proposition est respecter BIP39 pour les mnemonics anglais, mais pour les autres langues de remplacer chaque mot par le mot anglais qui a le même numéro.
Comme le BIP39 déconseille le multilingue et le définit d’une manière qui empêche la traduction (avec cette définition pas terrible, ils ont bien fait de le déconseiller), et que très peu de wallets semblent implémenter le multilingue, on aurait une meilleure compatibilité avec le reste de l’écosystème en “corrigeant” cette partie de la norme.
Générer le mnemonic EN BIP39, générer la seed et le wallet avec ce mnemonic EN
Afficher à l’utilisateur l’équivalence FR
Lorsque le user import le mnemonic FR, le client le converti en EN à la volée pour générer la seed de manière standard.
C’est bien ça la proposition ?
Si c’est bien ça la proposition, alors comme ça à chaud je suis plutôt pour car:
Les wallets Duniter v2s auront déjà un comportement spécifique différent du reste de l’écosystème crypto dans la mesure ou nous décidons de nous accorder sur le scan de dérivation pour import multi-wallet automatisé et cohérent entre les outils
Nous pourrons permettre aux user d’afficher l’équivalent EN officiel BIP39 de leur mnemonic dans un menu avancé et/ou dans des outils de conversion sur duniter-connect par exemple.
Si le premier point n’est finalement pas retenu dans notre écosystème, alors la question de l’interopérabilité native avec le reste de l’écosystème crypto pourrait se poser.
Le point noir c’est que ça demande un algo supplémentaire à implémenter côté client, source de bugs potentiel, et qu’il faut s’assurer une fois de plus que tous les clients v2s utilise ces specs pour garantir une expérience utilisateur optimale.
Je retirerais donc mon vote “N’a pas compris les specs” pour un oui.
Sincèrement, je pense que le jeu n’en vaut pas la chandelle. Quel utilisateur utilisant le mnémonique de sa langue est susceptible d’avoir besoin de compatibilité avec les autres wallets ? Très peu.
Ceux qui voudront faire un usage expert de leurs comptes sauront très vite qu’il devront transférer les fonds sur un compte au mnémonique anglais.
Dans Tikka je pense donc laisser le français par défaut, les experts créeront des comptes en anglais s’ils veulent aller sur des plateformes uniquement anglophones.
Là j’ai l’impression que juste parce qu’une bibliothèque ne supporte pas le français on impact notre écosystème avec une bidouille qui oblige à faire des specs bizarres et que tous les clients devront respecter. Je pense que ce n’est pas la bonne solution.
moi également. La question est de pouvoir avoir un mnemonic dans sa langue pour un usage ‘de base’ (donc portefeuille ou membre) sur lequel se concentrent 80% des utilisatrices. La compatibilité de ce mnemonic avec un usage plus avancé (protocole d’anonymisation, swap, etc) n’est à mon avis pas nécessaire.
Qu’une utilisatrice aille ‘traduire’ son mnemonic de sa langue vers l’anglais est un acte d’ordre bien plus technique que de se recréer un nouveau mnemonic en anglais sur un logiciel portefeuille ‘anonymisant’.
Donc recréer une spec (et le code afférent) maintenant une traductibilité de la phrase de passe me semble être 80% de travail en plus pour pour 20% d’utilisatrices qui sauront très bien s’en passer.
Si j’ai bien suivi :
la lib rust supporte les mnemonics multilingue → OK pour utilisation dans Tikka, Gecko (?) et GCli (?)
la lib wasm utilisée par polkadtoJS également → OK pour utilisation dans Cesium (?) et Duniter-connect (?)
Non le sujet n’est pas là.
Les mnemonic multilang ne font pas partie des standard officiels bip39. La lib polkadot.js utilisé par cesium2, Ğecko, duniter-connect et autre, je supporte pas les mnémotechnique multilang.
Le choix est donc:
on fait de la bidouille comme ça → on permet au user d’avoir une phrase de restauration dans sa langue
on ne fait pas cette bidouille → les phrases de restauration seront nécessairement en anglais
A la rélfexion je suis pour laisser les mnémotechnique en anglais uniquement, pas de gestion des accents, personne ne va retenir son mnémonique de toute façon il faut le noter/le backuper.
Moi je trouve ça chouette aussi d’avoir son mnemonic en français, notamment si on veut le retenir pour l’avoir toujours avec soi dans sa mémoire. Et comme bip39 décourage le multilingue et que certaines lib ne l’implémentent pas, entre faire une couche de traduction simple (juste un dictionnaire à ajouter) et réimplémenter l’algo un peu bancale
je préfère la première option. De cette manière, ce sera toujours possible d’ajouter une fonctionnalité à l’utilisateur “afficher le mnemonic en version compatible” qui pourra être utilisée dans les outils qui ne gèrent que l’anglais (par exemple à cause de la lib qu’ils utilisent).
Utiliser directement l’implémentation du mnemonic en français n’offre pas cette porte de sortie et risque plus d’enfermer l’utilisateur.
Et de manière purement logique, je trouve ça mieux de faire une bijection entre 2048 nombres et des mots dans différentes langues que de prendre le hash d’une phrase en utf8 normalisé. Leur protocole est étrange, alors mieux vaut ne pas trop mettre les mains dedans.
Pourquoi pas ? 12 mots ça se retient facilement et c’est un bon moyen de transporter discrètement des fonds dans des situations particulières mais qui arrivent régulièrement dans le monde, par exemple quand on fuit sous les bombes israéliennes américaines.
De mon coté mon ID Cesium est une phrase de passe de 12 mots que j’ai retenu et que je tape à chaque fois pour le conserver en mémoire. Dans le contexte Duniter2, j’apprécie que Gcli me permette d’utiliser ce mode d’authentification.
Mais sans même parler de qui va retenir sa phrase de passe et dans quel contexte, c’est une question d’UX. Toi et moi nous utilisons l’anglais couramment, donc le fait de voir une phrase en anglais ne nous gène pas. Il est des utilisateurs qui ne pratiquent pas du tout cette langue, et pour qui le fait de devoir enregistrer de l’anglais, le copier/coller, le recopier, ben ça fait qu’ils ne se sentent pas ‘à la maison’.
Que proposerais-tu si la spec BIP39 utilisait le chinois ou le turc comme langue pour le mnemonic (le turc s’écrit avec l’alphabet latin) ? ‘On peut le copier-coller, de toute façon personne ne va le retenir’ ?
Si c’est ça l’alternative, alors la bidouille avec mapping des dictionnaires BIP39 vers l’anglais est la bonne solution.
Mnémonique en langue locale - hash depuis locale :compatible dans le peu de logiciels dont les libs sont compatibles avec le multilingue. Non compatible dans les outils uniquement anglophones, soit la plupart des logiciels cryptos.
Mnémonique en langue locale - hash depuis anglais :uniquement compatible avec les logiciels Duniter qui bidouillent. Non compatible dans le peu de logiciels dont les libs sont compatibles avec le multilingue. Non compatible dans les outils uniquement anglophones, soit la plupart des logiciels cryptos.
Quoi qu’il arrive, on en viendra toujours à devoir utiliser un mnémonique anglais pour la majorité des outils de cryptos. Mais alors notre bidouille rend incompatible la mnémonique locale avec le peu de logiciels non duniter qui supporte pourtant les mnémoniques locaux.
Je pense au contraire que cela limite encore plus notre utilisateur aux logiciels Duniter uniquement (specs maison). Au lieu de respecter les wordlists du protocole BIP-39 multilingue qui, certes moisi, est quand même supporté par quelques logiciels et libs.
Avec bidouille : chaque compte est facile à utiliser avec nos outils, et compatible avec tout le reste avec une petite manip.
Sans bidouille : chaque compte est facile à utiliser avec nos outils et avec certains autres, mais inutilisable avec tout le reste.
La bidouille oblige les quelques utilisateurs qui voudraient exporter le wallet à cliquer sur un bouton de plus. Cet inconvénient me semble minime par rapport au gain en compatibilité.
Est-ce que nous avons une idée du vrai pourcentage de Juniste pour qui l’utilisation de mots anglais est rédhibitoire.
Avant de se lancer dans des développements ou des bidouilles, se poser la question de la réelle utilité.
Voir si cela peut attendre après le démarrage, vu que la plupart des utilisateurs continueront d’utiliser id/mdp…
Le problème est qu’il vaudrait mieux promouvoir le passage au mnemonic dès la migration sinon on risque de se traîner les mots de passe longtemps.
Les méthodes bidouille et non-bidouille n’étant pas compatibles, si on choisit la bidouille il faut le faire avant la migration pour éviter que des comptes soient créés avec des hashes français.
@vit si on décide d’implémenter la méthode bidouille (je crois que c’est son nom officiel maintenant), ça fera du boulo côté client pour tout le monde: soit on a fait que le EN et faut rendre ça multinlang, soit (comme tikka) tu as commencé à implémenter le bip39-multi, auquel cas il est encore temps de ne plus utiliser l’API bip-multi qu’expose ta lib et de partir sur cette implémentation.
Je suis d’accords qu’il vaut mieux prendre une décision maintenant qu’après la migration.
La migration implique de facto un changement de “RIB” pour les gens: pubkey → ss58.
Autant en profiter pour les faire utiliser methodes de génération future proof.
Pour le moment je ne vois pas de faille avec cette bidouille. Et comme dit tuxmain, ça rends de fait nos mnemonic multilang compatible avec l’intégralité des outils crypto (juste un clique en plus “export universel”), contrairement au bip39-multi.
