Subscribe
Share
Share
Embed
WASI Preview 3 is a turning point for WebAssembly outside the browser, and this episode explains why. F5's Joel Moses and Oscar Spencer are joined by Bailey Hayes, CTO of Cosmonic, to break down what “native async” really means for the component model, why it took two years to land, and how it changes the way we build polyglot, composable cloud systems.
At the center of P3 is first-class async and concurrency in the canonical ABI. That isn’t just a nicer developer experience, it’s a host-level capability: runtimes can understand who’s waiting on what across composed components, propagate async handles through the stack, and apply backpressure using standardized stream types. Bailey walks through how this shows up in practical interfaces like WASI HTTP, where response bodies become streams and service chaining becomes far more natural, without the awkward P2-era workarounds.
The conversation gets concrete on performance. Bailey shares real benchmark results showing order-of-magnitude gains when moving from serialized execution patterns to true concurrency, along with what changed mechanically from P2 to P3, including simpler interfaces, bidirectional streams, time zone support, better durations, and exit codes.
They also talk about ecosystem impact: how P3 affects different languages, what it unlocks for JavaScript via JSPI, why Go still needs cooperative threading to be truly native, and why the rise of “vibed-out” runtimes is accelerating component model adoption. Bailey closes with what’s next in WASI evolution, her thoughts on Preview 4, and what additional capabilities could meaningfully expand what developers can do, including a future WebCrypto-style interface.
If you’ve been waiting for WebAssembly to feel like a real distributed systems runtime, P3 is the milestone to understand.
Read the WASI P3 launch blog: https://bytecodealliance.org/articles/WASI-0.3
Check out Bailey's work on Cosmonic.com
Read the WASI P3 launch blog: https://bytecodealliance.org/articles/WASI-0.3
Check out Bailey's work on Cosmonic.com
Creators and Guests
Host
Joel Moses
Distinguished Engineer & VP, Strategic Engineering at F5. Joel has over 30 years of industry experience in cybersecurity and networking fields. Prior to joining F5, he designed large scale security and infrastructure architectures for consulting clients and served as the lead US Security and Infrastructure Architect for one of the largest accounting/consulting firms in the world. At F5, he is a founding member of the Office of the CTO, and is principally responsible for advanced research, intellectual property, proof-of-concepts, and strategic studies related to security, hardware, and cloud technologies. He holds several US patents related to encryption techniques.
Host
What is WebAssembly Unleashed?
Welcome to WebAssembly Unleashed, your monthly dive into the dynamic world of WebAssembly (Wasm). Join F5’s Joel Moses, Oscar Spencer, and Wasm enthusiast Matthew Yacobucci as they unpack the potential, challenges, and innovations within the Wasm ecosystem.
Designed for architects, practitioners, technologists, and Wasm enthusiasts, episodes offer:
Insightful discussions on Wasm advancements.
Practical tips for seamless integration into projects.
Interviews with influential figures shaping the Wasm landscape.
Strategies for maximizing the potential of WebAssembly.
Subscribe now and stay abreast of the latest in Wasm development. Whether you’re a seasoned pro or new to the field, WebAssembly Unleashed is your ticket to unlocking the full power of this revolutionary technology. Tune in for a deep dive into the limitless possibilities of WebAssembly.
Joel Moses (00:03.021)
Hello and welcome to WebAssembly Unleashed, your source for news and views on our very favorite Open Standard. Our goal as always is to help folks understand what's going on in the community, highlight valuable work, and try to translate what this technology means to the rest of the world.
We're not just fans, we're also practitioners in the polyglot world of Wasm. I'm Joel Moses. Welcome. It's clear we are not in Kansas anymore. WebAssembly is out of the browser and bruising for a fight on cloud workloads, all while promising a lightweight and secure future. But anyone building complex distributed systems tends to run into the same wall. How do we do async I.O. and streaming without messy workarounds and cues and crazy stuff like that? Well, today that wall comes down. We're going to dive deep into WASI Preview 3, Native
Component Async and we're gonna talk about the future, the future of composable cloud architectures. But before we get there, yes, indeed. With me is my all as always is my co-host Oscar Spencer. How you doing, Oscar?
Oscar Spencer (00:52.04)
Unintended, I guess.
Oscar Spencer (00:58.625)
I'm doing fantastic, Joel. Great to be here.
Joel Moses (01:01.009)
Excellent. So containers gave us cloud portability, but WebAssembly is keeping us portable, but also redefining compute density and runtime composition. Now WASI Preview 3 is moving future and stream primitives directly into the component model canonical ABI. We're seemingly entering a new era of distributed computing for Polygot languages, and our guest today is literally helping build the specifications and the runtimes powering this ship. So Bailey Hayes, welcome back to the show.
Bailey Hayes (01:30.968)
Thank you for having me.
Joel Moses (01:32.481)
Bailey, of course, the CTO of Cosmonic. Alright, let's get started. So, preview three. What's in it? Why is it important?
Bailey Hayes (01:42.764)
Wow. it for something that we usually summarize as a single major feature, from I'm gonna from here on out call it WASI P3 versus WASI P2. WASI P3 gives you native async and concurrency to the component model. And that's that sounds like one kind of feature, but it's a massive lift.
I held the vote for WASI P2 in the WASI subgroup in January 2024. And so it took us, you know, basically another two years to develop this next major revision. but it was worth it. And when we say native async, we mean it in a couple different contexts. We mean it in that the WebAssembly runtime itself, the host in this scenario, knows about.
The asyncness that's happening within the within the the system. So when you compose a bunch of components together and each of them are all wait awaiting each other, it's able to figure out who's waiting on who and how to handle that and to make that really efficient and to pass basically these async handles all the way through the system. On the other side, it means that I can write ergonomic, idiomatic.
Code, like I can do async08 and Rust and and in my TypeScript code. I could do things like writing Go routines within Golang. all of this essentially getting us to a place where we async is a a first party supported feature of both the language bindings that we built, so we call those the guest bindings, but also on the host side.
Joel Moses (03:27.895)
That's pretty cool. Now obviously when you're talking from component to component and you've got one fast guest component and a slower guest component, let's let's decompose that for just a moment because we do have some people who are just getting familiar with what's in P3. say you have a fast component like in Rust or C plus plus and one that's slower in Python or Go. how do you handle the back pressure?
Oscar Spencer (03:35.503)
Okay.
Oscar Spencer (03:39.247)
Just getting
So you have a fast unless it process.
Bailey Hayes (03:51.042)
Yeah, so the back pressure is natively handled by our type called a stream. so within WASI, we define the standardized interfaces that compliant hosts and guest tool chains support. And so one of those that we can talk about is let's let's take WASI HTTP specifically. A guest will export a WASI HTTP handler saying, hey.
I can serve HTTP. So call my handler and I will give you some HTTP back. Part of that handler API is a stream for the body of what it's going to send back. Now I might have another component actually chained with this component. So we call that architecture service chaining, where I take two components and I compose them together and I say, I want you to kind of make a chain. And and I might do this when I want middleware.
And I want to have kind of middleware operating across this chain. Maybe I want to do this because I'm emulating many different REST components, and each one manages their own RESTful resource. And so each one just kind of has their own set of business logics separate from what the other one is. And so for that reason, I want isolation around them and make them each their own components. There may be many different reasons why I wanna have this boundary.
But the boundary itself is defined by my export that something else maybe imports or that the host is providing, which is typically the most common case. So the host itself understands how to provide back pressure for this stream type. And when I have two components composed together, in that scenario, basically the same thing. The host knows how to basically pump these bytes through. And only as a component is reading off of that stream before it's been closed.
is how basically back pressure is natively built into the entire system.
Joel Moses (05:47.425)
But
Oscar Spencer (05:48.34)
And so let me ask then, how how does that affect performance, right? so it's like are is it actually that much better? Was this two years of work really worth it?
Bailey Hayes (05:59.414)
Yeah, okay. I did a really fun performance benchmark. You can actually see it on are wefestyet.wasmcloud.dev. if you go in there, I did the cheesiest of cheese benchmarks, but I I for the life of me couldn't find another way to not do something just totally contrived, which was, okay. In in the olden times in P2, I I really couldn't safely do any kind of async concurrency against a component.
Now, if you imagine, let's just imagine a basic microservice. You know, it's got a typical RAS crowd API, I'm calling into it, it's then going and calling out to a database, doing some stuff, maybe a query, and then coming back with a response. It's IO-bound. Significantly I.
Now, if I can't concurrently enter that instance, what I have to do is maybe spawn more instances when I get a burst of work. I I have different versions of these instances spawned out, but I've followed, you know, perfect 12-factor app practices. I've written a serverless, stateless, restful microservice, and gosh darn it, I should be able to reuse it. I couldn't safely do that in P2. I I couldn't really wire things up in a way that I could have safe re-entrancy. With P3.
I was able to say, okay, let's have you know let's concurrently enter this this instance. So if you wire things up correctly, both you can do this in Wasmtime if you know what you're doing in Wasmtime. WasmCloud embeds Wasmtime. We have a setting for max concurrency and an instance pool, so you can kind of fiddle with these knobs to get about where you want for your microservice. but essentially
In my cheese test, it's just completely bound by the number of cores that you have in your network card. once you are able to fiddle that knob up to the point where you're like, yeah, just basically thread all of all of these concurrent requests in and I will I will serve them. So the rough number that you can see in that test based on the hardware that's available in my benchmark host, it was like 13.x uh.6x improvement in performance.
Bailey Hayes (08:13.911)
But it's a total cheese, right? Because it's the difference between doing things serially versus doing things concurrently.
Oscar Spencer (08:20.332)
Yeah, that makes total sense. and I guess, you know, as a language person, let me ask you this. What does this actually mean for languages who wanna, you know, compile to WebAssembly? because I know for languages like Go, for the longest time, one of the biggest pain points was doing any kind of a sync or concurrent thing. so like, does this actually make it easier for languages to to target WebAssembly?
Bailey Hayes (08:46.309)
It made it a whole heck of a lot easier for languages like JavaScript and TypeScript, because the implementation over there is now able to use the JSPI. so that is just native, awesome, performant, easy. But let's be real, Go's not quite ready yet.
With Go, they have their own essentially you know, in in a lot of languages like Python, it's green threads, with Go it's Go routines, with C you may be using coroutines, or you may just be using like straight-up threads. And a lot of those languages, we still don't yet have a way to provide that. natively. You can do this in memory. You can basically do what we call asyncify in a lot of places.
where basically you are handling the stack switching and you're keeping that in memory and you're swapping things around. in practice that's not exactly what things like componentize go are using today. They're doing something much much better than that, but it's still not as good as it could be. And the way to make it as good as it could be is a new feature that we're going to be adding in a point release of WASIP3 that's called cooperative threads. Have y'all talked about that before on on the podcast?
Oscar Spencer (09:59.223)
coming up soon.
Bailey Hayes (10:01.119)
Okay, okay. all right, well then I I don't want to spoil too much. I'm also like not the person implementing this, so probably not necessarily the person to talk to on it, but essentially we're going to have at the ABI level a way to spawn threads and manage that. again, when I say native, what I really mean is we are providing it in the component model canonical ABI, and that's allowing the the runtime, like WASM time to be able to implement it.
Oscar Spencer (10:02.51)
Stay tuned, guess.
Bailey Hayes (10:31.217)
And when I when I have this capability, I can basically have a really nice native implementation for Golang's Go routines. so until we have that, it's it's it works. but it's not not necessarily as as awesome as it could be. And that's really mostly on performance and memory. It's not so much that things aren't going to work.
Oscar Spencer (10:57.042)
And so let me ask you this too. How much did the interfaces themselves actually change moving from P2 to P3? Like do we do we get like a a huge churn there? Is there a bunch of new stuff in WASI or what's what's happening?
Bailey Hayes (11:11.263)
A lot of it was largely mechanical. so we do have a really great blog post about this. I hate I hate to toot my horn because I'm one of the co-authors on it, but on the Bytecode Alliance blog when we announced WASIP3, you can see I I went through in detail basically what those changes are, like what the set is. but the short answer is if it could be async, it was turned async. And then if it instead of having an HTTP
WASI P2 you had incoming and outgoing handlers. Now streams are bidirectional. So the interface surface just got way simpler. Now we just have handler and it it takes a stream. And that now because the system can handle incoming and outgoing is just built in. so that's not something you have to mess with anymore. So for the large part, basically, you can mechanically just update. And what I mean by that is like a regex will do
but if you are using WASIClocks, there's some new features, some nice things in there that I I do want to give a fair shout out. What's up?
Oscar Spencer (12:13.907)
what w what do we got in there? What what's new in ti what's what's new in the time world?
Bailey Hayes (12:19.053)
In the time world there are time zones, which is kinda nice. we've been needing that for quite a long time. we also changed the way that we're doing durations, as you can imagine, being able to respond to things asynchronously. It's gonna be nice to make those a little bit more ergonomic and have like things that better basically, you know, do a dur duration on that kind of thing. So so those got tweaked, but all of that was not for the sake of churn, but for the sake of ergonomics.
I think off the top of my head, those are the big ones. We also added exit with code. So WASZCLI run will give you an exit code, which is nice. so that's a feature that's stabilized as part of P3. so so so yeah, you know, sometimes people are like, man, it doesn't feel like a lot of change. What did you do over those two years? but then when I say, you know, like you can get 13 times the performance for your microservice, people are like, okay, maybe something's here.
Oscar Spencer (13:18.557)
Well, and so talk a little bit more about that. Like how has this affected run times? Like what what changes have you seen happen in run times in in terms of supporting P3?
Bailey Hayes (13:28.351)
Well, I think one big difference between twenty twenty four and twenty twenty six is everybody is using agents and LLMs to write code now. and it's largely made code free. So one of the biggest hangups people had with the component model, which I think was a a fair reasonable complaint, is that it's complex and there's, you know, a lot here that I have to implement.
one of the one of the amazing things that have happened is that I've seen so many new runtimes, purpose-built runtimes for a given use case, and a lot of those are almost entirely vibed out. one that I think is worth calling out is WASI WCJS. that one is about I think I looked at it with SCC to see how many lines of effective code it required to create a component model runtime, and it was around 4,000.
so you know, 4,000 lines, not not crazy, but nobody would want to look at a vibed out PR and do a tight code review on that many lines. But that's about how much was required to be able to create basically JavaScript native component model runtime. obviously saying JavaScript there means there's other there's other runtime parts to it, but that was just the little bit that they needed to glue up the ABI. So that's that's sort of, you know, you can now have a mental frame of reference for exactly how much this takes, which I thought was pretty cool.
But it but essentially how the runtimes changed is that well, Wasm time changed a lot because it evolved with the spec, right? The Joel and Joel Dice, Alex Crichton, those guys did a ton of amazing work implementing, designing, refining what we need for the component model spec to give us you know native async. And so there was a ton of iteration that happened within the Wasm time space.
And you know, with all great evolution, there are sometimes weirdness, you know, there's sometimes vestigial tales left behind because you've evolved it. there is probably a little bit of that still in Wasmtime. and for that reason, that's why it's so interesting to see a lot of these vibed-out runtimes that now have component model support because they basically got to do a clean room rewrite of exactly what they needed. So I think that is one of my big call-outs. I would say
Bailey Hayes (15:46.026)
there's a coup bunch of different projects I've been watching. Another one is Waze, is how I'm gonna say it, W-A-Z-Y. and that is a component model supported version of fully Go, so like pure Go, no no C Go involved here, that was a fork off of Wazero, and so that now has component model support. so it's essentially I think there's maybe 20-ish runtimes that I'm aware of that have component model support. So
That's a pretty big difference from twenty twenty twelve twenty twenty four to now.
Oscar Spencer (16:19.34)
yeah, that's an absolutely huge difference.
Joel Moses (16:21.557)
Yeah. Now th there were some things that kind of emerged out of the last CG and I I kinda wanna get back to that. We've been talking about this in the context of cloud computing, but b maybe comment on P three and component model and its applicability to the browser, where it came from.
Bailey Hayes (16:38.529)
Yeah, so WASI P3, right, is built on top of and based on the component model. And so we define all of our standardized interfaces in terms of width, in terms of component model interface types. and the component model itself always had a goal of both working incredibly well outside the browser, obviously, because that's you know a big part of the WASI use case.
But also in the browser, and and has always been one of the key design goals of it. And and it's part of the reason why WASI and the component model are intentionally decoupled. so a lot of the work that's being done by folks like Ryan Hunt and Ben Business from Mozilla, I've been watching very closely and cheering for them because I think it's very exciting, where they're basically adding native component model support to Firefox.
that's been pushing a lot of things forward and and they found essentially a significant performance improvement by actually having native component model support rather than JavaScript Shim support. My teammate, Victor Adasi, maintains JCO, the JavaScript component tooling. And inside JCO, well, it does a couple different lots of different things, honestly. But one of one of the things that it does is it allows you to take a component and basically transpile it so that it could run in the web.
So given a component, it'll effectively unbundle it, wire a bunch of c WebAssembly modules together, and then give you a bunch of shim code that you need to be able to run in both a browser or in a Node.js environment. So it's got all those different shims that you might run. that performance is obviously not gonna be as good as a native implementation in the browser like what the folks are pursuing over at Mozilla.
Joel Moses (18:32.565)
So one thing that you know, when a platform engineer is working with code from from different developers and they're using polyglot systems, what about debugging? Debugging polyglot call stacks. When an async promise drops or it hangs across three distinct comp compose components, what's what's observability look like in P three?
Bailey Hayes (18:53.45)
Yeah. well, you know, it's still somewhat of a challenge, if we're being totally frank. That's not necessarily the easiest thing to debug. I'll be straight up that my favorite way to debug most things remains printf and I refuse to change. but there is also WASI Hotel, which is not yet a phase three proposal, so it's not considered a part of WASI P3. but in projects that I maintain, like WASM Cloud, we're using it directly there and we have
Really great instrumentation. I I I actually just really love it. It has been working extremely well in production environments. So if you haven't tried it out, you should definitely give WASI Hotel a look. there's a lot of also goodies here that have already been built out. Like within the Bytecode Alliance, there's OpenTelemetry Libraries for probably your favorite language. there's a little SDK that you can just basically drop in and it'll behave like the OpenTelemetry SDK that you
We're probably already using for your other projects that didn't compile to WebAssembly. So that's that's my other go-to. In a any kind of distributed system, or even inside the exact same exact same component but composed with many other components across many different languages, Otel's a great thing to reach for. I also follow the traces as logs methodology. So so basically I always emit a trace whenever
you know, some people might write a log. So when I was saying printf, I'm being a little cheeky. I technically am mostly writing traces and I'm using a dashboard. Usually locally, I like the Aspire dashboard. If you if you want really my my full nitty-gritty details, that's usually what I'm running locally when I'm running stuff. but essentially that's that's one big way.
I don't want to steal the thunder though because I I believe on Oscar's team what y'all are doing is pretty exciting in the debug space and the demos that I saw from Chris Fallon were pretty awesome. I haven't gotten my hands around it yet, but the I that idea and that RFC within the Bytecode Alliance is my hope for having a nice native debugging experience in the future.
Oscar Spencer (20:55.18)
Yeah, and that plus, you know, as we're getting into composing components, really getting into tools like Splicer, like going in and say, hey, like let's just drop instrumentation around everything happening that's going in and out of these components. And so I think once we start combining all these different tools together for debugging, we're gonna have a pretty awesome experience. But one of the things we touched on there was WasmCloud. Bailey, for our listeners, can you just let them know what WasmCloud
is and then like tell us about what p3 has meant for wasm class
Bailey Hayes (21:28.051)
Absolutely. That's my one of my favorite topics other than WebAssembly. So CNCF LASM Cloud, it's an incubating project within the Cloud Native Computing Foundation. We give you the ability to run a multi-tened host natively in Kubernetes. So essentially we give you a custom resource definition that says, hey, this is my workload. I can have n-number of components. I can also have this special kind of component, which is a long-running component. We call them services.
Those are super handy if you want to do client-side connection pooling, reach out to databases, or you kind of want it to be your root application router, act as your sidecar equivalent or API gateway running right intended inside your workload. Then we also have the ability for you to supply capabilities of the host. So one challenge in WebAssembly is that you can only do what you're granted.
Which is an intended challenge. That's how we keep you sandboxed. But that means I can only do what's either available in WASI or what has already been created inside my host. And updating a host is a serious business because that's expanding on our footprint of the things that we have to audit, of the things that we have to maintain, all these various dependencies. So one of the major reasons why I think any of your listeners might be interested in WasmCloud is that we give you a host that you can give a component and have that.
service the the capabilities and have it be host teneted. So I can launch a host, run a long-running component that is holding on to, let's say, my Kafka broker. And it is able to now fan out messages like we were talking about the max concurrency part earlier on this call. I'm able to concurrently fan out and burst lots of different components running on my host, each one of those multi-tenited, so so tinted and sandboxed safely from each other.
but also having a host level capability that is also a component that is also isolated and sandboxed from all these other things. so CNCF Wasm Cloud has a lot of neat stuff and is all WASI compliant, built on standards, built on bicode alliance projects like the like Wasmtime. So if you haven't checked it out, I strongly recommend you do.
Joel Moses (23:42.771)
that sounds really cool. I do have to ask though, 'cause you know, it it seems like you you're you're providing a host level corridor that that uses Kubernetes to good effect, and then you've got WASM component elements that you're fanning out to. Where's the boundary between Kubernetes pods and Wasm component workloads going to be sitting over the next two to three years?
Bailey Hayes (24:03.294)
It's a question I get a lot. That's a really good one. So for us, we're all about in CNC of Awesome Cloud giving people the picks and shovels to build whatever kind of architecture you want to. There are a lot of people who don't just want picks and shovels, they want pitchforks against Kubernetes, and so they're trying to run not in Kubernetes. We do support that, and you can't just run that way. now
For what I recommend to people who are running a production on top of CNCF WasmCloud, and there's quite a few folks now, which is cool, terrifying for a maintainer, but cool, is running with our operator that is part of the WasmCloud project. it's a single home install. our operator runs and does the reconciliation of that custom resource definition I was talking about, the workload.
and in the workload, it's just OCI rafts, two components, their configuration, being able to bring secrets in from Kubernetes secrets natively. so you can do things like external secrets, so you can back that up with Vault, etc. etc. now when our operator runs, what's pretty interesting about us is that we're pushing events to the host. so it's our operator that's actually doing the scheduling. So wherever your host is running, whether that be in a pod.
or outside of Kubernetes, or you know, maybe in one pod in another container, you know, multiple hosts in one pod with mini containers. Whatever that architecture might be. But again, my production grade architecture is one host per pod, so one container per pod. Inside that pod is a host. It wakes up and and it it it you know think Jason Bourne. It it tells the operator like I'm here, you can schedule to me. I I'm ready to be scheduled to
Our operator just does basic command and control. Workload start, workload stop, checking for help. But basically it schedules the workload and it's already done the reconciliation of touching the Kubernetes API, of getting secrets, all of that trust boundary is actually tightly scoped to the R back of the operator. And the host itself does not have any of those dependencies, isn't able to reach out to that, it's not talking to Kubernetes, it doesn't know what Kubernetes is. All it's like
Bailey Hayes (26:11.294)
I just have my basic workload start and stop API and that's all I need to be able to run. And so a lot of people have also built WasmCloud hosts in a lot of different kinds of environments that I haven't even really touched on too much here. Like I have a WasmCloud host that runs inside the JVM. That's pushed up on the Cosmonic Labs page. That's running inside inDive, which is another Bytecode Alliance project.
Joel Moses (26:27.637)
Okay.
Bailey Hayes (26:32.096)
We have a WasmCloud host that runs on itty bitty microcontroller devices. So you can you can mix a match your host, and so long as you are able to give me basically a way to schedule to you, we can schedule and run you as part of our entire cluster.
Joel Moses (26:47.489)
So lots of architectural choice possible. That sounds good to me. Picks and shovels are great. pitchforks are also great as tools. Just depends on what you do with it, right?
Oscar Spencer (26:47.779)
You know
Bailey Hayes (26:54.252)
They are a driving force. Yes.
Oscar Spencer (26:58.793)
Yeah. And Bailey, one thing you said there, I was you're saying, yeah, you know, this thing doesn't know anything about Kubernetes. That sounds like a beautiful place to be. Somewhere that
Bailey Hayes (27:06.444)
Would be nice if but you know, turns out enterprises, they have to be in Kubernetes. They are also the people who pay my bills. so I am happy to give them the best possible experience in Kubernetes.
Joel Moses (27:06.999)
Yeah.
Oscar Spencer (27:19.241)
Yeah, absolutely. so more on sort of just like you know, getting into like just more P3 and and sort of what's coming in in these dot releases for P3. How has it changed designing new WASI interfaces?
Bailey Hayes (27:33.989)
it has changed significantly. So when when we shipped WASI P2, we had not figured out necessarily the way that we were going to evolve WASI. and so during the life cycle, basically the lifespan of WASI P2, which was over those two years, we figured out how to do feature gates.
So at sense, add unstable, we figured out really well how to update doc comments and make that nice for people. We found better ways of shipping the OCI containers and standardizing on annotations and labels and like building up the kind of the ecosystem ergonomics around all of that. But we didn't really ship like major new features. We shipped additive non-breaking changes to the WIT APIs and lots and lots and lots of doc updates.
Now, over in P3, we now had a way to evolve WASI. We had a way now to add new features that are gated behind AtSense and Add Unstable, but we had not quite yet gotten to the point where we were willing to take in new component model features. So the WASI subgroup in our last release came to a place where we not only adopted you know additions to WIT, which was minor bug fix.
But we also added two new component model features. And we we we basically adapted an entire process around that. And that let us add in maps. so like you probably like writing in just about any language, you would prefer to write a map instead of a list tuple string string for for b basically doing a lot of, you know, let's say you're trying to model a config map in Kubernetes. I'll keep bringing up the dirty word.
in that world I would I really want to map API. I don't want to have to generate the bindings of like a tuple thing. especially if I'm I'm in a language that supports it. but the
Oscar Spencer (29:25.705)
I mean I'm an O Camel developer, so it doesn't bother me, but I understand it bothers most people.
Joel Moses (29:27.809)
Ha ha
Bailey Hayes (29:29.452)
Okay, understandable. Well, now we have the ability to write a WIT API that uses maps. Is anybody taking advantage of it yet in WASIP3? Not yet, but as part of that proposal, I called out a few places that will evolve and probably will define their WIT APIs in terms of using maps. I have already started using maps in WASICloud, so I immediately started using that feature just right away. then the other one, which I think is particularly interesting,
Is implements. So I basically can have named imports and exports on my WIT APIs. And you know, the the top thing that we shouted from the Roost Tops about what this gives you is cool. And I guess I'll talk about that, but I have a better, cooler thing. But first thing that it gives you is the ability to have multiple different implementations of the same API. So I can have a backing implementation for a cache. If I name it cache and then I import
let's say WASI key value store, and then I name it something else, like my long durable storage. and then that'll that'll reach out to let's say you know S3 or something. Now that's cool. but one of the things that
Me being kind of a, I'm not gonna say I'm a Kubernetes person, but I'm definitely somebody that believes deeply in having declarative APIs. And not only that, but I go even crazier when you let me start designing WIT APIs for components. I want them to be declarative about the resources that they need to be able to start and run. So when I'm writing a WIT definition for what my component runs, I want to know all kinds of things about it. I want to know exactly what secrets do you need to be able to run.
I don't want to start you. I don't want to schedule you in an environment where I can't provide that secret. I don't want to get you running until you have a config. That is that is not a runtime failure. Yes, you should start and fail at your runtime. You should follow good coding practices for that, but that's not on you. That is on me, the operator, the scheduler, to get that right. And so with implements and with named imports and exports, I'm now able to basically say things like: hey, I want to import db password.
Bailey Hayes (31:36.454)
And I want that to be a single secret, a single value. And now my backing implementation, so all my stuff knows about WasmCloud secret. So so we know what that is, and we know how to plumb that through our system, which means I also know how to find, given that name, what the value is of that secret and if I actually have it or not. And so now I can do that declaratively, which really changes the game for what types of APIs I can build and design.
Oscar Spencer (32:04.794)
yeah. And definitely for implements, I know people have been asking for that forever. And so the fact that we have that now is a big freaking deal. But all right. I've got a potentially contentious question for you.
Bailey Hayes (32:19.956)
Love those.
Oscar Spencer (32:21.958)
Is there gonna be a WASI P four?
Bailey Hayes (32:25.685)
Can I curse? I don't know. no, no, there is there is not gonna be a P4. P4 is not necessary. We figured out how to make additive, non-breaking changes throughout all of WASI P2. And now also P3. We are adding new features that we need.
Joel Moses (32:26.935)
Ha ha ha.
Bailey Hayes (32:45.371)
Awesome ones like implements along the way, major ones like cooperative threading, which might even happen as early as October as part of our next release for O32. Hopefully you did not hear that here first, and you totally hear it from the person who's gonna be responsible doing that implementation soon. But I've run it, it worked fine for me, it's shippable, right? but essentially we are able to build up the body of features that we need on our road to 1.0 for the component model.
And once we think we're pretty darn close, we're gonna cut a release candidate and we're gonna just shave off a bunch of warts. We're gonna say, all right, well we we made additive APIs. So like I already had an API, let's say, that was called handler. And so I needed to add another API that said my better handler. And I I added my better handler, and now I need to delete the old not great handler later. We're not gonna delete that. We're gonna mark it, you know, we're gonna tell you it's deprecated, tell you to upgrade.
But we're not gonna remove it. We're not gonna make a breaking change until we're ready for that release candidate towards one dot
Oscar Spencer (33:49.993)
All right. You heard it here. I'm not gonna ask about a P4. All right. but okay. Last question I've got for you, Bailey. If you could slip in any wazzy interface you wanted, just you know, no l no standards process. It just happens to get in there, your own, you know, free will. what do you get in there before one dot
Joel Moses (33:55.18)
Ha ha.
Bailey Hayes (34:14.186)
I think I would bibbity bobbity boop optional import. w which is definitely a controversial opinion, because a lot of people see that one as post MVP. but if you're letting me slam in what I want and I don't have to worry about how hard it is to implement, then it would definitely be that one. Now in terms of wazzy APIs, I would probably say I want a web crypto one. I think that will expand out the the surface of what
Oscar Spencer (34:19.601)
Ooh, okay.
Joel Moses (34:21.389)
Interesting.
Bailey Hayes (34:42.08)
people want to be able to do immediately and extremely well. and it's hard, you know, a standardized API. We just need to adapt it to work really well within WebAssembly. and that should be straightforward. You know, y y'all had Mindy Berger a little while back and Mindy talked about one of his tools that he wrote for basically automatically being able to take a Web IDL and produce WIT that he's using for Web GPU.
Joel Moses (34:57.997)
That's right.
Bailey Hayes (35:07.968)
That's a bibbity bobbity boop right there for being able to generate this web crypto WASI API.
Joel Moses (35:09.975)
Yeah.
Joel Moses (35:13.527)
That's pretty cool.
Oscar Spencer (35:13.574)
Well, okay. All right. So okay, we y you want web crypto. we just got some wide arithmetic in in Core Wasm. Isn't that isn't that good enough for you? Are you you need actual crypto APIs?
Bailey Hayes (35:22.603)
Ha ha
Bailey Hayes (35:28.424)
Yeah, I want I want hardware enabled crypto. Give me the speed.
Joel Moses (35:32.621)
There we go. There we go. Oscar's granting it. Isn't that fantastic? Yeah. I'm I'm just kind of stuck on the 1.0 release being the wart shaving release, but maybe that maybe I read too much into that. I I hate to do this, but that does wrap up our conversation today. Thank you to Oscar and Bailey. You know, for decades in computing building distributed systems across different languages felt like building a global rail network where every comp a country used different size tracks.
Oscar Spencer (35:33.746)
All right, fine, you can have it.
Bailey Hayes (35:38.732)
Thanks, Oscar. I appreciate it.
Joel Moses (36:01.879)
Forcing it to stop at every single border, unpack the entire cargo train into heavy containers and reload it onto a new train just to keep moving. WASI Preview 3 finally unifies the tracks for distributed computing. It gives us a universal high speed rail system where data streams seamlessly cross language boundaries at near native speed without the container toll booth.
To learn more about the ongoing work with with P3, check out the open source specifications on the Bytecode Alliance GitHub. And for myself, Oscar and Bailey, thank you for joining us. Be sure to hit like and subscribe for future WebAssembly news and views. As always, it's a big application world out there. It's time to embrace the power and promise of WebAssembly. Take care.