Transcript: wash RC6 — Persistent Blobstore, Virtual TCP Loopback & The Path to wasmCloud v2
wasmCloud Weekly Community Call — Wed, January 21, 2026 · 19m 24s
Speakers: Bailey Hayes, Lucas Fontes, Eric, ossfellow, Colin Murphy, Jeremy Fleitz
Full Transcript
Jeremy Fleitz 00:06
Hey Bailey, everybody. How's it going? I still want you to be the only person on camera to start off.
Bailey Hayes 00:14
I appreciate it. Better than looking into the void looking back.
Jeremy Fleitz 00:20
Even though I probably have broccoli or something in my teeth. Impressive you ate broccoli.
Bailey Hayes 00:35
Broccoli, celery, carrots and some hummus — the meal of New Year's resolutions.
Bailey Hayes 00:51
As usual folks — we wait till 1:05 to get started. Haven't hit live or anything, so none of this is being recorded by YouTube. I think it's being recorded by Liam, though.
Bailey Hayes 02:52
RC6 rolled out and we've got more work to do — we'll be giving an update on that. Getting close. Hey Liam — will you hit the live stream button?
Bailey Hayes 03:54
Hello and welcome to the 21st community call for wasmCloud. Today I'm expecting to be a short one. We just reached a major milestone — released wash RC6 yesterday. That rolled out quite a lot of feature changes with a goal toward simplicity — really narrowing down our scope for what we want to commit to for a major 2.0 release. Lucas, if you're game, maybe chat a bit about what's in RC6. I know you gave a demo last week — what's in RC6 and what's coming next? Are we done?
Lucas Fontes 04:36
Let me share my screen — release candidate six is out as of yesterday. Plenty of new stuff, both in terms of changes in behavior — especially in wash dev, nothing to do with wash host — and inside wash dev, significant changes in configuration expectations, build environment, how wash dev behaves.
We also took the opportunity to clean up the code base in terms of linting and usage of expect/unwrap. We made sure there's no possibility of panics in the critical path — quite important for software that should be running 24/7.
What I want to touch on here: between RC5 and RC6 we got one new example in the code base that might be interesting. A QR code generator in WebAssembly — in the wash repo under examples/qrcode. You can run it with wash dev. Once it comes up you have a little UI to generate basic QR codes, or you can put in URLs and these URLs will be valid.
Take a quick look there if you're looking for an easy way to create a component that receives HTTP, processes an HTTP POST request — pretty much a very straightforward way to get the overall inner workings of how to build a WebAssembly component that's actually doing meaningful work with the request.
This is an image — but this is not SVG, this is not being rendered at the browser. This is actually a PNG generated server-side, streamed back to the client. One of the examples we took to use wash dev to do the dev cycle and see how wash dev is living up to expectations. Colin — see your mic is open, you have a question?
Colin Murphy 07:33
No I do not — I just didn't mute myself when I joined. Sorry.
Lucas Fontes 07:39
I thought you heard image processing and were like "this is my thing." New example here showing some pretty interesting patterns — how to do component HTTP, how to serve static HTML, how to do error handling. Notice the code here is 71 lines and it's taking care of the QR code generation, HTTP parsing, the UI, and so on.
In terms of work going into the release — release candidate six is out and is one of the largest release candidates we've had so far. If you go through the list you'll notice changes both in the Rust API and in the behavior of the wash CLI itself.
We took the opportunity to introduce the Blobstore and wasi-keyvalue plugins backed by file systems. This means when you run wash dev and add things to your Blobstore, you can stop wash dev, restart it, and data will be there. Before everything was in memory. Now we're backed by file system, and you can pick which directory backs Blobstore and KV.
We did a lot of work in service and component communication — both in terms of correctness (making sure the proper Wasm context is being passed around) and in implementing virtual TCP/IP loopback. What this means: components can now connect to services over localhost (127.0.0.1). You can run a long-running component that opens a TCP port, and only the components in that workload can communicate with that TCP port. If multiple workloads are trying to open port 80, they can do that because their interfaces are virtualized now.
Plenty of stuff. We're getting more into a testing phase now — making sure everything works as expected and is correct.
In terms of project planning — is RC6 the last one? Are we close to an actual release? I think we're really close — to the point we could start leaning toward making RC6 the release. However, I feel there are three items we likely want to get in before we call this complete:
First — a pull request that's been open for a while. More a matter of rebasing and having a chat. About using an internal Kubernetes identifier instead of creating one on the fly. Requires changing things in multiple places. Plays into consistency — to guarantee we're never sending workloads to the wrong host.
Second — about security. Right now both the runtime operator and wash host do not support NATS authentication — any type. This PR makes sure we can use client certificates for NATS authentication. The PR itself is pretty straightforward. There's investigation: will TLS certificates be the only way we authenticate to NATs, or do we need to support tokens, NATS credentials files, etc. Anything we do here has to be reflected in the Helm chart and supported with security concerns in mind. Getting the authentication code inside the host is not the main problem here.
Third — an outbound transport system to make our HTTP calls gRPC-aware. Right now if you try to use a gRPC client you're going to have issues with trading headers. This PR automatically makes the host figure out you're in a gRPC environment by checking HTTP headers, and if so use a more gRPC-compliant implementation of the HTTP libraries underneath. gRPC on top of components will be essentially transparent.
If we get these three in, pretty sure we are in a good spot. The other items in our to-do list are not so much "go do code" as "while doing the validations for the release, make sure these things have been addressed." These have been open months before and a lot has changed — more about verifying the expected behavior is actually correct. So in reality, three items, getting them to the finish line and iterating.
If any questions, anything else to chat about, we can also jump into that.
Bailey Hayes 14:41
Thank you Lucas. Anybody have questions for Lucas?
ossfellow 14:58
Quick question — the release to v2 will be along the way of moving to the main wasmcloud/wasmcloud repository? Because Lucas talked about it a couple sessions ago. I wanted to see — is it going to be different?
Bailey Hayes 15:24
That's still the plan. We're doing the best we can to make sure we don't impact v1 in any way possible while we're iterating. But once we are ready and v2 is officially our latest supported major version — what we'll do (Lucas correct me if I get this wrong): effectively move what is wasmCloud v1 as its own repo out of our main wasmcloud/wasmcloud, and move what we have in wash as wasmcloud/wasmcloud. We'll be releasing artifacts from wasmcloud/wasmcloud.
ossfellow 16:02
Awesome. Thank you.
Bailey Hayes 16:12
Good question. Anybody else? One thing for RC6 — now that it's out, we're updating documentation. wasmcloud.com is being updated for it. Eric did a first pass already, that's up in PR. He's going to update it today. We'll probably land it tomorrow or so. Eric, want to speak to that?
Eric 16:38
You said it all — it's up in the PR, you should see it merging today.
Bailey Hayes 16:43
That'll be helpful — there were obviously config changes as part of this. Most people's step to update will be updating their config to match the new schema if they're using the RC6 binary. Lucas added a version identifier that's optional — you don't have to put that in your config YAML, but it's one way to see drift, and it'll help us going forward as we stabilize, having a set version we can keep as part of our schema.
Thank you Eric for taking a swing on that doc — we'll post a link to it once it lands in wasmCloud Slack.
I called out two other issues of the week. I really enjoyed the conversation Lucas and Pavel were having on API design — going to drop this link in chat. It's wash issue #230, iterating through API refinements we want to make. A lot of that has already landed as part of correctness — the context PRs Lucas reviewed and merged.
On the other side — Lucas called out we already added additional lints to prevent panics. Those were high priority. There are a lot of others I'd like to add to improve code quality, but not as high priority. I've called them out in issue #235. I plan on Claude and I iterating on that in the background, but it is definitely lower priority and non-blocking for our release. More focused on getting correctness and making sure we're feature-complete so we can release.
I think that's all today. Anybody have other topics? Community announcements, anything? Anybody get a talk accepted?
Bailey Hayes 19:06
I know a few awesome cloud talks that got accepted, but I'll keep that as a secret. Alrighty — thank you everybody. Hope you have a wonderful rest of your week. Bye.