wallet: Make and record an init-messenger pattern decision
Maintainers usually reply within 1 day
@grypez is already working on this.
Since May 26, 2026.
Assessment
This issue has not been assessed yet.
Description
Problem
The extension and mobile clients both create two restricted messengers per controller: a controller messenger (runtime, narrow privileges) and an init messenger (boot-only, broader privileges for one-shot setup steps). The wallet currently uses a single messenger per controller. Whether to adopt the two-messenger pattern is unresolved and undocumented. Without a written decision, every new controller wired into the wallet inherits this ambiguity silently.
Proposed direction
Evaluate the trade-offs and write a short decision document (init-messenger-decision.md) in the wallet package recording the chosen approach and the concrete conditions under which it should be revisited. Link from the package README.
To inform the decision, gather empirical data on which messenger actions are invoked during init() vs. at runtime across the controllers already wired (see sub-issue for tooling). If the init-time and runtime allowlists are effectively the same, the two-messenger pattern adds boilerplate without narrowing any privileges — which favors deferring adoption.
Acceptance
- A decision is made and written down in
packages/wallet/init-messenger-decision.md. - The document covers: which pattern is chosen, why, and what conditions would trigger revisiting.
packages/wallet/README.mdlinks to the decision document.
Context
- Extension reference:
app/scripts/messenger-client-init/—getInitMessenger/getMessengerfactory pattern. - Mobile reference:
app/core/Engine/messengers/— same dual-factory convention.
Subissues
- #8791
- Dominant language
- TypeScript
- Stars
- 422
- Forks
- 313
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 414
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from MetaMask/core
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
CI: "Validate changelog diffs" job fails on every fork-sourced pull requestPossibly taken @Roxen-AS claimed this 20 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
platform-api-docs: `scan` strategy misses ESM-only packages, which ship `.d.ts` rather than `.d.cts`Possibly taken @gaohan1994 claimed this 21 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
[utils] Replace the `uuid` dependency with `crypto.randomUUID()`Possibly taken @avantikonde claimed this 34 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
MetaMask/core#10210 · 1 reaction ·
Maintainers usually reply within 1 day
-
[utils] `toWei` accepts fractional wei and returns wrong valuesPossibly taken @Roxen-AS claimed this 20 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
Similar issues
-
enhancement module: library-ui
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
chthollyphile/folia-major#1206 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
typescript-eslint/typescript-eslint#13189 ·
Maintainers usually reply within 2 days
-
severity:medium triage:confirmed triage:in-progress triage:reproduced
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
Cotal-AI/Cotal#6442 · 2 comments ·
Maintainers usually reply within 1 day
-
wrong type
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
elastic/elasticsearch-specification#6919 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day