 Hi, my name is Christian Dildog Ryu and this is Katelyn Medis for Bowden. We are members of the Cult of the Dead Cow and here to present to you an unveiling of Veilid. We've been pumping this thing up for six months online, a lot of interesting stories about what it could and couldn't be. We're just ready to pull back the curtain a bit and talk about what is Veilid. So today we are about to drop some fantastic code. We're about to drop some really cool apps and things and we are about to make some cool announcements but I think above all I really hope that everybody understands that the biggest thing we're doing here is presenting an idea. And that idea is that some things are just worth doing even if it's not monetary. I think we all found ourselves in hacking for one reason or another and that was to make a difference, to do something that's worthwhile. If you wanted to go make a bunch of money you'd be over a black hat right now but you're here. So we want to inspire all of you to hack the planet with us today. So in short, the Veilid mission, we exist to develop, distribute and maintain a privacy focused communication platform and protocol for the purposes of defending human and civil rights. There's a big mission there. We spent a lot of time thinking about this thing before we started writing code on it. We want to affect a particular outcome on the world. We're not interested in just writing cool code for the sake of it. We want to rethink the way applications are built so that the things people take for granted about application development change. You don't have to monetize everything. You don't have to sell users out just to make your cloud bill get paid. That kind of future is the future we should have had. So let's get into a little bit. Others have come before us. We had some inspiration from other tools. We looked at the world. We said we want to build things that are better. What tools exist already today? And Tor was there, front and center. I remember hanging out with Roger and Nick early in their development days and seeing how they had a similar mission to make things private that just weren't back in the day. I looked at IPFS, which is pretty novel in its use of distributed hash tables and all these crazy technologies to make interplanetary file systems. That just sounds huge, doesn't it? And there's a lot of other efforts in this space. Pewterpeer has been bounced around for 20 years since Napster and BitTorrent and everything else. We are at a time now where everyone has a supercomputer in their pocket. You got a terabyte of storage. And it begs the question, what if the cloud was everyone's computer, not just Jeff Bezos's? That's right. Valid is an open source, Pewterpeer mobile-first networked application framework. What this means is that it's like Tor and IPFS had sex and produced this thing, okay? Imagine a world where your apps can talk directly to each other, bypassing all the middlemen, not taking storage in the cloud or requiring some central authority for things like identity and storage or whatever. I looked at the Web 3.0 people and the things that are coming down the pipe there, there's been a lot of talk about decentralization lately. You've seen Mastodon and Blue Sky and these things, we're moving from centralized networks down to more feudal control. This is sort of the next logical step toward individual nodes all being peers in the same level, no hierarchy, but how do you affect that? How do you build that? How do you make it work? So here's what we're going to do. We put some design goals together for this project and obviously security was first. If you're going to be asking people to do something new with their applications and mobile devices, you have to be thinking like an attacker, how would you tear this apart? So security first, we wrote it in Rust, it is now over 100,000 lines of Rust, lovingly hand coded, built for memory and type safety. It runs everywhere, Rust is extremely portable. We have a core that runs on Linux, Mac, Windows, Android, iOS and in browser wasm today that works. We use standard internet protocols, you can think of this as an overlay network, so we're not going all the way down and writing a kernel, you know, but we're also not building on top of things like blockchains and, you know, transactional protocols and all this. We use UDP, we use TCP and we use WebSockets because these are the tools that are rock solid and available on all these platforms. It's all in network. We don't have external services, we don't rely on Google stun servers to do hole punching, we avoid DNS because that's a giant information leak. There's a tiny little bit of DNS, but we'll explain why that doesn't matter. And you know, we have all of the services that make VALID possible inside the VALID network itself, it's self contained. You just link it in, everything is working, all nodes are equal. Privacy focus was really important. When I looked at IPFS, it was not designed with privacy in mind. Tor obviously was designed with privacy in mind, but it wasn't designed with performance in mind and it was more about like proxying and it really enabled, you know, websites to talk, you know, to be reached anonymously, but that's not sort of a bi-directional privacy when, you know, the NSA runs 100 exit nodes, you know. So what if there were no exit nodes and in fact there were tens of millions of nodes? It would be really hard to monitor tens of millions of nodes instead of a couple exit nodes. So privacy focus from the beginning and keeping nodes and identities distinct. I'm going to get to why that's important and how we do it. Resiliency matters, you know, mobile networks, if you're going to be mobile first, you have to be able to handle networks that come and go, driving through the tunnel, losing your cell connection, coming onto a Wi-Fi, all of that. It's got to be able to context switch real fast. So we thought about all these things early on and we had to write code to support it. So feel free to cover this. So when we built this, we, when Dil first came to me with this idea, you know, he had the tech in his head, but what it really needed and I feel that this is really important and something that is often overlooked is the human side of things. What is the point of building these amazing technological, fantastic privacy things like Tor? If no one except for the people in this room understand how to use it. How does that benefit our parents? How does that benefit the people that might not be as comfortable with the internet? What we needed to do was really focus on what the user needs, how to make this approachable because, frankly, everybody deserves privacy. Everybody. Okay? When it came, you know, and not everything does need to be centralized. We've seen the problems with that. Human beings are flawed and they are going to, you know, put some of themselves into anything that they have control over. We've seen that with Mark Zuckerberg. We've seen that with Elon Musk. We want to make sure that this is something that no human imperfections can, you know, destroy. There's not going to be an algorithm. There's not going to be somebody pushing their ideals on you. This entire network is going to be what we all need it to be. All right. So let's start getting into the nitty gritty of how this works. All VALID nodes are applications running the VALID core. This means that no nodes are special, okay? There are no special nodes. You don't have to have an admin running servers or any kind of, you know, special. Everyone's running exactly the same thing. In fact, every application that is a VALID application looks the same to each other. So the network gains strength from a single popular app. Even for the less popular apps, they're all in the, the water level is raised by that one app that's very popular, right? So you don't have to build a really popular app and build your own VALID network. You can if you want. But the big VALID network is supported by the entire ecosystem, not just, you know, your app sailing away with a sea of eight users. So there's basically two kinds of uses today for the VALID core applications that are intended for end users and, well, headless nodes that could be used as a way to contribute to the network. If any of you guys that are Linux nerds like I am want to take the, what we're calling VALID server, it's not aptly named because it's not really a server per se. It's just VALID without any app. It's just running VALID, runs the RPC mechanism, passes data around. If you want to help the network out, the way you do it is by running that and just let it sit there. You don't have to do anything. You're not, you know, passing or passing encrypted traffic around and storing encrypted things to disk, and that's it. So today we have bindings for different languages. We're going to get to that. Again, the protocols are all low level. So UDP and TCP programmers that are writing apps can choose whether they want to talk over a more reliable sequenced protocol or if they would rather just have something be fast and unreliable. So, all right, let's kind of go through, I'm going to spend a little time on this slide, but let's go through what happens when you turn a node on. There is a bootstrap mechanism. So this is the only time that we're going to use DNS. And that is when you turn your node on, it will make a few text message requests to bootstrap.valid.com. This pulls down some public keys and some dial information. I'll get into what a dial info is exactly, but you can think of it as an IP address with a little more augmentation. This gets you access to a few other valid nodes, just says, oh, by the way, the network's over here. And here's a public key that you can use to make sure that you're talking to the right nodes. You contact those nodes and download a chunk of routing table. And the valid server stores those routes and can then proceed to query all the other nodes in the routing table and find more routes. And it builds this routing table up and applies a distance metric, which is an XOR of a public key that is assigned to each node. Node generates a public key, private key pair. Nodes are identified by a public key. And the distance in the graph of nodes is measured by the XOR. It's sort of like, you know, if you were to subtract the nodes addresses, but XOR has that property where it doesn't matter, it's commutative, you know? So we use that for a nodal distance, and that's important later on. So all of the nodes do the same thing. So desktop apps reach out to Bootstrap, they download the routing table. The next time you launch it, it doesn't try to Bootstrap again. It tries to reach out to the previous nodes that it has talked to before. So Bootstrap operation is very lightweight. And assuming that you've talked to some nodes that are going to be long lived, it probably doesn't need to happen with every single time you switch into a valid app. Again, there's mobile apps and progressive web apps, and they all have slightly different network characteristics. But the first things that are going to happen is we're going to ask those Bootstraps to find themselves. And when I mean that, you're going to be finding nodes that are close to the Bootstraps and then close to yourself. We're going to be doing a NAT detection operation, which is somewhat like stun. You ever heard of stun? It's a detection of your public IP address, but also kind of tells you how you can be reached. It's a way of calculating what kind of NAT you're on. So your network address translation is like you're either fully firewalled or you have a full cone NAT or Porter address restricted NAT or symmetric NAT if you're on one of those weird carrier grade phone networks where every place that you go gives you a different IP address. Makes it a little more complicated. But valid nodes need to understand where they stand in the world. They need to understand how they could be reached from the outside and if they need any help. Achieving connectivity. So that operation happens very quickly at the beginning. About five seconds after a node starts up, it's figured out its public IP address from other nodes that it knows about and calculates its dial info. The dial info says, if I publish this to you, you'll be able to use this information to be able to reach me somehow. So basically we sign this information with that same public key for the node. That way when you pass it around, people can't forge your dial info and redirect your traffic by claiming that your dial info goes to somewhere else. No other overlay networks that I know of actually use signing on the routing table itself. They pass around a lot of information but nodes are just trusted to not modify it in transit. That doesn't really make sense to me. So all of the node information is signed and valid. So yes, network class detection determines if you are inbound capable or not. You know, with a symmetric NAT, you just can't be inbound capable without help. Relays are used in that case. Every node in Valet is expected to relay encrypted traffic to the best of its ability to help out other nodes. So if a node is, say, a cell phone on a cell network going through a tunnel and it just can't receive inbound traffic, it's going to use a relay from the network to help get inbound traffic. It'll make an outbound connection and that relay's IP address is going to be part of its dial info as signed and published. So that way, you know, you don't have to relay forever and relays can start rejecting stuff and then the nodes will automatically pick a new one. So after that, you just have to know whether or not nodes are alive, whether or not they've continued to pass packets if they're still there. And we have an exponential back off mechanism of pinging those nodes over the same Bailey protocol to determine if nodes are still alive in the routing table. This turns out to be a statistical effort, almost entirely. You're really trying to understand the performance characteristics of other nodes and how alive they are. Should I talk to them? Can I trust them to keep being there? Turns out that if a node's been around for five minutes, chances are it's going to be around for another five. If a node's been around for half an hour, it's going to be around for another half an hour. It's just the math behind it, sort of. If a node's only been around for a couple seconds, you probably shouldn't be relying on it for, say, your private routing, because chances are it's going to just drop off soon. So we keep this math and we do it on a per node basis. So. All right. So what we're here to do with y'all is to help you inspire you to build stuff on this. I'm sure you can imagine after hearing all of that the many, many ways that this can be used and built upon. And I'm sure everyone is sitting there noodling over what projects could be built with this. Whether it's a peer-to-peer message or whether it's social media, the possibilities here are endless. And we really want to give you the tools to do that. All devices are going to be welcome and treated fairly. It's all equal. And then we're only as strong as the weakest node. Like every node is equal. And I think that's pretty cool. And yeah, you're welcome to use the Baylor network on its own or you can just build on it. And we really hope that everybody takes the opportunity to build on it. OK, so let's get into some deeper stuff. What is this cryptography that enables what we're doing here? Devil's in the details. And I know I've already had a ton of lovely, contrary conversations with all of you at some point. How does this actually function? OK, well, we have a cryptography suite that we have blessed for this project. We're calling it VLD0. I'll give you a hint. If we have to change it, it would be VLD1. We have a set of tools that we vetted. We did not roll our own crypto. We know better than that. But we're hoping to put things together that are known good. Authentication is done with ED25519 on Curve25519. So we have a very fast public-private key authentication signing system. All node IDs are effectively ED25519 nodes. Key exchange is done with the DH that is came on Curve25519 shortly after ED25519 was made. And yeah, so the same nodes can also be used to generate a symmetric key between nodes. So everything that if you have somebody's public key and you have your own secret key, you can DH those to produce a shared secret. Once you have that, you have to have a stream cipher or something to encrypt with that in an appropriate way. That is invalid. We're using the extended nonce version of Chacha 20 poly 1305, which is a stream cipher that comes with an AEAD built in. It is an associated data encryption system. So you can do things like partially encrypt a packet, include a header in the signing part, and have the signing identity as part of the encryption all in one go. You don't have to worry about do I sign first or do I hash Mac and all this other stuff? No, it's all just built in. You don't have to worry about it. If you got a symmetric key and you want it to be a signed transfer of information, you can just use that mechanism. And then yeah, so message digesters are being done with the Blake 3, which again is a fast hash. It's extremely, extremely fast. Everything in this key space, by the way, is 256-bit. So all of these algorithms here are tuned for a 256-bit key space. And key derivation is done with Argon 2, which won the 2015 password hashing competition. And that is a very slow hash intended to slow down and stymie GPU-based attacks on passwords. So all of that is in the VLD0 suite for people to use as part of our framework. If we have to change things, though, VLD0 has been built with an upgradeable crypto system from the beginning. We recognized that cryptography is going to fail us through the advancement of technology, CPU speeds, memory availability, GPU attacks, whatever it is, differential, this, that, the other things. Stuff falls apart. We know that we'll have to change some of this down the line, so we built in the ability to upgrade the cryptography from day one. You don't have to understand necessarily every cryptographic decision that's being made. Every new version of our crypto system is supported alongside the old ones. So we can add a new crypto system, wait for it to become popular, and then deprecate the old one. Everything has typed keys as a result, so you know which crypto system was used with the key. We have migration support built in, so if data is persisted with an old crypto system, it can be automatically re-encrypted with the new crypto system. And we can use, again, simultaneous crypto systems to do transitional, have both of them alive at the same time. This enables a bunch of different kinds of storage. Valet has secure storage. We have completely cross-platform support for device-level secrets. So we're using iOS and MacOS keychains. We have the Android Key Store. We have Windows Protected Store, Linux Secret Service. We have a table store, which is an encrypted key-value database, so nothing needs to be stored at all on the file system without being encrypted. Keep all of those private keys in the Protected Store, encrypt everything to the table store, and then that enables the actual record store and block store, which are a distributed hash table and the content-addressable storage. So on the wire, everything, all these protocols use the same encryption. Everything is encrypted and signed. Everything is time-stamped, and all of the node information is signed. That means very little of what we do has an opportunity to be spoofed, and it really wouldn't matter if you did. So the reason that I am up here is because at one point, somebody got into my ex's phone, took some pictures out of it that I didn't wanna be shared, and they shared it online because my ex didn't understand the importance of his own privacy. He didn't understand how important it was to keep his phone locked. That is one reason that we really wanted to push that all of our storage is encrypted at rest. It's going to always be safe, no matter what. Like, unless they actually know how to get into everything, it doesn't matter. Like, it's going to be safe, and that is the point. We want to really address the fact that everybody, you know, we want everyone to understand the value of their privacy. That's part of this, is to understand what you're giving away and what you're trading in order to use a lot of these websites. Your data's protected even if you lose your device, and we're just making sure that everything's going to be safe, and things like what happened to me don't happen to other people. And I know I said I wasn't gonna drop any zero days or anything, but you really should do an iPhone backup of a lot of your popular encrypted messenger apps and take a look at what stuff is actually encrypted on disk because you might be surprised about that. Okay. RPC protocols. Okay, so between nodes, how are they talking to each other? Time check. I'm doing all right. So how are they talking to each other? What is on the wire exactly? Well, first off, everything's encrypted. So you run a sniffer. You'll see chatter encrypted, small chunks of stuff going over a bunch of protocols. I picked port 5150 as the default if you kind of want to smell around for it, but other ports get used if necessary. So nodes will find each other one way or another. I think if you put it on port 53, you can just use it on the airplane without paying for that. Anyway. Yeah. So the schema language that we're using is a in-schema upgradeable documented RPC called Captain Proto. Captain Proto is written by the same guy who started the protobuf project at Google, but it was meant to fix a lot of the schema upgrade problems and produce a zero copied deserialization system. So we're talking about something that uses the same decrypted on-the-line message format as the same as the in-memory format. So that way there's no marshalling and moving shit around to slow things down. The RPC itself fully supports private routing and we're gonna get to that. And it has schema evolution built in so the next version available doesn't break apps that only use the previous version. And it's cryptography independent. So I'm gonna skip over a couple of slides because there'll be about 15 minutes left, but effectively the RPC operations are a nested set of Captain Proto definitions that define a series of operations like pinging and status finding nodes and then doing things like distributed hash table value gets and value sets. And again, some RPCs are unidirectional, some are bidirectional, they expect a response. Distributed hash tables get a lot of press because they were like the backbone of a lot of the file sharing tools. They're used in things like BitTorrent and the old school Nutella. And if you wanted to download executable files so they weren't P3s. DHT is basically just searched though and the valid DHT is a better DHT because it enforces data locality to the related data. Effectively all the DHTs that you're gonna see out there for like IPFS store little tiny bits of stuff very distributed across the hash space. And what ours does is it actually lets you store a bigger chunk of stuff. We're talking like a megabyte per key across an array of subkeys that can be allocated on a per writer basis. Now what does that mean? Well DHT keys are signed key pairs with a public key. It represents its location in the hash and the private key lets you sign the data that's pushed to the keys value. No other DHTs right now let there be multiple writers to sub chunks of those keys. You can build some pretty powerful distributed synchronization and data structural paradigms there if you can allow people to commingle data on the same hash key. That means that you have a conversation you can put it in line in one place and have a private routed but you can have the data located in the same place. That allows for that sort of caching to happen and for related data to be all together in one place. It means you don't have to search the whole network every time you need to find a new thing. This makes our DHT faster. So one of the reasons that we wanted to do things this way is that we could avoid using blockchain or a coin. To me using a coin is an accessibility issue. It's making sure that people that aren't as comfortable with the internet are not going to be using it. Also, it's putting a price on something that I feel is priceless. You shouldn't have to pay for privacy. It should not be behind a paywall. Privacy should be free, accessible and available to everybody from the start and that is it. One of the things that we really built in with Valid was to make sure that we are building it for the people in this room. We are building it for the people outside of this room. We are building it for the people that are still on Facebook because that is the only app that has made itself accessible to them. We want to build this for the people that don't want to see the privacy, like what goes on behind the curtains. They just want to click and things are growing great and that's what they wanted. They don't want to wait. And the one thing that I really love about what we're doing here is that we're making sure it's seamless. Privacy is there but it's just the baseline and that's how it should be. And we can get into why this is not a free lunch for infinite storage. There is some tricks to it but generally speaking you're gonna be able to use the DHT to store a whole lot of stuff and the network will support you. So talk about private routing. How is this sort of like Tor? How is this protecting people's IP addresses? If I launch my Valid-powered messaging application how is it that it maintains its speed and keeps people's IP addresses private? Okay, I'm gonna define some terms. There's a safety route, a private route and a compiled route. Now this is a little different than Tor. Tor has things like guard nodes and entry and exit nodes if you're familiar with those. Safety route is sort of like a guard node if you're thinking in terms of Tor terminology. So the idea is that if you have two people talking if only one end of the conversation can control the entire route then you've lost. They could pick nodes that are adversarial or phoning home with everything. And that's no good, right? If you wanna truly be able to keep yourself private neither node needs to you should be able to have to trust the construction of the route. So what we do is we build our routes in two chunks. The sender allocates a safety route for sender privacy and the receiver publishes a private route for receiver privacy. Those are compiled together to build the circuit that the communication happens over and the nodes in the middle don't understand necessarily where the end of the route is. So you have to assume that if I look at A, N8 and N7 A is choosing those nodes and N6, N5 and B, B is choosing those nodes. But when they snap together the nodes don't know any different. And you have a circuit that is connected. And we actually used to know to snap them together in this onion style encrypted payload where the addresses and public keys of the next hop are embedded in an onion style peel off a layer as you go system. So this blob of stuff has a private key associated with the route itself, not with the nodes. So everything gets signed but it's associated with the private route or the safety route not with the node ID or an identity. That's allocated on a per route basis and these things are coming and going all the time. This is one of the reasons why we don't necessarily require perfect forward security. We don't need to worry about long encrypted people monitoring a single node for a long time and then going back in time and cracking that conversation. It's because it's moving around all the time. These routes are coming and going. You'd have to monitor the entire valid network to be able to generate enough information to be able to utilize some of those differential crypto attacks. So that envelope that you build has this header and an encrypted chunk of stuff that is guaranteed to be de-aged across just the private route and the safety route and as it goes from node to node we're shrinking those payloads and eventually it drops off where the end can receive the encrypted blob. All of these slides are gonna be available online if you wanna tear apart the exact cryptographic implementation and of course the code's open too if you wanna read it. So toward the future, there are ways to improve private routing. We wanna do per hop payload keying as well. We wanna minimize the number of things that you can glean about traffic from sniffing the wire directly. So reducing the number of things that are common between packets is a good goal over time. Right now we also do some internal hop counting. That was for debug purposes. We can just drop that. We have bidirectional routes today. Allocations are done directionally. We could drop that and just go with bidirectional routes to begin with. We could do things like hop caching and increasing our hop counts if we wanted to. Right now our hop count is effectively equal to Tor's hop count and they did a whole lot of math on why a single guard node and a single exit node would be sufficient. We actually have two extra nodes in there but the reason is why is to make sure that no node can look to the left or to the right and know anything about who they're talking to. As we said in the beginning, we really wanted to make sure that this is private. Make sure that nobody can see your location. It can't get your IP address. You have to invite somebody to be a part of your network. You have to, you know, nothing is going to be forced upon. You are put in an algorithm. So that means that you have a lot more say as a user in how this is being used. The no IP address means no tracking, collection or correlation. That's right, no tracking. As of right now, that is the biggest way. Well, let's give it up for no tracking. How nice is that? Right now that is the biggest way that people are monetizing our internet use. When I was a kid, I was, you know, told, you know, about the internet, you know, way back in the day and I was learning about it and I was told it was going to be this open, free place where people can learn and they can connect to each other. And instead we have had billionaires that have decided to monetize those connections and seep every little bit of information and data out of each connection and use that they can. And you know what? A lot of people are falling for that. We have made, like I said, privacy has to be accessible for everybody. We have to make sure people understand what that means and we have to make things that are going to entice them, that are going to be inviting to everybody. If we do things like build social media networks like, you know, if we get our parents off Facebook, we're all free, okay? So let's build that. Come build that with us. Let's do a thing. Okay, so how do you do this with us? Valid loves Rust. We are crabs. We have crabs. We want more crabs. Valid is written in Rust. The crates are going to be published. I wrote this before I said that the crates are going to be published. The crates are on the Git lab and we'll explain that a little bit more. We haven't published everything because we're still working on Rust doc because when you're rushing a product out the door, you don't get time for making sure the documentation's right, we're getting there. The crates will be on crates.io in about a month probably as we make sure the docs look as spiffy as they deserve to be. There is a power user quick start. When you are ready to run your own Valid server, you'll be able to do that by either cloning the code and running it, or you can get DEB, APT, or RPM packages from our package servers today. Just download it, install it, turn on automatic or unattended upgrades because we're going to keep changing this thing and keeping everyone up to date will help the network out. There is a really cool vapor wave looking CLI that you can use to talk to your node and send little weird messages and shit. So knock yourself out with that. We also love Flutter. Flutter is a cross-platform mobile first application development framework. Powers all kinds of cool apps like your Instacart and DoorDash and all that kind of stuff. It is Dart internally, which is a JavaScript overlay that does a really good job of providing asynchronous programming to environments that deserve it like the web. So we have a first-class FFI and JavaScript wasm plugin for Dart today. And we have actually written an app using it that we will talk about later, maybe at the party tonight. You know what's going to come to the party? Yeah, I hope so. And we love Python too. If you want to learn how to use Valid and just hack on it and mess with it, we support Python today through a JSON API that's a no-compile way of talking to a Valid server. So app install Valid server, pull down the Valid bindings for Python, and you can start writing little apps and scripts and things that talk over Valid today. Our demo lab tomorrow at 10 is going to talk and demo the Python side of things and show you how you can make your own little chat app that is completely private, distributed, and encrypted both at rest and on the wire. And so how can you help? We need coders and hackers. But more so we need regular people. Everybody. Okay, we need everybody. It takes a team, it takes an entire village to build something that is approachable and usable for everybody. I mean, I love all of you coders. I love all of you hackers. But we need people. We need human beings. Regular people. We need to speak to human beings. So let's make sure that everybody here has a voice and it all matters. So you can find us online, valid.com is up. We have a Twitter, you've probably seen it ad nauseam for the last six months, but it's there. We're also on Macedon. We love Federation. We want to do more with that. We have a Discord coming up. And we have a GitLab that is going to be open now. So feel free to go poke at it and see what we've built. Also, if you are here looking for a flag for a certain CTF, it is not here. It is in that code. You might have to read the code. It's in there somewhere. So you can see it live. Two night, we have a release party at 8 p.m. We're rocking the house. We've got all kinds of cool bands and shit. It's gonna be a wild time. CDC Highdrinks, you name it. Have you ever heard of a little thing called B.O.2K? Let's bring that back. Let's bring that vibe, that feeling that you can do something that we can just mess the world up. We have the Colts of the Dead cow. Enforce. They're here. Come on. Let's all do a hack to vision together. Awesome. Let's do it. If you have any questions, you can bug us out in the smoking area outside in about 10 minutes. All right, talk to you soon. Thanks, everyone.