Search selfstore
v1.8.21

selfstore vs browser-fs-access

TL;DR: browser-fs-access solves the picker: one call for open and save across browsers that do and do not ship File System Access. selfstore solves the loop the picker is a step in - what to write, encrypted how, merged with what.

What browser-fs-access is

A small, well-made library from GoogleChromeLabs: fileOpen() and fileSave() that use the File System Access API where it exists (Chromium, where you get a real handle and can write back to the same file) and fall back to <input type="file"> and a download elsewhere. It does that one job cleanly and it is a sensible dependency for any app that touches files.

What it does not do - correctly, since it is not its job - is decide what those bytes are.

What selfstore is

The decision about the bytes, and everything after it. A disk file is one of selfstore’s destinations, and connecting one is store.connectFile(); what gets written is the app’s whole state as a portable encrypted ZIP, what happens next is a debounced auto-save on every mutation, and what happens when a second device connects the same file is a deterministic merge rather than an overwrite.

It also handles the parts that only show up in production: the file mode is Chromium-only, so a browser without it gets a 'manual' outcome and an honest download path instead of a broken promise; a desktop shell (Tauri and the like) can hand its own file calls over once and get a real path that survives the session; and a handle that needs re-granting surfaces as a typed status with a reconnect action rather than an exception.

browser-fs-access selfstore
Scope Open and save dialogs The storage loop
Cross-browser fallback Yes Yes, as a reported outcome
What is written Yours to define A spec’d ZIP of the app state
Encryption No AES-256-GCM + Argon2id
Re-open the same file later The handle, yours to keep Remembered and restored
Second device Not in scope Merged, not overwritten

Use browser-fs-access when

Use selfstore when