 Great, you can all hear us. Let's put you guys out with a bang here. Welcome to Component Model, the final abstraction. We'll be finishing up your day here, and then we'll all get to go full, I think is what the plan is tonight. So first off, just some quick introductions. If you were at my earlier talk, you already saw this. The picture is me as an AI is putting me as a restation with a very cursed looking hat. But I'm Taylor Thomas. I'm an engineering director at Cosmonic. WasmCloud maintainer for a long time. I also have been in the web assembly space for a while. I helped co-create Crestlet for any of you in the Kubernetes space who may have heard of that one. And then I'll thank you Kubernetes. And then we have, I've done a bunch of stuff here with WasmCloud. Like I said, restation, done lots of open source. So I've seen either seen a lot of you out in the open source community before or have been here in the Wasm community. So that's me. My name's Liam Randall. Serial entrepreneur in the open source space. I've done a whole series of startups starting with Brozeek, a large-scale network monitoring. I created the very first Kubernetes company in 2014. I was involved in OSquery, Cloud Custodian out of Capital One. I'll put that into the CNCF. And my sort of career experience has led me to believe that web assembly isn't just the next big abstraction of tech, but it's the final abstraction of tech. So today we're gonna talk a little bit about NFRs, non-functional requirements. And we'll give a little bit of the what and why of the component model. And we'll talk, we'll show these components in action with WasmCloud and we'll talk a little bit about how you can componentize things. So let's start with Liam, like as he says, he's a very strong believer in this. And I think he's probably the most qualified to explain why. Great. So how many engineers have in the room out of curiosity? People that write code as a large part of their job. You know, the dirty secret of software development is that the vast majority of software is just built with free software. And unfortunately the cost of free is very high. When we talk about what is the cost to keep it up to date and maintaining it. When I was at Capital One, I was there for almost six years. I owned open source and I really worked hard to make the lives of the developers great. And I started to explore and do frequency analysis of code usage in the company. And it was shocking to me how much code reuse there was and it made sense. You know, we wanted, we loved our developers. We wanted our developers' lives to be good. And we did probably what you have at work. We gave them a template, you know, Java Spring Boot, except we would customize it with our goo and then put it out there. And the sad reality is that when we're in this golden template kind of world, they drift very quickly. And developers end up simply just copying boilerplate from app to app. And if you're out of the tree of your application and thinking in the forest of your company, this is by far the largest and greatest opportunity that we have in technology today. Is to give developers back 80% of their lives. Most of you, especially if you work at a highly regulated company, are boilerplate farmers. Every week, your job is to take all of the red and yellow boxes and turn them back into green and submit them back into CICD. And that is a complete and utter waste of time that we have a pattern that we solved for before on this. And if we think of these epics of computing, you know, if you started in tech, when I did, we were still mapping one application to one computer. And we wanted a new application where you had to go to Dell.com and pick out another, you know, Dell Blade server and download it and purchase it. And we said, this is crazy. We've got all this unused opportunity down at the bottom of the stack. Most of our compute is idled. So we started to think about virtualization. And, you know, there were multiple efforts. And ultimately we started to say, hey, we can start bin packing at the CPU level. And our lives were a little bit better and developers got to stop worrying about the hardware. And then we said, well, this is crazy. Why are we all building our own data centers? Most of our data centers are idle. You know, couldn't we go faster if we started to share data centers? And we all agreed to go in on the public cloud. Your lives get a little bit better. You're no longer at least waiting for hardware to get shipped in. But this pattern that you start to observe is that from the bottom up, we look for the common complexity in our lives and we turn it into a platform. We get to the cloud. We start thinking about operating systems. Why are we building our own AMIs, right? You know, who built AMIs with a HashiCorp tools 15 years ago, right? Uploaded them to the cloud. Why are we doing that at a team by team basis? What if we could have some sort of a stackable template? Well, this is where containers were born. And initially there were multiple standards there. And then we said, well, I want to have more options than just AWS. I'd like to be able to orchestrate on different clouds. Well, why do we want to have a simple, why do we want to tightly couple ourselves to AWS? Why don't we have a portable orchestration format? And we had Mesosphere and Kubernetes and lots of choices to compete. And we sort of standardized on Kubernetes. And the sad reality from where we are today is that there's still a ton of common complexity. And the pattern we followed is just cannibalize the next layer. And the next layer in the stack is the application libraries. When you, if you've been here for the last two days and you've been attending lots of these sessions, I think you start to see the magic of the WebAssembly component model coming to bear on the biggest problem that we have in tech, which is the cost to free, right? The cost of these open source libraries. If we can turn those into a reusable, composable platform, then the only thing that we have left is our business logic. And we can finally give developers back the gift of their own lives. And of course, this comes with the additional advantage of all of the things that WebAssembly brings to bear in the problem space. If you'd like these, market texture is what we call this. It's all available at cosmetic.com. Just click on press and you can download all these images and use them in your own presentations. So this is where we come back to that question, the component model, right? Now, I'm just gonna ask this and I need honest answers. How many of you feel like you understand what the component model does? You see these like, yeah, like one or two and a couple of, I think so. So if you didn't attend Luke's keynote, I'd highly recommend going and watching that because he gave you the full explainer. I'm giving you the ELI 5 explainer about what this is and this is coming to give you a little background like to understand why I'm so passionate about this. I came from heavy Kubernetes involvement. I helped write a large chunk of Helm 3 if that gives you any sort of indication about what I've done in the past. And so I care and I saw all these things that were going on, the component model really solves it. So I'm gonna go through the ELI 5 version of this. So forgive me if Luke watches this later because he's not here in this room right now. Forgive me, these are the biggest shortcuts but I am going to the ELI 5 version. So these are two components. Components can have an export and an import and these things can click together. That is the, there you go, components. That is the most basic thing right there. If the import and the export matches, then click, they work, that's all that's required. But then you start to, let's talk about this a little bit more concretely. Let's say you've built an application and you need to do HTTP stuff, you need a key value thing and you need messaging. Those are the things that you need. So in order for your application to run, you have to have something that can provide that functionality for you. And in the component model, once again, any one of these little blocks is a component, you could have one component that implements key value for you. You don't have to know about the details, just that clicking part. And then to say, okay, that's great. And you could have another component that implements both messaging and Blob Store but you only really need the messaging part of it. That could be once again, this could be like provided by a cloud provider. This could be something from a host runtime. It could be any one of those things. And these things once again, click together. Now, question, will this component, as it's all right now together, will it run? Okay, yep, no, it will not run. It will not run because we still have a dangling import. Okay, so this is where we get into the next tool. Remember, import, export, they match, they click. That's step one for ELI 5. Step two is, if things are still wanting to be imported, it will not run. Now, let's say I have this component and I actually wanna run it. This is where run times come in because not only can other components provide these things, run times can. So they can come in and say, you know what, I have a couple of custom things that I offer and I have HTTP functionality. Like when you do it, I'll take care of all the HTTP stuff for you, whether that's incoming or outgoing. I'll do it. And it can actually click in and provide the thing that you need. So this is the quick overview of the, hopefully, now the question is, do people feel like they understand it better? Maybe, yeah, I see. So this is what the basis of the component model is. Now we can talk about some of the really cool things that happen underneath the hood, but you start to see where the flexibility comes in here. And we get some very, very powerful functionality here, but what isn't here? That's the real question now. I'm gonna go out of ELI-5 mode for a second. Does anyone notice what this is from? Anyone, anyone? It's Sean, you got it. That is C plus, it's C headers in this case, but do you know, does anyone recognize it? This is the POSIX headers. This isn't even all of them. I couldn't fit it on my screen to screenshot the whole list of headers, right? And on the right is just one of those, a lot of the file operations, and once again, that's not all of the functions in there. When you do things with components, you bring in only what is strictly necessary instead of all of POSIX. That's why one of those things that we talk about, why we talk about the component model so much, is that it's freedom from that too. The more stuff you have that's exposed, the more surface area and attack area you have, that's both to worry about the functionality that needs to be provided, and also the way that it could be exploited. And all of that is not here inside of our components. When you start to do stuff with, the way I think of it is, when you have a sandbox like WebAssembly, and you punch a bunch of holes in it to add all these headers and things in there, all the sand drains out, and all you have left is a box. We already have a name for that box. It's called a container, right? So like, there's no, like POSIX is not something that gets included in every single container in, or every single WebAssembly module like it does in a container in a model like this. You bring in exactly what you need. If you're doing file operations, you can bring in the WASI contract for those file APIs. And the most important thing to observe when you start thinking like this is, when you're building a big monolithic ABI, you get one shot. And if you want to iterate or go fast, you're revving the whole world. So the way that this, the advantage to this level of ABI decomposition, application boundary interface means that as this long tail of capabilities becomes created, we can rev those even faster. There's this core set, the frequency analysis that I did across the time around 5,000 applications. Three standard deviations of those apps had about seven capabilities. They had HTTP, they had logging, they had KV, they had S3, I'd way to hotel, and a couple of other little things. But if you look at the corpus of APIs that are available across clouds, it's many thousands of long tails. There's ML things. And we don't want to build some massively continuous ABI like we have with POSIX. It's a different world. So we need a slightly different approach here. And this produces ultimately modules that are smaller because again, we're only bringing, it's not what we're bringing with, it's what we get to leave behind. But developers are no longer responsible for it. Exactly, and that's the kind of thing here, like in my little dumb example I gave before, this one where we have key value messaging and HTTP, why am I bringing along all these things? When it can be this for example is the interface for key value that I'd be using. All that I care about is I get these and things underneath can wrap what's needed for wherever you're running it, but all I'm asking for a get set delete exists. That's all I'm asking for with key value. And instead of having this, you now have this. It's also just much cleaner and easier to consume and understand. So let's quickly review where we're at with components. Full component support will land with Wazipreview 2 sometime around end of November, beginning of December 2023. Don't quote me on that because they said towards the end of the year, as far as I heard when I wrote these slides, that's roughly where it's at. You can use it right now. We're gonna show some of that with WazenCloud today, but you can do that right now with the component model. Also everything is now defined via an interface and these components compose together. That's why they have the name component. You take them, they go together, they're composed. That's the name and where it comes from. So you might be asking, Kate Taylor, this sounds a little bit like a pipe dream. How do you know it works? WazenCloud has been doing this for four years. Now, we didn't have the component model four years ago, but we have been doing this exact thing. We've had things that we call actors that run that are WebAssembly. We have things that are called providers. They give you these capabilities like your key value in your Blob Store and HTTP, but they are entirely separated from each other. In fact, they can be running on completely different machines and architectures apart from each other. And so we know that this pattern works. This isn't just something we've pulled out of nowhere and are saying, great, now do it now. We've been doing this for years. And so we just want to emphasize that we believe in the component model because we've been pushing for this along with the rest of the community for years because of this experience we've had. So the WazenCloud application runtime that I mentioned, you've probably heard it at least a couple of times today. We have a bunch of open source technologies we build on that you see here on the left. We have cloud events and open telemetry. We run on top of NATS. And the main thing is that we run and orchestrate WebAssembly in a distributed way. Our whole goal is you can build complex apps easily in a distributed way. They can run anywhere in the world. And we're gonna show you that as we move in towards our demo right here. Okay, I'm gonna go off script for a moment, Taylor. I know you love that one. I do that. Hold that for a second. I'm gonna give you guys a QR code if anybody wants to follow along here. But what this repo has is a list of commands for creating components in different language with the current open source tooling as it exists in the By Code Alliance. So Kyle did a presentation. There's very similar to this, Kyle. If you're here, Kyle Brown, you can watch this talk later. But I wanna show you a couple quick things here when we get into the concept of components here. So in this repo, if I click through here, we'll start with C maybe. And let me actually press the dot button. And then I'm gonna switch to VS Code View, I think. Dot, there we go. Let's walk through the simplest component that we have here. I'm gonna take some C code that implements a power controller. So, let's see where's my critter component. Okay, so this over here is simple code that implements an algorithm that you can use for power components. Is that it, actually, or is it here in Rust? And when we think about what is defined by the WebAssembly standard, the core standard, there are two outputs. You get a Wasm file, which is integers all the way down. And then you get the human readable WAP file. And you can see right away that this looks like those integers all the way down. WebAssembly is numbers in, numbers out. But what the component model gives us here is it calls a component. And if you look down at the bottom of the module, you get this extra, in this case, maybe 100 bytes. And this is where those interfaces are defined. And when we think about the component model giving you a strong typing for your variables, this is where that strong typing is defined. So this is the really low level view of this. Well, let's look at this at a really high level. And to do that, we're actually gonna switch back to Wasm Cloud and our demo here. Actually, I'll use a Cosmonic here. Now, Cosmonic orchestrates WebAssembly and Wasm Cloud underneath the hood. So each one of these components here is running in a WebAssembly sandbox. And again, I can only pull in those little pieces that I need in order to get this done, to build my applications. I'm leaving behind everything else. So I've got a simple app here that has two components that's pulled in. A web client, so an HTTP client, and a web server. And if you wanna deploy this yourself, I'll show you a QR code here momentarily. If you take your phone and hit that QR code, you'll actually launch that yourself and you'll have that right there in your hand to play with. But again, it's the simplicity of the application that's happening. Now, there are lots of great ways that you can run components. Wasm Time is the open source engine that we use from the Byte Code Alliance. And Wasm Cloud wraps Wasm Time and then lets you use components even if they're running on different systems. So what's amazing about this app that you're looking at is one of those components is running right here on this WiFi, on my computer, on the Edge. And two of the other components are running in AWS East. So when you're browsing this website, if you wanna open this up on your phone, there's a QR code for you, the top right one. Think about your request. You're hitting a tiny component that's running in US East in AWS. It's coming out over Wasm Cloud to a separate Wasm Cloud process running here on my computer. The HTTP request is issued then out of AWS East and then it's responded and sent back to our browser. And all of this happens in milliseconds. Underneath the hood, WebAssembly can obviously still be scaled in microseconds. When we think about these huge advantages that you have, it enables us to scale on invocation. We're exploiting two orders of magnitude here. One of the critical problems that you have in today's infrastructure is that cold start problem. But when these things are so tiny and we can run them really close to the users, we can actually scale up for invocation here. Well, let's do a little bit. Actually, let's look at how we orchestrate that and put that together. So what Wasm Cloud features is an OMSPEC, which is an open application manifest. This was actually launched by Microsoft two years ago. And you can see that when you define your application, you can actually pick the components. And these are open, by the way, on GitHub. You can pull them down, look at them, do whatever you'd like. Specify some components on where they should be launched as well as how many copies. Identify the imports and exports. So I've got a component, remember to explain it like I'm five, I've got a web server and a web client. And then I can choose components that satisfy those requests. And that is that composability that happens there. And we can take this and even do more complicated demonstrations. So deployed here, let me switch back to my slides for a second. Which one is that? Which deck are we on? That one. Okay. Let me do the decks. Slot show. So let's go to an even smaller one. So right here on Taylor's chest, I mean if you were in the keynote on yesterday, you may have seen me do this demo. But we're running a teeny tiny little computer here. And what's magical about this is that there's three components that are involved. And same story. One is running in AWS East. One is running here on my laptop. And yet another one is running right here on this batch. So Bosm cloud is actually running in three different places orchestrating these. And if you hit this QR code, the curl me maybe, you'll actually talk to a component that's right there on Taylor's chest. And any message that you send in your HTTP request will actually pop up right here on the screen. Now if you did it from an iPhone, I just see somebody hit it. It says, Hey to Hey-Taylor. If whoever just did that changes it, we'll get a different message here. We'll get a different one. We'll see how the poor CPU on this thing handles all if you're trying to hit it at once, but... I still see a whole bunch flying across here. Yeah, we just get a bunch flying across there. So that's all sending right here to my badge. Even though this is just a tiny little machine running, it's tiny processor and 512 megs of RAM. It's sending it. And all the business logic is being processed. And it's even crazier because I can come over here and say and press this button and it changes the text. And what's actually happening is this is sending the event to my business logic running inside of US East then bringing that logic, using that logic there to send a message back to here to put it onto my screen. And it all does that very quickly, very fast. There's no tricks here. This is actually live and like you might, like I said, you might be overwhelming the processor and you might like hit a timeout or something because everyone's hitting it, but that's what's going on here. So when we were thinking through this and designing, how would we build this? We thought what was most critical was this concept of capability-driven deployment. And in our own spec here, if I pull up a simple one, you can see that you can have these labels. So here you can see that I'm deploying three of these where Stargate is true. I'm running this web server process where the label says on Cosmonic. And what WasmCloud will do is interrogate a system where you can launch WasmCloud with particular labels. You can say, this node has GPUs. This node has high bandwidth. This node is running in a PCI DSS certified data center. This node is running in France. This node is running in Germany. So it gives you the ability to start thinking about orchestrating your capabilities across time and space and thinking about regulatory domains or locality or privacy or security. You can deploy capabilities that are then reassembled in a self-forming, self-healing, auto-discovered way. Because nowhere in here, when you're using these components, do you have to change the topology of your application? I'm sorry, the logical outline of your application. If this is running on a single MacBook or this is running across 30 systems, the topology is still the same. Underneath the hood, WasmCloud does a discovery process in order to find its most local capability. If there's one running in the same process, it'll use that. If there's one that's nearby, it'll find that through the magic of some software called NATS. Well, what can we do with that? If we have this ability now to deploy across various infrastructure, we might think about routing machine learning, or traffic to different machine learning models depending on privacy or availability or locality. This work was originally pioneered by some developers at BMW who fortunately donated this back to the WasmCloud community, and this is baked into WasmCloud today. Let's just look at that high-level application architecture. Web requests come in. You can send pictures to this model where they're turned into vectors. That's how machine learning works. It's essentially just vector math. What's magical about that process is that is both a one-way hash and it's also a massive compression step. If you're taking a multi-meg image and you're turning it into a vector that's only 1k, you suddenly now are saving all that ingress and egress cost. So in the demo that we're about to do, I'm gonna run these preprocessors on the edge that'll send vectors to two different models depending on privacy, availability, performance, cost, or any other such results. The machine learning model's output, an output vector that then gets interpreted as a result. This is a picture of a cat. This is a hot dog. That's not a hot dog, that whole thing. This runs just fine on WasmCloud. This is the open-source UI. I think at Lackland here, you've actually created an updated version of the UI that's much more beautiful than this, but I haven't updated my slide yet. Thank you for that. And this is the sort of mapping for what we're gonna do. I apologize for the color coding here on the images. But essentially, what I'm projecting in my fictional scenario is that devices that are on the edge that are close to me do really well when they're disconnected from the internet. But they're not very secure. And if I want things that run faster, I wanna route it instead to one of these big public cloud servers, where I'm renting beefier boxes, where I've got more security than a laptop that could accidentally walk away. And then in the UI, it essentially looks like this. Again, the topology, the application architecture doesn't change regardless of the topology I'm running. I could run one copy of all of this in a single WasmCloud process right here in my MacBook. Or I could change my app spec and use those labels and say on everything that's tagged out as an edge, or everything that's tagged out in edge in France, run this set of preprocessors. On everything that's tagged out on an edge in Germany, run this set of preprocessors. Let's take a look at what that looks like. All right, so let's look at my infrastructure that I have. So I've emulated here a telco network just using these labels. You can see, we were just having a good time that you can just throw emojis in or something like that. And you could actually route on emojis which was actually kind of like one of those late night laughs we had when we were like, could we use an emoji as a targeted selector? And then sure enough, you can. That worked just fine. So I've got two different telco branches here that are tagged out, core and edge across a fictional France in Germany. And then the model itself is actually very simple. I've got, if you know image detection libraries, a very popular one is called ResNet. It's a very small model appropriate for running on edge devices. And there's a very large model, I'm sorry, the small model is called MobileNet. The large model is called ResNet. So let's just manually throw a few images at this. And these are available via a UI, of course, or I'm sorry, an API, of course, a REST-based API. But if I throw a grand piano at MobileNet, I get a 50% that it's a grand, but a 1.8% that is a barber chair. And if I throw, let's throw some Espresso at the edge model. It's only 85% sure that that's Espresso. Depending on how I wanted to route for more accuracy, say, I could send the same images to this larger model. And if we send the piano, we suddenly now get a 91% confidence that it's a piano. Now that came at a cost of running a larger model. It came at a cost of running it in the cloud, which is, now that model actually, you could just as easily spin up on your MacBook or somewhere else, but I'm trying to just convey the idea of the thing here. I'm not arguing that ResNet is too large to run on a localized device. I'm just conveying the idea. But if we look at the Espresso, again, we get more accuracy. These demos are a little contrived, but what they show you is that the WebAssembly component model is ready for prime time today. And that first repo where we started here with the raw tooling is a danger under- construction kind of place. Other window. Other window? Yep. Thank you. There's instructions here in this repo if you do wanna play with the languages that the guest languages here for C and for Go and for JavaScript. And the instructions are very simple. You can walk through here and just sort of look how simple the Wasm tools are for working with static languages like C and C++. You can build these components now and you can also run them on Wasm Cloud today. The other demos I hope kind of inspire you to start thinking about what the power of capability-driven security, capability-driven routing could do for your applications today. Dylan? Yeah. So to wrap this all up, we'll go ahead and show this. So how can you componentize? And the answer is only you can componentize the world. Thanks, Smokey. So really, if you wanna do this, tomorrow we have the, we're jokingly calling Bacon, B-A-Con, which is where it's a Bicode Alliance conference. And we're gonna, most of the people here who have been involved in WebAsimilar a while are gonna be there. So it's a good time to pick people's brains and to come contribute and componentize things. How do I get my favorite library working as a wit interface and a component? Those kind of things. And these are the kind of like, here's where component language support is at. You have a lot of these core languages like Python, JavaScript, C, Rust. And these things are rapidly expanding to languages like Go and Kotlin and other things. So we're getting more and more languages to support it. And as soon as that supports it, that means we get to have all these language interon things we've never had before. So if you're interested, there's the QR code for the event. And last but not least, we want to invite you to come join our community Slack and our GitHub. We have a QR code for each of them there. This is where you can chat with us. We're an involved community of people really interested in WebAssembly, showing off all these things. We'd like you to try it. Let us know what you run into. We're gonna be continually improving and following along with everything going on with components. So anything else you wanted to close with, Liam? I do, one more thing. Just one more thing. I don't know if anybody remembers this commercial, but the dog goes bacon, bacon, bacon! So just one last call to get registered for the last day tomorrow. We'll have an opportunity to sit down with the creators of the key component tooling and help us to start componentizing the world. Your time is very valuable. I hope that you've enjoyed not only the session, but all of WasmCon this week. And thank you very much for coming. We'd love your feedback so we can know how to make WasmCon 2024 even better. Thank you. Any questions? We have about two minutes before official end. We can also sit around and talk around the thing, yes. The ELI-5 version, yeah, uh-huh. I think I'll go to open my mic. Yeah, technically all components can be re-exploded by looking at the constituent parts. So that's not something we're doing right now, but that's something where you could technically slice out stuff you didn't need or use certain parts of it, just depending on how it's built. Let's actually walk through a maybe a more detailed example of that. We've talked a lot about the advantages of the component model. But when we think about what they actually look like, they're just modules underneath the hood with the definition of what the Lego block looks like. I import, I export a string and a vector of bytes, and I require a web server and a key value in a SQL database. The explain it like I'm five, you have to satisfy all of the imports for a module, for a component in order to make it work. Now what the developers are helpfully doing for you is they've just added a feature I'm called virtual platform layering. So even if you, when you think about testing these things or developing these things, there's the ability to virtualize components for QA or for debugging. That's gonna be a very powerful addition to this model here. And in the wasm cloud world, what we actually do is, you're familiar with the concept of a polyfill in browsers. It's like where you sort of like upgrade a web page or downgrade a web page to support a particular deployment location. We have what we call a wazifill that we do in wasm cloud. And we take your standard component, any standard component when you plug it in, and we upgrade it and do a bunch of wasm cloud value ads like signing the component, letting you check the source of it and a few other things like that. That's the work that I've been heading up. We're still working actually, we found some bugs on how certain things work inside of wit. That's why it's not something I'm fully ready to show off, but that's something we're actually working on where we take different things to make it work. So we take any component that comes in and we glue in basically the wasm cloud specific stuff. You never have to touch that in your code. That's what the ultimate future is here for everybody. And we're trying to show that from the get go with wasm cloud. You get all the benefits of wasm cloud, but you don't have to like import wasm cloud libraries or anything anymore. You just write your code according to the interface and bring it and plug it in. That's the whole point of it. Here's our theory on what we think you want. And you can come to wasm cloud and tell us what you want or it's open source. It's in the CNCF, you can do what you want. What we're doing is we're building many of the most common components that we think that you want like HTTP right into the run time. Why? Because you want them to be a lightning fast. You want them to just be included. You don't want to have to download other components, but they're also still pluggable. You could still satisfy those requests with your own component. But you have this, we haven't done the default component yet, but we've talked about this a lot internally that if you just give us a component and you don't specify a web server and a KV that we'll just plug it into a default set by default here. And again, the sort of magic here of what we think this world looks like are these little microliths. Somebody earlier made the best example. They said it's no longer pets and cattle. It's pet, cattle, and shrimp. And maybe that's something we could build on. Okay, so that's the time we can go ahead and stay out in the hallway track for those who want to keep talking to us. And thanks for attending WasmCon, everyone. Woo!