Mapping Out Status App, Keys, and Names

Archive UX and UXR
1

After today’s Multi-account discussion, I’ve started to revisit my older diagrams that attempted to map out how keys are derived and used within Status.

I have now attempted to create a map of Status and how keys will be derived and stored in the various parts of the “Status App.” This is also an attempt to get a logical overview of how we are sectioning off Status and how they interoperate with each other.

Hopefully we can use this as a diagram to make our arguments on what Status is and why we call various parts of it the things we do, and what we eventually want to agree on.

Here is a miro (previously called realtimeboard) link to what I currently have since that talk:

1 Like
2

is it possible to share for status team? i can’t open it

1 Like
3

updated the link, should work now

4

I’ve updated this to what seems to be the current state of things. I need everyone who has information on this to put in their 2c so that we get a VERY CLEAR AND ACCURATE picture here.

Status%20Keys%20and%20Entity%20Names
Status%20Keys%20and%20Entity%20Names2444×2556 335 KB

This can also be found in the OP link under the Current Scheme (V1) view.

2 Likes
5

If you right click the photo and “open in new tab” you can see an enlarged version. You can also do that within the OP link.

6

So cool, that’s super usefull!

My 2 cents:

  • (typo ?) the BIP44 wallet root key last level is not hardened and should be m/44’/60’/0’/0
  • when discussing multiaccount we had decided that the the BIP44 wallet root key is stored (non keycard mutliaccount) so that adding a new account (on the BIP44 path) does not need to enter the seed again
  • might be nice to mention ( unless it’s super obvious that it is necessarily) that for keys that are bound to be derived we store the extended key
1 Like