wallet: Make and record an init-messenger pattern decision

Abierto
#8,790 0 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@grypez ya está trabajando en esto.

Desde el 26/5/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

team-ocap-kernel
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.md links to the decision document.
Context
  • Extension reference: app/scripts/messenger-client-init/ — getInitMessenger / getMessenger factory pattern.
  • Mobile reference: app/core/Engine/messengers/ — same dual-factory convention.
Subissues
  • #8791
Lenguaje dominante
TypeScript
Estrellas
422
Forks
313
Merge medio
1 d 8 h
PR fusionados (30 d)
414

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de MetaMask/core

Todos los issues de MetaMask/core

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.