phickey

Some of my colleagues have built https://component-model.bytecodealliance.org/ to help get folks up to speed. The best place to ask questions is in the bytecode alliance zulip: https://bytecodealliance.zulipchat.com/

> The component model is addressing this but it's sprawled out into literally rebuilding "worlds" and turning wasm modules into sort of lightweight virtual machines. I wish there was just more of a focus on getting data into and out of modules first.

As someone who works on the Component Model, this perception is interesting to me, can you explain your thinking a bit more? From my perspective, getting data in and out of modules is indeed solved. Worlds are a type signature that describe what datatypes and methods are available in a particular embedding, with standards for command line and http proxies, but easy to define whatever your situation requires.

The bytecode alliance zulip is the best place to discuss that: https://bytecodealliance.zulipchat.com/

WASI Co-chair here: WASI is for the Web as well as beyond. The jco project (https://github.com/BytecodeAlliance/jco) provides an implementation of the Component Model and WASI Preview 2 for JavaScript systems. Right now, node.js support is complete, but support for Web embeddings is in progress and coming soon.

We have already made big improvements in using SpiderMonkey on WASM, and have more work in progress that will enable SpiderMonkey to have "native"-like codegen for WASM: https://cfallin.org/blog/2023/10/11/spidermonkey-pbl/

An additional benefit of using a fast JS runtime inside of WASM, even on a WASM engine that natively supports JS, is to use a Wasm Component as a security boundary around JS code. This could be used as an means of isolating supply-chain security issues, or allowing users to provide (untrusted) JS code that extends an existing system while having a clear and strong boundary on how untrusted JS code can affect the host JS code.

> WASI-Preview2's benefits are not going to be realized in a browser, it's more for the non-web world

The jco project (https://github.com/BytecodeAlliance/jco) provides an implementation of the Component Model and WASI Preview 2 for JavaScript systems. Right now, node.js support is complete, but support for Web embeddings is in progress and coming soon.

> These interpreted languages can run in WASM, but only as language interpreter inside the WASM interpreter - so they work, but they are not efficient.

The Bytecode Alliance has made big improvements to SpiderMonkey performance on WASM/WASI systems, and has work in progress to take advantage of SpiderMonkey's "native" codegen targeting WASM: https://cfallin.org/blog/2023/10/11/spidermonkey-pbl/. We targeted JS first for this work because it is the most popular language with our customers and users, but we expect that this will show the path to adding similar improvements to Ruby, Python, and other languages commonly thought of as "interpreted".

WASI Co-chair here. Nothing in WASI is "somehow blocked by Google", or indeed blocked by anyone at all. Graphics support in WASI hasn't been developed simply because nobody has put energy into developing graphics support in WASI.

At the end of 2023 we counted around 40 contributors who have been working on WASI specifications and implementations: https://github.com/WebAssembly/meetings/blob/main/wasi/2023/... . That is a great growth for our project from a few years ago when that issue was filed, but as you can see from what people are working on, its all much more foundational pieces than a graphics interface. Also, if you look at who is employing those contributors, its largely vendors who are interested in WASI in the context of serverless. That doesn't mean WASI is limited to only serverless, but that has been the focus from contributors so far.

By rolling out WASI on top of the WASM Component Model we have built a sound foundation for creating WASI proposals that support more problem domains, such as embedded systems (@mc_woods and his colleagues are helping with this), or graphics if someone is interested in putting in the work. Our guide to how to create proposals is found here: https://github.com/WebAssembly/WASI/blob/main/Contributing.m... .

it solved it so well that nobody outside of chrome ever implemented nacl, and chrome's nacl team became their webassembly team

The component model is already shipping in Wasmtime, and will be stable for use in Node.js and in browsers via jco (https://github.com/bytecodealliance/jco) soon. WASI Preview 2 will be done in December or January, giving component model users a stable set of interfaces to use for scheduling, streams, and higher level functionality like stdio, filesystem, sockets, and http on an opt-in basis. You should look at wit-bindgen (https://github.com/bytecodealliance/wit-bindgen) to see some of the languages currently supported, and more that will be mature enough to use very soon (https://github.com/bytecodealliance/componentize-py)

Right now jco will automatically generate the JS glue code which implements a Component Model runtime on top of the JS engine's existing WebAssembly implementation. So, yes, Components are a composition of Wasm Modules and JS code is handling passing values from one module/instance to another. You still get the performance benefits of running computation in Wasm.

One day further down the standardization road, we would like to see Web engines ship a native implementation of the Component Model, which might be able to make certain optimizations that the JS implementation cannot. Until then you can consider jco a polyfill for a native implementation, and it still gives you the power to compose isolated programs written in many languages and run them in many different contexts, including the Web.

(Disclosure: I am co-chair of WASI, Wasmtime maintainer, implemented many parts of WASI/CM)

Useful things are hard to make.

To run a JavaScript interpreter (spidermonkey, in this case) in Wasm, as well as running that same wasm in a JS engine, you want to look at `jco` https://github.com/bytecodealliance/jco

The component model tooling is getting very close to maturity and will solve many of these problems.

Yes, CM resources are unforgable references.

Wasi co-chair and Wasmtime maintainer here: we agree! Wasi Preview 1, which this article is about, was a first attempt at porting some of these Unix ideas to Wasm. We found pretty quickly that unix isn't the right abstraction for Wasm. Not only is it not really portable to platforms like Windows without reinventing a compatibility layer like cygwin, it also doesn't really make sense in a Web embedding, where users end up implementing something like a unix kernel in Javascript.

Wasi Preview 2, which we are aiming to launch by the end of the year, rebases Wasi on the Component Model proposal, which enables composition of Wasm programs, including those which are written in different languages, and which do not trust each other. Wasi is now specified in the Wit IDL, which has a strong type system for representing records, variants, lists, strings, and best of all, external resources, including sugar for constructors, methods, and destructors.

Instead of basing everything on the filesystem abstraction, the core Wasi primitives are the `input-stream`, `output-stream`, and `pollable` resource types, for readable and writable bytestreams, and a pseudo-future: you can `poll-oneoff` on a `list<pollable>` and it will block until one is ready, and return a `list<bool>` indicating the set which are ready. `wasi:filesystem/types.{descriptor}` is the resource for files, but if you need to read, write, or append to a file, you can do so by calling a method on `descriptor` that returns a `input-stream` or `output-stream`.

Preview 2 is also adding networking: wasi-sockets for platforms which support sockets, and wasi-http for those which don't, like the Web.

We are closing in on shipping Wasi Preview 2 but its not quite fully baked yet - changes related to resources are slated to land in the net few weeks. The spec definitions are on github: https://github.com/WebAssembly/wasi-io/blob/main/wit/streams... https://github.com/WebAssembly/wasi-filesystem/blob/main/wit... . Stay tuned for much more approachable documentation, tutorials, and so on, once we are confident it is a stable target ready for users.

Related: one of my colleagues created [wasm-smith](https://github.com/bytecodealliance/wasm-tools/tree/main/cra...) for fuzzing wasmparser and Wasmtime.

You can use jco to both compile a JavaScript module into a WebAssembly Component (with spidermonkey running as wasm inside), and to generate a Javascript embedding for that component. This solves all of your problems except for untrusted code looping forever, and that’s something which could be added to spidermonkey.wasm. https://github.com/bytecodealliance/jco

You can also run these same components server-side with Wasmtime.

`jco componentize` turns a JavaScript module into a WebAssmebly component: https://github.com/bytecodealliance/jco

Additionally, googlers are championing memory control https://github.com/WebAssembly/memory-control/blob/main/prop..., which provides memory protection, as well as memory 64, which is already done in chrome and firefox https://github.com/WebAssembly/memory64/blob/main/proposals/...

Wasmtime modules have an internal arc, and are unloaded from memory when there are no more references.

The wit-bindgen work required would be a significant undertaking (a week? more?) by someone who already has some expertise in wit & python. Maybe the wasmlabs folks are up for taking it on.

In general the Wasm Component ecosystem is still a few months away from being generally useful. There are a lot of people across the bytecode alliance working on the fundamentals right now, and we are making great progress, but its not ready to ship quite yet.

Wasmtime's `wasmtime-py` embedding in python has support for Wasm Components: https://github.com/bytecodealliance/wasmtime-py#components (disclosure, I helped create it)

The remaining piece of the puzzle would be to create a wit-bindgen guest generator https://github.com/bytecodealliance/wit-bindgen#guests for this build of the python interpreter. You could then seamlessly call back and forth between the host and guest pythons, without even knowing that wasmtime is under the hood.

I am a hiker and a ham and I disagree with this advice. I carried a ham radio while hiking for years and they were never a useful safety device. Here in the PNW, anywhere I was prominent enough to reach a repeater or another ham on the calling frequency, I also had plenty of cell signal. Whenever I was off the ridgelines and down in valleys, I wouldn’t be able to reach anyone with either method. Both cell phones and handheld ham radios are roughly line of sight, and when you are down in an uninhabited valley without cell coverage, it also quite doubtful there is another ham listening.

I swapped carrying a ham radio for a Garmin inReach a few years ago and it has been far more useful. I pay an annual service charge, but in return I can let my partner know I’m safe a few times a day, and I can use it to arrange for rides, neither of which I could do via ham. I have never had a problem getting reception, and it’s a much smaller, lighter device, and it recharges via USB so I never worry about spare batteries.

There are some ham specific activities for carrying a radio on the trail, like summits on the air, but if you are just trying to go hiking, get an inreach.

there’s a good write up on this somewhere that you’ll have to forgive me not being able to find tonight on mobile. In general, we want the wat syntax to mirror the binary format very closely, but that’s often at odds with a surface syntax that promotes good software engineering or good developer ux. Two cases for that off the top of my head:

* the component model wat can represent interfaces, but it can’t represent the composition of interfaces, e.g. if we were writing a new interface which opened something file-like and wanted to reuse the oflags type from wasi-filesystem, there would be no way to express that indirectly because we insist wasm binaries are self contained (don’t require you to load other resources), so the oflags type definition would need to be copied in literally.

* when we add resource types back to wit syntax (you can rewind history in wit-bindgen 2 months to find examples, we got rid of them because they were a strawman and now something quite similar is getting speced) it’s nice to have wit syntax appear just like constructors and methods, even if we all know a method desugars to a functions that take a resource as it’s first parameter in the canonical abi. It’s nice to have a distinction in wit that can be used by code generators for creating idiomatic C++, Rust, JS etc methods. Even if we give methods a faithful wat/binary repr (like, e.g. flag types, which are a shorthand for a struct full of bools), the wat/binary form will necessarily have much worse syntax than the wit will, and we think having a syntax that doesn’t send you rubbing your temples reading the component model spec will help adoption.

Speaking as someone who has had to read and write a nontrivial amount of wat over the last 5 years, it’s lovely for small examples and it’s pretty challenging for large, “real world” programs.

Yep that’s exactly the plan (I work on wasi and the component model and etc)

I work on Wasi at Fastly, as part of the Bytecode Alliance.

WASI development has indeed been quite slow. Most of our efforts for the past 2 years have been developing and implementing the Component Model proposal. Right now we are working on porting WASI to the component model, which has been pushing all of the new wit tooling more than it has WASI itself.

I can’t really say that adding more people would have sped up the last few years. The vision of the component model is very ambitious - it’s the first credible open (as in, not owned by Oracle or MS) standard for a real cross language VM, and the security posture supports mutually distrustful components by default. If we had just iterated on the witx version of wasi without coming up with the component model first, I believe both the component model and wasi would be worse off for it.

A lot of the foundational spec work and tooling is now (hopefully!) pretty stable. We used to rewrite everything related to the component model (fka interface types or module linking) every 6-9 months because the spec changed really radically, now I genuinely believe you’ll be able to take todays wit-bindgen to production in 6-9 months of polishing. We are approaching the point where we can get those tools in the hands of way more contributors and the ecosystem can grow.

So yes, the contributors to it today are small, but they are growing (I’ve spent a big chunk of the last few weeks bringing on more contributors from other bca companies) and soon will be able to grow even more.

Wasm doesn’t yet have any sort of longjmp instructions. Stack switching is currently a proposal and the leading candidate is based on delimited continuations. Additionally, there are no wasm instructions that can manipulate the control stack besides call, indirect call, and return, which are always typechecked. So, if you call untrusted code, you can be assured that it will not be able to manipulate your stack and that it will either return or trap.

Native code might assume that code it calls won’t misbehave in these ways, but wasm guarantees it, and that allows wasm VMs which run untrusted code to have more efficient implementations.

I work on wit-bindgen. One major advantage of the WebAssembly VM is that we can trust the call stack, which gives cross-language calls optimization opportunities to skip serializarion or copies. This will be an even more important when we add async to the component model, and e.g. async rust can await on async typescript, all in the same “executor” in Rust terms.

Sandboxing also goes a long way towards containing the supply chain security issues that every language is susceptible to.

We worked with Igalia to upstream the SpiderMonkey patches required to build for wasm32-wasi. We point to a fixed version (see: https://github.com/fastly/spidermonkey-wasi-embedding) which we haven't updated for a minute.

These are good questions! Here's some answers from the corner of the world I know best as a Wasmtime contributor at Fastly:

1. Spidermonkey.wasm is the basis of Fastly's JavaScript on Compute@Edge support. We have found it to be faster than QuickJS. The source code is here: https://github.com/fastly/js-compute-runtime.

2. Fastly Compute@Edge is built on wasmtime. You can develop web services for it in Rust, JS, and Go: https://developer.fastly.com/learning/compute/

3. Fastly's multi-tenant platform is closed source, but our single-tenant local development platform, which also uses wasmtime under the hood as well, is open source: https://github.com/fastly/viceroy. It isn't a big leap to make viceroy multi-tenant: Wasmtime provides everything you need, and all Viceroy would have to do is dispatch on e.g. HTTP host header to the correct tenant. Our multi-tenant platform is closed source because it is very specialized for use on Fastly's edge, not because the multi-tenant aspect is special.

The security properties are ultimately why we invested in WebAssembly. We (Fastly; the author is my colleague) run very large numbers of WebAssembly modules, all in the same process where the plaintext HTTP requests and responses from very large numbers of our customers reside, without needing to trust the authors of those modules. There are many technologies for running untrusted code out there, and we picked WebAssembly because we can make it fast in all the ways this article details without compromising on security.

Stay tuned, the next article in this series on Wasmtime security will run next Tuesday.

Wasmtime is actively maintained, and owned by the Bytecode Alliance. I’m not sure what project you are thinking of but it’s not Wasmtime. (Disclosure: I am a Wasmtime maintainer)