Implement Chrome's "File System Access" interfaces

Integrations
1

Google has introduced browser APIs to allow browser-based apps to request access to the user’s local files stored on disk.

The surface area of this API is fairly small. (See https://wicg.github.io/file-system-access/#idl-index.)

remoteStorage.js (or some other library) could implement these APIs in such a way that, provided the user has (a) indicated they wish to store their data with their remoteStorage provider rather than granting read and/or write access to the files stored locally on their disk and (b) has connected and authenticated with their remoteStorage provider, the data that the operates on is a remoteStorage without requiring the application or its creator work with remoteStorage.js APIs or the client-to-server interface exposed by remoteStorage providers.

It would also be possible for the library that implements this to be packaged into a browser extension that intercepts all File System Access requests and offer the user the option to confine and redirect the application’s reads/writes to a given folder with their remoteStorage provider.

2

While the paradigm of remoteStorage is based on the file system paradigm, the connection to data not being “reliable” changes the semantics — that is, an app using the File System API makes assumptions that are not true for remoteStorage. The result would be flakey.

3

The bigger problem would be file access patterns—poorly behaved programs that assume way more authority (in the POLA sense) and things about the underlying implementation could cause issues, but nothing that can’t be ameliorated and nothing new that native OSes haven’t had to deal with (wrt whether a given write is really just changing bytes in memory or the kernel is actually flushing those queued writes to disk).