You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issues #481, #482, and #486 explore native-like local files, backups, and storage behavior in the PWA. This Discussion asks how ordinary-file convenience can coexist with one authoritative project state.
Current state
The browser storage authority and any user-selected external mirror must have an explicit relationship. File System Access could support Open, Save, Save As, and a user-selected backup folder, but permissions, revocation, conflict detection, storage health, and cross-browser fallback need a coherent contract.
Product decision space
Explore installed-PWA file handlers, user-selected backup folders, conflict detection, storage health indicators, permission revocation, and a safe fallback where File System Access is unavailable. An external mirror must not silently become a second writer or overwrite a newer canonical generation.
Role perspectives
Role-perspective note: The viewpoints below are maintainer-curated, AI-assisted design lenses. They are not separate community members, votes, or evidence of consensus.
✍️ Author wanting ordinary files: Open, Save, Save As, and backups should feel familiar and reversible.
🧪 Data integrity: one authority, generation checks, no-loss writes, conflict visibility, and recovery matter more than convenience.
🌐 Browser platform: capability detection, File System Access support, installed-PWA handlers, and cross-browser fallback must be honest.
🔐 Permission/privacy: user grants, revocation, file scope, and local data exposure must be explicit.
🖥️ Desktop-parity perspective: provide useful native-like affordances without promising identical browser and desktop semantics.
Questions for the community
Should browser storage remain canonical when a file mirror is connected?
Which Open/Save/Save As and backup behavior is essential first?
How should conflicts, revoked permissions, and unavailable folders be explained?
What storage health signals would prevent accidental loss?
Which cross-browser fallback is good enough without hiding capability differences?
Relationship to implementation
This Discussion explores the product surface for #481, #482, and #486. Those Issues remain the implementation and acceptance authorities; the Discussion does not create a second storage authority or change execution sequencing.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Why this exists
Issues #481, #482, and #486 explore native-like local files, backups, and storage behavior in the PWA. This Discussion asks how ordinary-file convenience can coexist with one authoritative project state.
Current state
The browser storage authority and any user-selected external mirror must have an explicit relationship. File System Access could support Open, Save, Save As, and a user-selected backup folder, but permissions, revocation, conflict detection, storage health, and cross-browser fallback need a coherent contract.
Product decision space
Explore installed-PWA file handlers, user-selected backup folders, conflict detection, storage health indicators, permission revocation, and a safe fallback where File System Access is unavailable. An external mirror must not silently become a second writer or overwrite a newer canonical generation.
Role perspectives
Questions for the community
Relationship to implementation
This Discussion explores the product surface for #481, #482, and #486. Those Issues remain the implementation and acceptance authorities; the Discussion does not create a second storage authority or change execution sequencing.
All reactions