 So I'm going to present to you Rapid, which is a new experimental download client and the goal is to optimize for Peruvian. So the main program right now is that we use Bitwap, a Go Bitwap client, which works. However, it's not very fast. I have quite fast internet and it's downloading at 3 mb per second. And just so you know, the file I will be testing with is dist.ipf.io because it's a pretty big folder, 50 gigabyte, and it has lots and lots of people that download IPFS themselves. So it should download very fast because there are many peers in the networks that have the file. And yes, it's downloading very slowly. So I'll show you the demo of the programmer. So it's not downloading very fast right now. So it's only 75 mb per second because right now Rapid, so my new client is using gateways for the backend and the gateway are a bit overloaded right now. So that means that the speed right now, which is already pretty time faster than Go Bitwap, is actually limited by the file you're using. And so the main way that Rapid is achieving this speed is by multiplying the transfers. So instead of downloading blocks one by one or 32 by 32, Rapid is going to divide the graph in multiple parts in a tree following the links between the values blocks. So all the blocks in the middle, so except x, y, and z, are blocking the graph we want to download. And then you have a algorithm that will repart partition nodes and gives them tasks on values part of the network. I won't go there in detail about how the algorithm work. If you want to know, I've made a presentation of it that moves a byte working group. So you can find the link right here. It's expressed with performance. It's very good, I would say. The positive group is just basically you take the sum of all the peers you have. And unless in each case where it is a graph, you have more peers than blocks in the graph that are able to be downloaded, you should expect just the sum of all the group. And that's one of the main reasons how I can reach 2.5 to give it per second, which is a limit of my fiber, that it will download from many, many peers in value. And the time to first byte, it's because at the start, we don't have any peers. Like we only know one block. So what Bracky does is that it will download from many, it will download the same block from everyone because it has nothing better to do. So the time to first byte is a minimum from all the downloaders, which is still quite good. It's not incredible, but it's so quite good if you have multiple gateways in the lower values. The efficiency, the CPU usage around 100 nanosecond to 500 nanosecond per block, which is just counting rapid. It's not counting the protocol behind, which is extremely good. In theory, you should be able to do 45 to be byte per second. Obviously, you don't do that. It's just basically rapid is like so fast that all you care about optimizing is your actual underlying data transfer. The memory usage is more of depends, the bigger your graph, the more memory it uses because we need to keep the tree. And the network efficiency is still rather good. The wider the graph is, the better, because we don't have those cases where you have two people down things the same block as much. The right now, that it only works on gateway using the car response. And the goal is to make it support more protocols. So I have not worked on this yet, but basically we need a slightly more complex logic that keeps track of the list of work because we have this logic of the metric, which is how many people are attempting to download some part of the graph. But I will work on this in the near future. And GraphSync would be very easy to add because you can reuse the same logic for the car gateway, because GraphSync can get a car over a gateway. It's pretty close for the code. They are both appled and server driven. That means that I ask for some requests and the server is sending me a bunch of blocks without having me to keep asking for more and more. So I can start a request somewhere and then stop it when I'm unhappy. The main reason right now it's not shipping in Google is because it lacks critical features. Content routing. Currently, I just have a hot code list of gateways I'm using. We'll need to use DHT and IP and I. Now having BitSwap support, this is very important for Kuba because all the content we download today is in BitSwap. And a small tweak to this algorithm. Right now, it's the algorithm that everyone has all the content, which is true for a gateway because even if the gateway doesn't have the block, it's going to fetch it for you. So I need to add something like this where it's able to remember, oh, this here doesn't have that block at all. I want my story. And so that's all.