Support keyring metadata in KeyringController #5112
Conversation
|
@metamaskbot publish-preview |
|
Preview builds have been published. See these instructions for more information about preview builds. Expand for full list of packages and versions. |
PatrykLucka
force-pushed
the
multi-srp-mvp
branch
from
1ab7570 to
407f96d
Compare
|
@metamaskbot publish-preview |
|
Preview builds have been published. See these instructions for more information about preview builds. Expand for full list of packages and versions. |
PatrykLucka
force-pushed
the
multi-srp-mvp
branch
3 times, most recently
from
b9ca305 to
83c8a21
Compare
|
@metamaskbot publish-preview |
|
Preview builds have been published. See these instructions for more information about preview builds. Expand for full list of packages and versions. |
There was a problem hiding this comment.
Let's make sure the keyring metadata also bubbles up to the AccountsController events.
I believe this block would need an update for that to happen.
Also, do we expect 1 keyring ID === 1 SRP ?
or would we ever have multiple keyrings derived from 1 SRP?
|
@metamaskbot publish-preview |
1 similar comment
|
@metamaskbot publish-preview |
|
Preview builds have been published. See these instructions for more information about preview builds. Expand for full list of packages and versions. |
montelaidev
force-pushed
the
multi-srp-mvp
branch
from
131c449 to
0e8b42a
Compare
|
@metamaskbot publish-preview |
|
Preview builds have been published. See these instructions for more information about preview builds. Expand for full list of packages and versions. |
PatrykLucka
force-pushed
the
multi-srp-mvp
branch
from
4c4eb52 to
aec8dc4
Compare
PatrykLucka
force-pushed
the
multi-srp-mvp
branch
from
93856d4 to
aebc8a7
Compare
|
My understanding is that now, if In either case, can we add a test case for the expected behavior? |
This is a suggestion on how to improve error handling for keyring metadata in the PR #5112.
|
@metamaskbot publish-preview |
|
Preview builds have been published. See these instructions for more information about preview builds. Expand for full list of packages and versions. |
PatrykLucka
force-pushed
the
multi-srp-mvp
branch
from
74d7cea to
7a6b427
Compare
| @@ -213,6 +214,7 @@ export type AccountsControllerMessenger = RestrictedMessenger< | |||
| type AddressAndKeyringTypeObject = { | |||
| address: string; | |||
| type: string; | |||
| metadata: KeyringMetadata; | |||
There was a problem hiding this comment.
Do we really need this? I think it has no real use, so I would remove it if possible?
There was a problem hiding this comment.
@ccharly I'll have to re-re-read (😅) the PR but I think it could be of use for account syncing?
There was a problem hiding this comment.
It could be useful indeed 🤔 even though, I'm not a fan of duplicating (kinda like mirroring, but here we truly are duplicating) state everywhere.
However, we must be careful with the metadata field, we do have a schema for the InternalAccount and "native accounts" (or also named "normal accounts") which includes simple + HD keyring accounts, will also be re-created as InternalAccount in the updateAccounts method of this controller.
This controller re-creates internally its list of accounts based on keyring's accounts.
And I think having a "flat" KeyringMetadata here is not ideal. I would maybe add an intermediary field for this, like keyringMetadata maybe? It could also introduces conflicts and overwrites potentially, because of this logic:
BTW, here's the list of "known metadata":
WDYT @montelaidev? @PatrykLucka is this already being used elsewhere in some other PRs?
There was a problem hiding this comment.
For now, the goal is to make it easier to find the keyring of a specific account. Since we can have multiple HD keyrings, it's now easier to query them by id. However, we will soon need to add entropySourceId, which will be essential to support multiple SRPs for snaps.
There was a problem hiding this comment.
entropySourceId at the moment (though this doesn't exist in our code anywhere, only in our Architecture) is in account.options
The reasoning here is that an account snap can set this during the AccountCreated event (see this line here in "Multi-SRP for preinstalled account snaps"
I'm not sure if this helps, just feel like it's the right time to highlight it
There was a problem hiding this comment.
I think your comment is on point actually @shane-t! That makes sense for Snap accounts, but to my knowledge, we don't have any use of the options bag for the "normal accounts". So IDK if we'll follow the same logic for those, but this we have to be decided (if not already 🙈).
My comment here, was more about being careful of adding some new information to the metadata object (because of the way InternalAccount are being re-created internally).
Also, after checking the accounts state, I'd say that metadata.keyring.id might be the safest option here (but could be a bit more tricky to implement).
My recommendation here would be to remove this keyringMetadata from the logic of this PR if we don't use it now.
We can always follow-up with a 2nd PR to re-introduce this if needed (but we'll have to discuss and add more tests to make sure nothing gets overwritten or cause conflicts).
WDYT @shane-t @PatrykLucka?
There was a problem hiding this comment.
Makes sense. As I understand it though, we have to find some way for @mathieuartu to read the keyring ID for eth-hd-keyring account related events, right?
I might be off here, but the type that's needed in, is whatever type represents the event paylioad
There was a problem hiding this comment.
We need some form of metadata about the source of the account in the accountAdded/accountRenamed events to be able to perform account sync properly.
If we can get that information by some other means, please guide us to it.
A second PR would also be acceptable as long as it's within a similar timeframe.
Without this, we won't be able to filter events properly and you'll end up with a new account on your primary SRP every time a new account is added elsewhere.
There was a problem hiding this comment.
For now, the goal is to make it easier to find the keyring of a specific account
@PatrykLucka could you elaborate on that? since withKeyring can be used with the { address } selector, isn't the account itself enough to access the keyring it belongs to?
There was a problem hiding this comment.
Just to close up this thread, it has been decided to not inject those metadata for the moment. Account syncing will be addressed later with the addition of entropySource (see SIP-30).
|
New dependencies detected. Learn more about Socket for GitHub ↗︎
|
PatrykLucka
force-pushed
the
multi-srp-mvp
branch
from
3164e97 to
a0a1422
Compare
PatrykLucka
force-pushed
the
multi-srp-mvp
branch
from
023cdfa to
66c3f05
Compare
Explanation
Currently, we assume that the only HD Keyring is the Primary Keyring. Most methods related to adding accounts or displaying the SRP assume that it refers to the first keyring, which is the Primary Keyring. To enable having more than one SRP, and consequently more than one HD Keyring, this PR adds an array called
keyringsMetadata, which contains an id that can be used to identify all keyrings and a proper place to keep other data we might want to add to each keyring such asname.keyringsMetadatais a separate in order to minimize changes that we need to make to keyrings and the way we process them. We also can keep this data outside of the vault, as it's not storing any sensitive data.References
Related to ADR 0002-keyring-id-and-name.md
Blocks Extension PR
Changelog
@metamask/keyring-controller{ id: string }selector towithKeyringfunctionkeyringIdparam toaddNewAccountfunctionkeyringIdparam toexportSeedPhrasefunctionkeyringIdparam togetAccountsfunctionkeyringIdparam toverifySeedPhrasefunction#getKeyringByIdhelper functionkeyringIdparam to#verifySeedPhrasefunctionmetadataparam to#newKeyringfunctionmetadataparam to#newKeyringfunctionChecklist