# Be clear about what "account migration" is
**URL:** https://forum.duniter.org/t/be-clear-about-what-account-migration-is/12701
**Category:** Applications
**Created:** [18 November 2024 12:18 UTC](https://forum.duniter.org/t/be-clear-about-what-account-migration-is/12701 "2024-11-18T12:18:18Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [18 November 2024 12:18 UTC](https://forum.duniter.org/t/be-clear-about-what-account-migration-is/12701/1 "2024-11-18T12:18:18Z")
> [@Ğ1nkgo v2 support progress, plan and pubkeys/address proposal](https://forum.duniter.org/t/g1nkgo-v2-support-progress-plan-and-pubkeys-address-proposal/12617/14):
>
> My ideal is to migrate the network to v2 and that the users do not see more than improvements. The use of bip39 is not necessary for existing wallets IMHO. In other words: We should continue asking for pass/passphrases to old wallets (or nothing for ginkgo/superbot basic wallets) and only use bip39 in new accounts (if we don’t find nothing more usable). Derivations? Not now for them.
> [@Ğ1nkgo v2 support progress, plan and pubkeys/address proposal](https://forum.duniter.org/t/g1nkgo-v2-support-progress-plan-and-pubkeys-address-proposal/12617/15):
>
> About Salt/passwords, they proved to be a real problem for users.
> As we’re moving from pubkey to ss58 addresses, the migration is the best opportunity to offer a better form of key generation.
> But not all Wallets have to follow the same strategy, as long as we make the minimum effort to ensure compatibility between the main tools.
We have here a good illustration of **two different approches** to make things simple for the user :
1. change the least things possible because the user has learned how to work with handicapping features
2. change everything at once to make things simpler for the user
I think it’s nice to have multiple clients with different strategies. I also think that when the client does something onchain with the user’s account, it should get consent from the user, which involves him **understanding what the app does**.
Right now it’s not really clear that Ğecko “account migration” is actually a transfer from the user account to another account, with an optional identity transfer.
About the ss58 vs b58, since it is offchain, it is a choice from the client that does not impact other clients. So the users can choose their app for what they like / dislike in it.
* * *
Outside of this, the two approches will correspond to two categories of users.
---
### Author:  [@vjrj](https://forum.duniter.org/u/vjrj)
#### Post date: [23 November 2024 10:44 UTC](https://forum.duniter.org/t/be-clear-about-what-account-migration-is/12701/2 "2024-11-23T10:44:08Z")
> [@HugoTrentesaux](#):
>
> - change the least things possible because the user has learned how to work with handicapping features
> - change everything at once to make things simpler for the user
- _change the least things possible **for existing users (authentication, pubkey identity, etc.)**, because the user has learned how to work with handicapping features. **Introduce new features only for new users after v2 nodes migration.** _
- Regarding _“making things simpler for the user,”_ as someone who spends a lot of time in G1 markets resolving issues with wallets, nodes, etc., I believe migrating all current users would not make things simpler. On the contrary, it genuinely feels like a nightmare and something that would discourage users from migrating to v2.
This is why I propose migrating our protocol, nodes, etc., to v2 while avoiding any noticeable changes on the client side (at least from the user’s perspective). This is the simpler for me and rest (IMHO).
v2 and polkadot/substrate is a great opportunity to do many things, but not necessary now, in a migration.