Transcript: WASI P3 Roadmap, wasmCloud Secrets Plugin & NATS Messaging Interface
Transcript
Aditya 00:08
Howdy. Howdy. Hello.
Bailey Hayes 00:23
I joined a touch late. Liam, do you mind also giving me full host so I can do the live stream? Yeah, thanks.
Liam Randall 00:32
I was already doing it, Bailey. Just waiting for you to hop on.
Bailey Hayes 00:36
Cool. I was just merging the agenda, which today is pretty light. Well, it looks light. I think we'll spend quite a bit of time going through the review of the roadmap, and then Eric's got some new docs, so we'll run through that. Are there other items people want to add before we get started?
Bailey Hayes 01:01
Cool. And we start at 1:05. Aditya, you had a chance to look through — did the roadmap look what you expected?
Aditya 01:13
Yeah, it's got pretty much everything I wanted. There's quite a few questions that I wanted to ask about one or two tickets.
Brian Boynton 01:40
Nice to meet you. Yes, nice to meet you too. Thank you for the invite link yesterday. Appreciate that.
Bailey Hayes 01:51
Whenever we have new folks on the call, we usually invite them. We haven't — so we started at 1:05 technically, so we haven't hit the custom live stream or record or anything. When new folks join, we invite them if they want to introduce themselves to the community. Would you be interested in that? And if you're not, that's okay, and I will call you out.
Brian Boynton 02:12
Yeah, I'm an Ear, Nose and Throat surgeon switching over to tech and bound to Rust in the component model. I'm like, this is the solution. This is it. This is what I'm looking for.
Bailey Hayes 02:25
That's so cool. Okay, all right, so I'm gonna hit record. I'm gonna ask you more about your story, because that is such an interesting genesis. And I think a lot more people want to hear it. A lot of folks don't join until we hit 1:05 Eastern time directly. So we're not quite there yet.
Brian Boynton 02:50
So I'm working on a demo before you hit record, and one day I'll share that with you. I'm deep into WASI P3 component model.
Bailey Hayes 03:02
Yeah, me too. How's it going?
Brian Boynton 03:08
I'm working and making changes, and it's like — yeah, I'm so far deep. I'm like, wait a second, I think I already changed that. Does anyone have it working full all the way through hitting async, not just sync?
Bailey Hayes 03:28
Yes, now we do. So if you try out wasmCloud directly, we actually have it now behind a flag for P3 and we've got a couple example components that exercise it. The HTTP one specifically does async, although I found some things that I need to do performance-wise. And I have another ticket that's like "harden the implementation." That's sort of my roll-up for several things that I need to do to make it better. But yeah, we should do a demo — that's important work.
Brian Boynton 04:03
Yeah, it's important work. We're building on that for sure. Cool.
Bailey Hayes 04:32
Hello and welcome to wasmCloud Community Call for April 15. Last week, we did a collaborative roadmap session where we went through top issues that we requested from the community. We did a dot-style voting of the folks who were on the call. We triaged from that list, and now we have a project in GitHub under wasmCloud for our roadmap, which I believe is basically the finalized version of our roadmap. Of course, we can make changes throughout the quarter, but the goal is to roughly scaffold out what are the big things that we're trying to hit as a community before we get to July. And you know, little stuff of course can come in, and sometimes we learn new things and we've gotta be agile about it — and that's okay. But you create a plan, and sometimes the act of creating the plan is just as valuable as having the plan itself. So I'm going to run through that, but before I dive into that, I'd like to introduce a new person that we have on the call today. Should I call you Dr. Brian Boynton?
Brian Boynton 05:53
Call me Brian. That's completely fine.
Bailey Hayes 05:54
Cool. Hey Brian, do you mind introducing yourself and how you ended up here?
Brian Boynton 06:02
Yeah, I'm an ear, nose and throat surgeon switching over to tech. I guess I'm still practicing, but I found the component model and I'm like, this is the way forward. This is it. This is the solution. And so I'm deep into Rust and WASI P3, trying to get that working. I have a registry for myself and others — that's a build on everything.ai — and it's working for synchronous, trying to get async going. So that's where I'm at.
Bailey Hayes 06:37
Very cool. Are you building on top of wasmCloud for some of the stuff that you're doing, or are you more interested in some of the WASI P3 work that we do also as maintainers here?
Brian Boynton 06:47
WASI P3 for sure, that's my future. Yeah, it's just awesome. I have task-driven searches through components, and it's just awesome. I mean, that's the way architecture is going to be for software. That's the future for sure.
Bailey Hayes 07:09
Well, I have a couple of things in that space that we should totally call out. The first one I'd like to highlight is component interposition. Have you seen this project? So Elizabeth Gilbert, who is a PhD student at CMU, created this project. She's made a number of other things, and I think I've convinced her to write a blog post about this to share it more broadly. But she really goes through some of the power of what you can do with WASI P3 and composition, specifically focusing on the WASI HTTP new middleware interface that we provide, and all the different ways that you can compose components together — where you could even order your middleware, for example, making sure that authentication middleware is always first in the list of middleware that you go through. And she does a really great job of explaining how all this comes together. And even better, she gives you a shell script that helps you get things building for P3 and so you should just be able to clone this and run this, and it will actually get you to something that works, which is a great place to start for anybody else who's totally brand new to P3.
Now, on our team and on the call is Eric Gregory, and he is one of the folks that are in SIG-Docs within the Bytecode Alliance, and they're responsible for being the maintainers essentially of wasi.dev and the component model book. And so he's going to be leading out getting that refreshed and updated for some of the WASI P3 stuff. Is there any more you want to add there, Eric, that maybe I didn't hit?
Eric Gregory 09:29
Nope. You know, that's going to be a big effort, and it's ongoing over the next week or two especially. But yep, work is underway.
Bailey Hayes 09:39
Yeah. And tomorrow we have our WASI subgroup update that is within the W3C, where we're focused on the spec side of the world and making sure that we've got a strong standard before advancing to phase three — which is sort of like the launch of WASI P3 essentially. And the last few things that are holding that back is having a full, complete second reference implementation with 100% tests. Victor Adithya, who's also a wasmCloud maintainer, is working on that and he's getting pretty darn far. So we're really in — I think less than a month out. Aggressively less than a month. You know, aggressive goals, honest status is the saying there. So I think we might pull it off.
So this is our roadmap. I have it here, and essentially our goal is to have basically full WASI P3 support by the end of the quarter. I think we can pull this off. We do already have the first part of this in the latest release of wasmCloud, but it's behind a flag, and the flag is not default. Where I would like to be is that it is a default flag by the end of the release, but I do still like the idea of keeping it behind a flag — at least for some time — in case folks are running systems and they exclusively only support P2 for whatever reason, for their pipelines or for their hosts. So I want to make sure that they still have the ability to disable it.
And actually, I call it "ready for work," but it's not actually ready for work. It is totally in progress. We've already landed a few things since running our roadmap session from last week, and this one was from Jeremy, giving us basically a much more Kubernetes-native way of doing routing. And so this has already been merged and released. So roughly, this is what our roadmap looks like. And I believe we already have some questions on some of the things that are here that we want clarification. So I figure let's dive into that, Aditya, and then if there are others that folks are interested in, we can go through them one by one.
Aditya 12:48
Yeah, hey everyone. I wanted to discuss the multiple backend instances. I think I've mentioned a point there that I wanted to discuss. So the approach that is being proposed is to have named interfaces to override the backend implementation for the interfaces. But when it comes to the multi-path HTTP routing, it's kind of an inverted logic where basically the runtime decides which components to invoke. So instead of having a named interface, there's the — I believe there's a YAML manifest I've mentioned that has the interface-specific override for each component.
Bailey Hayes 13:57
Do you not have the case where other components inside your workload want to call each other — like, I have an endpoint for accounts. Accounts goes as its own component and deals with accounts CRUD operations. And then it says, okay, well I need some information from user, and then it hits the user path. Do you have that use case?
Aditya 14:25
Yes, because we have a workload where two different components export an HTTP incoming interface, and we do need the full HTTP path-based routing for that.
Bailey Hayes 14:43
Yeah. So my main thought there was that if we know — from both component composition perspective and from the host perspective — what different APIs, basically what the instance name is backing that incoming handler, then we would be able to have components call other components, and also have the host do the routing. So with your change right now, which is awesome and cool and we could totally just get that first part in if we wanted, it's doing it from the host side. But I think with that other implementation, it doesn't do it for the component-to-component side.
And the second reason why I think it would be really cool to have that is that it would also work for composed components, which we don't support yet either. The third reason why I think this would be a cool way to do it is mainly that obviously this is the direction the spec is going. Now, you could talk me out of making the spec changes potentially, but I know that there are places like Akamai and Microsoft and Fastly that have all expressed interest in that design. And so I think even if I don't do it, somebody else will. So I want to make sure that we're charging towards that standardization path, so that we're not too different and get left behind.
Aditya 16:13
No, yeah, totally. I get it. I was just playing devil's advocate and exploring. I appreciate it.
Bailey Hayes 16:20
I mean, we can definitely do it. I don't know if you saw my original change to include names. I actually had a dynamic router inside it, and that was basically like, okay, I'm afraid I'm going to be too slow in the upstream. So what will we do if it's not there? And I want to be clear, I am always okay with us adding, effectively, host magic to fill the gap between what doesn't exist in upstream and what we can do today. And that's essentially what you did — it's the category of host magic, which again, totally fine.
So I think if we think that we can't get it done in, let's say, three weeks with something behind a flag, and we want to go faster, we should just go ahead and do the host magic. I think three weeks is pretty aggressive for getting it plumbed all the way through components and everything else. I did actually do an update with Luke Wagner on this yesterday, diving into it — it was him being like, Bailey, hey, your PRs, I want them updated a little bit to deal with this extra syntax that I came up with called External ID. And people are asking me what's the status on it, so can you get back and do it, because we're ready to merge it. So three weeks seems pretty possible actually. So I think let me take my swing at it, probably next week, and if that doesn't happen, we'll go the host magic route to get something solved sooner.
Aditya 17:56
Totally. Thank you for your clarification. I had another thing that I want to discuss, which is with regards to the wasmCloud secrets plugin. So we have WASI config right now, but it only loads the Kubernetes secrets once during start time. Is wasmCloud secrets meant to support use cases other than that? Because WASI config loads stuff into the environment — I believe wasmCloud secrets is basically meant to overcome that.
Bailey Hayes 18:38
Yeah. Okay, so a little background for other folks. Essentially, the way that things work today is that by default, when we build a host, it has a default set of plugins. When we're deploying on Kubernetes, we are basically talking with our API to go fetch secrets — and that's from the external secrets operator in Kubernetes, which is kind of the industry standard way to do that when you're in Kubernetes. And today we plumb it straight through to WASI CLI environment. And we can also optionally put them on a blob called WASI config.
The reason why we opted not to start with wasmCloud secrets and have the default mode be WASI CLI environment is that we wanted existing programs to just work as best they could. And for people who are choosing to be component-native, choosing to embrace the more expressivity that you can do with defined capabilities — if you're opting into wasmCloud secrets, this was an additive thing that we can add outside our initial MVP when we shipped v2. And so I'm proposing that we bring back something that we did have in v1 but we descoped it out of our initial MVP.
Now, Aditya's question is, will this run at runtime — like, will this go fetch from some secret store? My initial thought was no, actually. Let me give you background on why, and which is also why I'm keeping the API synchronous here. If we wanted it to be async, we would actually want to say async here and do this for P3.
My main reasoning: I want it possible so that we can, at deploy time, be declarative about all the resources that we need. When I actually think of component-native architecture and design from first principles, one of the most important properties that we can't lose is that it supports declarative resources, and that I can take a .wasm file, independent of config and all this other stuff, and know — oh, it needs X, Y and Z. And that is the biggest downside of why I don't like doing WASI CLI environment variables — it doesn't say what environment variables it needs. It's not clear at all. I want to be able to, at some point, express that I need these specific secrets, and if I can't get them, fail. Like, don't even instantiate me, because I can't work without them.
Bailey Hayes 21:59
So that doesn't solve this problem entirely, to be clear, but it's a step in that direction. The idea is basically that I want this to be a capability that only the host has, not necessarily that the component itself has. So since it's dealing with secrets, it's something that is done in a secure context. I trust that the host plugin is allowed to go and do this. It will go and get the secret from my secret store, whether that's through the external operator or — the benefit of having this interface here specifically is that it makes it easier to create host plugins that can talk to other things. So if we don't want to do the external secrets operator, one of the big motivations of this was, I think a lot of people just want to talk straight to Vault. So this will let folks add a plugin that does exactly that.
Now, I want it to be synchronous in that when I start a component and it's getting deployed and it's about to run inside a workload, I want something else to have already fetched the secrets that it needs before it actually runs. And if it fails in that process, then it doesn't get scheduled on that host — because potentially the reason why it failed is that the host didn't have the right permission to connect to Vault in this scenario. And so that's what allows us to retain the properties of remaining declarative throughout the whole pipeline, and we're explicit and declarative in our workload deployment.
Taking an even further step back — what is a workload? Our workload deployment spec has N number of components and one service inside it, and then it has config and secret values inside it. And the main reason why we are very expressive about the individual config and the individual secrets that we're passing in is that we didn't really have the expressivity that we want inside a component, inside WIT, to be able to be declarative about the resources that we need. So because we couldn't do it there, we put it in the workload deployment. I'm expecting to be able to bridge that gap in the future, potentially with the same External ID approach I was talking about for HTTP routing — that's sort of my main idea on how I'm going to bridge that, having a specific External ID for the secrets that I need for wasmCloud secrets. So I'm sorry that was a lot. Does that make any sense at all?
Aditya 24:25
Yep, that made perfect sense. In fact, I wanted to show off a project that I've been working on. It's called wasm-to-env. It basically takes a Wasm file and uses Walrus, and it goes through all the deterministic pathways, and it specifically looks for WASI CLI environment and WASI config store get, and it returns those specific environment variables that are located at that offset.
Bailey Hayes 25:03
That is so awesome. Yeah, that is what I wanted to see in the ecosystem.
Aditya 25:08
Yeah, and I've been able to get it to work, and it works pretty good.
Bailey Hayes 25:13
Can you drop a link? I want to pull that up.
Bailey Hayes 25:19
Let me do one little plug — if you haven't tried it out, there's another thing that I think is a spiritual successor to Walrus, called Worm, that will give you even more component APIs. And I shouted out Elizabeth's component interposition project before — Elizabeth is the maintainer of Worm as well, and a lot of her good stuff is in there.
So you might want to check that one out, but I'm going to bring up your project here. This is what I'm talking about. You get it. This is exactly where we want to be. Now, this one is kind of similar to also another project that I've been collaborating with Elizabeth on, called Splicer, and she's got a concept in here of an adapter component, which is essentially what you've built. What you've built is effectively an adapter component in that it's also like this other cool project — if you haven't seen, you should also check out — called wasi-virt. Have you seen this one, Aditya?
Aditya 25:50
I have not.
Bailey Hayes 25:52
Okay. Pretty cool. So this one — I want to revisit in the world of P3 — but essentially it will virtualize and give you declarative deploys for each one of these WASI interfaces, including environment, and it will bake it in just like you did. And this is P2-specific. I think we can do better. Guy and I came up with a design for this — sort of like, we kind of got stuck with P2 composability constraints, and what we wanted was for each one of these to be its own modular component. And what we ended up with is one component that we build — it's like, okay, since we only get one composition, you get one uber virtualization component. Knowing that in P3, we'll be able to make it modular. And I think that's the future.
So the combination of what you did, revisiting wasi-virt, and using tools like Splicer to be able to build that — I think we can get to some pretty sweet stuff.
Liam Randall 27:35
I'll drop a detailed link in wasmCloud Slack — an example that Bailey and I did on stage. We've done it a couple times, and I'll link to the video as well. I'll put that in there here in the next hour. Brian, if you're not on our Slack yet, you can just go to slack.wasmcloud.com and it'll let you click right through and join the community.
Bailey Hayes 28:04
Okay. Well, more questions on just the wasmCloud secrets. One specifically —
Brian Boynton 28:11
I have a question. So the goal here is wash will then inject in the secret into the component?
Bailey Hayes 28:18
Basically, high level, yeah. The step would be — instead of reading an environment variable off a WASI CLI environment, the component would import wasmCloud secrets, and then it would run get. So it's a wasmCloud secrets get, and it would get a reference to the secret.
And this — I want to highlight — this reveal step. It is completely for expressivity — that people could add in for auditing and logging and knowing at what point in a component did reveal get called. And it's only important actually in composed component use cases. So imagine you have a top-level component, and it knows, hey, I need all these secret keys. Like, I have one thing that goes and talks to DynamoDB, and I need the API key for that, and I've got another one that writes to Postgres. So I've got like a sort of document store type thing, and I've got something that maybe is dealing with more CRUD — like account management. And so I've got two different secrets, and I actually, as a component, have composed in two components to deal with those two different properties. Each one of them are their own component, and it's all composed together in one top-level component, which is the app.
The app may say, all right, I need these API keys for these two things, and then it passes that key down to the sub-components, but they only get the key for the thing, the resources they actually need, and not all the keys. And you could do a virtualization of not giving all the keys by doing these essentially adapter proxy components — like what Aditya built. You could say, all right, when you get composed, when you get WASI CLI, you only get this one, and when WASI CLI calls you, you only get these keys.
It's a little weird, a little hokey, versus having this API of reveal where we say, okay, top-level app component does a get, second component here actually runs reveal on exactly that secret. And so I know that not only did you go and get the secret, but you also used it. And I know which component instance inside an entire composed graph which one actually used it. And again, it's not necessarily a security feature. It's completely that we can add a lot of different expressivity about what the component graph is doing.
Brian Boynton 31:03
Gotcha. And then the secret will be stored where?
Bailey Hayes 31:07
So today it's essentially in memory inside the host. And then when you run get, it's still in memory on the host. This resource is owned by the host plugin. The host plugin itself has the secret ref. And that is also kind of an interesting property of using resources for this problem versus using just a string primitive. When you run reveal, you get a secret value, and that's when it's in memory inside the component.
Brian Boynton 31:41
I get you, and then that can be logged. That's a brilliant solution. I need to add that to my vault.
Bailey Hayes 31:48
Yeah, there's a lot of tricks there. And I mean, hey, the whole idea is like, what can we add in wasmCloud that is generally industry standard and useful to just about anybody? We want wasmCloud as a platform to be the picks and shovels you need to build any type of platform.
Aditya 32:07
I had a question — to make wasmCloud secrets backed by something, we would use external secrets at the runtime operator layer, I believe, or would that not be the case, and we directly go for Vault?
Bailey Hayes 32:27
So the default implementation — I think I did actually remember to call this one out — the default will still be the external operator with Kubernetes. Effectively, the only change to somebody that's using things today is they could now add a component that imports wasmCloud secrets. So almost no change in behavior, other than you get something that's more expressive about what you're doing.
Being able to reference secrets later, you could do more interesting things with your platform. We could put a lot more observability specifically around "you're messing around with a secret." The other thing that this would eventually enable is doing things like — ooh, that is actually typed as a secret. The challenge with WASI CLI environment is that you've lost all typedness about it. All you know is like, this one might be totally fine to log because it's "this is my logging level," and the other one is like, "this is my API key." So the general approach — what everybody does — is just be careful. And instead, we can say, let's make sure if it has a type of wasmCloud secret, we can actually trace through the code and prove whether or not it's okay. The way that other tools existing today are like, "let me look for the word key and let me look for the word password" — it's so weird, but that's how modern software is written. And we want to still make sure those use cases work, but we can do better.
Aditya 33:59
Yeah, there's a lot of heuristic-based determination, which we want to avoid. Exactly.
Bailey Hayes 34:06
Yeah. So there's so much more we can do, but you gotta crawl, walk, run. This is the first step. Get the types. That was good. Any other ones we want to go through?
Aditya 34:22
The HTTP client plugin, which is in progress — is that with reference to the outgoing handler that we've been working on?
Bailey Hayes 34:38
It is, yes. So we've got this one here. I know I've been slow to come in here and respond. I just rocked up and I was like, I think I broke what you did. That was basically all I had left in your comment. I think we should, if you're — oh, 54 minutes ago, heck yeah. I think basically do the builder pattern. Let's make sure this works for both. And I just hadn't had a chance to totally dive deep on it.
It is going to run into something else, actually. No, it won't run into this at all. But since I already said it out loud, let me just show you this one thing. This is relevant for the other direction, and I think we'll touch some of the same code. What I found when I was running micro benchmarks is that the construction of our store context is like — once I solve this, we were roughly 4x slower than Wasmtime. After Wasmtime added this new feature, I have a fix already that basically implements this. And when I measured that, I was still missing about 1x basically. And the 1x — like, 10% of our time — is actually just the reconstruction of our store context, because we do it in a threaded way. And we do it in a threaded way because the volume mounts themselves are async. And I'm like, I think I can make all that sync. And then if I make it all sync, then it's just all simple, fast CPU calls.
Anyway, since I'm mucking about in your store context, I'm probably going to break you again, but maybe you should beat me and then I'll adapt all of these.
Aditya 36:34
Yeah, I'll keep an eye out for that. And yeah, just for context, I will try to implement it around the PWD builder pattern as well. Because I believe those are distinct types with the socket crate.
Bailey Hayes 36:49
They are. I made them separate because I ran into a bug, actually. So I've got a little TODO in there for P3 where I run .collect(). You need that because there is a legitimate async bug that I ran into that we're getting fixed in upstream Wasmtime, and then I can back that back out. But that also, I think, is going to be fixed relatively soon. But that's a large part of why they have different function calls — they have to have different runtimes.
Aditya 37:23
Yeah. Thank you so much. That's all I had to ask. I don't have any more questions.
Bailey Hayes 37:30
Cool. Anybody else? Any more that would be fun to talk through? We essentially — this is what the roadmap looks like. Now, Jeremy helped me a ton earlier today where he helped just run through these and get tickets filed for some of the dot-voting that we did. And roughly, we tried to leave little breadcrumbs that we got all of these groups together and filed, and for the most part, we've handled them.
I wasn't quite sure what to do on these two, mainly because I don't think we heard what scheduler is desired. And just as a taster, for anybody that feels strongly — maybe you can help me file some issues around it — some schedulers that I'd personally like to see: it would be really straightforward to create a KNative host, like it is super in reach. And that would be fun because then that would work in some existing ecosystems. We've had on and off Nomad in the past, although after HashiCorp doing HashiCorp things, Nomad has really fallen out of vogue. But the clients are Apache 2, so I'm totally chill if we want to include that as an example. One that I personally think would be really useful for most people is ECS as your scheduler. And in that same vein, Cloud Run inside Google Cloud — a couple of these might be pretty neat.
And there's another one — I think it's called something like Akri — for IoT and edge development that might also be cool. I had tossed this one out as an option for something that we could target as a community, but folks didn't really bite on it too hard, so I did not bring that into the roadmap. But I think if we were to do it, these two would go hand in hand, because a lot of folks use those together.
Liam Randall 39:45
What about something as simple as a flat file? Where would that go — like if you think about an edge deployment that is denied, disconnected, intermittent, limited? What do you think the option would look like for something in that case?
Bailey Hayes 40:03
Well, I mean, I would argue that's already what wash dev is. wash dev takes a config file and loads that component, and you can pass it a local file ref. I think I would just continue extending that. The config YAML for wash is meant to basically be a developer-friendly, limited version of what you can do in a workload deployment. And if you want to do more in a workload deployment, then just use a workload deployment.
So I think in the world where you might want to run a lot of things that are disconnected — without an external scheduler — and you want a flat file, I think that flat file is literally just lots of workload deployment YAML, all shoved into one directory, and then it loads straight from that. And all that would be is a tiny little script starter that's just like workload start, workload start, workload start. And then that would be it — it would just take the workload deployment, which you could already do with what we have called wash lit.
So inside our host, we have a couple different hosts. A lot of people don't realize that. So you can run wash dev, you can run wash host, and you can also mess around with wash lit. And wash lit is probably the closest to what you're asking for here. But for anybody that's interested, it's really easy to DIY your own host. We designed it that way so that you just need another embedding of the wash-runtime crate, and then it's just a different type of start mode.
Liam Randall 41:55
Thank you so much, Bailey. That was really informative. We should maybe think about getting a doc together on the host modes there.
Bailey Hayes 42:02
Yeah, you know, but again — if you're running DDIL and you're disconnected, I would argue that you're not always disconnected. I would argue that in a lot of cases, you actually want an agent that's still reaching out to a hub, and that you're actually a spoke. And so in a hub-spoke architecture, I would have an agent that gets information whenever it gets connected. Otherwise it's just wash host — that's all it would be. It's already the host that we have with a little agent. That is the thing that actually is talking out to the remote host. That is how I would design most IoT edge solutions — not necessarily flat file. Flat file would be like, I've got a box that I'm never going to update again. Let me go shove it out somewhere and leave it.
Eric Gregory 42:55
I just want to shout out real quick — we do have documentation in the runtime section that talks about wash lit and breaks down when you might want to build a custom host, use wash lit, things like that. So if this is something that you're interested in, definitely check that out.
Bailey Hayes 43:10
Yeah, check this out. Nice job, Eric. I forgot this was here. Yeah, and we have a host builder that helps you do all of this. Exactly. So I think the answer for most IoT edge is this one — this is the one that we basically are doing inside Kubernetes, but would also be really great for hub-spoke — the hub being your Kubernetes cluster and spokes being your IoT hosts that are still just communicating over NATS. And NATS being the thing that effectively is acting as that agent that I was talking about. Nice job, Eric, thank you. And actually, we had other docs that you wanted to give a shout to. Do you want to tell me where to open?
Eric Gregory 44:09
Sure thing. So our newest docs — and this is unrelated, but hopefully useful to some folks — they are in the language support section under TypeScript. And specifically, I want to call out the file system and configuration docs here. So we have, for a while, had in our operator manual instructions on using file system resources in Kubernetes volumes providing those to components, but we haven't had docs on how to actually consume that from the component authorship side. So this is filling that gap, and the configuration page does something pretty similar with consuming configuration data that you may have provided in the various ways that you can do that in wasmCloud v2.
Both of these have companion pages in the operator manual talking about how to provide those things to the system. Worth noting also — the file system page starts with the HTTP service hello template that we have in our TypeScript repo, and then it adds the file system functionality. But we also added to the TypeScript repo a complete sort of finished-state version of this page, so you have a ready-to-work-with template with file system functionality if you want to play around with that.
Bailey Hayes 45:27
Yeah. So basically you're saying you started with the hello template just so you could show what it takes to add it, and that's why the doc does that precisely. Okay, will you show me the operator changes that you did that are companion to this? Is it the file systems and volumes?
Eric Gregory 45:47
Yeah, and those are actually pre-existing pages. Those aren't new, but like you say, they're kind of companions to those developer-side pages that are new.
Bailey Hayes 46:04
Yeah. Anything else folks would like to see in this area? You know, you got Eric, who's the best doc writer there ever was. Here's a good time to put a bug in his ear for other things you want to see. We did capture one thing on the roadmap —
Eric Gregory 46:24
Maybe, yeah, it was host plugins versus services — when to use them.
Bailey Hayes 46:32
Yeah, exactly. So we do have this one as something that we already want captured on our roadmap — to add a lot more explanation around that and other examples too. There was also an example ticket around it.
Awesome. Well, that is everything that's on the agenda today. So given that, are there other topics people want to go into? Questions they have? Things that are challenging?
Aditya 47:06
Yeah, so I've been running into a use case when I'm using wasmCloud messaging with the NATS source plugin, and I was wondering if it was possible to use NATS JetStream to do something like a message replay, rather than just fire and forget. Would folks be open to that — to make a change to wasmCloud messaging?
Bailey Hayes 47:36
I think what I would love to see is a NATS-specific WIT interface. If you want my strongest preference — NATS gives so many more things than the common denominator, like what a generic off-the-shelf event bus provides. And the semantics around "is this send once" or — especially when you're starting to talk about durability of the message itself — it's so specific to the different event buses.
And I've always wanted this, for what it's worth. Like, this is something I've always wanted to see, and I've seen some pretty awesome people make their own, but I don't have access to their WIT definitions. But I have seen this in the wild, where folks have gone and just created basically a WIT definition that's specific to NATS. I would love to host that in wasmCloud. I think that using wasmCloud messaging is nice in that you get some portability, but I think it's very, very, very rare that people basically jump around event buses. You know, that's like changing databases.
Aditya 48:50
That's what I thought. Because NATS seems to be the only one, or limited one of them, to have some sort of persistence for the messages. And wasmCloud messaging is more of a just a plain event bus, so doesn't really support that. So I totally get what you mean by having a NATS-specific WIT interface, and I think I would be keen on implementing something like that.
Bailey Hayes 49:14
If you are planning to do it this quarter, please create an issue and let's go ahead and add it to the roadmap. I think people would really like to have that. Do consider the case on local dev loop on that one.
And also, big shout out to somebody else in Slack — was it today? It might have been today, could have been yesterday — but they were asking us about could they do NATS connectivity with the wash dev loop. So if you had a NATS plugin, it would be a much more natural fit for wash dev and wash host, rather than the trick that we're doing today, which is very much like — everything for developers is all local, no dependencies, solid memory. It's just file system. We've been trying to keep it tiny.
Aditya 50:07
Yeah, I totally get what you mean. It would get a lot easier to include NATS into the wash dev loop itself. So hopefully, if I find time today or tomorrow, I should be able to create an issue request on the wasmCloud repository. And yeah, I'd love to get everyone's thoughts on it. It's a lot more collaborative than you think. So please let me know.
Bailey Hayes 50:34
Nice. Yeah, you know, one line that you and I and all the maintainers on wasmCloud have to decide is like, what dependencies do we want to maintain? Because every time we add another plugin, that's another maintenance path, another Dependabot update, all that kind of stuff. We already depend on NATS — so this one's like a no-brainer to include.
But if it's like some weird, not-everybody's-going-to-use-it type dependency, then I think we might want to go back to the contrib model — like, have a wasmCloud contrib, have a couple different plugins people could community-maintain that way. We don't have any trouble releasing wasmCloud because some esoteric dependency couldn't get updated.
That does apply to this one. Just saying — just an FYI. One other reason why I was a little reticent to update wasmCloud messaging is that it's basically directly based on WASI messaging, which is in draft and was kind of churning. We created a wasmCloud messaging version so that we could put a stake in the ground and not have it change underneath people. And same thing with wasmCloud secrets — a lot of that is just straight from Luke, who's obviously one of the creators of WebAssembly and the component model and drives a lot of the standard. We created wasmCloud namespace versions because they're not a standard yet, and so we host them here. And once they become a standard, we will provide adapters to get them to the WASI version.
Anyways, for wasmCloud messaging, I can send you a couple links, Aditya, if you want to see what it looks like to try to come up with a common denominator across all event buses. But there's one GitHub issue in particular that had 65 comments. And honestly, I just don't want to open that Pandora's box again. I want to just kind of leave it and not modify it if we don't have to.
Brian Boynton 52:53
What about wRPC over WebSocket for messaging?
Bailey Hayes 52:58
Oh, is that what you're interested in?
Brian Boynton 53:00
Yep, that's what I'm building for my registry. It's exploring. Let's put it that way. Comes with challenges.
Bailey Hayes 53:12
There's tricks there. So right now, wasmCloud itself doesn't depend on wRPC today. wasmCloud v1 obviously, architecturally, was totally dependent on it. We learned some hard lessons, like, make sure it's real obvious to everybody that they are making a network call and no magic behind it. And you kind of hate to see it, because COM learned this very hard lesson too, and we got to learn it again.
But I think with wRPC, it's really nice in that you have kind of an ideal that maybe people who are doing component model stuff — that's their natural lingua franca. But I think you might be interested in the support that we already have today that's built in with gRPC protobuf, which also can be upgraded to WebSocket. So there are some things that just work and have a huge ecosystem around it. People hate protoc for other reasons because it's native code, and that means folks have to deal with protoc. Anyway, every choice has its trade-offs.
I just want to make sure it's clear that there's a lot of choices you could go with there. My recommendation for you is probably gRPC, since I'm doing it in places and it's working great, so I can endorse it. The other part is, I think you could do a WebSocket API directly, which might also be interesting — kind of similar to WASI HTTP. And that might also have its own hidden dividends, in that you're really clear about the type of call you're making. WASI HTTP is not written to support WebSocket upgrade because it's written to just immediately adapt to HTTP/3 — which, saying that, that might actually be literally what you want, and maybe you should just be doing WASI HTTP or gRPC.
Brian Boynton 55:19
Okay, all right. QUIC transport on Cloudflare — I'd be jumping for that.
Bailey Hayes 55:25
Oh, Cloudflare supports HTTP/3 now. A lot of their work is the reason why a lot of this exists, including in the Rust crates too. They were the ones leading out a lot of that effort. Now, with QUIC transport in other places though — oh my goodness, no. The moment you start stacking networks, HTTP/3 starts not working.
Brian Boynton 55:50
Yeah, they're close. It's not quite making it to their Workers yet, so if that hits, I'm ready to switch over.
Bailey Hayes 55:58
Cool. Yeah, that makes sense. I feel like I've been following it for years now. But it's worth calling out that we do support it today in wasmCloud. So you can immediately start playing around with it. That's part of our HTTP server embedding inside both our WASI P2 and WASI P3 implementations on our HTTP server, and also something Aditya is going to have to worry about in his client.
Bailey Hayes 56:35
Well, we're at time. Thank you everybody for joining. Really appreciate it. It was good, lively discussion, as always. Post in Slack, ask questions, and don't feel like our roadmap is totally closed yet. If there's something really important to you that we didn't capture, because I know a lot of people watch this call after the fact, please file an issue or post in Slack, and we'd love to address it. All right, thank you very much. Bye.