 So, Caboose is a thick client that we've written over the last couple of months for Saturn as part of Project RIA. And so this is going to be relatively quick, but I'll talk a little bit about where that fits in and the point, what we get out of doing this and why we need a thick client. So let me first give a basic view of what's going on in Caboose. Caboose has two big data structures. One is it has a pool of the nearby Saturn nodes that it wants to send requests to. And it keeps those sort of logically arranged in a stable hash. So based on what CID you're asking for, that hash is somewhere into something that looks sort of like a DHT and chooses one of the nearby Saturn L1s to send the request to. And the reason that you use stable hashing there is that it really improves your cache affinity, that a node is getting sort of a limited space of CIDs that it is responsible for. And as a result, that node then can do better in having a warm cache for those. And then the other data structure that we keep is sort of a pool of other nodes that we'll sort of swap in if one of these nodes starts being bad. So we've got sort of the fallback set of Saturn L1s. And then what Caboose is doing is as it's getting requests, it's sending a small fraction of those to it's mirroring them and sending a copy to sort of these other pending nodes to get a sense of, are they working right? Are they fast or should it swap one of those in because they're doing better than the current ones. So what are we doing here? We've got, you know, on the normal CDN, you'd use DNS generally to talk to your CDN. But DNS is centrally controlled, right? So someone has to run that DNS that DNS has someone's name on it. And if we're really building a decentralized CDN, we ideally don't have, you know, a single entity that can turn off DNS. And so if you imagine that future in a year or something, we would have, we can, we can register the Saturn nodes through a smart contract and on-chain and in a decentralized way. But you've got to then have a client that finds who's registered and sends the request there. And so as long as you've got, you know, a thicker software stack, be that a JavaScript service worker or Caboose for GoLine clients, you can actually go out and pull and find the set of active nodes near them in a way that is decentralized and that is resilient. The other, and so we want to provide for one layer of abstraction beyond just a direct list. And that's what it does. DNS also has a bunch of caching things that aren't what you're going to want if you're running something that's really a, you know, doing a lot of traffic and doing a lot of requests. Right. If we're running things like the IPFS.io gateway where we're sending hundreds and thousands of requests per second, it's sort of unacceptable to wait for the minute long DNS time out before we fall over to another working Saturn node. So we want to be able to be much more responsive to node failures. And the way that we can do that is by having that active pull and active management in the client software to quickly notice a notice and responding and start redirecting the request that would have gone to it somewhere else. And so custom software there can do better than just a standard change in the client. I guess the other one is that DNS doesn't always get you the fastest nodes, right? It gives you who the DNS server is thinking is probably in your region. But based on doing sort of these active measurement things, which is on each request, we're looking at how fast it comes back and using that to understand what our actual latency is to these Saturn nodes. We can have a much more realistic ranking of which nodes are performing well for us. And we also by having the fit client get to do a couple of additional things that are really useful for SAP. One is this mirroring to find other nodes. That's active software, right? That's doing that. But the other one that we can do is an amount of challenge and verification of Saturn itself. So we can send challenges for SIDS that we know are unique. And then we can make sure that we get them. And that they're, you know, don't show up also back in the logs of some other Saturn L1 or in the gateway. And so there's types of misbehavior that we can detect and then remove nodes from misbehaving as a result of that. So by having this client software, we get sort of the validation in both directions with logging for payments with making sure that nodes are behaving correctly. And then also we can get better performance. So that's that's the thick client that is caboose for Saturn. Thanks hugely to Arsh and the rest of the Saturn team and then also for everyone involved in Bifrost Gateway for the integration and working with us on the design of caboose. We expect to launch it with RIA relatively certainly. So it will become another part of the interplanetary stack. All right, I think that's what I've got.