 I'm going to start from going way back in December when I talked about optimistic provide, which is addressing a problem that there is in IPFS that the DHT provide process is very slow. So you can see here the delay that it take the latency that we have that we see when we try to provide something so simplistically this means when we someone wants to publish something to the DHT. This takes quite a long time because we need to find the right peers the peers that are going to be more most easily findable later on. So what we also find out found out through some measurements is that okay it takes so long to go and find the appropriate peers and finalize the process but at the same time we figured out that actually if you go back and check after all this time that 10 or 50 or 100 seconds that we took, you know, to find those 20, which is the right number, peers that the provider record should go to, we actually have found those within the first second. And then the process was just hanging and trying to find even even closer peers. And yeah, and this is the figure that shows that it's mostly less than 0.5 seconds, but it could go up to a second or a second or two. So we thought okay there must be a way to try and find those peers and finalize the process much faster. That's why it's called the, well, some of the proposed solutions are called optimistic provide, and there were two approaches that were proposed one is called the estimator based approach and I'm not going to go into that today. The other one was the double query approach. So what we do there is that instead of going and finding, you know, asking around which is the closest peer to the one that I want to find according to the CD of the content I want to publish in the network, and trying to get as close as possible. Let's try to ask two guys at the same time. And that was actually the third idea and the thinking behind that behind that was that, you know, when we independently ask to completely relevant peers, you know, what is the closer beer that you know, for the CD, when we start getting common answers from peers that are coming back to us then we're probably have, you know, the, those nodes are common between both queries are probably the ones that are getting the closest ones because you know we're converging to that hash space. So we went on and the update here is that we implemented that, and we have some very initial results which I wanted to share with you today. And it seems that unfortunately, the results are not very accurate. So it's not necessarily a positive result that I'm presenting here today is just progress update and what we plan to do next. So if you go and check what happens when you go and ask peers one by one, like the single query approach, you see that you go in this graph the X axis is the normalized X or distance which very simplistically means what is the distance between where I want to reach, and what I have actually, which beers I have actually found to store the record. And this obviously is very small is like 0.01%. So it means that this process is very, very slow but very efficient at the same time, because it goes as close as possible. So going and checking the double query approach, we see that it's not bringing very accurate results. So that 0.0 something 0.02 that we've we're seeing with a single query approach now it can go up to 10 and 20 and 30%. It's still, it's completing faster. And we can see that more than 60% of peers are finding indeed, you know, those final peers very quickly, but these does not, these does not continue for the entire process for all of the provide operations that we have tested with. So what does this lead us to think it leads us to think that we need to perhaps play around with this and have perhaps not two queries but maybe even do three queries and try to see what is the intersection of answers that we're getting any, you know, if we can convert faster when three separate queries bring us back the correct results. It means that we need to also investigate other approaches such as the estimator approach that, yeah, I didn't talk about it today but I'm going to talk about it in a future session. Yeah, and also ideas that you might have so if you know if you can think of something that, you know, an estimation approach which is going to give back results much faster. We're more than happy to receive feedback and more ideas you can find here. I can share those slides. There is a proposal the discussion and the project page where we post updates and everything. So, yeah, that's me. Thank you very much. And yeah, thanks for listening. I mean, your screen was frozen the entire time so we didn't see the graphs. Could you really. Yeah, you should have said, sorry, people said in the chat but I guess like nobody wanted to interrupt. Could you say, could you send the links to the graphs and and links to the. Yeah, that's fine. And, and the implementation links just so we can look at the methodology. Yeah, absolutely, absolutely. Where's the place the best place to send out nowadays. I'm going to put in the chat, I guess, perhaps. Yeah, exactly, exactly.