[API Proposal]: Support OPFS persistence for System.IO in browser-wasm

[b-straub]

Background and motivation

.NET WASM applications currently use Emscripten's in-memory file system (MEMFS).
All file data is lost on page refresh, making System.IO APIs effectively useless
for persistent storage scenarios.

The Origin Private File System (OPFS) is now supported by all major browsers
(Chrome 108+, Safari 16.4+, Firefox 111+) and provides persistent, high-performance
file storage designed specifically for WASM workloads.

Current state

• Emscripten is developing WasmFS with an OPFS backend (still marked "work in progress")
• Both OPFS approaches require COOP/COEP headers (for pthreads) or JSPI
• .NET WASM has no integration path - developers must build complex workarounds
  (e.g., separate worker instances, manual JS interop)

Desired outcome

Standard System.IO.File operations should be able to persist to OPFS when
configured, allowing existing .NET code and NuGet packages to work with
persistent browser storage:

// Writes persist across page refreshes
File.WriteAllText("/data/settings.json", json);
var settings = File.ReadAllText("/data/settings.json");

Primary use cases:

• SQLite/EF Core databases that survive page refresh
• Offline-first PWAs with local data storage
• Porting existing .NET libraries that depend on System.IO

References

• WasmFS: OPFS AccessHandles backend emscripten-core/emscripten#15950 - WasmFS: OPFS AccessHandles backend
• Combining OPFS and JSPI emscripten-core/emscripten#19408 - Combining OPFS and JSPI
• https://developer.mozilla.org/en-US/docs/Web/API/File_System_API/Origin_private_file_system
• https://sqlite.org/wasm/doc/trunk/persistence.md
• https://www.powersync.com/blog/sqlite-persistence-on-the-web
• Example implementation workaround - .NET WASM + OPFS dual-instance architecture

Questions for the team

1. Is .NET tracking Emscripten's WasmFS/OPFS progress for potential adoption?
2. Are there plans to expose OPFS through the runtime when WasmFS stabilizes?
3. What's the preferred path forward - wait for Emscripten, or independent implementation?

[am11]

@dotnet/wasm-eng might have better insights on this topic. I think we might need certain API proposal to cover "I/O APIs which accept filesystem argument" for various filesystem offerings by emscripten: https://emscripten.org/docs/api_reference/Filesystem-API.html#file-systems.

[b-straub]

For a persistent FS, everything else except OPFS is outdated and not worse to follow.

OPFS can be async and sync. There are attempts to run Blazor WebAssembly directly in a web worker: dotnet/aspnetcore#17730 (comment)
This could make the sync variant a natural choice and doesn’t need to wait for direct Emscripten support.

[pavelsavara]

WASMFS is mostly interesting for performance and multi-threading reasons. I don't have any experience with it's current maturity, but the fact it's not a default tells me it's not ready for prime time.

As far as I remember, this is first time someone is asking for persistent FS as a dotnet WASM feature. Unless there is stronger signal from the community, I don't think we are going to prioritize it.

I would like to hear more about the use-case. Why do you prefer files over other persistent APIs ?

I think Emscripten FS object is extensible via FS.mount which can accept alternate implementation of the FS API. That makes it possible to create a demo of your idea outside of runtime repo. From my perspective, community owned project would be ideal.

[b-straub]

This is one of the use cases:

https://github.com/b-straub/SqliteWasmBlazor

It’s working perfectly on all major browsers but naturally I had to implement things that belong in my opinion into the runtime.

At end result adding EFCore SQLite nugget should give persistence without further ado.

[pavelsavara]

The sqlite could export/import the DB and you can store it anywhere.
https://sqlite.org/wasm/doc/trunk/cookbook.md#impexp

[b-straub]

I suggest you look at my project in detail to see the difference that a real OPFS makes.

It’s not about import/export.