Transcript: New People Pages, Multi-Backend Named Interfaces, and WASI Preview 3 on main
wasmCloud Weekly Community Call — Wed, Jun 24, 2026 · 16 minutes
Transcript
Bailey Hayes 0:09
Hello, and welcome to the wasmCloud Community Call for June 24. We've got a couple of little brief updates today. I think this one might be a little bit of a shorter one, but if anybody has any questions, or anything they want to bring up, or agenda items to add, or announcements — please, please do. And let's get started.
So, first up, we're going to check out the quick start update that Eric put in, and also talk through the new people pages. I'll give everybody a status update on what's happening on main, which is a lot, and that's basically it for now. So, Eric.
Eric Gregory 0:46
All right, I'm going to replace the share there, and we've got two separate pieces to talk about.
So the first: we've been making some ongoing efforts to improve discoverability across the wasmCloud documentation site, and that is creating people pages for our maintainers who are involved in either writing blogs or contributing to these exact community calls. So these are live now, and you can see an example for Bailey here. This is scoped pretty much exactly as I just said — to active maintainers who have either participated in a community call or who have written a blog post — and you'll kind of see how that emerges in a moment. But these pages give social information, links to blog posts, and links to community calls where that person has been involved, along with other things around the web that are relevant in the WebAssembly ecosystem. So you can see we've got pages for everyone who meets that criteria that we talked about.
These pages are linked either from the author byline on a blog, or — if we go to our community call summary pages, where we see speakers listed over here on the side, or in the transcripts — you can click on those and follow to the maintainer's page. So if you have any thoughts on these pages in general, or your page, or things — if you're an active maintainer who's been involved here, you can reach out on the wasmCloud Slack and let us know if you have any comments or feedback.
The other piece I want to highlight that's gone up in the last week: we've had a couple of instances where we've hit minor or kind of significant regressions in the quick start — the flow from creating a simple HTTP component to one that has added persistent storage. So in the process of trying to build resilience against that, we realized we were kind of missing an in-state example — an example that has the persistent storage implemented in the exact way that you do in the course of the quick start. So we went ahead and put that up in the wasmCloud examples repo.
What that allows us to do is, A, readers and users can refer to this as an example of what they should be winding up at — that's really useful — but B, we can test against this, and that can help us to make sure we catch if something is going to throw the quick start out of whack. So if you're running through the quick start, or if you're pointing someone to it — hey, here's the end-state reference that people can use. And if you're a little more involved in documentation maintenance, that's another piece to keep in mind. Any thoughts or questions on either of those updates?
Bailey Hayes 3:59
Great, Eric. So, did the wasmCloud docs page get updated to point at that? Cool, nice. All right. Well, yeah, I don't see any questions in the chat, so we'll go on to what's happening on main.
And are there exciting things? Absolutely. So the big thing that we've landed now on main is actually building with Wasmtime 46, which has the latest 0.3.0 WASI APIs with WASI P3 enabled by default. So you don't have to turn on a feature flag to get P3 — in fact, there's no feature flag to turn on P3, you just get it as part of wasmCloud if you bring it in.
Additionally, we've also built in a new feature flag for the new implements feature. So on main right now, basically if you go and do — let's see — if you're using the Wasm component model implements, we just mirrored that existing flag that Wasmtime surfaces for this proposal. And this is what we're actively building on right now.
Let me show you one more PR that builds on top of it, that allows us to basically have multiple backends for a single named interface. So in this example that I have in here, basically I can have a guest component that says, "I want to talk to both Redis and NATS as my key-value store." And so when it imports it, it will basically say — as part of its bindings — give me something that is both... not that one, I've got a more interesting one. Yeah, here — this one. As you can see, it has basically two different bindings that are named Team A and Team B in this scenario, and it's able to thread through statically as part of the bindings that are generated for both the component and on the host side.
And so on the host side, where we handle it, you'll see new types of multiplexed plugins. Those multiplexed plugins, in this scenario, are kind of the core of multiplexing for the key-value interface. They are able to say, okay, if somebody said "I have host interfaces and they have these specific names," and I'm configured to know exactly what the type of backend is that you want me to use — so it's keyed by the name of it. So NATS is NATS, Redis is Redis, that type of thing.
We'll need to add extensive documentation around a lot of this, but these are the bones of that feature, and it will allow you to do this for every single type of host plugin that we have. So this one I'm expecting to land soon, and it's specifically just for key-value, just so that I exercise one as part of this PR threaded all the way through. And then we're going to do it for blob store, for Postgres — essentially for all the plugins that need implements backing. So that one is in the works right now, and I'm expecting it to be part of the release next Tuesday, I think.
The other big thing — since I just saw Aditya join, hi — is to talk a little bit about your change that you have here. We briefly called this out, I think, last week as well, but I'm also expecting us to build on top of this. Now that P3 is part of our main, we're building on top of those types and making sure that it's ergonomic for you when we're doing the linking between components that are inside a workload — that they're able to talk to each other using P3 types like streams, futures, and being able to also pass around the handle for a resource. Any more I should add there, Aditya?
Aditya Salunkhe 8:22
Nothing much. I think we've covered it a lot these past meetings, and it's all I've mentioned it quite well. I think I've covered most of it in the description, so yeah, nothing much to add.
Bailey Hayes 8:42
Cool. And so this is specifically for component-to-component inside the same workload. I am working on components in the same workload with service — kind of a similar idea. So we have some overlap. I think you and I are going to have a fun time melding those, but I think that's going to be a really nice feature add.
The next thing I'm going to call out — so those are a lot of our big pieces. We land that, we land implements, host components builds on top of implements. Now I have that locally kind of flushed all the way out, and so I'm aiming to get to that the moment we're happy with where implements is at. And actually, let me show you a little diagram on how that's going to look. It's a lot like what you're doing, Aditya, on your PR, but essentially the host component architecture — we will basically have different workload stores for each component per workload, and then we need to basically have sort of a bridge for spawning these concurrent tasks. We'll have that kind of like manage all of that and thread everything through. And essentially, if we have a host component, it needs to be able to handle all of these separate tasks that are coming into it from the workload components.
A lot of this is going to be very much shared infrastructure between what Aditya is changing, what I'm adding between workload components and services. And in a lot of ways the host component is just a specialization of the service that's for all workloads on the host. So I'm excited about a lot of that.
If you look at our project board, you'll see that that is most of it — we're almost there. These remain blocked. This one right now is blocked for two reasons: one is that we're patching in implements on top of Wasmtime 46 with a patch that's already been merged to main for Wasmtime — but rather than wait another month for Wasmtime 47 to come out, we're able to go ahead and start depending and building on top of it. This one requires some pretty intense tricks, and I think I want to detail my changes on the P3 concurrency before we barge that problem, so we're holding on that one. This one is waiting on host components, which is in progress. Multiple backends, obviously with the implements PR, is — I would say — 70% there, and the remaining 30% is going to be largely mechanical and easy. The hard one is the PR that's up right now; that's the core of it. And so once we have those, these other ones are much more straightforward.
This one builds on top of that example, and also I put in a PR for SQLx. Actually — anybody knows anybody that works on SQLx, they'll know, hey, I've got some stuff that's hanging out over here. Their main branch has been broken for a while, and so I put up a PR to get it fixed for them here, but my change basically can't merge until they fix main. But it just works. My PR here is just so that basically humans or LLMs, when they want to write code that uses SQLx, know how to do it. So this is just an example, no modifications to SQLx required, and it shows them exactly how do you do both MySQL or Postgres — and it actually has even connection pooling enabled now too. So I got that trick working. I've done this before, but just so you know, this exists. So if you're having trouble getting something working, know that you can point your LLM over here at this example, and it'll roll. But I'm also going to build this over on the wasmCloud side, so that we're not blocked by waiting on this to merge upstream.
And so with that, we have a lot of our roadmap complete. I do expect some things to bleed over, but that's okay. If we go over to our discussions, you'll see that right before this call I just tossed this up. Aditya, everybody, feel free to add to this.
Bailey Hayes 13:35
I hustled it in so that we could call it out in the community call, so that people have fair warning and full notice that we're going to plan on doing our roadmap session July 8. So if you've got big-ticket items — big rocks that we need to consider and plan for for our wasmCloud releases over the next quarter — feel free to add comments here or file issues and describe what you're looking to build. I tossed in some of the things that are top of mind for me, but I think there's a lot more that I would add here. So I'll probably keep expanding that bulleted list as we lead up to July 8, but yeah, I think that's probably the next big thing.
Next week is a holiday week, right? Hang on one second, let me double check. It's the Fourth next week, right? Yes, it is. Okay. So I'm expecting a lot of people to be on vacation, that kind of thing. So that's why, even though next week is the end of the quarter, we're going to be doing it the week after, to avoid the holiday week.
Questions, thoughts, obvious things that I totally forgot to include on this that I should go ahead and get in so I won't be embarrassed? Well, hit me up on Slack and we'll work it out. And I think there's more things that we can keep adding, and there's certainly a lot of big rocks, so to speak, that I think should be on here. Like, I didn't include distributed cache for WebAssembly compilation and caching cwasm, for example — having a mechanism around that. That was a larger T-shirt-size feature that we didn't scope for this quarter, but I think it's something that we should scope for next quarter.
Aditya Salunkhe 15:34
I would just say the pre-compiled stuff — it's really cool if you had that.
Bailey Hayes 15:41
Yeah, I think everybody wants it, right? It's just tricky, right? Because we've designed this thing very much so that it's your toolbox — we give you the picks and shovels to build what you need. We don't want to be too early-opinionated about the infrastructure, because it's our superpower that we can literally run anywhere from edge to cloud. So, how do you do that, and the right way, with the right abstractions? So yeah, that'll be fun to build out.
All right. Well, any other topics, announcements, anything for anybody else? Okay. There's a quick one. Thank you, everybody. Have a good rest of your day.