[b33j0r]

Love/hate with this one. How was I supposed to follow this? I tried, and few things were publicly visible for nearly two years. I last checked in march and it looked like no progress had been made.

That makes me very suspicious of wasiv3. Funny enough, I already implemented a bunch of the promises (pun not intended) and think that freestanding wasm with custom integrations is the more likely future.

The promise of wasi components has not been fulfilled. The market wants to hotload and link artifacts dynamically. The wasi project requires insider wizardry to use it that way: the offering has been statically linking components before you ship. Defeating 99% of the use cases.

I do not like that this has been worked on in the shadows.

[spankalee]

There is an issue open for instantiating modules at runtime: https://github.com/WebAssembly/component-model/issues/423

[hectaman]

I don't think it's fair to say this work has happened in the shadows. I work on CNCF wasmCloud, and I know how hard we try to make this content available.

- Many standing meetings organized around SIGs, all on the public community calendar: https://calendar.google.com/calendar/u/0/newembed?src=events...

- A dedicated Zulip: https://bytecodealliance.zulipchat.com/

- Conferences organized around exactly these topics: Wasm Day, WasmCon, Wasm I/O, and the Bytecode Alliance Plumbers Summit

- CNCF projects: wasmCloud, Spin

- Blogs, many with recordings, summaries, and transcripts: https://bytecodealliance.org/articles/the-road-to-component-..., https://wasmcloud.com/community/, https://spinframework.dev/blog/index

If you want the architectural direction straight from the source, Luke Wagner's keynotes are the best place to start:

- "What is a Component (and Why)?" (WasmCon 2023): https://www.youtube.com/watch?v=tAACYA1Mwv4

- "The Path to Components": https://www.youtube.com/watch?v=phodPLY8zNE

- "Towards a Component Model 1.0" (Wasm I/O 2026): https://www.youtube.com/watch?v=qq0Auw01tH8

I mean this, though - what else would you like to see to try and make the content and process more accessible? Are there communities that are doing this really well that we could use for inspiration?

[tete]

> - "What is a Component (and Why)?" (WasmCon 2023): https://www.youtube.com/watch?v=tAACYA1Mwv4

At 18:00 the speaker states something like "It should not be Systems Interface but Standard Interfaces" which honestly sounds like a different project. As an implementer or even as just a user in general, can it be trusted that tomorrow it isn't something completely different? Seems like an odd standard to follow.

(EDIT and aside: Rereading this it reads more dismissive than I meant it. So if this isn't clear: I want WASI to succeed. I think having a widely used system interface is great, but I think many know standards that suffered from scope creep. And while big successful standards for better or for worse at least have a chance of surviving this, WASI as the 0.3 indicates is in its infancy. So I worry about it turning out bad, leading to people abandoning the idea altogether or the standard losing sight of its initial goal. So while this is criticism the only reason I bother to write it in first place is because I badly want it to succeed. I worry that if WASI tries to do too much at once - and I totally understand wanting to do that - it makes it less likely to be successfully implemented and thereby less likely to succeed as a standard.)

[syrusakbary]

If you are looking for a Systems Interface, I don't think the Component Model will be a good fit

[spankalee]

The speaker is right. Why should "system" interfaces and interfaces from other components ever be fundamentally different?

[tete]

I get that. That's not my criticism. My criticism is that you can do say that about many things. With that argument you can essentially encompass everything, which is cool in a way, but also means that the scope is at least bigger than the original - hence what the speaker says.

What I worry about here is that when I think about implementing it the scope will likely grow as well. And while I very much get the wish to encompass things in a standard (I think everyone who ever wrote any kind of specification knows that) a standard doing that extension when the initial goal of being a (commonly used) system interface isn't achieved - at least that's how'd interpret being 0.3 now - then what if that scope extends like that. Will we see full implementations?

To me it seems like maybe it would have made sense to separate that a bit. Something like a WASI based standard. Or something else. The fact that you almost need to change your name like this indicates that you went quite a bit away from the initial goal and doing that before a 1.0 seems like a very early point to get of course for any project. Sure sometimes you find out that you have looked at it from the wrong angle, but honestly this doesn't look like it. This looks a lot more "this is something we can reuse".

[airstrike]

So join the community and be the change you want to see in the world?

[b33j0r]

It was not fair. It was how I felt trying to build on it. I love the content that was produced, but it was all very experimental and garden shedded from a decision-making angle.

To answer directly, I would credit the PSF and python community with having the best structure that has outlasted my weirdest expectations.

[hectaman]

Yeah, I feel that - everything was so green in the beginning that getting a Hello World together was painful. When I started, I was still at a big bank, and there wasn't even an IDL selected, so we just started building with SMITHY. Then adopting WIT, etc...

I would say now, especially with AI and Rust, it is night and day. I think as folks come to the conclusion that they care more about what gets built than the how it is done, they start to feel the need for a sandbox. So, WASI P3 is coming along at a really fortunate time. I haven't had any issue nearly oneshotting things directly into wasm with claude.

I appreciate the suggestion on good communities doing it well.

[airstrike]

It's version 0.3...

[jauntywundrkind]

The work is being done quite publicly, it's just not narrated particularly well. You can go look at the commits and github posts happening! It's all very public. There's extensive discussions ongoing.

My guess is that there's a bit of a circular issue, where the team doesn't particularly see lots of good/useful feedback when they do try hard to explain the work, and drive-by folks like me and you don't have much to see or grasp at when we do take a pass through the repos to try to see what's going on. They do have regularly scheduled meetings though, which are open attendance, if you want to try to ask in person for more help: I don't know how that would go, but I doubt you've tried.

It has been nice to have LLMs for the past year, which have helped summarize what's been going on in various wasm repositories.

That said, I agree with you on two fronts. Yes: dynamic hotload and linking is very high on my want list. Trying to get to a place where we have lightweight isolates like things that can use existing loaded libraries has been the northstar, and one I'd love to see start to become real.

Second, it is really hard to figure out what is and isn't possible, to assess and try the tools to see how far you can get. There's also a lot of old documentation floating around, so if you for example go use rust there's a 33% chance you'll happen upon material that points you in the wrong direction.

[derefr]

> The promise of wasi components has not been fulfilled. The market wants to hotload and link artifacts dynamically. The wasi project requires insider wizardry to use it that way: the offering has been statically linking components before you ship. Defeating 99% of the use cases.

I think both of these points on the spectrum (on the one end, fully static linking of WASI components within a monolithic single-source project; and on the other end, dynamic-at-runtime compiling + linking + loading + "hot instantiating" of arbitrary black-box WASI-component artifacts, with dynamic [presumably reflection-based?] API discovery to drive interaction with those components) are strawmen. There are relatively few "real" use-cases for WASI on either of these ends.

Most of the stuff anyone is really interested in using WASI for (AFAICT, from the use-cases for it I've seen in the wild) involves something closer to the midpoint between these two points. Somewhat dynamic and modular, but with no JIT compilation / components-fetching-components / hot component instantiation / dynamic reflection stuff going on.

Specifically, the "point" of WASI (in my opinion, and in the opinion of most people I've spoken with about it), is to serve as a sort of meta-standard (with tooling) for concrete "pluggable runtime" systems to implement plugin-support SDKs in terms of.

In such "plugin ecosystems", every "plugin" (WASI component) is of the same shape (i.e. exposing the same endpoints, and expecting the same capabilities.) And so the host runtime, and each of its plugins, can be precompiled (separately, in separate projects!) against that shape. And the plugin host can load arbitrary wasm components into a pre-baked plugin "slot" at runtime, because there's no dynamism / introspection / reflection / component framework support required or involved. The plugin host isn't a component itself; it's just ordinary host runtime code, written once. The component framework doesn't load the component; the host runtime does. Etc.

In a sense, this is "custom binding" as you were talking about. But it's custom binding against a WASI-specced target; which is what enables different plugins to be runtime-fungible within the same plugin "slot" from the host's perspective. (While giving you sandboxing for free, unlike the traditional "a plugin is just a DLL that exports certain symbols" approach.) WASI does all the work plugin hosts want of it at component compile/link time: verifying that the plugin is of the expected ABI shape, and guaranteeing sandboxing (by a WASI component inherently being a thing developed to run as an isolate under an abstract machine.) The fact that a compiled+linked WASI-component artifact is a blob of WebAssembly built against certain WIT interfaces, isn't just something tagged onto it by external metadata; it's also something inherent to the structure of the resulting artifact, i.e. a property determinable via static analysis.

At runtime — or slightly earlier, at plugin "install" time — a plugin host might not even keep the component as a component. It might preprocess it into a DLL, or whatever its runtime's equivalent of a DLL is. (A Java class file, say.) The crucial thing was that the component was a component when it was handed off from the downstream developer to the plugin host. Because then any code generated to wrap the component into a host-runtime-native module, is code trusted by the host, rather than code controlled by the downstream developer.

---

If your goal is to compile some one-off blob of WebAssembly code into an artifact that you can then e.g. treat like an old-school ActiveX component from browser JavaScript, then yeah, you don't need WASI at all for that. You're not trying to create a plugin ecosystem. You don't need to spec out a standard "socket" for downstream devs to plug into. You're just "plugging X into a thing that expects only and exactly X". So skip WASI; just use a one-off custom binding. (Though I would note that the WASI work has acted as a forcing function for the WebAssembly-component ABI, enabling you to write much richer custom bindings than you would have been able to write before WASI.)

But if you're:

- developing a FaaS runtime like Cloudflare Workers

- developing a game engine that allows "mods"

- developing a cloud-hosted agent sandbox, where the toplevel is code (that invokes LLMs, that invoke capabilities)

- developing a modern replacement for Wordpress, with an aim to allow just as much extensibility but to not repeat Wordpress's endless vulnerabilities

(etc)

...or, in other words, if you are developing an application or service that O(N) downstream-developed things (workloads, plugins, mods, extensions, whatever you want to call them) all plug into; where you want these things to all plug into your host system in a very precise and controlled way, rather than being given free rein to touch anything they want; and where these interaction patterns can all be described in one of a few very specific shapes, with a precisely definable spec for 1. what API the runtime wants to call into on the component; and 2. what APIs the runtime wants to hand to the component, to enable the component to call those APIs...

...then WASI was developed precisely for you.

And, more specifically, WASI was created so that you could:

1. use WASI to define that API spec (as machine-readable WIT files); and then

2. give that spec, and those WIT files, to the developers in your ecosystem;

3. so that they could then use existing WebAssembly+WASI tooling to build WebAssembly components that target your API spec. (Most likely not by expecting them to independently bootstrap a WebAssembly+WASI dev environment; but rather, by you shipping an SDK that embeds WebAssembly+WASI tooling and your WIT files together.)

(I would also note that this — i.e. "the thing WASI solves for" — is actually a rather rare use-case on the whole. Your average dev isn't [and shouldn't be!] building an ecosystem for API-sandboxed plugins of their code. The few devs that do need to construct their own plugin ecosystems around their project, probably can therefore be expected to go quite deep on learning any required "insider wizardry." If that was even required. Which it generally isn't, when all you're trying to do is to load one of N unknown-until-runtime but statically-defined-ABI-shape plugin components; rather than trying to load arbitrary runtime-generated dynamically-defined-ABI-shape components, allowing those components to load or compile+exec further components, etc.)

[himata4113]

I do specifically that and abandoned WASI in favor of freestanding with shared memory regions + PIC memory region. It works today and is easily extensible as well as increadibly fast, sandboxing is not as strong since modules can read code they don't own and modify data they do not own, but splitting modules into "trusted" and "untrusted" largely mitigated those issues as memory has write bit stripped for execution during untrusted modules, only allowing data they own to be modified. Sensitive data lives outside the runtime and has to be fetched with (slower) host methods.

Point being, if you rely on a non standard specification of developer defined wasi api subspec you might as well just go with freestanding.

[xyzzy_plugh]

> Point being, if you rely on a non standard specification of developer defined wasi api subspec you might as well just go with freestanding.

Precisely this. The whole endeavor has been disappointing. I'd love to build support for WASI but realistically it's far simpler for all parties just to do something custom, which feels wrong. I get that it's only 0.3 but it's advancing far too slowly for my tastes. I just don't know who it's for right now.