Storage Resilience E10: Full Application-State Backup + Redundant Storage

What is this about?

Goal

Keep a complete backup of application state so we can silently and reliably restore all state after a corruption event — no user-facing recovery flow, no "some data was lost" notice.

Why

Partial recovery (old E5) only recovers silently in limited cases; the rest of the time the user still hits a recovery flow or a data-loss notice. A full backup restores everything, invisibly. Mark believes it's easier to build and maintain than partial recovery and strictly better for users. Redundancy across independent mechanisms is the most reliable protection (Simeon): IndexedDB > browser.storage > OPFS — every store has bugs, so don't rely on one.

Hard prerequisite (gate)

Application state must be shrunk first — target under ~1MB; David: at least 2× smaller. Two blockers make this non-negotiable: (1) users already complain about MetaMask's storage footprint; (2) users who are out of space can't fit a full backup at all. So E1 + E3 must land before backup ships. (David, reply 11)

Success criteria

• Complete application state backed up redundantly across ≥2 independent mechanisms.
• On a corruption event, full state is restored silently (no recovery flow / no notice) in the common case.
• Backup write cost bounded: incremental IndexedDB backup on change; OPFS file backup throttled (≤ ~1/hour or /day).
• Holds up on Firefox despite its weaker storage integrity (redundancy covers it).

Tasks

• Decide backup topology: expand current backup, add OPFS file backup, or both. Proposed happy-medium: expand current backup + a throttled OPFS file backup (≤ ~1/hr–1/day) that's less up-to-date but higher-integrity. (Mark, reply 9)
• Resolve: does the full backup replace or augment the current vault backup? (open question — Alexey/Mark, replies 6–7)
• Implement redundancy tiers: IndexedDB (primary, incremental) → browser.storage → OPFS (file, throttled, highest integrity — direct filesystem, no DB layer).
• OPFS adapter: split-state style, one file per controller (<controller>.json); handle retry / errors / atomicity. (David, reply 19)
• Evaluate finer granularity (one key per top-level controller property) — only if the persistence↔update-event plumbing complexity is justified. Persistence layer doesn't currently see update events. (David, replies 16–17)
• Silent restore path: detect corruption, select newest valid copy across tiers, restore with no user-visible flow.
• Verify post-shrink footprint of duplicating state is acceptable (ties to the E1/E3 gate).
• Firefox validation (known integrity issues; small browser team — Mark, reply 5).
• Telemetry: backup writes, restore events, tier used, restore success/failure.
• Security review — backups of sensitive state; interaction with the existing vault backup.

Dependencies

• Depends on: E1 + E3 (state shrink — hard gate), E2 (inventory of what to back up).
• Replaces: E5 (partial recovery — dropped, per Mark "never, even longer-term").
• Reduces scope of: E8 (manifest-replica redundancy is largely superseded by full cross-store backup).

Scenario

No response

Design

No response

Technical Details

No response

Threat Modeling Framework

No response

Acceptance Criteria

No response

Stakeholder review needed before the work gets merged

• Engineering (needed in most cases)
• Design
• Product
• QA (automation tests are required to pass before merging PRs but not all changes are covered by automation tests - please review if QA is needed beyond automation tests)
• Security
• Legal
• Marketing
• Management (please specify)
• Other (please specify)

References

No response

Start by reviewing the E1, E3, and E2 dependencies and resolve whether this backup replaces or augments the current vault backup. No files or tests are named; done requires redundant complete-state backups, silent restoration from a valid copy, bounded backup writes, and Firefox validation.