Transcript: The wasmCloud Q3 Roadmap — Build Stuff, Agentic AI, and Platform Engineering

← Back to watch page

wasmCloud Weekly Community Call — Wed, Jul 8, 2026 · 63 minutes

---

Transcript​

Bailey Hayes 0:20

So hey, welcome everybody to the wasmCloud Community Call for July 8. Today we're planning on going through roadmap planning. We haven't gone and created GitHub issues for everything we plan to put on the roadmap — first, we want to solicit community feedback and talk about prioritization of the different things that we're going to work on. And to start, I'd like to go and show what we did for our past roadmap session. So I'm going to share my screen real quick and walk you through that. Pulling that one up — can folks see that? Okay, and it's not showing other windows and stuff. I've got my Zoom overlay; I'm only on one monitor here.

All right. So for Q2 we had one major, big, big feature that we wanted to work on, and that was WASI P3 — and guess what? WASI P3 shipped, and in the most recent release of wasmCloud, P3 is enabled by default. Now, it pushed back a few things that were dependent on it, although those have been actively rolling out over the last couple of weeks. The big ones are in this bucket here, where it's the implements feature. There was one more addition to the implements feature, called external ID, that Alex has already landed inside wasm-tools, and so as we update dependencies we'll get that as well — and we think that's basically completion of that feature. The way that we're using that inside wasmCloud is that essentially you can name the host interface that you want to use, and that will allow you to have multiple different backends for the different imports that you have of a host interface. So you can now have Redis and NATS serve as your key-value store, and you can swap between those different backends and configure that from your workload deployment.

Another thing that we said we were going to do that we got done is our SQLx example REST component. That one I actually pushed all the way up to LaunchBadge SQLx. It ended up not getting landed there, but I created this one because it was more than just creating the example — it's actually making it work all the way through the ecosystem. And we got there because we landed mio, Tokio, and socket2 changes within the Rust ecosystem. So if you just take SQLx from Rust, you can build a Wasm component out of the box without changes to that dependency, which is pretty powerful, and a lot of people are using it, so I'm happy about that.

One that we didn't get to — that I'm going to Command-C here — is building out more things around cron, so I think we might pull that one over. We nailed this one. We've done a huge amount of iteration over the last quarter on this, and a ton of hardening on our CI pipelines. In terms of integration of things, Jeremy's done a huge job there. We've also done a ton of work in the OTel space. So so far I'm really happy with this, with the exception that we didn't finish k6 benchmarking — but we do have benchmarking infrastructure in place. We've got a box; it's triggered on every release build. It's been running really smoothly for a really long time — long time being about a month and a half now — so we've gotten some good data. We have really good micro benchmarks that I've been using a ton for all the things I've been landing, like host components and services, and the stuff that Aditya has been doing. That was my direct need. But basically this is all in place, so it would be very straightforward for us to drop in k6 on top of that; a lot of that work has actually been completed.

Now, last time a lot of people asked about agentic AI and MCP.

Bailey Hayes 4:48

I think we should bring this forward into our Q3. We didn't prioritize it this quarter, but I think that's probably one of the top-of-the-line features. I think we've done a good job building out different types of templates and services and examples. There's more to do here, though — there always is.

Let's see, what else did folks want? They wanted to see some more connection pooling examples; we've got some of those in flight. Folks do want to see more Go. There's been a lot of work on componentize Go, and I actually just saw a new PR come over the line in the component model book for documenting and making a really good walkthrough on how to use componentize Go. So that ecosystem is moving forward really well. We've got a new Postgres API out there as well. So for the most part, we did a really great job of hitting what we had on our roadmap — and there was significantly more that we added.

So let me jump over to the actual official roadmap, which is our project board over here. Right after this, once we finish soliciting kind of where we're at, I'm going to update this for the next quarter. But essentially, I called out that we're not totally done here. I have this in flight, and I'm very hopeful that we'll end this by the end of the week. This one I'll close out once we thread external ID all the way through — talked about that already. So most of these will be wrapped up — not this one, but the other two will be wrapped up by the end of the week. We've made progress on wasmCloud Secrets, so honestly I think this one is still accurate; that is ready for work. And I've got this one that actually will be — I actually have an example of that locally, so I should go ahead and push that one up. So overall we did a really good job of closing a ton of stuff. Some of it's going to bleed over. That's okay, that's always expected. If you do everything on your roadmap, did you really set aggressive goals? So I'm happy where we landed.

Now, I've created another board similar to what we had before; I dropped this in the chat. If somebody else could drop the link one more time in the chat, that would be very much appreciated for anybody that's just joined. But essentially, what we're going to be planning towards is: what can we get done by October 1? And just remember the rule — aggressive goals — so it's okay if we don't get everything done. But if it's already not plausible now, imagine what it's going to be like in August; we probably won't be able to get it done. So let's not say we're going to rewrite the whole world — but, you know, we're only revolutionizing how we do computing today, so still be aggressive with what we throw out.

So one I just copied over is a more configurable cron job. I'm going to put this over kind of in this category. I already jammed with a couple of people on a couple of ideas, so we've already populated this board with some things, but what I'm going to do is encourage everybody to join me and add in some more stuff, and then we can talk through prioritizing and what we think is the most important as a community.

But I'm going to start with probably what I think should be potentially our number one theme, which is just: build stuff. If you build stuff on top of wasmCloud — whether it's a whole product, or an example, or a thing that you built inside your enterprise — we want to know about it. We want to highlight it. We want to do user stories, we want to do blog posts, we want to show people actually building cool and useful things on top of wasmCloud. Our past quarter, obviously our number one thing was getting WASI P3 out. We did it. So what can we do with it now? That is absolutely our number one theme.

Bailey Hayes 8:48

And last week we got some pretty cool demos from Bharat and others building with P3. That's what I'm talking about — I want us to build stuff. This will be another cool kind of stuff that we could build, but there's a lot in this category, and I've got a few others that sort of fold under this.

Part of that is that I'd like to propose what was suggested in the last roadmap session, which is bringing in a little bit more of the agentic type compute, agentic type workflows — maybe spending time as a community coming up with a wasmCloud LLM inference API that we can start building some things around.

Another aspect here is that I think if we get really good WebGPU integration, we can do some really cool stuff in the WebAssembly space. And Mendy's been spending time on this already, so I figure we might as well include it as part of our roadmap: getting async APIs for WebGPU. WebGPU itself is actually an async API, so what I really should say is WASI WebGPU here — that's what he's building out.

A couple of other themes, and once I finish introducing the themes I'm going to invite everybody to come in and jam in here with me. So thinking about agentic LLM provider kind of work — that's one category. Another one is thinking through long-running compute, and so the epoch interruption that Aditya has been proposing and working on is one category. For me, the ones that I'm working on are host components and services having their own lifetime and their own store. These two are actively in flight, so I feel like I have to put them in the roadmap because they're obviously on the roadmap. So these three are rolling right now.

Something that I kind of have a question for the community on is: do folks have a need for using multiple services in their workloads? Is that a feature that we need to prioritize this quarter? I really would like to hear more about that use case. We want to see more GPU metrics — I'm going to go ahead and put that one down there. And one more thing that I wasn't sure where to put necessarily, but is obviously a very top priority for us now to complete from our last roadmap, is benchmarking with k6. So that one's definitely still here and still really important to us.

Another category I want to introduce is just general DevX. Bharat actually asked on the discussion — I'm sorry I didn't get a chance to respond, I've been out of office a bit — but essentially I called out a bunch of other things and I didn't call out Rust directly. Rust is — you know how when you have a problem child, that's the only one you ever talk about? So I'm always talking about Python, but I'm not talking about Rust, because it's always well behaved. In terms of the wasmCloud roadmap, I think there are definitely some things that we can do to continue making the Rust experience the best possible experience it can be. The main thing that comes to mind for me is that Yash is working on a P3 edition of wstd, and so once that rolls out I think we should do a pass through our Rust examples and templates and build on top of that. Obviously, once we get a Rust edition with the latest WASI SDK, which is within the month, we will then go and update everything to that latest version. But I didn't have in my mind other big blocks, at least for the wasmCloud roadmap, of what we needed to do there. If folks think of things that they want to see, let me know. SQLx and WASI sockets was the big thing in the last quarter that we did pave a way for. But I'm sure there's other stuff — I'm sure Colin's going to say something about time zones or crypto... cryptography.

Colin Murphy 13:05

No, it's cryptography.

Bailey Hayes 13:06

Yeah, people get—

Colin Murphy 13:07

Yeah, I learned that many years ago: don't say crypto, say cryptography.

Bailey Hayes 13:13

Okay, cryptography. You're right, you're right. But if there are other things, drop them near that.

I kind of thought through in my book, at least in the order of priority that I'm seeing from what people ask of us in Slack and in other forums. Generally, it seems like Python is people's number one, and if it's not Python, it's Go. JavaScript, TypeScript — we have a good SDK, things work. I know that there are definitely rough edges, and there's definitely work happening upstream that we'll just get as it rolls out, which will be nice to have, and we'll fold that in as a community. But in terms of actual roadmap items, I think it's more of a maintenance position for us.

I want us to add a C++ SDK. I actually like C++, but sometimes I'm crazy. And also maybe a C SDK as well would be really nice to have. But a lot of that work also needs to happen upstream in wit-bindgen and in the Bytecode Alliance before it comes to us, so I put that as a little bit of a lower priority for us.

Otherwise, I've got a handful of other things that I can talk through, but big categories I'm just going to throw out: this, this, maybe some long-running compute work. Obviously benchmarking is its own category, but I actually think that's now a small T-shirt size, whereas last quarter it was a large or extra-large T-shirt size. So that's pretty much done. Another one I threw in here that's kind of in the DevX zone is some reference architectures, or example apps, or frameworks exported to Wasm — a lot of things maybe in that domain. I'm interested in anybody's favorite pet project that they really want to see done.

And one last thing before I set you loose: I wanted to highlight that with a lot of the things that we build on wasmCloud, we're always aligned with upstream standards. The release train for WASI essentially looks like 0.3.1 coming out August 4. Right now I'm hoping to see maps be brought in so we can use that WIT type inside our WIT definitions — that might be useful to know and build around, especially for some of the proposed interfaces we were talking about on this roadmap. implements, obviously, is what we're building around, and so once that stabilizes August 4, it'll be about just ungating that feature flag in wasmCloud. Another one that is largely just complete in the upstream ecosystem, with different implementations, is fixed-length lists.

Otherwise, I think the only other one that's really important to us as a community right now is probably the cooperative threads work. That's actually rolling out pretty well right now in the upstream. I have it in this slide as a perhaps more pessimistic date of December 8, but I'm not necessarily saying it couldn't make October 6. But I think right now it probably looks something like this. And so, given that, I wasn't necessarily going to include that in this quarter's planning, but we certainly can build behind flags for all of these things that just won't be released by then.

Colin Murphy 16:52

Callbacks on there too, right? At some point.

Bailey Hayes 16:54

It's a lot of people's favorite. Yeah, the reason why I didn't put it on this slide is that I haven't seen the code — I haven't seen anybody code it yet. Whereas cooperative threads, we actually have in a WASI SDK right now. But that's just how long it's going to take to get two different languages building with cooperative threads, and it fully threaded between Wasmtime, a second reference implementation, and wasm-tools and the 20 or so crates that float about our ecosystem. It just takes time for those types of things. I think callbacks — maybe this December, maybe.

Colin Murphy 17:35

Maybe we add another one. I don't know, but I'm just—

Bailey Hayes 17:38

Callbacks is super important because it's what the browsers are asking for, and we want them to build on the component model really bad. So that definitely bumps up the priority in terms of component model and WASI work. But in terms of our stuff, I think the place where we would be putting work is definitely here, where we would be dependent on that feature. I think we can give a really nice experience, but we would put it behind a feature flag, basically here, because of that.

Any questions, folks? I know I didn't cover this in much detail. I can do that, but first I wanted to get more feedback from other people before I just keep talking. Bharat, yeah.

Bharat 18:28

As you said in the building-stuff category — I'm building some demo here, like I demoed in the last call. And I'm trying to build a kind of full-stack app in the WASI P3 stack. So considering the priority of the SDKs, like Go — is Rust a good option to take the full-stack app? What are your thoughts?

Bailey Hayes 19:06

Yeah. What I'm seeing as I talk to people is that with LLMs, languages are really starting to matter a whole lot less — or rather, people don't care about their language, they care about the outcomes that they get from their language. So now people are more interested in what's fastest, what's the most efficient thing that I can build and target for, what's the safest. And across the board, obviously right now that's Rust; that's leading the way in just about every dimension.

There are a lot of people that do have a ton of incumbent software, whether it's all written in Go or all written in even Java. There are definitely still a lot of folks that are like, "Listen, I really need it in my language." But I would also say that the current tide seems to be that a lot more people are very, very interested in Rust. So while I neglected it because it's not one of my problem children languages, Rust is definitely, I think, our tier one. If we're trying to decide what example to build and we don't have an example of it in Rust, we should build Rust first.

Bharat 20:27

Yeah, sure thing. And apart from that — when I try to integrate the UI part with the wstd async library, which currently supports WASI P2, I guess.

Bailey Hayes 20:47

One second, let me show you something. So basically, Yash sent this to me yesterday. This is what he's been working on: this is the first PR of two, and he's going to add P3 in the next week, basically. And once we have that, then we'll go and update everything to the latest wstd with P3.

Bharat 21:11

Great news, actually. I was also trying that thing.

Bailey Hayes 21:24

Did you mean to get muted there?

Bharat 21:28

Oh, sorry. So I have one question. We have one example in the examples section, a template where we have an HTTP API with a distributed architecture. And in that we use the wstd macro for the HTTP server. So does using that macro make that component a service component by default?

Bailey Hayes 22:04

No, the macro doesn't turn it into a service. The macro basically changes its exported handler to use the HTTP handler export, and right now it's P2 only. Now, one of the cool things about wstd is that the way that it's written, when we get an update to P3 it will actually be transparent, in that in theory this existing code won't have to change except for an update to the Cargo dependency, and so it'll go from the P2 HTTP handler to the P3 HTTP handler. But it's not wstd that makes you a service — it's actually in the wash config for that example.

Let's go to that real quick. This one here, this one, right? Or is it the distributed one? I think this one's probably the best. So that's its top level. Actually, I think you're talking about a template, right? Yeah, okay, this one. So inside here, this one is one of the components in the workload. So it's itself not a wasmCloud service, but it is what gives it the HTTP handler on it. And then these two components actually are just components that serve over the wasmCloud messaging API. So if we go into the task component, I think we'll see — it doesn't have a ton of code here, but basically this is its main export for when it receives a message. So what this one is mainly trying to show is that you can have two components with the same export, and you can have one component that acts as the router between the two.

Bharat 24:19

Okay, yeah, got it. I was working with the UI, but I don't have any working demo right now, so I keep building on that. The idea is to build the full-stack application completely with the last demo, and adding also the agentic capabilities like summarization — the transcription generated by the one component, and using the other LLM to summarize that output. So that's in progress. I'll update you guys once it does.

Bailey Hayes 25:03

Thank you. So we'll just consider that as part of our wasmCloud roadmap. In terms of things that go in the build-stuff category, I think this is one that we'll want to flesh out wasmCloud Contrib with, for example. And Victor and I were actually talking before this call that there's probably a lot more things that we want to populate this with, including actix — or insert your favorite framework of choice — working as a component workload. So these all definitely very much go together. So thank you, thank you for working on that.

Bharat 25:44

Yeah, sure.

Jeremy Fleitz 25:45

And just really quick, calling out — Bharat, Aditya dropped a link to our service TCP template inside wasmCloud, which does have an example pretty close to what you're talking about, where there's an HTTP front end going back to a service.

Bharat 26:01

Yes, thank you. I'll check that.

Bailey Hayes 26:04

And this is what makes it know that it's a service, basically here.

All right. So we're 30 minutes in, and I've done too much talking. So let me pass the mic to you.

Aditya Salunkhe 26:24

Hey guys, I was wondering about the multiple services thing that you discussed, and I think there is a good deal of use case for that. For instance, what if you want your service to start with wasi:cli/run automatically, but also have an export — instead of being either/or, just having both as the initializers? That would be awesome.

Bailey Hayes 26:57

I'm glad you like that, because that is what I did here. It's in here. I call them reactors, because that's what they are — although it's a little silly, because all components are reactors. But I am going to try to break this down a little bit, because that's too many lines. And actually, I have another PR that I'm going to put up soon that's built on top of this that includes the host component work. But yeah, hashtag soon.

But I still kind of see this one as a little bit different than what I was talking about here. So you can solve this as a component that you compose together, right? Right now, with my PR, this use case works — you get one service that can do it. And the workaround that we would tell people is: let's say I've got my GitHub API handler, something like that, right? He does GitHub things, and this one does HTTP API gateway things, we'll say. And you've got two of these things, and you kind of wanted them to be long-running and to be stateful and to service the whole workload, and a lot of the things in the workload depend on this, and these two are kind of long-lived. Well, the answer that we would tell people today is to just — all right, I'm going to do a really sad plus sign, don't judge — to do a composition of these, and then you would get one component, and then you would still have just the one service in your workload. And what's nice about that is that we have one entry point into the whole workload, and we can just, from wasmCloud, know that that's there. And the combination of this would be an export on HTTP and an export on some GitHub API, and the whole thing would also have an export for wasi:cli/run, let's say, so that it can have a long-running loop. So you can do this with my PR — I can't say today, but with my PR you could do this.

But my question is if people would rather, or if they have real use cases where they would want this instead, and if we need to support that now in this quarter, or if we can keep pushing that one off. We could not do it with P2, but it is actually something that we could do now with P3 and all the work that we've been putting in there.

Aditya Salunkhe 29:58

Yeah, I'm a bit intrigued by how you would actually implement this, because which export are you targeting? And are you just going to — I mean, it's a—

Bailey Hayes 30:09

It's hard, yeah. Because if they both have this, what do you do?

Bailey Hayes 30:15

I don't know. I think the answer is you don't get that — you have to be like this, basically, and then at that point that changes how it has to work, and maybe that's not what we want. So here's an example of a feature that I could add and probably shouldn't add, unless folks really have a good motivation for it. This is my answer today, I guess.

Aditya Salunkhe 30:41

So with your reactors, you basically need to compose it always, and when you compose stuff, you basically wrap that with a single export.

Bailey Hayes 30:55

Well, you technically wouldn't have to do composition if, let's say, all you had was just this, right?

Aditya Salunkhe 31:06

Yeah. But I mean, if you had, say, two services—

Bailey Hayes 31:10

Yeah, yeah. Today you would have to compose it, and part of that composition would also be, where does this get wired to on the components that get composed?

Aditya Salunkhe 31:21

Yeah. Well, this is quite interesting, but yeah, I'm looking forward to the reactor stuff. And I mean, it's cool if you don't have the whole separate services both at the same time.

Bailey Hayes 31:42

Well, I'm going to leave that there in case other people have things that they need for that one.

I guess one last little bit that I did throw on here that folks might be interested in is if we should start building towards exploded components inside our OCI ref. One powerful thing that you can do with WebAssembly components is that they're basically a tree, and we know how to refer to each of these. If you're referring to them from, let's say, the registry, we know exactly what the version is of that individual component. And let's say we have 100 different components that are running on our host — there's some pretty nice things that we can do. Like, if we have a component per OCI layer, OCI will just dedupe this for us, and so we wouldn't have to every single time download something like CPython.

So this scenario is an example of a Python component where they have their own code, like their Python code. Maybe they've pulled in a shared library; maybe they've got a native dependency that's also a WebAssembly component — and each of these are loaded in separate OCI layers. And so that feature inside the component model we call exploded components. Today, what this actually looks like is just one box, just one .wasm. We download the whole thing, and that's in one layer. But something that we could spend time on is building this out.

So I threw that on here as something else that might be worth exploring in this quarter. There are a couple of reasons why I think it would be interesting, largely because it's in prep for, I think, these two languages, and maybe others like JavaScript as well, where basically if support for the language looks like compiling the interpreter or compiling the runtime into WebAssembly, then let's find ways to kind of dedupe that — both from the aspect of distributing it via OCI and downloading it, but also from the aspect of what we load on the host. So that's something else I threw out there, although I'm not sure — unless folks really want to see it and prioritize it, it might not make this roadmap. It might be the next one after this.

Okay, all right. I want to give everybody, let's say, five minutes. If you don't already have a link to this, I'm going to drop it in the chat one more time — drop in here and let me know some of your other ideas for what you'd like to see on the wasmCloud roadmap. Probably the most important thing would be, "If you do this, my company will run with wasmCloud." That's going to raise up in our priority queue pretty high. But if there are other things like, "I've always wanted to do this, and there's this rough edge that's been keeping me from doing it and getting my thing done," we want to know those too, and then we'll go through and talk through some of the boxes that you added and anything else that we want to discuss. So I'm going to be quiet for five minutes, and I would like folks to jump in and add things to this roadmap if you don't see the thing that you were expecting to see here for what we would get done this quarter. Now's your chance to put cryptography down, Colin, if you want it.

Colin Murphy 35:40

Sorry, I was muted. Yeah, it's actually — I don't really need it. I work with the Rust crypto crates, and they've been working fine for a year, so I don't want to put something on there that's not something I'm going to use.

Bailey Hayes 35:58

Nice. Yeah, I also want to throw out that I got rustls compiling in with the SQLx demo, which made me happy.

Colin Murphy 36:06

I mean, I really think we need a strategy for reqwest. That might involve somebody becoming very good friends with the maintainer, or something. I don't know. I guess, or maybe just continue doing wstd or something. But we are just at a point where it's just fundamentally different from the philosophy of WASI and the component model, and I don't know.

Bailey Hayes 36:29

I do know that that maintainer accepts donations for their roadmap, so it is possible for an enterprise to pay that maintainer to care. But otherwise, I don't think friendship's enough in this land of open source. But yeah, I'm definitely pushing for the wstd stuff for us right now in the immediate term.

Colin Murphy 37:01

Yeah. It's just such a pain to have a separate WASI setup and all your code. Although it's not like it's unheard of. I mean, right now I'm doing tons of C++ with Emscripten and, you know, macro or whatever — not macro, whatever, I forget the term. That shows you how good of a C++ person I am. I basically can't remember basic words. I'm just a terrible C++ person. Anyway. But yeah, it's not like it's unheard of in WebAssembly to have big giant chunks of code where you target WebAssembly. But it would be nice not to have to.

Bailey Hayes 37:57

Yeah, I think the C++ SDK stuff — we need to get wit-bindgen-cpp to do the async bindings upstreamed, and then probably I'll go and update the sample C++ for P3, and then at that point I think we can add our own C++ SDK, and life will get better.

Yordis Prieto 38:21

Do you have a link to it, Bailey? I can help. Not that I finished the maps stuff, because I'm trying to finish the C# runtime loop, but hey, I already—

Bailey Hayes 38:33

I slotted it. I put it on a slide, which basically means your stuff's done. I don't know if you know that.

Yordis Prieto 38:41

The what?

Bailey Hayes 38:43

My — what did I do? I gave this presentation like two weeks ago, Yordis, and this was about the process for WASI to adopt component model features. And I was like, yeah, I think maps is ready, so that's going to be in the first WASI release. Obviously, right, Yordis?

Yordis Prieto 39:04

Hell yeah. But I'm confused about something, because I'm still learning. There is something about the C# runtime that I need to finish. What the f*** does that mean? Like, I don't know what that means. Like, Wasmtime by C#? I don't — I'm getting lost. I'm just letting the AI teach me. Like, okay, go ahead and finish this. All right, good.

Bailey Hayes 39:25

I think you should ping Scott and say, "Hey, Scott, this is one of the last things that doesn't have map support. Can you land it?" That's what I recommend there, because every time I try to do it, I get lost too. And so what they're talking about is there's a .NET runtime, and it's got two different backends, and I think the one that you want to use is the AOT backend, but that's not the default, and so getting set up to use it — the way that you've got to do that is a little tricky. But let me just show you that. And I notice C# is one of my problem children that I did not include on the wasmCloud roadmap for this quarter, but if the people want it, we could talk about it. This — yeah, componentize-dotnet. Are you familiar with this, Yordis?

Yordis Prieto 40:19

No, I'm three — I'm like 343 or four repositories deep of link-finding. I'm in the wasm-component-ld, I think it is, the linker thing. And now it's like, no, no, you don't need to do anything there. Like, now there is another repo in the .NET org that they use branches inside the same repo, and between different branches there's technically the codebase, and like, dude, I'm so lost. Like, okay, I need Pepe brain right now: one step at a time, what do I do?

Bailey Hayes 40:54

Yeah, well, .NET's a special place, but I think all the repos and all the things — there's an XML file in here somewhere that combines them all together and gets the branches correct. So this is the only way I've found to actually get me an environment that will build all the way out with C# and .NET. But I'm also going to say that I don't think getting that done is a requirement for us. And I can't say this definitively, because the WASI subgroup has to vote on it, but I would say that it's very unlikely that having it in every single language under the sun is a requirement to be able to launch it. You've already got it in multiple different languages, which for me I think is very, very sufficient.

Yordis Prieto 41:46

I just want the wit-bindgen repo to be full — like, that's my goal. The official one: whatever is there, I need to finish it. So that's what I'm trying to do. But going back to the stream and stuff — if you have an issue, whatever, send it to me in a Slack and maybe I can just take ownership and try to add the types to the bindgen and stuff.

Bailey Hayes 42:15

Sweet, that would be awesome. Yeah, I think for the C++ stuff, we're kind of blocked on a design decision, which is very much just: what's the common denominator version of C++ we can depend on? If we can actually depend on coroutines, we can have nice things. But in C++, sometimes people just don't like nice things, and we've got to do things in the old way. So that's where we're blocked at right now.

Yordis Prieto 42:38

Well, never mind that then.

Bailey Hayes 42:40

I don't think you want to join that fray.

Yordis Prieto 42:48

Last time I had to tell them, C++ is like — just tell me what you want. I'll just get it to work.

Bailey Hayes 42:54

Yeah. Well, I see we got a few things added, so let's talk through those. This one I didn't talk through earlier. Jeremy, do you mind talking about your idea that you threw on here?

Jeremy Fleitz 43:07

Sure. So, really on this section right here for language adoption — now that we have P3, I feel like we're going to start seeing a lot more languages getting more mature with WebAssembly compiling, obviously especially like Go proper and Python. So similar to how we had "are we fast yet," you know, it's like "are we polyglot yet," and just really keeping track of which languages compile, and we have tested every single time we have a CI/CD build to make sure everything is working as expected. That way, when people are using that language, they have a nice feeling of, okay, wasmCloud 2.6-point-whatever came out, and I feel good that my application is still going to work.

The other two are really around streaming. Since we're focusing on providing streaming capabilities inside WebAssembly, really just creating demos around that, examples, and even places for people to start with if they want to make a streaming type of application. And then finally the wash new, wash build. That just goes back to the polyglot side, so I can do a wash new and have a Python-style template that's ready to go. Same with the wash build command.

Bailey Hayes 44:37

Thank you. Any questions for Jeremy on some of those ideas? More from Jeremy — let's talk about this.

Jeremy Fleitz 44:48

Yes, trying to think of how that one came around. So anyways, we're going to have host components supported very, very, very soon — I know Bailey is extremely busy. But host components are just like host plugins, but they allow you to extend a wasmCloud host without having to recompile the whole entire thing. And since this is going to be providing a lot of additional functionality that could be customized, I really feel like we need to show off how does this work with something like wasmCloud Secrets, or going to the edge with WASI SPI — there is a WASI SPI spec that recently got reviewed by the W3C committee that handles that. And then also this might be a good time to maybe move the Couchbase plugin: instead of being a host plugin, we can have a host component for that. And maybe it's more of the model of, start off with a host component first, and if it gets matured enough or it's used by a lot of people, maybe that's when we move it to a host plugin. Yeah, something like that.

Bailey Hayes 46:05

And I'm going to add — so, we put these things in wasmCloud Contrib. One of my favorite parts of having host components is that those dependencies are no longer in tree. I don't know if you noticed in the wasmCloud repo, but we now have, as part of our last quarter, we did a ton of stuff on having cargo-audit enabled, and we're revving our dependencies for everything. That's great for security. What's not great about it is the churn that that introduces, having a lot of different dependencies. So being able to put these as host components and make them an isolated thing that is just them, and out of tree of the wasmCloud Cargo.toml, means that we have to churn way less over there, and these components can be grabbed and maintained independent of the host — which I'm excited about. And so yeah, every time we add, you know, my favorite library or my favorite framework, now we don't have to put that in our monorepo and manage it there.

Okay, and then we've got a bunch of ideas on cool reference architectures that we want to create. That's kind of still in the vein of a lot of things that we had in our last quarter. I see a new one here. Was this you, Bharat? Adding—

Jeremy Fleitz 47:25

That was me.

Bailey Hayes 47:26

Oh, hey, okay. Tell me about it.

Jeremy Fleitz 47:29

All right. So about a month ago, a few weeks ago, we did autoscaling with KEDA and showing off HTTP requests coming in and autoscaling on workloads. That's great from an HTTP story. From a NATS perspective, right now wasmCloud Messaging NATS does a subscribe. So when I scale up the backend workload component, I'm actually fanning out that exact same message. So when I have one message coming in and I've scaled up to 10, now I've got 10 workloads doing the same subscribe. Which is fine — I mean, that's maybe what you want. But NATS does have queue groups, which I think is literally just round robin. NATS will basically say, oh, okay, these 10 workloads are subscribed to this group, I'm just going to start throwing them at each individual one, but make sure only one gets it. And so that way that'll allow for us to put autoscaling from a NATS perspective in place, and I think this will help a lot with transactional types of deployments. The second one—

Bailey Hayes 48:38

Sorry, my main question on that is: Aditya, at one point you had spiked on creating a NATS-native WIT definition? I mean, it wasn't on our roadmap, so it wasn't top priority.

Aditya Salunkhe 48:56

Yeah, honestly, that did go under my radar. Is that something you want to target for this roadmap?

Bailey Hayes 49:04

Well, we have options. I guess the reason why I'm throwing it back out is queue groups is a very NATS-specific interface, I would think, and might be hard to massage into something that's generic, like wasmCloud Messaging. I know that there are a couple of different types of delivery mechanisms for Kafka, for example, but I don't think I have the same thing in Pulsar. And I guess what I'm saying there is, Kafka, you have the—

Yordis Prieto 49:39

The consumer group, which is effectively the same.

Bailey Hayes 49:42

Do you know about Pulsar?

Yordis Prieto 49:46

I think Pulsar — RabbitMQ. I think Pulsar is like RabbitMQ, and RabbitMQ is the one who defined the consumer group. So no, I don't know what they call it.

Jeremy Fleitz 49:56

I would write down Pulsar right there. Well, I guess I can do it, sorry. But no, that's a great callout, because maybe, Bailey, to your point, maybe it's finding more of a genericized thing and calling it queuing or something like that, and just making sure it can be genericized enough for the backend side.

Yordis Prieto 50:15

Yeah, Pulsar's is a Christian name, but it's the same concept. It's just a consumer group — one of them picks it up, competing consumers effectively. So yeah, most of them have it. Although Bailey, I think I said this two years ago — I told you so. For these abstractions, the best you can do is actually to flip it around. Personally speaking, everything is specific until you observe what is actually common, and then you figure out what's the structure. Otherwise, just draw a line in the sand and say messaging does not mean everything. It just means this particular set of semantics; everything else is something else.

Bailey Hayes 50:58

Yeah, I mean, that's essentially what we landed on with wasmCloud Messaging, which is just basically pub/sub, which is why right now it doesn't include any kind of queuing concept — which is kind of why I'm wondering if it is a NATS thing, if we should push on doing wasmCloud NATS.

Yordis Prieto 51:17

It's not, but you need to think about what's the common denominator. Most of the time, what you're going to find around all of them is it's just an identifier of, you know, consumer group — or like NATS, whatever they call it, or Kafka, or Pulsar's subscription name, right? So in the worst case, you're most likely going to run into: okay, yeah, it's just an identifier to say this group of workers is supposed to act only once on the message. So, like, that's it.

Jeremy Fleitz 51:46

Like, Bailey, are you saying maybe this is more of a wasmCloud Contrib host component type model?

Bailey Hayes 51:55

Yeah, that's what I'm wondering. Well, and I guess what I'm wondering is if we should make a couple of these that are specific to them, or at least do that exploration. I mean, I'm totally game to find the common denominator, although I guess I deeply wonder if a lot of these just have such rich features that are specific to them that we're not better off just being explicit about that.

Jeremy Fleitz 52:28

Yeah, like not this—

Yordis Prieto 52:30

—level, but other stuff. Yes, there are a lot of queues and timeouts, poll timers — all of that stuff, they all have their own configuration. So in the worst case, a byte array of "I don't know what the heck is inside here," and put your own type there.

Bailey Hayes 52:45

What would you want to see, Yordis? Would you just want to see a wasmCloud NATS, kind of like what Aditya had spiked out?

Yordis Prieto 52:53

So here's my philosophy overall. These types of decisions are not something that you fiddle with every single day, right? Most of the time, the architect or the team decides we're going to use X and Y, and then you learn all the capabilities, and then you learn how to configure it, you set it up, and then you forget. It's not something that every day you have to reconfigure and change. And most of the time, changing them means, hey, you need to understand the guarantees of the semantics, the APIs, and so on. So it's not as simple as, oh, just flip it around.

Because of that, from my perspective, if you get one of these generic APIs, every single other API pays the cost of it, right? So for me, from the perspective of wasmCloud, I'd rather see wasmCloud NATS Messaging, wasmCloud Kafka, whatever — and those you may find eventually have some common types that you could share, but I don't care as much. That's what I would do, because otherwise you're going to punish every single messaging package, and you're going to end up with APIs where the complexity of getting a given configuration correct means an actual production outage: losing data, breaking. Because, oh, I forgot that when it's in Kafka the flip around is 2, 1, 3 — like, now it does something like that. That is actually where you're going to, you know, you may have even a liability from the company perspective. So I would not do that. I would just do a specialized one. Yes, have a second layer that you may want to share a bunch of stuff like that, but in reality, having one generic one always backfires.

Bailey Hayes 54:33

That matches my intuition. And I mean, that's why this was a little scary to me, that idea. I was thinking maybe we go for the thing that's a little bit more straightforward and then grow from there. I know that Pulsar and Kafka are both really important to the ecosystem as well, but I think it's easier to add now with host components, that we can kind of crank these out. Are there more that got added here that I haven't called out yet? Yeah, Bharat.

Bharat 55:17

I have a question with the reference architecture. Is this related to the architecture for building applications on wasmCloud?

Bailey Hayes 55:30

Yeah, I think we've had a couple of requests in a couple of different areas. So one that I'll just call out is, like, "how did you all do it" is one that we're asked fairly frequently. So having something for that would be nice to have. I think there are a lot of others, like how to run MCP servers — that's kind of one. Another one would be, give me your actual enterprise application architecture. Like, this is the pet store, right? I think a lot of people would love to see that.

Bharat 56:14

Yes. So with this, I have a question. When we talk about a full-stack application, does the application architecture have to be all the components in one workload, or can we have multiple workloads for an app? What is the right way?

Bailey Hayes 56:40

Yeah, I would say that we need to give them the answer to both, and how to decide would be the most important part here. The reason why I think things should be in the same workload is because they need to scale together, they need to deploy together, and they probably share the same resources — so that's when I would want them in the same workload. When I would want them in different workloads is when I would have also chosen to do a separate container or a separate microservice, for a lot of the reasons in that they have different lifetimes, they have different scalability requirements, maybe they have different RBAC that you want to apply to them.

And I think when you're thinking about building an entire enterprise platform architecture on top of wasmCloud, what it might end up looking like is hundreds of essentially serverless apps running, right? And you're going to have some that are owned by the team that — sometimes we call them the platform engineering team, sometimes we call them the middleware services team at enterprises. But often there are folks that own: how do I do authorization? How do I do authentication? How do I do logging? How do I do auditing? And for those common concerns, I wonder — a lot of that should probably be host components, a lot of that should probably also be services. And when to choose between the two, we need to have some reference documentation for.

My rule of thumb is, when I want something to be a service, it's because I wanted it to be workload-tenanted, and I want something to be a host component when it needs to obviously apply to everything on that host. And then giving people the right size for how to do some of this — I think there were some really cool things that happened in the containerization era over the past decade or so, and some projects that I saw that did a really great job of this include, like, Kubecost. Early demos, I remember, were really impressive. Of course, they did a lot with Spring Boot, Java, microservices, with the pet store being one of my primary things that I'm kind of thinking about there. But yeah, I think there's a lot to add here.

Actually, who had the most ideas on this was Eric Gregory. I don't know if you're still on this call — I know we're starting to run way over now. Eric, is there something else I should include here?

Eric Gregory 59:28

No, I think you pretty much covered it. Sorry, my computer's moving kind of slowly. Hopefully you can hear me. But yeah, I think that polyglot enterprise application use case is important to cover. That's one of the first ones I would imagine trying to represent here. And then how to run the MCP servers — that's a big one. And yeah, I think this is just a piece that's been missing in the docs for a bit, so really trying to focus on fleshing that out this quarter is a good documentation goal.

Bharat 1:00:05

Thanks, thanks. Also, one more question. I tried the local deployment of my demo with very minimal code with the WASI P3 async handler, but somehow it's breaking. I posted the question in the wasmCloud Slack channel, so yeah, I'd like to have your—

Bailey Hayes 1:00:40

I'll jump on that. Yeah, I saw that question come through. I've been doing a little bit of travel, a little bit offline, but I'll take a look at that, and we'll get back to you on that. That looked like potentially a legitimate bug.

Bharat 1:00:56

Okay, okay. No problem. Yeah, thanks.

Bailey Hayes 1:01:03

All right. Any other items on here that we want to talk through? I'm not going to do dot voting just yet for this one. I think for this, we generally understand that a lot of this is just basically following up under "build stuff." So many of these things are enablement activities, like getting us reference documentation, getting us examples, templates. Like, let's flesh out wasmCloud Contrib, let's build on top of these SDKs and show people all the different things that actually just work in WebAssembly today. And when I say people, I also mean agents. They're figuring out a lot of the things that we're able to build nowadays, and so I think we have a really great roadmap for that.

And then we're going to wrap up sort of our long-running compute work that we have that's coming through from last quarter, and then I think we've got a handful of interfaces that we're going to explore, which we'll be able to now that we have host components. So it's not like we're tightly tied to that API. It'll be really easy for us to rev that independent of the host, so we can do a lot of different types of experimentation and exploration now without worrying about breaking a ton of people. So that's going to be really nice.

So thank you, everybody. I think probably not today, but by the end of this week, my goal is to capture most of this in ticket form and then get this added to the project board.

Jeremy Fleitz 1:02:39

I will volunteer to help.

Bailey Hayes 1:02:41

Thank you. We could do that up here.

Bailey Hayes 1:02:53

All right, thank you, everybody, for joining. I really appreciate your feedback, and as always, keep asking questions in Slack.