diff --git a/community/2026-09-30-community-meeting-transcript.mdx b/community/2026-09-30-community-meeting-transcript.mdx
new file mode 100644
index 00000000..2055b9c9
--- /dev/null
+++ b/community/2026-09-30-community-meeting-transcript.mdx
@@ -0,0 +1,241 @@
+---
+date: '2026-09-30'
+title: 'Transcript: wasmCloud Q4 Roadmap: Python, Workload Identity, Wasm Components'
+description: 'Full transcript of the September 30, 2026 wasmCloud community call covering wasmCloud 2.10.2, the Q4 roadmap, a Python SDK, exploded components, k6 load testing, S3 for WASI Blobstore, and workload identity.'
+keywords:
+ - wasmcloud
+ - webassembly
+ - wasm component model
+ - wasm components
+ - webassembly news
+ - wasmcloud roadmap
+ - python webassembly
+ - rust webassembly
+ - exploded components
+ - precompiled component cache
+ - k6 load testing
+ - wasi blobstore
+ - s3 object storage
+ - workload identity
+ - credential brokering
+ - host component plugins
+ - ai sandbox
+ - webassembly kubernetes
+image: https://i.ytimg.com/vi/U04P5os6D_k/maxresdefault.jpg
+showTitle: true
+slug: 2026-09-30-community-meeting-transcript
+about: wasmCloud
+mentions:
+ - ComponentModel
+ - Python
+ - Rust
+ - WASIPreview3
+ - Wasmtime
+ - WASIBlobstore
+ - OCIRegistry
+ - AISandbox
+---
+
+import YouTube from 'react-player/youtube';
+
+**[← Back to watch page](/community/2026-09-30-community-meeting/)**
+
+
+
+
+
+{/* truncate */}
+
+## Transcript
+
+**Bailey Hayes** [0:09](https://youtu.be/U04P5os6D_k?t=9)
+
+Hello and welcome to wasmCloud Wednesday for September 30th. So this is our last community call before spooky October, and also the end of our quarter three, and so we're wrapping up a few remaining things that are on our project board for Q3, and then next week we're going to do our Q4 planning. That's a collaborative session. We're going to do it all together, and I'm going to dive more into that.
+
+But first, I just want to call out that we're getting ready to cut 2.10.2. So this is another patch release on top of 2.10. Got a couple little bug fixes in there that I'm going to go ahead and get out before we drop some bigger features. So get those patches out. I'm expecting to have that cut later today. And if you haven't been building on the latest 2.10 — heads up that last week I took you through our very hard to read release notes. Eric has created a much easier to read release blog, and that's now up on wasmCloud's release blog. So if you want to see the differences between 2.9 and 2.10, that is the place to look. Let me actually bring that up really quick.
+
+
+
+So we went through this in detail in the last call, so I don't plan on doing that again. But, hey, we have a huge new feature called same-host routing. That's pretty nice performance if you choose to opt into it. We also have host outbound identity, and then a whole bunch of OTel stuff. So all good things in here, including an upgrade to Wasmtime 48. One thing to highlight what's coming is that Wasmtime 48 is one of the first releases of Wasmtime where I can enable cooperative threads that match what I produce with WASI SDK 34. So, if you're doing experiments in that, heads up, you can with wasmCloud. And if you find stuff, please report it.
+
+So yeah, that is basically our 2.10 release summary. If anybody has any questions on that, happy to dive through any of these features line by line. But I think Eric did a great job summarizing. So I'm going to move on to the next agenda item. If you go to the wasmCloud repo and then go to Discussions, here we have our Q4 roadmap.
+
+
+
+This is what we've done for the past several roadmap sessions. We do quarterly planning, and we do most of it together live on the call. I like to basically do an Excalidraw that I share with everybody, and then we can kind of point at things. People can drop ideas. We can talk more about each individual thing together collaboratively. But I actually did my pre-work this time, and I went ahead and came up with what I think are the big things that we should definitely hit this quarter further down in this doc. But the main thing to call out is it's next week, same time and place as the call that we're on right now, and I really, really welcome feedback and thoughts. I have these three little prompts that I've been using for the past couple. Nobody answers them, so I might remove them. But if you wanted to make me happy and answer them, that would be very much appreciated.
+
+I did have this little summary for what we shipped in the last quarter, and oh my goodness, it's a lot, and it's a lot of really awesome, important features. Host component plugins make us, in my opinion, the best WebAssembly runtime out there. Nobody else can extend functionality and capabilities of their host using components, and it is definitely the best way to do it. So, pretty happy with that.
+
+
+
+We've got a really nice pluggable framework for having different types of ways to trigger services. We've leaned in huge on P3 with async messaging. We also have a P3-native NATS plugin and interface. We support being able to have multiple components in the same workload, all with the same API that they import or export, and be able to multiplex between all of them. That's freaking huge, and then the ability to also multiplex across different capabilities.
+
+**Bailey Hayes** [4:45](https://youtu.be/U04P5os6D_k?t=285)
+
+So I can have, let's say, an import for my users database to Postgres, and I can also have my accounts database be separate, and those have totally different, separate configurations and credentials, but all against the same interface. We did a ton of work in performance, including having concurrency, elastic instance pools, all kinds of good stuff. And not only that, but we spent two full sprints really just hardening and improving reliability and security, and vastly expanded basically all the different knobs for policy settings that you can set in wasmCloud. So feeling pretty awesome about this Q3.
+
+So the main reason why I added this is we will do things that aren't explicitly on the roadmap as needs arise. Obviously, this wasn't all completely scoped for, but the big rocks definitely are up there at the top that we did call out, and so I want to highlight those for what I think should be in the Q4 roadmap. I always like to try to do a couple of bucketed themes, because I think folks like to work in one of these layers, and so I just want to highlight: there's a chunk of things that might be fun for you, and they all kind of go together.
+
+
+
+Starting with just the component ecosystem — I think this is one of those places that's really great for new contributors. It's definitely user-facing, right? You get immediate value anytime you improve this. You get people using it right away. I wanted to highlight that basically every quarter we always have a component ecosystem theme. There's always more work to do. This past quarter we focused on Go, and I think we got to a really great place with it. We have our own Go SDK in wasmCloud. It builds now on top of componentize-go, which means people get easy access to WASI P3 through that SDK. And so now I'm kind of wondering if for this next quarter we do a Python SDK, because that's probably by far the number one language that I'm getting asked about, because of this whole AI thing. Everybody wants to use it, so I think now could be a great time.
+
+And remember what I said about our update to Wasmtime 48 and how you can flip on cooperative threading in the background? That means we can start working towards this Python epic. So yes, you'll have to flip on flags. In the South, we have a saying: "hold your mouth right." So it's going to be a little brittle. You're going to do silly things to make it work. You might not be holding it right to get it all the way through. But I think by December, which is what we're trying to scope for in Q4 planning, we could have something really nice that's awesome and stable.
+
+Another thing that is totally on the table is the C++ SDK. Again, with the cooperative threading work, we basically have full pthread compatibility. We know this because — check this out — we have 100% compatibility with this POSIX test suite for pthreads, so I know that we can make something really good there. So I think a C/C++ SDK is also on the table. If people are really into it — I don't think I'm going to commit my time on it, but happy to help people drive that through. So if that's something that you need for your company, then that's obviously something we could definitely scope for.
+
+I also am totally expecting in the next couple weeks to refresh everything with the latest wstd, which is going to have WASI P3 support. So do a rev through the Rust ecosystem and continue to make that even better. Oh, other thing I wanted to highlight, just in that same vein: there's a million and one of these kinds of tasks that need to be done.
+
+**Bailey Hayes** [8:55](https://youtu.be/U04P5os6D_k?t=535)
+
+I'm not going to scope them as part of wasmCloud's roadmap, but I do think that we should call them out here, because there's a ton of different places where we can add value to the whole ecosystem. In this case, there's a really popular library that everybody uses basically for TLS, and you can compile this to WASI now, and it's just really tricky to do it, and now it's approved. So I'm just waiting on this last thing to merge, and other people will get this.
+
+
+
+The trick basically is: how do you configure compiling with WASI SDK for a Rust project that actually uses C stuff underneath? So it wasn't the case that I made it compile so much as I've now provided a recipe for anybody to be able to use, perhaps with an LLM or agent doing their thing. Now they can look at this and be like, "Oh, cool! Yeah, WASI's supported. I have to set these knobs to be able to compile it, and now it'll just work." And so that's the combination of having enhancements in our WASI SDK and wasi-libc. And then also now WASI P3 is a target in nightly here for Rust, and very soon Rust 1.100 will be coming out, and it'll be a stable target that you can use directly. So lots of things in the component ecosystem umbrella. There's work, actually, Aditya, you've been doing. You're really great at going upstream and getting X, Y, and Z to compile to WASI, right?
+
+**Aditya Salunkhe** [10:28](https://youtu.be/U04P5os6D_k?t=628)
+
+Yep. Yeah. Where do I start? I've tried doing a lot of stuff with Lapin, which is the AMQP driver. I got that to compile. I've also made Sentry compile. Also got, I think it was SQLx at some point, which was WASI P3. But it was later revised by Bailey herself, which was a really simple revision using the Tokio update for the WASI P2 support for Tokio, which completely blew it out of proportion. But yeah, that's also something we could prioritize.
+
+**Bailey Hayes** [11:15](https://youtu.be/U04P5os6D_k?t=675)
+
+The short answer for that SQLx one is it's just flags, and same thing with this AWS change. It was just flags. For so much of the ecosystem now — before, it was like, okay, I've got to change 40 dependencies, and I've got to change what the code does and how it does it in all these different ways. And now it's like, oh no, I just flip on or off a feature, and so long as that's documented in that repo, my downstream LLM is going to know exactly what to do and be able to get it working. And so, just tons of opportunity here and a ton of value. The work that Aditya has done to get things like Sentry, AMQP, all that kind of stuff compiling to Wasm — now everybody gets to just use it, right? And we all get to build on top of it. So work here is a huge uplift, and it's super appreciated. And anytime you do work in that space, give it a shout in our community call, because once people find out, "Oh, I can do that now" — awesome. So let's make that a point. Anytime you do another ecosystem change, Aditya, let me know. Holler. I want to give it a shout.
+
+**Aditya Salunkhe** [12:27](https://youtu.be/U04P5os6D_k?t=747)
+
+Yeah, because earlier it was quite difficult, because you needed to change every layer of the socket, the internal net libraries, the async support and tooling. But yeah, now with the additional ecosystem support, it's like Bailey said. It's just a simple flag switch, so it should be much easier.
+
+**Bailey Hayes** [12:47](https://youtu.be/U04P5os6D_k?t=767)
+
+Yeah. So okay, that's that half of the component ecosystem side, and all of that is what we envision for an "Are we componentized yet?" initiative, so people can see: how am I supposed to do AMQP in Rust or Go or in Python? And then we can point them at what they want to use, or what works in Go but what doesn't work really well in Go, right? And we didn't really fulfill our vision for this last quarter, because it was a little too underspecified. So I'd like to spend time just creating a bunch of subtasks and saying, all right, we should be able to have this kind of table for Rust versus Go, and then if we choose Python or we choose C or C++, add a column for that too. If we can just surface that data, I think that also would help people get started really quickly with the whole ecosystem.
+
+Now, these two came out of our really awesome discussions in the past two wasmCloud community calls, and I broke them up into two separate things. I think people really need guidance on what protocol to use given this problem space, right? I get this question a lot, so it definitely means we probably need its own doc page, diving into that and exploring the full design space and all the different things that you should consider when creating an architecture that is component-native. Then the second side of it, which is deeply related but should be its own topic that we dive deep on, is coming up with WIT interface design and composition best practices — talking through my preference for how you design WIT, but also what do I mean when somebody gives me a new WIT definition and I ask, "Does it compose?" Just being able to answer that question, and us having a shared knowledge base for that, I think is going to be very valuable.
+
+So that is the component ecosystem section. Is there anything huge there that I forgot to call out, folks, that I should add before we have our call next week? Well, if you think of something, add it here. We'd very much appreciate it. Or just post up in Slack or send me a DM or whatever. I encourage you to give me feedback, because feedback is a gift and I love to have it in any form. And if you're shy, that's okay. Any of these venues, super welcome.
+
+So moving on to the next section: we want to make sure that our cache for precompiled component artifacts is very customizable, so people can bring their own solution for their own embedding of wasmCloud. We've had this one for a bit, just hadn't gotten to it. So I'm putting this one at the top as one of the first features we should ship in the next quarter. This next one, I think we should consider and potentially commit to, especially if we choose to take on doing a Python SDK. If we're willing to invest in a Python SDK, then I think this needs to be a part of that story. I talked about exploded components in our last roadmapping session as something that we could do, but we didn't quite have an appetite for it, because there were so many other more important things that we needed to get done. But I'm bringing it back up again. It's one of my favorite hits. It's something I really do want to build, which is essentially: in OCI, I want a separate layer for each component that I bring in. I want to be able to dedupe the CPython runtime or the StarlingMonkey runtime that everybody pulls in — the exact same version, the exact same bytes.
+
+**Bailey Hayes** [16:29](https://youtu.be/U04P5os6D_k?t=989)
+
+So I want to be able to dedupe it at the OCI layer, and I also want to be able to dedupe it in the runtime layer. So that's why it's right there next to our precompiled component artifact piece. We also need an understanding between those two features: I've been able to essentially explode a component, and now I'm sharing precompiled bytes between, maybe, the same CPython in two places.
+
+**Liam Randall** [16:58](https://youtu.be/U04P5os6D_k?t=1018)
+
+And then just to be clear, what that would translate to is: today, when we look at components, for example, in Go or in Python, they're a bit larger, because each one has a full copy of the runtime. After we do this, the wasmCloud host could load, say, one copy of Python A, another copy of Python B, another copy of Python C, and then just load the data segment and execute from there. Is that correct?
+
+**Bailey Hayes** [17:25](https://youtu.be/U04P5os6D_k?t=1045)
+
+Yes. I will say "data segment" is a specific thing in WebAssembly, and technically it wouldn't be the data segment.
+
+**Liam Randall** [17:32](https://youtu.be/U04P5os6D_k?t=1052)
+
+Yeah, I used a random word. It would still be its own separate component with a stack and its own linear memory and data and all that.
+
+**Bailey Hayes** [17:44](https://youtu.be/U04P5os6D_k?t=1064)
+
+Yeah, yeah. "Instance" would be the word that I would use here. We would spawn an instance from the precompiled artifact. The reason why I want to make sure we disambiguate from a data segment here is that I have this other one of my favorite boondoggles, which is a streamable data segment. In the world where I think components should be your one true packaging mechanism that you use for everything — Markdown documents, prompts, models, all of the static assets that you load for your app — those, in my book, we should have a feature for. A data segment is effectively the layer when you load things into linear memory: how do I bootstrap a WebAssembly module? So this is a core Wasm thing. If I have the ability to make those segments asynchronous and load them as needed, then I can stuff all kinds of cool static assets in them and be able to do things like prefetch all the things that I'm going to load for a web page, or be really smart about going through a neural network and picking the appropriate paths based on the decision that I'm making given the inference that I'm running. A million and one different use cases for that.
+
+**Liam Randall** [19:02](https://youtu.be/U04P5os6D_k?t=1142)
+
+Now I'm glad I misspoke, because now you painted a much richer picture of how this all comes together. Thank you very much for putting that out there for the community. I think that's one of the super nuanced points. I was trying to plant a question with that, because I think your description maybe didn't communicate to all the people that watch and consume this the impact of that feature. That's one that I think is just super exciting. Sorry —
+
+**Bailey Hayes** [19:30](https://youtu.be/U04P5os6D_k?t=1170)
+
+Absolutely. So to be clear, this one is just for specifically deduplicating the module bytes that we load, which we're going to be able to precompile and prefetch. We do actually already have a precompilation cache that we use, but making sure that it's customizable, so other people can slot in and bring their own distributed cache, for example, or use different kinds of caching mechanisms rather than the one that we have baked in. So all that good stuff — which also means anytime you're touching that kind of stuff, you should be doing benchmarking. And our benchmarking milestone will be evergreen. We will always be doing benchmarking and expanding out that suite. We've had one that we hadn't quite closed out for Q3 yet that Jeremy's been putting in a ton of work on recently. Jeremy, is that PR already up? You want to —
+
+**Jeremy Fleitz** [20:27](https://youtu.be/U04P5os6D_k?t=1227)
+
+Yeah, I put it in chat.
+
+**Bailey Hayes** [20:30](https://youtu.be/U04P5os6D_k?t=1230)
+
+Well, I'm going to do it the slow way.
+
+**Jeremy Fleitz** [20:32](https://youtu.be/U04P5os6D_k?t=1232)
+
+Okay. Yeah, it's 5630. Yeah, there you go.
+
+**Bailey Hayes** [20:38](https://youtu.be/U04P5os6D_k?t=1238)
+
+You want to talk about it?
+
+**Jeremy Fleitz** [20:39](https://youtu.be/U04P5os6D_k?t=1239)
+
+Yeah, just really quickly. So there's this issue that's been out there, 5052, for I think two quarters now, and finally it's like, hey, it's the end of September, I need to get this in. So what this does is — we already have benchmarking that's out there, and that runs every time we do a release. This is more for doing a load-type test with k6, and then going through different types of scenarios, like a fan-out scenario, or even chain calls on the same host. Doing the chain call on the same host, it can also use local routing, which was one of the later features. And when I enabled that, that's when it actually found an issue with local routing. So this is very helpful even just for finding issues that occur only under a strong load-type test.
+
+
+
+So this one's in draft right now. It should be ready to merge later today, and it also has scripts inside the same folder where the other benchmark ones are. But it doesn't have to run just in CI/CD. You can run this locally on your laptop, and you can also run it against your cluster where you have wasmCloud installed, if you wanted to test to see how the performance is.
+
+**Bailey Hayes** [21:50](https://youtu.be/U04P5os6D_k?t=1310)
+
+Cool, yeah. And can you describe what suites you have created right now? I see k6 bench, a smoke test. Are there other kinds of specs that you've added?
+
+**Jeremy Fleitz** [22:05](https://youtu.be/U04P5os6D_k?t=1325)
+
+No, this is very preliminary. This is really just a basic k6 bench type of test, and actually in the next quarter, like you called out, we have some more k6 enhancements that we're going to be adding too.
+
+**Bailey Hayes** [22:19](https://youtu.be/U04P5os6D_k?t=1339)
+
+Yeah, that's kind of the thing. Every time we add a new plugin or we add anything that involves the network, for example, we really should be running that through its own k6 spec. So we can very much be focused on expanding that out. So I'm really excited about it. Getting a spec, for example, on the NATS plugin that you added would be a super valuable one. Continuing on that front, it's not just k6 benchmarking that we're going to be doing. k6 is a macro benchmarker. There's a ton of things that are still super valuable with micro benchmarks as well. Fine-tuning how host component plugins load and how we do async and all that kind of stuff is much easier to do at a micro benchmark level, because you're talking about really fine margins. But then we really should be doing more different types of tests, like realistic load tests for long periods of time, that kind of thing. That's always a fun area to innovate. So that's our performance and efficiency bucket. As always, if you think of other things we should be throwing into that theme, add them right here.
+
+Moving on to the next one, on integration. This one, I'm already mentally booked for Aditya, basically, as we talked about last week. Anything you want to say on that one, Aditya?
+
+**Aditya Salunkhe** [23:51](https://youtu.be/U04P5os6D_k?t=1431)
+
+Yeah, I already have the issue filed upstream on object_store, and I also have the pull request generated for that. I reviewed it quite a few times, actually, with the little time I got, and it seems good. I also tested it with a preliminary version that I implemented in wasmCloud, and it worked — only on LocalStack, though. But I'm sure it works well with the real cloud providers. It should be up for review by those maintainers, and once that's done, we're going to take a poke at implementing only the S3 part of it, and I think we're going to stub out the Azure and GCS parts of it until the upstream portion lands. After that, I think we should be good to go. It's quite close to completion.
+
+**Bailey Hayes** [24:46](https://youtu.be/U04P5os6D_k?t=1486)
+
+Yeah, so that's something I'm expecting early in the quarter, and that's huge. I think there's a lot of things in this integration bucket that somewhat overlap with the component ecosystem. You get this thing compiling to Wasm, then we can reuse it in a lot of places. But specifically, we have built-in plugins, and this is one of the built-ins that we ship, and for that reason we want this upstream project to be the one dependency that we really have to maintain that can talk to all these different kinds of providers. So it's definitely the right library for the right abstraction that we're providing with WASI Blobstore and WASI Key-Value.
+
+Now, there's more things that I think we can do in this space that could be powerful and unique to us. You can see where we innovated quite a bit on the NATS plugin, where there are NATS-specific policy decisions that happen, and we do that at the binding level: we want to attach this workload to this plugin, and that binding is a capability grant. On these capability grants, it can say things like, you're allowed to talk to these topics, or you're allowed to create these buckets. And as I was reviewing that from Jeremy, I realized there's a huge opportunity here for us to do the same thing for Blob Store and Key-Value. There's a big design part that we would need to put in first for those, but I think it's also really valuable, because that's something that most people generally want. They're going to have authorization at play here already, which we already lean into, but I think people are going to really want even finer-grained control that's also declarative to the workloads that are accessing these things. So that's kind of the ideal.
+
+**Aditya Salunkhe** [26:52](https://youtu.be/U04P5os6D_k?t=1612)
+
+Do we have any early shouts for some blob stores or key-value stores that we probably want to port?
+
+**Bailey Hayes** [27:02](https://youtu.be/U04P5os6D_k?t=1622)
+
+Oh yeah. Well, S3 is the most important, I think, by far. Everybody's just kind of landed on that as being the lingua franca of object stores. Oh yeah, I should give that one a shout, and there's probably some more forked names that I can't think of. And I get in trouble if I say Redis, for example. Yes, those would be really valuable for the bucket policy — I thought that's what you were asking for. I did actually create a sketch of this way back when, with the idea of exposing what a bucket is: surfacing a prefix and whether or not you should be allowed to create it. Right now, we just create it, and there are other kinds of things that are policy-level that you might need to specify on each bucket.
+
+
+
+We weren't quite ready to swallow this one, so it hasn't landed yet, but it's something I think we should bring into scope. Now, one more thing I'd like to give a shout for: a great way to expand our capabilities is to do host component plugins, right? It's very easy for me to say "yeah, add that one too" when it's not in the main wasmCloud repo, where we're doing cargo-vet and audits on all the dependencies. So I'm just saying, please go wild over here on integrations and expansions. There's a million and one things that I think we can start adding, and because we have the host component plugin feature, I feel great about adding them, because each one of them is sandboxed, right? So it's a really great way to expand the host capability footprint. So that was that shout there. But yeah, my number one, if you want my preference, is an S3-specific API. Yeah, Frank.
+
+**Frank Schaffa** [29:16](https://youtu.be/U04P5os6D_k?t=1756)
+
+I'm wondering — so you're asking for folks to test those things and experiment and so forth. I'm just wondering, why don't we have Claude or any other agentic stuff doing this, and we just spec those things?
+
+**Bailey Hayes** [29:41](https://youtu.be/U04P5os6D_k?t=1781)
+
+I mean, it should be totally possible. And look — you can tell that that's what I'm up to myself. If you look at my PR over here, we went through — I haven't finished it — but I came up with all the different ways that you could support a host component plugin.
+
+
+
+So it's one of those cases where it does take a decision, right? And you do need a human driver to make sure that the output takes advantage of the properties that WebAssembly gives you. That requires a bit of prompting. We do have a skill that a lot of people are using that I totally recommend people use. What would really speed this up is, again, having this documentation, which would help these LLMs produce the right thing.
+
+**Aditya Salunkhe** [30:36](https://youtu.be/U04P5os6D_k?t=1836)
+
+Yeah, because it's a bit tough to actually navigate the whole WIT interface that drives the whole host component plugin, because at the end of the day, the whole idea is to have as much specificity as possible, which is a bit tough to box in, and that requires a bit of skilled expertise. Take, for example, if someone were trying to implement something like NATS — we would probably hand it over to Yordis, who would actually be able to give his inputs that would help shape the NATS interface better. But yeah, with improved documentation, that would certainly be better.
+
+**Bailey Hayes** [31:22](https://youtu.be/U04P5os6D_k?t=1882)
+
+I think that would definitely accelerate it. I think we could absolutely spec out some of these things. I think doing a good spec is the hard part, though, because that's coming up with this decision-making. Right now we're not quite at the point where LLMs produce what I would want. Will it produce a thing that works and runs? Yes, you can one-shot that. It's not quite at the point where it's something that I would want in the wasmCloud namespace that other people would build on top of. But I think by doing these two, and then getting some more representative examples and highlighting what those decisions are in awesome-wasmcloud, anybody can then point an LLM and go forth and create really rock-solid host component capabilities. So that's definitely why I want it on the roadmap, because there's no reason you should have to require me. We should be able to scale this out quite a bit.
+
+So the next one is continuing our work on security, but I want to call out workload identity as being — you know, when you do quarterly planning, you should plan your big rocks first. And our biggest rock, in my book, is this one: actually having full, integrated support for workload identity in wasmCloud. And when I say that, I mean a combination of things, because there's a lot of aspects to this. It's more than just mutual TLS support, and it's more than just an individual workload having its own identity that it can use for a mutual TLS type connection to some other external service. I actually mean even more than that, in that I want to be able to do credential brokering in a rock-solid way in our host, so that people writing agents and agent harnesses are able to safely run them on our sandbox. And we're not just a sandbox. We're a multi-tenant sandbox, so the design for us here is a huge opportunity, and a huge place of complexity, but also completely worth doing, because this is what people ultimately want right now.
+
+Everybody is looking for their agentic platform, right? What can I use to safely run my agents? And there's no better sandbox than WebAssembly. There's nothing that has finer-grained control. With VMs and these other mechanisms, people are aiming for isolation, but they're not actually truly aiming for sandboxing, and that's why they are failing. You can look at the one from this weekend, which was DNS. And pro tip: it's always DNS. And guess what we don't have in WebAssembly and WASI? DNS. So we sidestep so many of these problems that people are getting when they're trying to build on an operating system with POSIX.
+
+So anyway, this I think is a big one. I've been working on an RFC. I have a huge Notion doc where I've been exploring the design space. What I'm going to do is synthesize that down into a human-written RFC for everybody to give feedback on. But the first big thing is that I actually have a series of drafts that stack on top of each other that will essentially get us to where the basics are for this. So we should be able to land some of the first parts of this next week, and I've broken it down into several phases that I'll take you through when we start doing the RFC for that one.
+
+So I've lost where I was supposed to be — too many tabs. I even pulled up a window that didn't have all the tabs, because I feel like I scared Yordis last time, but yet here we are again. I guess I'll just show you how to get to the Discussions tab, and you can give me feedback, because I still see there's nothing here, folks. So please give me feedback on the things you want to see.
+
+**Bailey Hayes** [35:59](https://youtu.be/U04P5os6D_k?t=2159)
+
+But yeah, that is what I had in mind for what I think we should scope for our roadmap session. And welcome others to come in and talk about the things that they think are important. Anything more on this topic? Nice. Okay. Well, that is mostly everything. I know that we're starting to accumulate a bit of a backlog on pull requests. So even if you're not a maintainer, I welcome other people to come in and code review other folks. It helps me get confidence if somebody else has already had a look and done a first pass. I have a prioritized list for getting through some of these reviews and burning them down. But right now my current rate is maybe four PRs a day, and I need to close them all out. It's somewhere around 15 right now, at least. So I've got my work cut out for me. If anybody wants to help, super welcome. And that is basically it for the planned agenda today. Next up, I'm going to stop the recording, but I want to take at least the maintainers through a threat model that I've been working on. I want some feedback on that, so I'm going to hit the button.
diff --git a/community/2026-09-30-community-meeting.mdx b/community/2026-09-30-community-meeting.mdx
index 5d7736ee..9a619fc1 100644
--- a/community/2026-09-30-community-meeting.mdx
+++ b/community/2026-09-30-community-meeting.mdx
@@ -1,60 +1,227 @@
---
date: '2026-09-30'
-title: 'Meeting Agenda - 2026-09-30'
+title: 'wasmCloud Q4 Roadmap: Python, Workload Identity, Wasm Components'
+description: 'A Q4 plan for the wasm component model: wasmCloud weighs a Python SDK, exploded components, k6 load tests, S3 for WASI Blobstore, and workload identity.'
+keywords:
+ - wasmcloud
+ - webassembly
+ - wasm component model
+ - wasm components
+ - webassembly news
+ - wasmcloud roadmap
+ - python webassembly
+ - rust webassembly
+ - exploded components
+ - precompiled component cache
+ - k6 load testing
+ - wasi blobstore
+ - s3 object storage
+ - workload identity
+ - credential brokering
+ - host component plugins
+ - ai sandbox
+ - webassembly kubernetes
+chapters:
+ - { seconds: 9, label: "Welcome: the last call of Q3, and wasmCloud 2.10.2 lands today" }
+ - { seconds: 71, label: "The 2.10 release blog: same-host routing, outbound identity, and OTel" }
+ - { seconds: 110, label: "Wasmtime 48 runs WASI SDK 34 cooperative threads" }
+ - { seconds: 159, label: "The Q4 2026 roadmap discussion and the October 7 planning call" }
+ - { seconds: 229, label: "What shipped in Q3: host component plugins, P3 messaging, and multiplexing" }
+ - { seconds: 367, label: "Component ecosystem: from the Go SDK to a Python SDK" }
+ - { seconds: 472, label: "A C/C++ SDK, pthread compatibility, and a Rust refresh with wstd" }
+ - { seconds: 554, label: "aws-lc-rs on WASI P2 and P3: a compile recipe, not a fork" }
+ - { seconds: 628, label: "Aditya Salunkhe: Lapin, Sentry, and SQLx compiled to WASI" }
+ - { seconds: 776, label: "Are we componentized yet? Protocol guidance and WIT design practices" }
+ - { seconds: 921, label: "Customizable cache for precompiled component artifacts" }
+ - { seconds: 954, label: "Exploded components: deduplicating CPython and StarlingMonkey" }
+ - { seconds: 1018, label: "Liam Randall: what deduplication means for Go and Python components" }
+ - { seconds: 1081, label: "Streamable data segments: components as the packaging for everything" }
+ - { seconds: 1208, label: "Evergreen benchmarking, and Jeremy Fleitz's k6 load-test PR" }
+ - { seconds: 1378, label: "Macro vs. micro benchmarks and long-running load tests" }
+ - { seconds: 1420, label: "Integration: object_store upstream and S3 for WASI Blobstore" }
+ - { seconds: 1540, label: "Declarative capability grants for Blob Store and Key Value" }
+ - { seconds: 1612, label: "Which backends first? S3, and a bucket-policy sketch" }
+ - { seconds: 1707, label: "Grow integrations as sandboxed host component plugins" }
+ - { seconds: 1756, label: "Frank Schaffa: why not have agents build the integrations?" }
+ - { seconds: 1952, label: "Workload identity: Q4's biggest rock" }
+ - { seconds: 2004, label: "Credential brokering, multi-tenant sandboxes, and no DNS in WASI" }
+ - { seconds: 2085, label: "A human-written RFC and a stack of drafts" }
+ - { seconds: 2170, label: "Wrap-up: a PR review backlog and a call for reviewers" }
+image: https://i.ytimg.com/vi/U04P5os6D_k/maxresdefault.jpg
+duration: 2250
+showTitle: true
+slug: 2026-09-30-community-meeting
+speakers:
+ - bailey-hayes
+ - liam-randall
+ - aditya-salunkhe
+ - jeremy-fleitz
+ - frank-schaffa
+about: wasmCloud
+mentions:
+ - ComponentModel
+ - Python
+ - Rust
+ - WASIPreview3
+ - Wasmtime
+ - WASIBlobstore
+ - OCIRegistry
+ - AISandbox
---
-## Agenda
+import YouTube from 'react-player/youtube';
-{/* Update before the start of the meeting with planned agenda items */}
+{/* Video hero — the whole point of this page */}
--
--
--
+
+
+
+
+The September 30, 2026 wasmCloud community call was the last of Q3 and a preview of the **Q4 roadmap** before next week's collaborative planning session. Bailey Hayes walked through the draft in [discussion #5619](https://github.com/wasmCloud/wasmCloud/discussions/5619). It has four themes: the **wasm component model** ecosystem (a Python SDK is the likely next language), performance (a customizable precompiled-component cache, exploded components that deduplicate language runtimes, and k6 load tests), integration (S3 for WASI Blobstore and declarative storage grants), and **workload identity with credential brokering**, which she called the quarter's biggest rock. Jeremy Fleitz showed a k6 load-test harness that has already found a local-routing bug.
{/* truncate */}
+## Key Takeaways
+
+- **wasmCloud 2.10.2 was due the same day.** It is a patch release with a few bug fixes, cut before bigger features land. The [2.10 release blog](/blog/wasmcloud-2-10-release/) is the readable summary of 2.10: same-host routing, outbound workload identity, spec-conformant OpenTelemetry, and **Wasmtime 48**, which can run components built with WASI SDK 34 cooperative threads
+- **Q4 planning is collaborative, and async input counts.** The roadmap lives in [discussion #5619](https://github.com/wasmCloud/wasmCloud/discussions/5619) and the planning call is October 7. Bailey asked for comments on three questions: what wasmCloud should prioritize that it doesn't today, which rough edge you've normalized, and what would get your organization to production
+- **Q3 delivered a lot.** Host component plugins, a pluggable model for service triggers, `wasmcloud:messaging@0.3.0` async messaging on P3, a P3-native NATS interface, multi-backend component binding through `implements`, warm and elastic instance pools, outbound mTLS identity, and two sprints of reliability and security hardening
+- **A Python SDK is the probable Q4 language.** Go got the focus last quarter, and the wasmCloud Go SDK now builds on componentize-go with easy access to WASI P3. Python is the language Bailey gets asked about most. Cooperative threading in Wasmtime 48 makes it possible, and she thinks something stable is achievable by December. A C/C++ SDK is on the table for anyone who needs it, and Rust gets a refresh onto the latest `wstd` with P3 support
+- **Compiling to WASI is often just flags now.** Bailey's [aws-lc-rs PR #1239](https://github.com/aws/aws-lc-rs/pull/1239) adds `wasm32-wasip2` and `wasm32-wasip3` targets using WASI SDK 34, as a recipe others (and their LLMs) can follow. Aditya Salunkhe has gotten Lapin (AMQP), Sentry, and SQLx compiling. "Are we componentized yet?" will turn into a per-language compatibility matrix
+- **Exploded components would deduplicate runtimes.** If each component in an OCI image gets its own layer, identical CPython or StarlingMonkey bytes can be shared at the registry and in the host's precompiled cache. That cache is getting pluggable so embedders can bring a distributed one. Further out, Bailey wants **streamable data segments** so components can carry assets, prompts, and models and load them lazily
+- **k6 load tests found a real bug.** Jeremy Fleitz's [PR #5630](https://github.com/wasmCloud/wasmCloud/pull/5630) adds a k6 harness with HTTP, fan-out, and same-host chain-call scenarios that runs in CI, on a laptop, or against your own cluster. Turning on local routing under load exposed an issue, and the PR waits on the fix
+- **Integration: S3 first, then finer-grained grants.** Aditya's bucket-scoped operations PR to Apache's `object_store` is up for review upstream, with S3 to follow in wasmCloud. Bailey wants NATS-style declarative capability grants (bucket prefixes, create permissions) for Blob Store and Key Value too, and new integrations as sandboxed host component plugins in [awesome-wasmcloud](https://github.com/wasmCloud/awesome-wasmcloud)
+- **Workload identity and credential brokering are the biggest rock.** The goal goes beyond mTLS: the host brokers credentials so agents and agent harnesses can run safely in a multi-tenant WebAssembly sandbox. Bailey is distilling a long design exploration into a human-written RFC, with stacked drafts for the first phases expected to start landing next week
+
+## Chapters
+
+- [0:09 — Welcome: the last call of Q3, and wasmCloud 2.10.2 lands today](https://youtu.be/U04P5os6D_k?t=9)
+- [1:11 — The 2.10 release blog: same-host routing, outbound identity, and OTel](https://youtu.be/U04P5os6D_k?t=71)
+- [1:50 — Wasmtime 48 runs WASI SDK 34 cooperative threads](https://youtu.be/U04P5os6D_k?t=110)
+- [2:39 — The Q4 2026 roadmap discussion and the October 7 planning call](https://youtu.be/U04P5os6D_k?t=159)
+- [3:49 — What shipped in Q3: host component plugins, P3 messaging, and multiplexing](https://youtu.be/U04P5os6D_k?t=229)
+- [6:07 — Component ecosystem: from the Go SDK to a Python SDK](https://youtu.be/U04P5os6D_k?t=367)
+- [7:52 — A C/C++ SDK, pthread compatibility, and a Rust refresh with wstd](https://youtu.be/U04P5os6D_k?t=472)
+- [9:14 — aws-lc-rs on WASI P2 and P3: a compile recipe, not a fork](https://youtu.be/U04P5os6D_k?t=554)
+- [10:28 — Aditya Salunkhe: Lapin, Sentry, and SQLx compiled to WASI](https://youtu.be/U04P5os6D_k?t=628)
+- [12:56 — Are we componentized yet? Protocol guidance and WIT design practices](https://youtu.be/U04P5os6D_k?t=776)
+- [15:21 — Customizable cache for precompiled component artifacts](https://youtu.be/U04P5os6D_k?t=921)
+- [15:54 — Exploded components: deduplicating CPython and StarlingMonkey](https://youtu.be/U04P5os6D_k?t=954)
+- [16:58 — Liam Randall: what deduplication means for Go and Python components](https://youtu.be/U04P5os6D_k?t=1018)
+- [18:01 — Streamable data segments: components as the packaging for everything](https://youtu.be/U04P5os6D_k?t=1081)
+- [20:08 — Evergreen benchmarking, and Jeremy Fleitz's k6 load-test PR](https://youtu.be/U04P5os6D_k?t=1208)
+- [22:58 — Macro vs. micro benchmarks and long-running load tests](https://youtu.be/U04P5os6D_k?t=1378)
+- [23:40 — Integration: object_store upstream and S3 for WASI Blobstore](https://youtu.be/U04P5os6D_k?t=1420)
+- [25:40 — Declarative capability grants for Blob Store and Key Value](https://youtu.be/U04P5os6D_k?t=1540)
+- [26:52 — Which backends first? S3, and a bucket-policy sketch](https://youtu.be/U04P5os6D_k?t=1612)
+- [28:27 — Grow integrations as sandboxed host component plugins](https://youtu.be/U04P5os6D_k?t=1707)
+- [29:16 — Frank Schaffa: why not have agents build the integrations?](https://youtu.be/U04P5os6D_k?t=1756)
+- [32:32 — Workload identity: Q4's biggest rock](https://youtu.be/U04P5os6D_k?t=1952)
+- [33:24 — Credential brokering, multi-tenant sandboxes, and no DNS in WASI](https://youtu.be/U04P5os6D_k?t=2004)
+- [34:45 — A human-written RFC and a stack of drafts](https://youtu.be/U04P5os6D_k?t=2085)
+- [36:10 — Wrap-up: a PR review backlog and a call for reviewers](https://youtu.be/U04P5os6D_k?t=2170)
+
## Meeting Notes
-{/* Add summary of topics during the meeting. Each Topic should have an H3 heading. A list is usually sufficient for the recap */}
+### wasmCloud 2.10.2 and the 2.10 Release Blog
+
+Bailey Hayes opened the last community call of Q3 by announcing **wasmCloud 2.10.2**. It is a patch release on top of 2.10 with a couple of bug fixes, and she expected to cut it later that day so the fixes would ship before bigger features land. Last week's call walked through the raw GitHub release notes. Eric Gregory has since published a more readable version, [wasmCloud 2.10: Same-host routing, outbound identity, and OpenTelemetry that follows the spec](/blog/wasmcloud-2-10-release/), and that post is the place to compare 2.9 and 2.10.
+
+Bailey picked out three items. **Same-host routing** is an opt-in performance path for HTTP calls between workloads on the same host. **Host outbound identity** presents mTLS client certificates. The rest is OpenTelemetry work. The upgrade to **Wasmtime 48** is one of the first Wasmtime releases that can run cooperative threads matching what WASI SDK 34 produces, so anyone experimenting with threads can now do it on wasmCloud. Bailey asked them to report what they find.
+
+### The Q4 Roadmap, and What Q3 Delivered
+
+The Q4 roadmap is in [discussion #5619](https://github.com/wasmCloud/wasmCloud/discussions/5619) on the wasmCloud repo, and the collaborative planning session is next week's call (October 7) at the usual time. Bailey usually builds the roadmap live in an Excalidraw. This time she did the pre-work in the discussion and asked for comments ahead of the call, since async input carries the same weight as live participation. The discussion poses three questions: what wasmCloud should prioritize in the next three months that it doesn't today, what rough edge you keep hitting but have normalized, and what would make your organization more likely to put wasmCloud into production.
+
+Since July, wasmCloud shipped five releases, 2.6 through 2.10. Bailey singled out **host component plugins**. In her view they make wasmCloud the best WebAssembly runtime available, because no other runtime lets you extend the host's capabilities with components. She also listed a pluggable framework for service triggers, async messaging on WASI P3 (`wasmcloud:messaging@0.3.0`), a P3-native NATS plugin and interface, and **multi-backend binding**. With multi-backend binding, several components in one workload can share an imported or exported API and the host multiplexes between them. One component can also import the same interface twice, say a Postgres users database and a separate accounts database with different configuration and credentials. On performance, the team added concurrency and warm, elastic instance pools. Two full sprints went to reliability and security hardening, which greatly expanded the policy knobs available in wasmCloud.
+
+### Component Ecosystem: Python, C/C++, and Rust
+
+Bailey organizes the roadmap into themes, because contributors tend to work in one layer. The **component ecosystem** theme recurs every quarter, and she pointed new contributors to it: the work is user-facing and pays off immediately. Last quarter focused on Go. wasmCloud's Go SDK now builds on componentize-go, which gives users easy access to WASI P3. Bailey thinks this quarter could deliver a **Python SDK**. Python is the language she is asked about most, largely because of AI. Cooperative threading in Wasmtime 48 makes it feasible. It will be brittle at first and need feature flags, which Bailey described with the Southern saying "hold your mouth right," but she expects something stable by December.
+
+A **C/C++ SDK** is also possible. Cooperative threading gives near-full pthread compatibility, and Bailey cited 100% compatibility with a POSIX threads test suite. She won't commit her own time to it, but would help anyone who needs it drive it through. Within a couple of weeks she also expects to refresh the **Rust** ecosystem onto the latest `wstd` with WASI P3 support.
+
+Plenty of ecosystem work happens outside wasmCloud's own roadmap. Bailey's example was [aws-lc-rs PR #1239](https://github.com/aws/aws-lc-rs/pull/1239), which adds `wasm32-wasip2` and `wasm32-wasip3` targets for a widely used crypto library behind Rust TLS stacks. The PR cross-builds in CI with WASI SDK 34 and tests under Wasmtime 48. It was approved and waiting on one last merge. The hard part was configuring a Rust project with C underneath to build against WASI SDK, so the PR's real value is a recipe that people and their agents can reuse. Improvements in WASI SDK and wasi-libc made that possible, and `wasm32-wasip3` is now a nightly Rust target that should become stable soon.
+
+Aditya Salunkhe described what he has compiled to WASI: **Lapin** (the AMQP client), **Sentry**, and **SQLx**. Bailey later simplified his SQLx work using the Tokio WASI P2 support. Her point was that this used to mean changing dozens of dependencies and much of the code, and now it is usually a feature flag. Once a repo documents the flag, a downstream LLM can apply it. She asked contributors to announce each newly compiling library on the community call.
+
+All of this feeds an **"Are we componentized yet?"** initiative that never got enough specification last quarter. The plan is to break it into subtasks and build a table of what works for each protocol and language: Rust versus Go, plus a column for Python or C/C++ if those SDKs happen. Two more items came out of the previous two calls. One is a doc on **which protocol to use** for a given problem when designing a component-native architecture. The other is **WIT interface design and composition best practices**, so the community shares an answer to Bailey's standard review question: "does it compose?"
+
+### Precompiled Caches, Exploded Components, and Streamable Data
+
+The **performance and efficiency** theme starts with a long-standing item: make the cache for precompiled component artifacts customizable, so embedders can bring their own solution, such as a distributed cache. Bailey wants it among the first features shipped in Q4.
+
+Next is **exploded components**, one of her favorite ideas, and in her view essential if wasmCloud invests in a Python SDK. Each component gets its own OCI layer, so a CPython or StarlingMonkey runtime that many components pull in, with the exact same bytes, can be deduplicated in the registry and also in the runtime's precompiled cache. Liam Randall asked what that means in practice. Today Go and Python components are larger because each carries a full copy of its runtime. Afterward the host could load one copy of each runtime and spawn **instances** from the shared precompiled artifact. Bailey corrected his wording from "data segment" to "instance" because data segments are a separate idea she also wants to pursue.
+
+That idea is **streamable data segments**. Data segments are the core Wasm mechanism for bootstrapping linear memory. If they could load asynchronously and on demand, components could become the single packaging format for everything: Markdown documents, prompts, models, and other static assets. Apps could prefetch what a web page needs, or load only the parts of a neural network that the current inference path uses. Liam called it one of the most exciting features on the list.
+
+### k6 Load Tests and the Benchmarking Milestone
+
+Any work on caching needs measurement, so **benchmarking** stays an evergreen milestone. Jeremy Fleitz showed [PR #5630](https://github.com/wasmCloud/wasmCloud/pull/5630), which closes [issue #5052](https://github.com/wasmCloud/wasmCloud/issues/5052) after two quarters. wasmCloud already runs Criterion and Gungraun benchmarks on every release. The new k6 harness instead load-tests a deployed wasmCloud v2 stack end to end, measuring throughput, tail latency, the breaking point, and CPU and memory cost. Scenarios include `http-hello`, `fan-out-10`, `chain-5`, and `many-workloads`, with constant, stress, and spike profiles. The `run.sh` script creates or reuses a kind cluster, installs the runtime operator chart, and runs the same way in CI, on a laptop, or against your own cluster.
+
+Running the same-host chain calls with **local routing** enabled exposed a bug that only shows up under strong load. The PR is a draft until that fix merges, and Jeremy expected it to be ready that day. Bailey wants every new plugin or network-touching feature to get its own k6 spec, starting with the NATS plugin. k6 is a macro benchmark. Micro benchmarks remain the right tool for fine margins such as host component plugin loading and async, and the team also wants realistic load tests that run for long periods.
+
+### Integration: S3 for WASI Blobstore and Declarative Storage Grants
+
+The **integration** theme belongs largely to Aditya. His issue and pull request adding bucket-scoped operations to Apache's `object_store` crate are filed upstream and awaiting maintainer review. He tested a preliminary wasmCloud implementation against LocalStack. Once the upstream work lands, the plan is to implement S3 first and stub Azure and GCS until they follow. Bailey expects this early in the quarter. `object_store` is the one dependency that can talk to every provider behind the built-in [WASI Blobstore](https://github.com/WebAssembly/wasi-blobstore) and WASI Key-Value plugins, so it is the right abstraction to maintain.
+
+Bailey then proposed borrowing from the NATS plugin. There, the **binding** that attaches a workload to a plugin is a capability grant, and it can say which subjects a workload may use or which buckets it may create. Reviewing Jeremy's NATS work made her want the same declarative, fine-grained authorization for **Blob Store and Key Value**. She showed an earlier sketch, [PR #5498](https://github.com/wasmCloud/wasmCloud/pull/5498), which adds operator-controlled bucket naming, a `bucket_prefix`, and a `create` policy for NATS-backed key-value. Asked which backends to prioritize, she said S3 by far, since it has become the lingua franca of object stores.
+
+She closed the theme by encouraging new integrations as **host component plugins** in [awesome-wasmcloud](https://github.com/wasmCloud/awesome-wasmcloud), outside the main repo, where every dependency goes through cargo-vet and audits. Each plugin is sandboxed, so expanding the host's capabilities this way is low-risk.
+
+### Can Agents Build the Integrations?
+
+Frank Schaffa asked why the community doesn't spec these integrations and have Claude or other agents build them. Bailey said it is possible, and pointed to her own Couchbase PR in awesome-wasmcloud, which compares several ways to implement one host component plugin. An LLM can one-shot something that works, but not yet something she would publish in the wasmCloud namespace for others to build on. A human driver still has to make sure the output uses the properties WebAssembly provides. Aditya added that host component plugins are built around WIT interfaces that need specificity and expertise, the way Yordis Prieto's input shaped the NATS interface. Both agreed that the protocol and WIT design docs, plus more representative examples, are what would let agents produce solid host component plugins at scale.
+
+### Workload Identity and Credential Brokering
+
+Bailey said quarterly planning should place the big rocks first, and that **workload identity** is the biggest. She means more than mTLS, and more than each workload having its own identity for TLS connections to external services. She wants the host to do **credential brokering** reliably, so that people building agents and agent harnesses can run them safely in a **multi-tenant** sandbox. That design is complex, but she thinks it is what people want right now as they search for a safe platform for agents.
+
+She argued that WebAssembly is the best sandbox for this. Approaches built on VMs aim for isolation rather than true sandboxing, which is why they keep failing. She cited a weekend incident that came down to DNS ("it's always DNS") and noted that WASI has no DNS interface, so whole classes of POSIX-era problems never arise. Her design exploration is a large document that she will condense into a human-written RFC for feedback. The implementation is broken into phases as a stack of drafts, and the first parts should land next week.
+
+### PR Backlog
-### Topic 1
+Bailey said open pull requests are piling up. She has about 15 queued and reviews roughly four a day. She invited anyone, maintainer or not, to do first-pass reviews, because another reviewer's look gives her confidence. After the recording stopped, she planned to walk the maintainers through a threat model she has been developing.
-- Note 1
-- Note 2
+## WebAssembly News and Updates
-### Topic 2
+This week in **webassembly news**: wasmCloud 2.10.2 was cut, and the [2.10 release blog](/blog/wasmcloud-2-10-release/) is live. [Wasmtime 48](https://wasmtime.dev/) can now run cooperative threads produced by WASI SDK 34. That progress in the [Bytecode Alliance](https://bytecodealliance.org/) is what puts Python and C/C++ SDKs within reach for the [component model](https://component-model.bytecodealliance.org/). `wasm32-wasip3` is now a nightly Rust target and should become stable soon, and [aws-lc-rs](https://github.com/aws/aws-lc-rs/pull/1239) is close to building for both WASI P2 and P3. Apache's `object_store` is getting bucket-scoped operations so one implementation of [WASI Blobstore](https://github.com/WebAssembly/wasi-blobstore) can reach S3, Azure, and GCS.
-- Note 1
-- Note 2
+## What is wasmCloud?
-## Weekly highlights
+[wasmCloud](/) is a CNCF project for building applications out of [WebAssembly components](/docs/overview/workloads/components/) and running them across cloud, edge, and [Kubernetes](/docs/kubernetes-operator/) clusters. The [Wasm component model](/docs/overview/workloads/components/) lets you write business logic in Rust, Go, Python, TypeScript, C#, Java, and more. The platform supplies capabilities like HTTP, messaging, key-value storage, blob storage, and observability through [standard interfaces](/docs/overview/interfaces/) and a pluggable [host plugin](/docs/overview/hosts/plugins/) architecture backed by [Wasmtime](https://wasmtime.dev/). [`wash`](/docs/wash/) is the developer shell for building, running, deploying, and debugging. The [runtime operator](/docs/kubernetes-operator/) schedules Wasm workloads on Kubernetes the same way you schedule containers, with [WASI Preview 3](/blog/wasi-p3-on-wasmcloud/) support on by default. Together they give you a production platform for WebAssembly on Kubernetes and at the edge.
-### Issue of the Week
+## Topic Deep Dive: Exploded Components and the Wasm Component Model
-- [title](https://github.com/wasmcloud/wasmcloud/issues/)
- - summary
+In the **wasm component model**, an interpreted-language component is mostly runtime. A Python component built with componentize-py carries a whole CPython interpreter, and a JavaScript component carries StarlingMonkey. Your code is a small slice on top. That is fine for a single component. On a multi-tenant host running hundreds of them, it means storing, pulling, and precompiling the same interpreter bytes over and over. **Exploded components** separate those parts. Each inner component gets its own [OCI](/docs/overview/packaging/) layer, so a registry stores one copy of a given runtime build and a host pulls it once. Because wasmCloud precompiles components before running them, the host's precompiled cache can deduplicate too: one compiled CPython artifact serves every component that embeds those exact bytes, and each workload gets its own **instance** with its own linear memory and stack.
-### Documentation of the Week
+That is why the feature sits next to the customizable precompiled-component cache on the Q4 board, and why Bailey Hayes tied it to the Python SDK. Cheap Python components need both. Streamable data segments go further, letting a component carry static assets, prompts, or model weights and load them on demand instead of at instantiation, so the component itself becomes the packaging format. For background, see [how components work in wasmCloud](/docs/overview/workloads/components/), [packaging](/docs/overview/packaging/), and [language support in `wash`](/docs/wash/developer-guide/language-support/).
-- [title](/docs/v1/intro)
- - summary
+## Who Should Watch This
-## Community Updates
+**Contributors looking for a first project** should start with the component ecosystem theme at [6:07](https://youtu.be/U04P5os6D_k?t=367) and the "compile it with flags" discussion at [9:14](https://youtu.be/U04P5os6D_k?t=554). **Python and C/C++ developers evaluating WebAssembly** will want the SDK outlook at [6:07](https://youtu.be/U04P5os6D_k?t=367) and exploded components at [15:54](https://youtu.be/U04P5os6D_k?t=954). **Platform engineers running wasmCloud on Kubernetes** should watch the k6 load-test harness at [20:08](https://youtu.be/U04P5os6D_k?t=1208) and declarative storage grants at [25:40](https://youtu.be/U04P5os6D_k?t=1540). **Teams building an AI sandbox or agent platform** should jump to workload identity and credential brokering at [32:32](https://youtu.be/U04P5os6D_k?t=1952).
-### Tune in…
+## Up Next
-{/* Add any upcoming events/streams/etc */}
+Next week's call (October 7) is the collaborative **Q4 roadmap planning session**. Add comments to [discussion #5619](https://github.com/wasmCloud/wasmCloud/discussions/5619) beforehand. Expect wasmCloud 2.10.2 to be out, Jeremy Fleitz's k6 harness to merge once the local-routing fix lands, and the first workload identity drafts to start landing, with Bailey Hayes's RFC to follow. Bailey also owes a Rust refresh onto `wstd` with P3 support and subtasks for the "Are we componentized yet?" compatibility matrix. Aditya Salunkhe's `object_store` work is waiting on upstream review.
--
+{/* TODO: Link to next meeting page once created */}
-### Catch up…
+## Get Involved
-{/* Add any blog posts/articles that the community might find interesting */}
+wasmCloud is a CNCF project and contributions are welcome. Join the community:
--
+- [GitHub](https://github.com/wasmcloud/wasmcloud) — star the repo and check out open issues
+- [Slack](https://slack.wasmcloud.com/) — join the conversation
+- [Community Meetings](https://wasmcloud.com/community/) — every Wednesday at 1:00 PM ET
+- [wasmCloud Blog](https://wasmcloud.com/blog/) — latest news and releases
-## Recording
+## Full Transcript
-{/* Automated - No need to adjust this unless automation fails */}
+Read the complete transcript with speaker labels and timestamps:
-
+**[Read the full transcript →](/community/2026-09-30-community-meeting-transcript/)**
diff --git a/src/data/transcript-inheritance.json b/src/data/transcript-inheritance.json
index 5cdad975..308cc73c 100644
--- a/src/data/transcript-inheritance.json
+++ b/src/data/transcript-inheritance.json
@@ -1,6 +1,6 @@
{
"$comment": "Auto-generated by scripts/generate-transcript-inheritance.mjs (prebuild step). Edits will be overwritten. Maps transcript permalink → { about, mentions } from the parent landing page's frontmatter so video-seo.tsx can inherit entity refs.",
- "generated_at": "2026-09-23T23:06:15.653Z",
+ "generated_at": "2026-10-01T20:48:00.016Z",
"entries": {
"/community/2022-11-02-community-meeting-transcript/": {
"about": "wasmCloud",
@@ -2299,6 +2299,19 @@
"capabilityBasedSecurity",
"AISandbox"
]
+ },
+ "/community/2026-09-30-community-meeting-transcript/": {
+ "about": "wasmCloud",
+ "mentions": [
+ "ComponentModel",
+ "Python",
+ "Rust",
+ "WASIPreview3",
+ "Wasmtime",
+ "WASIBlobstore",
+ "OCIRegistry",
+ "AISandbox"
+ ]
}
}
}
diff --git a/static/img/community/2026-09-30/image001.webp b/static/img/community/2026-09-30/image001.webp
new file mode 100644
index 00000000..38661cf9
Binary files /dev/null and b/static/img/community/2026-09-30/image001.webp differ
diff --git a/static/img/community/2026-09-30/image002.webp b/static/img/community/2026-09-30/image002.webp
new file mode 100644
index 00000000..3e6a4ce8
Binary files /dev/null and b/static/img/community/2026-09-30/image002.webp differ
diff --git a/static/img/community/2026-09-30/image003.webp b/static/img/community/2026-09-30/image003.webp
new file mode 100644
index 00000000..6a4266b3
Binary files /dev/null and b/static/img/community/2026-09-30/image003.webp differ
diff --git a/static/img/community/2026-09-30/image004.webp b/static/img/community/2026-09-30/image004.webp
new file mode 100644
index 00000000..d2a28fa9
Binary files /dev/null and b/static/img/community/2026-09-30/image004.webp differ
diff --git a/static/img/community/2026-09-30/image005.webp b/static/img/community/2026-09-30/image005.webp
new file mode 100644
index 00000000..4bb75cde
Binary files /dev/null and b/static/img/community/2026-09-30/image005.webp differ
diff --git a/static/img/community/2026-09-30/image006.webp b/static/img/community/2026-09-30/image006.webp
new file mode 100644
index 00000000..b8fa8ac3
Binary files /dev/null and b/static/img/community/2026-09-30/image006.webp differ
diff --git a/static/img/community/2026-09-30/image007.webp b/static/img/community/2026-09-30/image007.webp
new file mode 100644
index 00000000..5d9ed915
Binary files /dev/null and b/static/img/community/2026-09-30/image007.webp differ
diff --git a/static/img/community/2026-09-30/image008.webp b/static/img/community/2026-09-30/image008.webp
new file mode 100644
index 00000000..c3ec76ac
Binary files /dev/null and b/static/img/community/2026-09-30/image008.webp differ