 Yeah, great. So today I want to give an update on the DHT routing table health study that we've been conducting at Problab. And so I'm going to start quickly by introducing because this is a bit technical. So the Calemnia DHT routing table, the weight works. So Calemnia is a distributed hash table, which is basically a decentralized overlay network in which there is no central peer. And each node has to know at least some of the other peers participating in the network just to be connected. And this set of peers is called the routing table. And so in the Calemnia implementation, all of the peers that are in this routing table are sorted. So are sorted in what's called K-buckets, which is defined by the core distance between a peer ID and another peer ID. Each bucket is kept at 20 peers. So I'm going to just give a quick example to illustrate better. So for instance, if we take a random peer identified by an 8-bit string. So 0-1-1-0-1-0-0-0-0. And I just generated some random other 8-bit strings. And I filled in those peers or those bit strings in the K-bucket of the initial peer. And as we can see, so the logic is if two bit strings share a prefix of length x, it's going to be in the bucket x. So for instance, in the bucket 0, all of the peers start with a 1. Whereas our reference peers start with a 0. And so on. So for instance, in bucket 2, all of the peers share a common prefix of length 2. And we can see that when the peers are generated randomly, which is the case for IPFS or IPTP identifiers, we expect to have a lot of peers in the low ID bucket and a way fewer in the higher ID bucket. And in an exponential way. So to measure a bit the health of the actual network, we use the NebulaCroller, which will try to, that will crawl the network and provide a snapshot with all of the peers that are online and all the state of the routing table. All of the peers that are in each node routing table. And so for this specific study, the data was taken out of 28 scrolls, so from 20th snapshot of the network over one week. And so the methodology we use to get for this study. In the global snapshot, we're able to reproduce the cable cat for each of the peers. Simply by computing sort distance between each of the peer in the routing table and the reference peer. So from the global view, let's say we are able to see some of the node should be included in a cable cat, but are actually missing from the cable cat to retrieve from the network role. So we can see what the theoretical bucket should be and what they actually are. So for this study, it was a bit hard to compute all of the XOR distances because to see if any of the peer were missing, we need to get the X closest peers to a specific peer ID, which is computationally expensive as the XOR distance is not linear. And so we implemented a binary try in Python to speed things up. So the results we get from this study is the first we want to study what's the ratio of peers that are in someone's routing table but are unreachable from the network. And so basically stale entries in the routing table. So that's the result we get. So for bucket 0 to 8, the rate is quite low. So the buckets 0 to bucket 8 are the bucket that are full that contain 20 peers, almost all of the time. And so the rate is very low. It's on average out of the 20 peers that are in the bucket 0.75 are unreachable. So that's very good given the high train rate that we observed in APFS. And for the bucket 9 to 21 we observe a higher rate, but it's still very acceptable. And so I think we obtain different results for the low ID bucket and the higher ID bucket because the replacement method is different. Is implemented differently in Google. Now to the next measurement. So now we want to see if the distribution is the distribution of the peers in the cave buckets is as we expected. So as the peer the peer idea are expected to be generated randomly over the key space of 256 bit. We expect that buckets. So, yeah, there will be a half thing on the candidates that are eligible for each of the buckets. And so we can see that bucket 0 to 8 are capped at the maximum of 20. And then we can see this experimental growth or decline going down. And so that exactly the number we expected, which is good. So when we look at the rate or the number of missing peers for each bucket, we can see that for the full buckets. So, yeah, sorry again, the missing peers are if first bucket is not full. And second there is a peer in the network that would have fit this bucket. But that is actually not in this bucket that we've been able to observe using the global snapshot. And then the missing peers rate for the full bucket is very low. It's 0.12 out of the 20 peers. And it's a bit higher for the higher ID bucket. But again, it is still very, very acceptable. Now getting to the, so one of the key properties of the Academy at DHT is that the node is supposed to be aware or to have the 20 closest peers to itself in its routing table, just for routing their property. And what we observe is that given the high turn rate again, so we expect to have, yeah, not 100% obviously because some nodes are entering and leaving the network. So it trained us constantly. And we observe surprisingly that 61% of the peers know all of their 20 closest peers. So all of the 20 closest peers are in the K buckets. And 95% of the peers know at least 18 out of the 20 closest peers, which is also excellent. So what we can tell from this study is that the DHT is very healthy and maybe more than we could have expected. So it's perfect. So we have a very low rate of sale on trees in the, in the K buckets. The peer distribution is as expected. Only a few peers are missing from the routing table, which is good again, and a very high rate of no, no 18 out of the 20 closest peers. So that's very good. So the problem is doing a lot of RFM. I think at the moment there are 20 RFM that we publish on the GitHub repo protocol slash network measurement. So you can encourage you to go and check them out. So we've got the published one, which is RFM two, and this one RFM 19. So there is a report with much more details that is available on the, so the peers and marriage yet but the report is already accessible. And so I'm going to give some more details on this at the IPFS thing. It's going to take a week. So if you're around, make sure to attend the measuring IPFS track. And we also measure some, some things that were odd, and may mean that the DHT isn't as healthy on the, on some other aspect as we think, because the diversity in the low ID pocket is lowering over time. And it might become a problem because the network may become centralized. And here are some references with something so I will pull them later on the Google Docs. And yeah, that's it for me.