Suite du sujet FEUILLE DE ROUTE de Tikka :
À ce jour j’ai un unique compte sur la gdev. Je tente de l’importer dans Tikka 0.6.0, et le dialogue m’indique en rouge :
AVERTISSEMENT : il n’est pas sûr de stocker la clef privée d’un compte racine
Concrètement, ça veut dire qu’il est déconseillé d’importer ce compte dans Tikka ?
Oui, tout à fait. Il est déconseillé d’avoir sa clef secrète racine, même chiffrée et sécurisée par mot de passe, sur son disque.
Moi aussi mon compte V2 membre est un compte Racine.
La convention pour Duniter V2 est d’avoir :
Je vais ajouter la possibilité de migrer l’identité d’un compte à un autre.
Une fois sa monnaie et son identité déplacées sur un compte dérivé //0, on peut « Oublier le Trousseau » du compte Racine pour supprimer la clef secrète racine de son disque.
Ce processus sera indispensable pour les comptes V1 qui sont tous des comptes racines membres.
Ca ça reste encore à débattre, je ne suis plus convaincu par cette convention.
Dans tous les cas chaque client doit traiter le cas “identité lié à n’importe quelle dérivation, dont root” lors de l’import, car c’est techniquement possible de le faire sur d’autres clients.
Parce-que même si on se dit que chaque client n’autorise côté UX que les identités sur //0, rien n’empêche quelqu’un de présenter son address/qrcode //2 à son premier certificateur et de partir là dessus. On rentrerait dans des histoire UX du type “[rouge] Machin a créé votre identité sur un portefeuille non autorisé, cette dernière a été annulé (si c’est possible). Votre portefeuille (type) membre a été généré dans votre coffre, veuillez utiliser celui-ci pour vous faire certifier”.
L’enfer…
Moi pour le moment je suis partie sur aucune limitation/présélection pour les portefeuilles membres dans gecko. Je ne vois pas de soucis a partir là dessus, je ne vois pas d’intéret à ajouter un menu “Créer mon portefeuille de type membre” qui serait //0, ca permettrait d’afficher la licence Ğ1 à ce moment là, mais dans tous les cas vue c’est c pas obligatoire de passer par là, faudra aussi afficher la licence Ğ1 au moment de la confirmation d’identité, là où c’est un passage obligatoire.
Donc :
C’est ça ?
Et concernant la création de compte dérivé, pourquoi le mnémonique est-il demandé ? Ce n’est pas censé être le même que celui du compte racine ?
Et aussi, pourquoi proposer un mot de passe différent pour le compte dérivé ?
EDIT : J’ai l’impression qu’on ne peut créer de compte dérivé qu’à partir du compte racine. Donc une fois que je l’ai « oublié » je ne peux plus créer de compte dérivé ?
Non, tu n’oublie pas le compte (sinon tout disparaît et les dérivations avec). Tu oublies le “Trousseau” (le nom est peut-être à revoir) qui est ton “trousseau de clef cryptographique” stocké sur ton disque par Tikka (en fait la clef secrète).
Parce ce que Tikka ne stocke pas le mnémonique, il stocke la clef secrète uniquement. Et dans l’API substrate j’ai pas trouvé comment dériver depuis la clef secrète, alors j’en ai besoin pour créer la dérivation. Mais peut-être que si qq sait faire ça en python on peut effectivement se passer du mnémonique.
Sécurité maximum pour commencer. Si j’ai la clef secrète racine je dois pouvoir accéder aux dérivations. Même si moi j’ai pas capter comment en Python… 
À partir du moment où on ne stocke pas la clef secrète du compte racine il ne devrait pas être possible de déduire les dérivations. Donc on pourrait simplifier côté mots de passe, non ?
Pour l’instant c’est juste fortement déconseillé. Donc optionnel, même si je songe à supprimer le trousseau racine dès qu’on quitte l’appli…Histoire de bien dissuader.
Bref, à réfléchir…
Je songe à faire ceci :
Cela permet de faire « exceptionnellement » des opérations sur le compte racine, sans garder le trousseau sur le disque. Cela nécessite de se souvenir de son mnémonique pour déverrouiller temporairement le compte Racine.
Demander un mot de passe par compte est fastidieux pour l’utilisateur et ne l’encourage pas à avoir plusieurs comptes dérivés. Un seul mot de passe par compte Racine+dérivés encourage à faire des dérivations plutôt qu’à collectionner les comptes Racine//2.
Qu’en pensez-vous ?
NOTE : j’ai enfin compris comment avoir une KeyPair dérivée depuis la KeyPair racine, en Python, mais cela ne me sert à rien puisque je ne désire pas conserver la clef secrète Racine dans Tikka. Ce qui a pour inconvénient de redemander le mnémonique à l’utilisateur pour créer une dérivation.
Je suis en train de travailler sur l’import de compte V1 par transfert sur compte dérivé V2.
Et ne plus permettre d’utiliser son compte V1 dans Tikka.
Du coup je repense à la RFC et finalement j’ai l’impression que suivre la recommandation de transférer sur la dérivation //0 est assez pratique et plutôt une bonne idée.
Je parle uniquement du transfert de compte V1 vers dérivé V2 dans Tikka pour l’instant.
Pour le reste, Tikka reconnaît toutes les identités sur n’importe quelle dérivation, même root.
Alors oui, il est impossible d’empêcher que des comptes root aient plusieurs dérivation membres, mais autant que les clients ne se dispersent pas et essaient de créer les comptes membres sur //0. Même si plus tard l’utilisateur peut transférer l’identité où il veut.
Je verrais bien comme recommandation pour les clients, à préciser dans la RFC :
A discuter en visio je pense.
ping @HugoTrentesaux
Ces derniers jours, j’ai aussi réfléchi à ce sujet, et il se trouve que j’en arrive à peu près aux mêmes conclusions que toi 
Surtout depuis la possibilité de migrer une identité+solde facilement côté client entre 2 wallets.
Je suis OK avec ça. Je rajouterai que sur Ğecko, je compte désormais (entre autre suite à des discutions avec @HugoTrentesaux ):
Je n’ai pas tellement d’avis là dessus du point de vue de Duniter puisque c’est totalement transparent.
Côté client, c’est en effet mieux que les clients grand public se mettent d’accord pour éviter que ça devienne un problème et qu’on doive expliquer les dérivations. Si des clients “pour geek” veulent donner plus de souplesse (c’est le cas de polkadotjs app), il faudra juste pouvoir trouver facilement l’information de la convention utilisée, par exemple dans une infobox sur l’app.