De plus, on peut cumuler des chemins visiblement :
// known mnemonic, well, now it is - don't use it for funds
const MNEMONIC = 'sample split bamboo west visual approve brain fox arch impact relief smile';
// type: ed25519
const keyring = new Keyring();
// our ed25519 pairs
console.log(keyring.createFromUri(MNEMONIC).address);
console.log(keyring.createFromUri(`${MNEMONIC}//hardA//hardB`).address);
console.log(keyring.createFromUri(`${MNEMONIC}//hard///password`).address);
// some sr25519 pairs
console.log(keyring.createFromUri(MNEMONIC, {}, { type: 'sr25519' }).address);
console.log(keyring.createFromUri(`${MNEMONIC}//hard/soft`, {}, { type: 'sr25519' }).address);
Par défaut, l’extension de navigateur Polkadot.js génère des dérivations de type hard avec un simple entier, en commençant par « 0 », soit comme uris :
mnemonic//0
mnemonic//1
mnemonic//2,
Etc, etc…
Si on dérive d’une dérivation, l’extension ajoute un sous chemin hard avec le même principe :
mnemonic//0//0
Je propose de partir sur ce principe simple, pour harmoniser les dérivations chez les clients RPC.
Ca tombe bien que tu en parles, j’allais ouvrir le sujet
Les dérivations doivent être hardened en effet, donc //0, //1, ect …
C’est ce que je fait dans gecko pour le moment, j’ai repris le même protocole qu’on s’était fixé avec elois avant v2, c’est à dire:
//0: Dérivation transparente membre (peut se faire certifier)
//1: Dérivation « semi-opaque » (non implémenté)
//2: Dérivation « opaque » (non implémenté)
//3: Dérivation « transaparente »
//4: Dérivaiton « semi-opaque »
ect …
Soit des plages de modulo 3.
Je n’arrive pas à retrouver où l’on avait décrit ça avec @elois.
Surtout il faut toujours partir de la seed root pour dériver, et ne pas dériver à la chaine, sans quoi le résultat sera totalement différent.
Donc pour le moment dans Gecko duniter-v2s, comme je ne gère pas encore les portefeuilles membres, la première dérivation créé est la //3, puis la //6, puis //9 ect …
A l’import d’un mnemonic, l’address root n’est donc pas utilisé du tout, jamais présenté à l’utilisateur.
L’adresse par defaut est donc //3.
Je pense que même une fois que j’aurais implémenté la gestions des membres, je garderais //3 en première address généré par defaut.
L’utilisateur devra faire une actions pour générer la //0, valider la licence G1, instructions wot, vérifié qu’il a compris ect …
C’est très important qu’on se mette d’accords là dessus.
Qu’en penses-tu @vit ?
C’est pas sur le forum, j’avais commencé une RFC ici:
EDIT: si on veut poursuivre dans la même lignée, il faudrait réécrire cette RFC en utilisant les notations standard de substrate, si l’un de vous peut le faire, ça ne concerne que les clients/wallets après tout
