If you have used WASI in the past, can you mention your use case? Very curious if you found it to give you an edge compared to other sandboxing like containers or VMs.
If you have used WASI in the past, can you mention your use case? Very curious if you found it to give you an edge compared to other sandboxing like containers or VMs.
I used WASI to compile an existing 1990's 8-bit assembler cmdline tool written in C for use in a VSCode extension (https://marketplace.visualstudio.com/items?itemName=floooh.v...) - along with regular browser-based WASM compiled via Emscripten for the embedded emulators.
For this use case the old-school POSIX-style WASI was just perfect and completely hassle-free via the WASI SDK (https://github.com/webassembly/wasi-sdk).
Not sure what to think of all the bells and whistles that were added afterwards (esp the component model), the very first WASI standard was the perfect sweet-spot of simplicity and usefulness. I'm pretty sure I'll never need any of the things that were added afterwards (and I'm going to be slightly pissed when the simple use case - building and running POSIX code - gets more complicated).
WASI is the best format for code submitted by users, entirely untrusted, which is in principle of any complexity but expected to be pretty simple. It works on any platform, in any environment, with extreme and direct control over its access to every resource and its ability to execute at all. Wasmtime's "fuel" feature is not something you can do with containers, and if you can do it with VMs then I don't know about it, but VMs are behemoths for the task of executing a simple function that would in an alternate universe be CEL.
I tinkered with https://extism.org and basically the use case is that they suggest, namely you can extend software in another programming language but without having to setup a container or VMs on the client. They "just" run the code in the browser and it can be JavaScript, sure, but can also be Python, Go, whatever.
It's quite specific though as I'm working on support programming in the browser.
If you are not deep into letting a very specific kind of user extend, it's probably overkill.
Even then it's a very VERY niche thing because it has to be simultaneously :
- someone who is opinionated about a programming language (either because they know too much, i.e. expert, or not enough, i.e beginner)
- is dedicated enough to want to try to build something on top of an existing system
- does not want to bother with solutions you mentioned
We evaluated Extism and concluded that it did basically nothing that WASI and the component model didn't already do out of the box. Was your experience different?
> If you have used WASI in the past, can you mention your use case?
For my "TagLib for TypeScript" library, I use WASI for local filesystem operations when used with Node.js/Deno/Bun. https://github.com/CharlesWiltgen/taglib-wasm
Extending my Rust binary with a marketplace of WASM-based extensions like VSCode
In-process sandboxed llm-generated code execution. Considerably lighter weight, faster to boot (assuming pre-compilation) than Docker or spinning up micro-VMs.
I'm using it for a secure, language agnostic workflow orchestrator. Components have very finely-grained and controller permissions and access to data. They don't even get clocks by default (to mitigate against Spectre-style attacks) and credentials and tainted data are sequestered.
The best usage example of WASI I know of is the Zig compiler: https://ziglang.org/news/goodbye-cpp/
Edge rural farm systems
extending software with a plugin system
[dead]
[flagged]