Problem
The framework's promise is that users need not enable sync to keep local data. But every path that moves local data between storage containers today runs through sync election plus account recovery. The one place this bites hardest: WebKit's installed-app storage fork (Add to Home Screen copies cookies but not OPFS/localStorage), where data created in a Safari tab is invisible to the installed app. The shipped mitigation warns before install and detects the fork after it, and its recovery path requires turning on sync.
A file-based export/import flow would close that gap without sync:
Proposed user flow
- In the browser tab, the account panel offers Export data: the runtime serializes every declared table's local rows (plus the account identity or enough to re-key it) into a single encrypted file the user saves via a download or the share sheet.
- The user installs the app (or opens it in another browser) and chooses Import data on first launch — the fork notice would link to it.
- The runtime decrypts, validates the schema range against the running bundle (same lineage rules as the schema-compat gate), and inserts rows through the normal write path so journaling and effects behave.
- The imported copy is a fork by design: no merge semantics beyond row-id identity, and both containers continue independently unless sync is later enabled.
Open questions (why this is deferred)
- Fit: sync + recovery already transfers data for users willing to enroll a sink; is a second, manual channel worth its surface area, or does it dilute the recovery story?
- Format and encryption: passphrase-wrapped? keyed to the recovery phrase? A plaintext export contradicts the at-rest posture.
- Merge semantics: import into a non-empty container (skip, overwrite, duplicate?) has no obviously right answer.
- Scope: rows only, or also the account secret (which would make the import a device enrollment rather than a data copy)?
Deferred until the fork warning/detection work has been in use long enough to show whether users actually hit the no-sync wall.
Problem
The framework's promise is that users need not enable sync to keep local data. But every path that moves local data between storage containers today runs through sync election plus account recovery. The one place this bites hardest: WebKit's installed-app storage fork (Add to Home Screen copies cookies but not OPFS/localStorage), where data created in a Safari tab is invisible to the installed app. The shipped mitigation warns before install and detects the fork after it, and its recovery path requires turning on sync.
A file-based export/import flow would close that gap without sync:
Proposed user flow
Open questions (why this is deferred)
Deferred until the fork warning/detection work has been in use long enough to show whether users actually hit the no-sync wall.