The goal of WASI is to add a standardized system API to WebAssembly, allowing you to access underlying systems (filesystem, networking, etc) in a homomorphic and secure way.
In practice, this means that you can compile your Rust/C++/etc code to WASM + WASI, and that code will run anywhere you have a WebAssembly VM. So the same code that accesses the "filesystem" in a browser context can also access the filesystem in a desktop/mobile/edge/etc environment.
You could also think of it as an attempt to turn WebAssembly into a fully-fledged JVM alternative. Compile once, run anywhere (including browser).
For this specifically, it means that SQLite can integrate with WASI APIs (instead of only Web APIs as before) so that an SQLite Wasm build can run in other contexts besides browsers.
A lot of the sandboxing and security focus in Wasm makes sense. But the "capability-based security" mentioned at WASI spec [0] confuses me. For instance, when looking to what Cosmonic (an early adopter in Wasm fields) documents as capabilities [1] (e.g. 'messaging', 'http client', 'key-value store') it seems wholly different to concepts from the E programming language [2] by Mark S. Miller, that are finding their way in Cap'n Proto [3] and early work on the OCapN [4] unification effort. Is there any relationship to these, or are we looking at totally different approaches? Or is Cosmonic overloading the terminology of "capability"?
On a brief look, I agree that your link [1] does not appear to be thinking about capabilities correctly. It seems to make the classic mistake of orienting around verbs (actions you can do) instead of nouns (specific resources you can operate on). That said I only took a brief look and could be misunderstanding something.
However, my understanding is that WASI itself is actually capability-based, and I think your link [0] is thinking about capabilities in the right way. In fact I'm pleased to see "Interposition" seems to have been added here, IIRC a few years ago that was missing and I feel it's an essential piece of capability-based security.
As an example, in WASI, there is no singleton filesystem, instead the application receives a set of file descriptors for specific directories which grant access only to those directories and their children, not their parents. Though last I looked, the libc wanted to reconstruct those into a single virtual filesystem, assigning each one a mount point and matching paths against those, in the name of compatibility, which felt unfortunate to me.
As always, a lot of people struggle to "get" capabilities, even when they are building on top of a platform designed around the idea. :/
Well, I think it is a different approach. But in another submission I posted, "WebAssembly for the Server Side: A New Way to Nginx" [0], sponsored by Nginx, they mention things feeding the confusion again:
> Perhaps most importantly, role-based access control and attribute-based access control, and other authorization and access control technologies, can introduce complex external systems that must be synchronized with the plugin as well as the underlying server-side technology. In contrast, Wasm access control capabilities are often built directly into the runtime engines, reducing the complexities and simplifying the development process.
What I don't get specifically is what's being implemented here with SQLite. Assuming WASI is an interface an application can call into for things like filesystem access, sockets, does this add SQLite as interface (analogously to sqlite.h) next to these as part of WASI? So SQLite will be "under" the interface, i.e. part of a standard runtime?
How much "batteries included" is this runtime (planned to be)? If I understood this correctly, then there would be a tradeoff with having more batteries included which would imply more functionality for applications but make porting to new targets more work.
The main work behind this patch is to ensure that SQLite can compile to Wasm32-wasi. WASI doesn't offer all syscalls that SQLite may require, so it may require some conditional definitions and code to ensure it works properly. It doesn't mean that SQLite is part of WASI, but you can embed SQLite in a Wasm32-wasi module.
In the future, the WASI standard will include more and more features. This will allow SQLite to enable more internal features that are currently skipped due to the limitations on WASI.
In practice, this means that you can compile your Rust/C++/etc code to WASM + WASI, and that code will run anywhere you have a WebAssembly VM. So the same code that accesses the "filesystem" in a browser context can also access the filesystem in a desktop/mobile/edge/etc environment.
You could also think of it as an attempt to turn WebAssembly into a fully-fledged JVM alternative. Compile once, run anywhere (including browser).
For this specifically, it means that SQLite can integrate with WASI APIs (instead of only Web APIs as before) so that an SQLite Wasm build can run in other contexts besides browsers.