# Migration identitée smith de Pini
**URL:** https://forum.duniter.org/t/migration-identitee-smith-de-pini/11783
**Category:** ĞDev
**Created:** [3 December 2023 12:11 UTC](https://forum.duniter.org/t/migration-identitee-smith-de-pini/11783 "2023-12-03T12:11:42Z")
**Posts on this page:** 17
**Page:** 2
### Author:  [@Pini](https://forum.duniter.org/u/Pini)
#### Post date: [3 December 2023 21:00 UTC](https://forum.duniter.org/t/migration-identitee-smith-de-pini/11783/21 "2023-12-03T21:00:12Z")
> [@poka](#):
>
> c’est la dérivation //2 par defaut sur gecko
Est-ce qu’il serait envisageable de permettre à l’utilisateur de choisir la dérivation à utiliser lors d’une migration v1 → v2 (tout en gardant la `//2` par défaut) ?
Sur ce type de manip ça permettrait de gagner 1 semaine 🙂
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [3 December 2023 21:04 UTC](https://forum.duniter.org/t/migration-identitee-smith-de-pini/11783/22 "2023-12-03T21:04:04Z")
Oui c’est déjà le cas, il faut juste créer la dérivation que tu veux avant, sur l’écran de migtation tu as un dropdown pour choisir le portefeuille de destination.
---
### Author:  [@Pini](https://forum.duniter.org/u/Pini)
#### Post date: [3 December 2023 21:06 UTC](https://forum.duniter.org/t/migration-identitee-smith-de-pini/11783/23 "2023-12-03T21:06:02Z")
Ah ben j’avais pas vu ça. Je le saurai pour la prochaine fois ! Merci.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [4 December 2023 10:23 UTC](https://forum.duniter.org/t/migration-identitee-smith-de-pini/11783/24 "2023-12-04T10:23:39Z")
> [@poka](#):
>
> Ah oui, c’est vrai que tu est dans la toile smith, donc tu ne peux pas migrer ton identité.
> Je ne sais pas si @HugoTrentesaux souhaite faire évoluer ça, mais le seul moyen pour le moment est de révoquer ton adhésion smith (après avoir go\_offline…), migrer ton identité puis refaire ton adhésion smith …
Il faudrait qu’on repense la toile forgeron parce qu’il y a plein de choses pas intuitives et pas forcément utiles. Mais pour l’instant je pense que ça peut rester comme ça si on veut migrer la Ğ1 un de ces jours, donc il faut tolérer ces effets de bord au genesis.
> [@Pini](#):
>
> Comment fait-on ça ?
Avec Ğcli c’est assez facile en ligne de commande :
```sh
gcli smith revoke
gcli identity change-owner-key
gcli smith request
gcli smith claim
```
Mais il faudrait [publier automatiquement un binaire de Ğcli](https://forum.duniter.org/t/publication-automatique-de-gcli/11396) parce que pour l’instant il faut compiler soi même.
---
### Author:  [@Pini](https://forum.duniter.org/u/Pini)
#### Post date: [4 December 2023 11:37 UTC](https://forum.duniter.org/t/migration-identitee-smith-de-pini/11783/25 "2023-12-04T11:37:18Z")
> [@HugoTrentesaux](#):
>
> Avec Ğcli c’est assez facile en ligne de commande :
Je ne suis pas certain que ce soit si simple. Il faut d’abord accéder à son identité v1 pour pouvoir révoquer le smithMembership. Je n’ai pu faire ça que via le polkafork de @poka.
J’ai un peu de mal à comprendre pourquoi on part smith par défaut sur la gdev, alors que le premier geste à faire pour récupérer son identité est de révoquer le smithMembership. Cette logique m’échappe 🙂
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [4 December 2023 11:47 UTC](https://forum.duniter.org/t/migration-identitee-smith-de-pini/11783/26 "2023-12-04T11:47:08Z")
Ah oui, pardon, avec des identités v1 sur gcli il faut faire :
```sh
gcli -S cesium smith revoke
```
(Ğcli est maintenant compatible avec les identifiants Cesium.)
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [4 December 2023 13:11 UTC](https://forum.duniter.org/t/migration-identitee-smith-de-pini/11783/27 "2023-12-04T13:11:08Z")
> [@Pini](#):
>
> J’ai un peu de mal à comprendre pourquoi on part smith par défaut sur la gdev, alors que le premier geste à faire pour récupérer son identité est de révoquer le smithMembership. Cette logique m’échappe 🙂
Parceque techniquement ce n’est pas une obligation de migrer son compte ailleurs, c’est juste que côté client on estime mieux de se passer des id/pwd cesium pour des raison de sécu et d’ux.
Comme les clients affiches et manipules des adresses ss58 sur la v2 au lieux des pubkey sur la v1, ça fait un changement de “rib” pour les utilisateurs quoi qu’il en soit, donc autant en profiter pour inciter à changer ses clés au passage à ce moment là.
Le jour de la vrai migration, le plus simple serait que tous les smiths indique leur changement de clé au genesis comme l’a fait cgeek ici: [resources/gdev.yaml · master · nodes / rust / Duniter v2S · GitLab](https://git.duniter.org/nodes/rust/duniter-v2s/-/blob/master/resources/gdev.yaml?ref_type=heads#L72-73)
(action qui se faisait auparavant côté py-g1-migrator)
Enfin sauf ceux qui veulent garder leurs id/pwd cesium avec des clients qui le permettent…
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [4 December 2023 16:02 UTC](https://forum.duniter.org/t/migration-identitee-smith-de-pini/11783/28 "2023-12-04T16:02:29Z")
En fait c’est surtout pour Polkadotjs qui contraignait l’utilisation de sr25519 que l’on avait besoin de migrer au Genesis. Mais grâce à ton fork, le besoin n’existe plus il me semble. @HugoTrentesaux tu confirmes ?
Je serai plutôt d’avis de retirer la migration au Genesis pour les prochains reboots.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [5 December 2023 14:00 UTC](https://forum.duniter.org/t/migration-identitee-smith-de-pini/11783/29 "2023-12-05T14:00:13Z")
Il y a un monde où les choix de design côté clients peuvent impacter les choix de certaines fonctionnalités côté serveur.
Si les clients grand publics incitent à migrer vers des mnemonics pour certaines raisons (choix que nous avions fait avec elois bien avant la migration substrate, dès le début de gecko sur GVA), alors les smiths ne pourront pas utiliser leur compte membre sur ces clients.
Ce n’est pas forcements grave, les smiths pouvants utiliser des outils avancés, mais il convient de le noter tout de même.
Si Cesium² ne fait pas le choix d’inciter les gens à passer vers du mnemonic, il risque d’y avoir un soucis d’homogénéité entre les clients.
Je suis tout à fait ouvert à rediscuter de cela, et à changer la façon de faire dans gecko mobile si on décide de finalement revenir en arrière sur cette décision, mais je pense qu’il faut qu’on soit tous au claire sur ce sujet pour savoir comment orienter les clients, comment communiquer au publique, et trancher certains design côté serveur.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [5 December 2023 14:56 UTC](https://forum.duniter.org/t/migration-identitee-smith-de-pini/11783/30 "2023-12-05T14:56:53Z")
J’ai l’impression qu’on a du mal à se détacher de l’idée 1 identité = 1 paire de clés. Il y a plein de manières de faire autrement :
- lier plusieurs paires de clés à une identité
- déléguer certains calls avec la pallet proxy
Ce que suggère la sous-toile forgeron telle que formulée actuellement est que les clés avec lesquelles les calls forgeron sont appelés doivent être les clés actuelles déclarées par l’identité (“owner\_key”). Sauf que vu comme c’est implémenté actuellement, ça interdit de changer les clés d’un forgeron.
Petite prise de recul : les “session\_keys” sont les clés du noeud, on recommande que ça ne soit pas aussi les clés de l’identité, mais la pallet authority\_members permet de faire le lien entre l’identité forgeron (et donc ses clés) et les session\_keys. On pourrait faire pareil pour l’adhésion forgeron.
L’analogie des clés est d’ailleurs bonne : on peut en faire un double. Si j’ai chez moi :
- un garage à vélo
- une maison
- un coffre fort
je peux distribuer un double des clés du garage à vélo à tous mes voisins, un double des clés de ma maison à quelques amis, et être le seul à avoir les clés de mon coffre fort. Ce n’est pas parce que ma maison est ouverte que j’y suis.
Tout ce qu’on demande aux gens c’est de faire attention aux clés qui ont les droits d’accès sur leur identité et leur appartenance forgeron pour éviter que quelqu’un de mal intentionné s’en empare et nuise au réseau en usurpant leur trousseau de clé. Et c’est le sens de la toile de confiance : on s’engage à être le seul à avoir accès à ses clés.
* * *
Donc si on s’aperçoit que c’est pratique d’avoir :
- les clés d’un portefeuille sur son téléphone sans mot de passe
- les clés de son identité sur son téléphone, protégées par un mot de passe
- les clés forgeron dans son keepass ou sur un support matériel “hardware wallet”
- les clés de session de son nœud validateur dans un conteneur sécurisé sur son serveur et nulle part ailleurs
alors il faut qu’on fasse en sorte que ces clés soient différentes.
* * *
Concrètement, voici à quoi pourrait ressembler un nouveau comportement :
- quand une identité fait une demande d’adhésion forgeron, elle déclare des clés forgeron
- à partir de ce moment, les clés de l’identité ne peuvent plus être utilisées pour les actions forgeron
- seules les clés forgeron permettent d’effectuer des actions forgeron
En fait, l’intuition de elois d’avoir des métadonnées d’adhésion était bonne, mais c’était les clés forgeron qu’il fallait donner, pas les session\_keys.
* * *
Autre proposition d’implémentation plus simple :
- à l’adhésion forgeron, les clés de l’identité sont utilisées
- à tout moment un forgeron peut changer ses clés
- seules les nouvelles clés pourront effectuer des actions forgeron
---
### Author:  [@Pini](https://forum.duniter.org/u/Pini)
#### Post date: [10 December 2023 21:05 UTC](https://forum.duniter.org/t/migration-identitee-smith-de-pini/11783/31 "2023-12-10T21:05:46Z")
J’essaie à nouveau de changer mon identité via polkadot mais je ne m’en sors pas
Comment obtenir le paramètre `newKeySig` de l’extrinsic `indentity.changeOwnerKey()` ?
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [10 December 2023 21:16 UTC](https://forum.duniter.org/t/migration-identitee-smith-de-pini/11783/32 "2023-12-10T21:16:30Z")
> [@Pini](#):
>
> Comment obtenir le paramètre `newKeySig`
Ca me rappel quelque chose…
> [@Migrate identity (identity.changeOwnerKey())](https://forum.duniter.org/t/migrate-identity-identity-changeownerkey/9669/1):
>
> @elois peux-tu m’éclairer sur ce qu’est `newKeySig: `
> [@Migrate identity (identity.changeOwnerKey())](https://forum.duniter.org/t/migrate-identity-identity-changeownerkey/9669/2):
>
> Tu doit signer un message avec la nouvelle clé et insérer uniquement la signature, le message étant connu par la blockchain, ça ne servirait à rien de le fournir. voici le message à signer:
>
> `"icok" ++ GENESIS_HASH ++ IDTY_INDEX ++ OLD_OWNER_KEY`
>
> Tout doit être encodé et **concaténé en binaire**.
>
> - `"icok"` c’est juste un préfixe constant pour s’assurer qu’on signe bien pour cette opération et pas une autre, `icok` correspondant aux initiales de **i** dentity **c** hange **o** wner **k** ey. Encodé en ASCII ou utf8 c’est pareil, en hexa ça donne `0x69636F6B`.
> - `GENESIS_HASH` pour empêcher le rejeu sur un autre réseau.
> - `IDTY_INDEX` pour identifier l’identité pour laquelle on veut changer de clé publique. Doit être encodé en little endian non-signé sur 4 octets.
> - `OLD_OWNER_KEY` l’ancienne clé publique, pour empêcher le rejeu sur le même réseau. Ça implique qu’il ne faut jamais revenir à une ancienne clé.
---
### Author:  [@Pini](https://forum.duniter.org/u/Pini)
#### Post date: [10 December 2023 22:03 UTC](https://forum.duniter.org/t/migration-identitee-smith-de-pini/11783/33 "2023-12-10T22:03:32Z")
> [@Migrate identity (identity.changeOwnerKey())](https://forum.duniter.org/t/migrate-identity-identity-changeownerkey/9669/2):
>
> Tu doit signer un message avec la nouvelle clé
Donc je vais dans _Développeur / Signer et vérifier_, puis je saisis :
```auto
0x69636F6B
```
Je signe et je copie-colle la signature obtenue comme paramètre pour l’extrinsic ?
Si j’ai correctement compris, IDTY\_INDEX = 95320000 (12949 en décimal).
Comment je retrouve le GENESIS\_HASH et et OLD\_OWNER\_KEY en hexa ?
**EDIT** : J’arrête les noeuds dans la tête. Je suis passé par gcli et ça a marché.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [10 December 2023 22:58 UTC](https://forum.duniter.org/t/migration-identitee-smith-de-pini/11783/34 "2023-12-10T22:58:53Z")
> [@Pini](#):
>
> je vais dans _Développeur / Signer et vérifier_
> [@Migrate identity (identity.changeOwnerKey())](https://forum.duniter.org/t/migrate-identity-identity-changeownerkey/9669/22):
>
> > [@Migrate identity (identity.changeOwnerKey())](https://forum.duniter.org/t/migrate-identity-identity-changeownerkey/9669/21):
> >
> > Y a il un moyen pour moi de vérifier la signature via polkadot js ?
>
> Non, polkadot js ne peut vérifier que les signatures émises via la lib polkadot/api, car ça ajoute des wrapping bytes
> [@Pini](#):
>
> Comment je retrouve le GENESIS\_HASH
Oui via la lib:
`api.genesisHash.toHex()`
> [@Pini](#):
>
> **EDIT** : J’arrête les noeuds dans la tête. Je suis passé par gcli et ça a marché.
Mieux
---
### Author:  [@Pini](https://forum.duniter.org/u/Pini)
#### Post date: [11 December 2023 12:46 UTC](https://forum.duniter.org/t/migration-identitee-smith-de-pini/11783/35 "2023-12-11T12:46:58Z")
Ne me reste plus qu’à gérer les session keys avant de passer online. J’ai fait ça :
```auto
$ ./bin/gcli -u ws://localhost:9944 --no-indexer smith update-keys
Mnemonic:
transaction submitted to the network, waiting 6 seconds...
```
Il n’y a aucun message en sortie confirmant ou non que ça s’est bien passé. Comment puis-je contrôler que l’opération rotate keys + set session keys a bien réussi ?
---
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [11 December 2023 15:06 UTC](https://forum.duniter.org/t/migration-identitee-smith-de-pini/11783/36 "2023-12-11T15:06:55Z")
Avec Polkadot.js dans Données de la chaîne, session, nextKeys()
> [@Becoming smith (request\_membership, claim\_membership)](https://forum.duniter.org/t/becoming-smith-request-membership-claim-membership/10571/6):
>
> Storage session.nextKeys(pubkey) should be Some.
---
### Author:  [@Pini](https://forum.duniter.org/u/Pini)
#### Post date: [11 December 2023 15:43 UTC](https://forum.duniter.org/t/migration-identitee-smith-de-pini/11783/37 "2023-12-11T15:43:24Z")
Ayé je forge à nouveau :
[Previous page](https://forum.duniter.org/t/migration-identitee-smith-de-pini/11783.md?page=1)