Discussion: In memory filesystem implementation

[kevinkassimo]

(Moved from Gitter chatroom, for tracking and discussion purposes and avoid forgetting)

Per proposal from Reddit by @ChrisAckerman:

What if, instead if failing (which I assume is what currently happens) when file/network access is blocked, you simply provide in memory default implementations which don’t actually access the disk/network. And then exposing these abstractions as extension points will hugely expand the power for community extensions to your security and dependency models.

Comment by @kitsonk :

Well, ServiceWorkers are a sort of user land implementation that solves this, and might be the right model to apply here... they already have the ability to proxy all requests and determine what to do in case of network failure, be it serve up something else, use a cached version, etc...
In particular Cache and CacheStorage win a lot over local storage: https://developer.mozilla.org/en-US/docs/Web/API/Cache
and could be used to provide secure storage without --allow-write or --allow-read, they are much more suitable than localStorage which is really not good for serialising objects.

Potential Rust impl pointers: https://github.com/zboxfs/zbox (this one seems very nice, supports os fs
+ encryption/in-memory/sqlite/redis storage and provide APIs similar to std::fs::File), https://crates.io/crates/vfs , https://crates.io/crates/rsfs

A pure TS impl is also possible.

[kitsonk]

Related to Ry's comment in #1657.

[Janpot]

also related: upcoming writable files API

[ry]

@Janpot #1615

[lucacasonato]

Ref #5755

[kitsonk]

Feels like this should be addressed as a community library, versus something built into Deno, outside of supporting Service Workers as a whole (see: #5957), so closing as un-actionable for now.