Readit Newsyoshuaw commented on Wassette: WebAssembly-based tools for AI agents opensource.microsoft.com/... · Posted by u/yoshuaw
Hey all, today the Azure Core Upstream team has open sourced Wassette: a WebAssembly-based runtime that allows Wasm Components to connect to AI agents using the Model Context Protocol. Wassette’s main contribution to the MCP space is efficient sandboxing: because if you’re going to run untrusted third-party tools locally, it’s probably a good idea to proactively restrict which system resources it can access.
In this post we explain what Wassette is, how to set it up locally, and finally walk through an example that exercises Wassette’s capability system. What we don’t cover in the post is how to write Wasm Component-based tooling for Wassette, but we have some docs for that in the README [1].
Anyway, I hope this interesting to folks here! I’ll be around for a couple of hours here to answer questions folk might have. And if I don’t know the answer, I can probably find an engineer who does. Thanks!
[1]: https://github.com/microsoft/wassette#building-for-wassette
For someone looking for the visualization, here it is.
// foo [1.006s]
// bar [1.006s]
// baz in bar [1.006s]
// working in baz 3 [1.006s]
// baz [1.006s]
// working in baz 2 [1.006s]
println!("{tree}");
`await-tree` seems to be able to output to JSON. As long as all keys are unique, it should be straightforward to convert it into the Collapsed Stack Format most flame graph tools natively ingest.
As a reference: I wrote a Dhat-JSON to Flamegraph conversion tool a while ago for fun. Adapting this to instead convert from the await-tree JSON format probably shouldn't take long:
https://github.com/yoshuawuyts/dhat-to-flamegraph/blob/main/...
A study published just yesterday [1] showed that just two airborne diseases [2] were responsible for approximately 85% of all sicks days in Greece during 2023-2024. Disregarding the common-sense argument that reducing collective suffering is a good thing overall - even by the cold hard logic of capital, being able to reduce company sick days by up to 85% is a huge opportunity.
Imo we're way overdue standards and controls for clean indoor air that are on par with standards for drinking water and food. Like this article shows, we have the tech to provide clean air today. All we're missing is policy to uniformly deploy it.
[1]: https://www.sciencedirect.com/science/article/abs/pii/S01966...
[2]: SARS-CoV-19: ~75% of sick days, Influenza: ~10% of sick days
yoshuaw commented on Hyperlight WASM: Fast, secure, and OS-free opensource.microsoft.com/... · Posted by u/yoshuaw
So is Hyperlight a competitor to things like Firecracker or does it serve a different niche?
Though both share the ability so securely execute multi-tenant workloads, but they make very different tradeoffs when it comes to compatibility vs performance. To compare:
Firecracker is great if you want to securely execute an OS image. It has the benefit of compatibility with many existing programs, but that comes at the cost of some overhead.
Hyperlight is great if you want to securely execute program runtimes. This requires bespoke guest bindings, but it has the benefit of having less overhead.
There’s a place for both approaches, and I see both happily co-exist.
yoshuaw commented on Hyperlight WASM: Fast, secure, and OS-free opensource.microsoft.com/... · Posted by u/yoshuaw
I agree that some things are essential, and there's value in specifications. The question is how likely is the current tragectory to follow what happened with browsers? The major players are the same, which is concerning. Then there's early signs from the specs themselves. Why do we need wasi-sockets and wasi-http? Why not only specify wasi-sockets and let HTTP be implemented optionally by libraries for apps that need it?
Are there any forces in place to prevent the (de facto) mandatory API from becoming so complex that Google (or Fastly) is the only org capable of maintaining an implementation? Because that's how you end up in the situation where the "user agent" with majority market share starts gutting ad blockers.
I'm not saying I'm predicating this will happen with WASM or even think it's very likely. I don't know enough to have a real opinion on that. I'm just saying I really really don't want it to happen.
> Are there any forces in place to prevent the (de facto) mandatory API from becoming so complex that Google (or Fastly) is the only org capable of maintaining an implementation?
The big change going from WASI 0.1 to WASI 0.2 is that we decoupled the calling convention (Wasm Components) from the actual syscall APIs (WASI). That enabled us to make the various syscall APIs modular and composable.
Because CDN functions probably shouldn't know about TCP; and CLI applications probably don't care about blob storage. And now they don't need to. Take a look at the WASI Proposals page [1] for an overview of all WASI APIs.
[1]: https://github.com/WebAssembly/WASI/blob/main/Proposals.md
yoshuaw commented on Hyperlight WASM: Fast, secure, and OS-free opensource.microsoft.com/... · Posted by u/yoshuaw
I started using WebAssembly in earnest a few months ago to make a backend auth library that works in several different languages[0]. It's built on Extism[1], which abstracts away some of the interfacing complexity. It's been an awesome experience. Frequently feels like magic.
WASM is in an interesting place. The value has clearly been proved with a pretty minimal core spec. Now there's a big push to implement a much larger API surface for WASI and the Component Model. A lot of people in the community are concerned about this direction, or at least the way it's happening[2].
For my part, I hope WASM doesn't go the way of the rest of web browsers where it gets so complicated that only big tech is capable of making implementations and experimenting.
[0]: https://github.com/lastlogin-net/decent-auth
[1]: https://extism.org/
[2]: https://www.assemblyscript.org/standards-objections.html
I agree about what your concerns about complexity, but the way I see what we're
encapsulating is almost entirely essential. To draw analogies with native binaries:
- Wasm is a (virtual) instruction format for programs to be compiled into (think: x86).
- Wasm Components are a container format and type system that wrap Core Wasm instructions into typed, hermetic binaries and libraries (think: ELF).
- WASI is a reserved namespace for a collection of standardized Wasm component interfaces (think: POSIX header files).
To reach our goal of having shared, portable binaries that aren't locked into any one vendor we need all three. A standard instruction set, standard calling convention, and standard syscalls. Wasm Components and WASI might not be necessarily be perfect, but at a minimum they're targeting the right scope. And that carries essential complexity.
yoshuaw commented on Hyperlight WASM: Fast, secure, and OS-free opensource.microsoft.com/... · Posted by u/yoshuaw
All these cool and interesting projects make me think that WASM is successful everywhere except the browser.
Maybe we should drop the Web from Web Assembly and call it something else?
I suspect that Wasm on the web mostly just works and so we don't hear too much
about it. It is occasionally mentioned in passing though, usually as part of
another announcement. Well-known production users of Wasm on the web include
Dropbox [1], Adobe [2], Figma [3], and 1Password [4].
[1]: https://dropbox.tech/tech/2018/06/building-better-compressio...
[2]: https://thenewstack.io/adobe-developers-use-webassembly-to-i...
[3]: https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
If you want to write an OS in rust and provide rich services for applications to use, you need to offer libraries they can call without needing to recompile when the OS is upgraded. Windows mostly does this with COM, Apple historically had ObjC’s dynamic dispatch (and now Swift’s ABI), Android does this with a JVM and bytecode… Rust can only really offer extern "C", and that really limits how useful dynamic libraries can be.
Doing an ABI without a VM-like layer (JVM, .NET) is really difficult though, and requires you to commit to certain implementation details without ever changing them, so I can understand why it’s not a priority. To my knowledge the only success stories are Swift (which faced the problem head-on) and COM (which has a language-independent IDL and other pain points.) ObjC has such extreme late binding that it almost feels like cheating.
If rust had a full-featured ABI it would be nearly the perfect language. (It would improve compile times as well, because we’d move to a world where dependencies could just be binaries, which would cut compile times massively.)
Using them is unfortunately not yet quite as easy as using repr(wasm)/extern "wasm". But with wit-bindgen [2] and the wasm32-wasip2 target [3], it's not that hard either.
[1]: https://youtu.be/tAACYA1Mwv4
[2]: https://github.com/bytecodealliance/wit-bindgen
[3]: https://doc.rust-lang.org/nightly/rustc/platform-support/was...