Feature request: Vanity identicon

[Tbaut]

One feature that Signer had in the early days, and that ppl really liked, is the ability to see and choose the identicon and address of the account you generated. It would be great to bring this back.

Upon new account creation the app would show several identicons corresponding to several mnemonics. Users could generate more if you didn't like any. This allowed users to actually get an identicon they like. Only then would they be presented with the mnemonic. Here's how it looked like in Stylo for instance:

[montekki]

It wouldn't make much sense now since the root keys are not normally used and they do not have identicons (now root keys only have jdenticons) and in your proposal you can only show identicons for root keys. And the derivations will each have a different identicons; but they are always pre-defined for obvious reasons, as in they are deterministically derived from root.

[Tbaut]

It wouldn't make much sense now since the root keys are not normally used

Do you have any data to back this? I'd argue the opposite, just like in every other wallet, Ledger included, ppl use root keys. They were also the source of a major annoyance and compains from users when Signer decided to make root keys a second class citizen. Also Vault does not create any derived key per default any more. You are referring to a dark history of signer IMHO that's thankfully just this.. history.

[montekki]

You can check the latest releases, but generally work around root keys and jdenticons has been going for some while it looks for example: #2053

[montekki]

Do you have any data to back this?

What I meant is that currently in Vault it is not that straightforward to use root keys for signing and they are treated as a special case; they don't even have an dot-identicon to signal this. All normal signing flows are supposed to be done with derived keys.

[Tbaut]

This is Vault with a fresh account. Root keys are the default, there are identicons 🤷.

All normal signing flows are supposed to be done with derived keys.

Idk what's more normal than this. Fact are, many users don't use derivations. The feature request above is for these.

[prybalko]

Root keys are the default, there are identicons 🤷.

Not anymore. Here is the screenshot from the latest master Android build with a fresh account

screenshot

This is how it works on iOS as well. However, it has not been released on Android yet.

[Tbaut]

Well this is a mistake. Why has this decision been made? Is this backed by any research? Or is this yet again the arbitrary decision of one person?

This kind of design is the exact reason why Stylo, the fork of Signer I made back then, has been so well received. This behavior with default derivation caused confusion to many many users since v4. You know what, I now realised that this is the reason why some ex-Parity ppl contacted me a couple weeks back, because "hey I don't understand why the address is different when I typed the same mnemonic". The mistake was made in the past, then was corrected while Alex Slesarev was leading the dev and the designer made some research. Then you make the mistake again 🤦

You should not impose derivation paths, and should not make the root key a second class citizen. Go out of the bubble, open your eyes and look at what the wallet ecosystem does.

[prybalko]

Why has this decision been made?

https://hackmd.io/7OPDldkXRhOIBwlHfnwzSw

[krodak]

@Tbaut please try out actual newest version and maybe then reassess this discussion:

• currently we don't enforce any default derived keys - when user creates key set, they are free to choose if they want to create default derivations for selected networks, but it's optional
• you can create empty derivation for any network to use
• I'd be hesitant to call some decisions "a mistake" without insight in decision process, it's easy to pass judgement, it's harder to prove one's point
• I'm sorry, but I also don't see any data quoted on your side that would point towards previous design being optimal, beside "some ppl contacted me", "facts are"

For reference, this is current behaviour regarding key set creation, "default" derived paths and process of adding new ones.

If you find any of those not to your liking, please suggest other solutions with pros / cons if you really feel something is wrong with current approach, but arguments like "back in the days it was better" does not help anyone to make any progress and improve Vault 🙏🏻 🙇🏻‍♂️

[Tbaut]

Take me as as normal user. I have Vault on an android device that is online, to test. The version I have here is the one I screenshoted. If things have changed and not been released, I didn't notice.. and didn't test. I take ppl's word and go with it.

Happy to read that it indeed won't be a default. I'll check it out, and open subsequent issues eventually.

I'd be hesitant to call some decisions "a mistake" without insight in decision process, it's easy to pass judgement, it's harder to prove one's point

I'm sorry, but I also don't see any data quoted on your side that would point towards previous design being optimal, beside "some ppl contacted me", "facts are"

You're right, I shouldn't be that "trust me" person, I didn't spend the time searching for all the issues that must be around regarding the derivation. There are countless discussion on Element as well. Things along the line of #833 polkadot-js/extension#931 or #887.

Closing this issue as it seems you'd never consider it given the different types of users.

[Tbaut]

I've had yet other ppl reach out in the past weeks, because they suddenly thought they'd lost their funds. #2217 (comment) is a fresh example of this.

I hope you pay attention to users', and previous contributors' feedback in the future. Changing such important default settings is damaging if not communicated properly.

edit: Can't help but add to the list every issue I see popping up:

• Why do I get different accounts using the same '24 word phrase' recovery on ANDROID and IPHONE? #2270 (comment)

[Dmitry-Borodin]

Thx @Tbaut for a feedback, we considering improving this communication.