Support Multi-SRP in SeedlessOnboardingController #5
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ler' into feat/seedless-multi-srp
himanshuchawla009
approved these changes
Apr 29, 2025
packages/seedless-onboarding-controller/src/SeedlessOnboardingController.ts
Show resolved
Hide resolved
packages/seedless-onboarding-controller/src/SeedlessOnboardingController.ts
Show resolved
Hide resolved
packages/seedless-onboarding-controller/src/SeedlessOnboardingController.ts
Outdated
Show resolved
Hide resolved
fix: encryptor type
…ler' into feat/seedless-multi-srp
lwin-kyaw
commented
May 13, 2025
There was a problem hiding this comment.
This tgz package to be used as a github package in the mobile, since the mobile cannot use the tgz file.
This tgz file will be removed once the PR is raised in metamask repo when the preview-package can be built.
…at/secret-metadata-type
feat: Generic SecretMetadata
…ler' into feat/seedless-multi-srp
…oller' into feat/seedless-multi-srp
## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> New release for `@metamask/assets-controllers` that includes option to report DeFi metrics. ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [X] I've updated the test suite for new or updated code as appropriate - [X] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [X] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [X] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes --------- Co-authored-by: cryptodev-2s <[email protected]>
…aMask#5876) ## Explanation This PR ensures the origin (URL) that initiates a `wallet_sendCalls` request is sent to the security alerts API. This additional context is important for improving PPOM validation and threat detection accuracy. Changes: - Added `origin` property to `ValidateSecurityRequest` type. - Updated `validateSecurity` callback to pass the `origin`. <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> Related to MetaMask/MetaMask-planning#5030 ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [x] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
Currently, if a consumer makes a request to an RPC endpoint via a network provider object, and that request continually fails in some way and then throws a circuit breaker error, it will never resolve. Naturally, this causes problems if the consuming code (e.g. TransactionController, or UI code) is expecting a response from the network in order to proceed. This problem occurs because internally the NetworkController wraps requests in special middleware that use the block tracker to get the latest block number. This middleware gets executed before the desired request reaches the network, and in this case because the block tracker does not return a resolved promise, the middleware does not resolve along with the entire request. This bug has been resolved in `@metamask/eth-block-tracker` 12.0.1 and `@metamask/eth-json-rpc-middleware` 17.0.1. So, to fix this problem, this PR upgrades these packages.
## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> Adds new seedless onboarding controller. This controller allows MM extension and mobile users to login with google, apple accounts. This controller communicates with web3auth nodes + relies on toprf sdk (unreleased) to perform CRU operations related to backing up srps. The full list of operations supported are as follows: - Authenticate OAuth user using the seedless onboarding flow and determine if the user is already registered or not - Create a new Toprf key and backup seed phrase - Add a new seed phrase backup to the metadata store - Add array of new seed phrase backups to the metadata store in batch (useful in multi-srp flow) - Fetch seed phrase metadata from the metadata store - Update the password of the seedless onboarding flow The controller also persists some data to the local encrypted vault similar to keyring controller. This vault is encrypted with user password and contains ek, sk related to toprf flow. We also store backupHashes locally to showcase in settings page whether a srp is backed up or not The following items are not included in this PR and will be included in the next one - what to do when nodeAuthTokens are expired? - expires based on login timeout - adding support for refresh tokens - what to do when toprfEncryptionKey, toprfAuthKeyPair expire? - expires when user changes password - solved by password syncing - support password syncing when available (currently under design) ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> Please refer to seedless onboarding feature narrative ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [ ] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes --------- Co-authored-by: Chaitanya Potti <[email protected]> Co-authored-by: himanshuchawla009 <[email protected]> Co-authored-by: matthiasgeihs <[email protected]> Co-authored-by: Elliot Winkler <[email protected]>
Co-authored-by: Elliot Winkler <[email protected]>
## Explanation Minor release of @metamask/transaction-controller. <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Changelog <!-- THIS SECTION IS NO LONGER NEEDED. The process for updating changelogs has changed. Please consult the "Updating changelogs" section of the Contributing doc for more. --> ## Checklist - [ ] I've updated the test suite for new or updated code as appropriate - [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs), highlighting breaking changes as necessary - [ ] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
…feat/seedless-multi-srp
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Explanation
Adds new seedless onboarding controller. This controller allows MM extension and mobile users to login with google, apple accounts. This controller communicates with web3auth nodes + relies on toprf sdk (unreleased) to perform CRU operations related to backing up srps.
The full list of operations supported are as follows:
The controller also persists some data to the local encrypted vault similar to keyring controller. This vault is encrypted with user password and contains ek, sk related to toprf flow.
We also store backupHashes locally to showcase in settings page whether a srp is backed up or not
The following items are not included in this PR and will be included in the next one
References
Please refer to seedless onboarding feature narrative
Changelog
Checklist