Skip to main content
← Back

Wasm Component Model: Plugins, Shared Memory & WASI 0.3

The September 10, 2025 wasmCloud community call started as "the quickest wasmCloud Wednesday ever" — no agenda, with the team heads-down on the last items of the Q3 roadmap — and then turned into a wide-ranging hallway conversation about the hard edges of the Wasm component model. Brooks Townsend, Colin Murphy, and Victor Adossi dig into why adding system time-zone support to Wasmtime takes a year and a half, how a wasmCloud host plugin could route around runtime bottlenecks, Christophe's shared-memory proof of concept, and why first-class functions in WIT are the missing piece for generating polyglot SDKs — all while looking ahead to what WASI 0.3 (Preview 3) unlocks.

Key Takeaways​

  • Colin's WASI WebGPU work carries over to wasmCloud without a fork. Because a wasmCloud host embeds Wasmtime, the WebGPU linker calls Colin mapped for a demo can plug in through wasmCloud's host-surface/plugin facility instead of forking the project — the same linker mechanism, no runtime patching required
  • wasmCloud is building a built-in plugin model for the host. You write a small Rust binary, embed the host, and provide a capability (like a WebGPU implementation or a system time-zone interface) without going down to the runtime — an interim step before something like dynamic libraries
  • Landing anything in Wasmtime/WASI requires extreme consensus. Colin's system time-zone interface has been open ~18 months; the holdup is design agreement and security concerns (a time-zone-based "kick-me sign" attack), not the five lines of code — and time zones won't land until WASI 0.3
  • A host plugin can't fix everything. Real adoption needs upstream crates like chrono and tz to expose the capability, and those crates won't ship anything that isn't in Wasmtime — so low-level platform features are still gated on upstream consensus
  • WASI 0.3 (Preview 3) is the big unlock the team keeps pointing to. Async, futures, mio/Tokio support, sockets, and crypto are all "easy once 0.3 lands"; Roman demoed accepting socket connections and hitting SQLx over async on a P3 branch
  • Sockets in 0.3 should be real sockets, not "SQL sockets." Colin and Victor want socket support that also works for wRPC — not just SQL clients — and note P3 streams and futures are what most languages actually expect
  • Christophe's shared-memory PoC shows host↔component memory sharing today. Built on WASI P2 and updated to P3, it lets a host and component share memory instead of copying bytes — one of the most-requested-but-still-experimental capabilities
  • First-class functions (callbacks) in WIT are the gap for SDK generation. To define an SDK interface once in WIT and generate Node/JavaScript SDKs that take functions as arguments, the component model needs a way to pass and call back into functions — something the browser gets for free but WASI does not yet specify

Chapters​

Meeting Notes​

A Short Call, the Q3 Roadmap, and WebGPU Without a Fork​

Brooks opened by warning the call would be short — there was no agenda, and the team had been heads-down on the last items of the Quarter 3 roadmap, including the runtime piece and the wasmCloud host API discussed the prior week, plus the open-source Kubernetes runtime operator that was still waiting to be moved over. The natural off-ramp was Colin's upcoming talk: he had been adding WASI WebGPU to a build for a demo, mapping the WebGPU calls into WASI on top of what "looks like Wasmtime." Brooks pointed out that because the wasmCloud host embeds Wasmtime, Colin wouldn't need to fork wasmCloud at all — the same linker work carries over through a new host-surface facility that lets you embed the host and provide a capability as a plugin. Colin's plan for the talk was to show the workload running entirely in WebAssembly and then calling out to the ONNX runtime from a provider, as a pros-and-cons comparison.

System Time Zones and the Cost of WASI Consensus​

The heart of the call was Colin's frustration with getting system time-zone support into Wasmtime and WASI. The clocks interface had been in flight for roughly a year and a half while the ECMA group rewrote it; a recent change was "just" a rename that propagated through every binding file. The substantive disagreement was whether a Wasm guest should be able to read the system time zone at all. Colin's argument: nothing else does that — Docker doesn't — and granting it could enable a time-zone-based timing attack ("a kick-me sign"). The counterpoint from Roman was that you'd need full runtime access anyway. Brooks framed it as a recurring theme: landing anything in Wasmtime or WASI requires extreme consensus because it has to be correct, which Colin respected even while finding an 18-month wait for a five-line change exhausting. Pragmatically, the current behavior already falls back to UTC when no system time zone is available (mirroring how jiff/chrono behave, and how an Alpine slim image with no tz database returns UTC), and the cleaner interface won't land until WASI 0.3 regardless.

Plugins, Upstream Crates, and the Limits of the Bottom Layer​

If Wasmtime is slow to absorb features, Brooks argued, wasmCloud has an opening to provide a better experience through a plugin — a small always-available facility that exposes, say, a system-time WIT interface in five lines. The catch, Colin noted, is the layering: a plugin solves the bottom layer, but real adoption needs upstream Rust crates like chrono and tz to expose the capability, and those crates won't ship anything that isn't already in Wasmtime. (Colin recalled forking a stack of crates years ago to get an earlier demo working; Brooks recalled upstreaming small fixes to the url crate and ring just to keep things compiling on stable.) The takeaway: a host plugin is great for many capabilities, but low-level platform features remain gated on upstream consensus. Colin also reflected on his role as the "non-myopic" voice — he runs a real software project where colleagues question why WASI is in the repo at all — arguing that if you pass capabilities into the runtime sandbox, they should "just work," while still respecting the sandbox.

WASI 0.3: Async, Sockets, Shared Memory, and First-Class Functions​

The forward-looking thread was everything WASI 0.3 (Preview 3) is expected to unlock. Colin is "looking forward to 0.3" to see whether it actually delivers the long-promised wins around mio, Tokio, async, crypto, and more. Brooks pointed to Roman's earlier demo accepting incoming socket connections and hitting SQLx over an async socket on a P3 branch; Colin and Victor pushed on whether 0.3 sockets are real sockets (usable by wRPC) or effectively "SQL sockets," landing on the view that P3's streams, futures, and cross-component IO are what most languages actually expect. Victor highlighted Christophe's shared-memory proof of concept — host↔component shared memory built on P2 and updated to P3 — as an experimental but exciting answer to the perennial "I don't want to copy all these bytes" request. Finally, Colin made the case for first-class functions (callbacks) in WIT: to define an SDK interface once in WIT and generate Node/JavaScript SDKs (which expect functions as arguments), the component model needs a way to pass and call back into a function — something the browser gives JavaScript for free, but which WASI does not yet specify.

WebAssembly News and Updates​

There were no new blog posts to call out this week — the team was deliberately heads-down finishing the Q3 roadmap. The substantive "news," such as it was, lived in the standards work: the long-running WASI clocks/time-zone interface rewrite, the steady march toward WASI 0.3 (Preview 3) with its async, streams, and sockets story, and community experiments like Christophe's shared-memory PoC and Colin's WASI WebGPU mapping. For the broader picture of what Preview 3 brings to wasmCloud, see the WASI Preview 3 on wasmCloud post, and follow the Bytecode Alliance and the WASI project for upstream progress.

What is wasmCloud?​

wasmCloud is a CNCF project that lets you build applications using WebAssembly components and deploy them anywhere — cloud, edge, or Kubernetes clusters. It uses the WebAssembly component model to let you write business logic in any supported language (Rust, Go, Python, TypeScript, C#) while the platform handles capabilities like HTTP, messaging, and key-value storage through a pluggable provider and host-plugin architecture. wasmCloud's reference host is built on Wasmtime, so improvements at the runtime level — like the WASI clocks interface or WASI 0.3 sockets — flow directly into the platform, while wasmCloud's own plugin model gives teams a faster path to expose new capabilities. With built-in OpenTelemetry observability and Kubernetes integration, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure.

Topic Deep Dive: The Wasm Component Model​

Nearly every thread in this call traces back to the Wasm component model and the WIT interfaces that define it. The time-zone debate is really a question about which capabilities the component model and WASI should let a guest reach, and how much consensus that requires. The plugin discussion is about where a capability lives — in the runtime, in a wasmCloud host plugin, or in upstream crates — once it has a WIT interface. Christophe's shared-memory PoC pushes on how host and component share state across the component boundary instead of copying bytes. And first-class functions are a gap in the component model itself: to generate SDKs in Node, Python, or other languages from a single WIT file, you need the ability to pass a function and have it called back — the kind of typed composition the component model is meant to enable. The connective tissue is WASI 0.3 (Preview 3), which brings async, streams, futures, and real sockets, and which the team treats as the moment many of these long-deferred capabilities finally become practical. As the component model and WASI mature, the promise of "define an interface once, run it across hosts and languages" gets meaningfully closer.

Who Should Watch This​

This call is especially valuable for WebAssembly runtime and standards contributors weighing how much consensus a new WASI interface needs and where features should live (the time-zone and plugin discussion from 9:21), platform engineers and host authors evaluating wasmCloud's host-plugin model as a faster path to new capabilities than forking the runtime (Brooks at 12:32), and SDK and tooling developers interested in async, sockets, shared memory, and first-class functions arriving with WASI 0.3 (the deep dive starting at 18:21).

Up Next​

The team expected more substantial updates the following week, with the Q3 roadmap wrapping up and Q4 planning on the horizon. Watch for progress on the wasmCloud runtime and host API, the move of the Kubernetes runtime operator into the open, the maturing host plugin model, and the steady approach of WASI 0.3 with its async, sockets, and shared-memory story — plus Colin's upcoming WASI WebGPU talk.

Get Involved​

wasmCloud is a CNCF project and contributions are welcome. Join the community:

Full Transcript​

Read the complete transcript with speaker labels and timestamps:

Read the full transcript →