 We're going to talk about the use of challenges to build on top of a light plant. So why we want to use light plants, basically, when you have a DAB and you connect it to a third blockchain, you're most probably not connected with your own node, you will just connect to infra, for instance, and this is like a trusted node. And that's problematic because we want to decentralize this space, right? The problem is if you go to this trusted node and the trusted node goes, you know, it starts tracking you or starts censoring you, that's probably a really bad thing to happen if you want to decentralize, right? So what you can do is actually, there are not only those full nodes, these are the nodes from the third network, but also light nodes or light plants that I just used to exchange. What you can do is actually have a light client inside your DAB that will connect to the third client, the third full node. And this light client can be trustless, so you can just verify everything you get from the third blockchain and it is decentralized because it's your own node, right? It will not be censored or you will not use centralized volume failure. So by using the light plant inside our DAB and not connecting to the third party trusted node, we're trading a tiny bit of speed for privacy and decentralization. So when you build a decentralized app on top of a light plant, you have to make sure that you deal with some problems that could happen because of this, because you're using the light plant things are a bit slower and you have to identify your pain points, something that your users who are some problems that few users would have eventually because you're using the light plant and things are a bit slower. So for instance, because of P2P connection, your node could have problems to find peers, for instance, or could take a bit of time to show account formations. Of course, it happens also for third party nodes, but if the internet connection is not good, things like token images will start to slow to load and eventually the whole singing time might also take a bit of time anyway, a couple seconds. So you have to let your users do something while these things happen. So what we want to do is we want to make sure we're transparent. You don't want to freeze the whole thing if your node is not responding. So tell users that the node is not responding and just relaunch it. If you have no peers, maybe the user has a bad connection, you should show that. And while you're sinking because the, you know, the light line will sink, you will have to, you know, show off what you are. If images are long too fetched, it's not a big deal, so you can show a placeholder. Just make sure you're not blocking your users. I'm just going quickly over there. I just want to show you verbally how we implemented this in Feather. So Feather is an application built on top of a light line. So when you launch it, it's actually sinking here in the background. And it will sink in a couple seconds, maybe a minute, but, you know, like you can do stuff as a user. So for instance, here, you know, creating an account, generating, you know, cat. And then of course, you, you know, you have, like, this is the onboarding code. So you have to do the things like show them the money, ask them to, yeah, prove that they've put that on paper, then create a password, confirm. And this is sinking, you know, in the background, you show them like, okay, we're 39% there. And what you can do is, you know, let's say people just can add another account, whatever, taking a number of time, but I'm selecting a file here for my, for my PC. Yeah, I mean, you get a thing at one minute depth. So I want to talk about just this application that is built on a light client has been audited by Trail of Bits. We will release a version, I think, next week, with all the things fixed. And we'll now let it run by the community. If you're interested, go ahead. Sheamus plug, we're hiring the talk to me if you're interested. It's very