 My name's Greg, I'm from Chainsafe. Eric, we've got Eric over here, and Dean. Dean's from Status, Eric and I are with Chainsafe. We're here to present to you guys something that we worked on as a hack and in realizing that there's a lot of actual application to it. And it's called Ultra Lightning. So, quick outline, we're just gonna go over everything and give you guys a code walkthrough. We have a full, we have a, oops, sorry, we do have a running Swift SDK that works, but it only supports Bluetooth currently and it's a work in progress on Wi-Fi Direct. If we want, we can show you guys how to integrate it directly into a native Swift app right now, but we can be like, how far is it? We're gonna try and teach the principles. So, we have this slide, it's kind of cheeky. Put this Wi-Fi, good luck downloading Xcode, so that's what we're gonna do today. We're doing a code walkthrough on an actual integration. But if you have Xcode, we can do it. That's like four games. So, what is Ultra Lightning? Where did it happen? So, we were at ETH New York and basically, we had this crazy idea that we were gonna transmit offline Ethereum transactions over Bluetooth and Wi-Fi Direct and we did it, but very nicely put. We started working on that and then it eventually proceeded into, we started with Type 2 and we were like, okay, let's just do a Type 2.2.2. Then we're like, whoa, these Biden, you know, there's no support for Bluetooth in these languages, you know, on Mojave. And then we're like, well, that's a problem. And then we realized there's no support for certain functionalities of Bluetooth on, only on iPhones or standard devices. So, everything we realized really quickly that the ecosystem itself within Bluetooth, even Wi-Fi, was insufficient. So, we ended up moving more towards Switched and because, you know, actually as people say, it can compile pretty much anything. I still haven't seen it work with this head. So, basically what is ultimately, we're a transport and agnostic manate, so mobile ad hoc network, for sending arbitrary data over the wire. Basically what that means is we don't really care whether you use Bluetooth, whether you use Wi-Fi to react, whether you're using like, you know, hard code, like, man. It really doesn't matter what we're trying to do is we're trying to find a way to actually communicate over your networks that are, we don't care about really the topology, we like, we only care about how you're transmitting data from one peer to another peer when you don't have a stable connection. That's like basically the idea behind this. It's like, how can we actually make that work? And how can we do it in the future to do it so we can actually do kind of like relay a theory of transactions in, or just any transaction really, in a very unstable environment. And we'll get into that shortly. So, quickly about manates. So, man refers to continuous self-configuring infrastructure-less network of mobile devices with an active wireless network. That's a lot of those words. I have just a very little interactive thing I'm gonna show you guys right now to make the difference. So, it kind of sounds like a mesh network and I want to make the, explain the difference quite clearly. So, a mesh network you can think of like a bunch of IoT devices that don't move. Is your camera moving? Okay. All right, probably not. Your camera is like staying still. And Eric is gonna be our camera. You know, same with like your toaster. Your toaster probably doesn't move or that stove that's like all connected. That's a mesh network. Or even your router, you know those Google like old router modules, like they're staying in one place and typically they're not moving and they're relaying this, whatever the data is, like in a very static way. Dina over here is gonna be a phone. And I'm gonna be a caterer. The idea here is that, this is technology that's sending that is very low-powered, doesn't need a lot of work and can actually like, will work on this set. So, in our example, we are static, we're not moving, we're a mesh. But, as Dean starts to move around, we're still transmitting data to them and somehow this camera's actually moving or no, I'm moving sorry, as a pager, right? This camera can move too. This camera can move too. This is a mesh network. This is a mesh network and we're transmitting data like, Dean, hi Dean. Hi. Hi. Hi. And then wait, Dean's gonna go through this wall where there's no connectivity. We're still a man in America. I'm saying, hi Dean. Hi Dean. The messages are in queue. Eric, did you see my hi Dean? Yeah, dude. You saw hi Dean. Oh, Dean's back. Hi Dean. Hi. So right there, you know, these messages that he didn't get, the idea is in a minute, he should still get them when he comes back because Eric over here queued them up for him. That's a man in it. It's a really cheeky way to do it, but you know, it proves my point, right? Any questions on man in it versus man in it? How do you actually like, what about the limitations on the amount of traffic in store? Because that's spamming, right? Yes, it is very gospel. We're still in early stages. We're working on a clever red ink technique, hopefully. We have some issues on GitHub to ways that we can filter and drug traffic to have the least amount of hops. And we do that using more centralized entry layers so somebody doesn't connect. But we'll talk about that. We'll get to the protocol. Any man in it for his questions, though? Just want to make sure we have the difference. Yes. What's it stand for? Mobile ad hoc networks. Mobile. AdMob. It's a lot of those words. That's why I tried to explain that. Yeah. Cool. Alright, let's move on. Yeah, like why is this super useful? Let's think about this for a second. So this photo during, it's Catalonia, right? Yeah. Yeah, where like internet is totally cut off. We're talking like zero internet. How do you communicate with one another? You can do it in a manner of using the tools you already have, like Wi-Fi and Bluetooth, which means like those, that's not sensible. These are like non-sensible tools at a disposal. You know, going over data and connecting to a carrier, that's sensible, right? Because they can completely shut that off. You know, large crowd. All you need are a few people with devices going and you have a full-blown network and where you can communicate with somebody, potentially on the other side of the world, as long as one person is internet, then we can be funneling all our requests through that one person to like bounce back outwards. And you know, you could be like two kilometers away. As long as there's people moving, carrying these messages around. Kind of like carrier pigeons, you know, like they just like fly and fly and fly and eventually get to their location where they need to be. It's kind of a similar idea. I don't know what this is about. Oh yeah, in buildings. Another really good use case for this. So no, no, no, no, no, no, no, no, no, no. Like you've ever been in a building and you're like, there's so much concrete you just can't actually communicate with anybody. Like your phone's down. Like, same concept. You could just keep relaying it until there's one person with internet and you can get out. And one of the things I wanted to like clearly differentiate here is like, yes, this is to like do an offline setup, but it's also a way to actually get offline devices to actually connect to the internet and send and receive messages. So that's where the like power behind this like really becomes like empowering for people is because you can now like, we can give internet access, well, messaging access to the internet to devices that could be, you know, 50 stories deep with no actual active connection as long as there's somebody who. Similarly, you know, like in places that don't have access to like good infrastructure whatsoever, you know, we can, this could set up like in like small communities of like to talk to people, right? Yeah. So that's kind of like my intro to kind of mesh, manage and the use of applications to them. Do we have any questions on that? Cause then we're going to talk about like the actual like stack here and kind of like go a little bit deeper. So this is like the best time to ask about like that stuff. Yeah. Yes. So it's secure Scuttlebot, right? Or is that a first call you would run online? You could. Yeah. You probably could run it. Again, let's just manage some like, we're using a Manit simply to help. Yeah. No, yeah, you could run Scuttlebot on a Manit. Yeah. Right. Yeah. Well, Eric's going to dive you guys deep into kind of like what all this means and what we've got. Thank you, Greg. Yeah. Yeah. So this is kind of our architectural diagram for ultra light beam. We have, I'll go into like each part separately, but kind of the flow is like, if you're sending and receiving information, like data comes in through the transport, it goes to the node. And if the node supports like certain services, then it will process that information. If it doesn't, it like propagates it back out to somebody else who can potentially, then in reverse. So transports. It's, we, I'm not sure if we're going to stick with this name, but transports in ultra light beam are, it's the communication protocol, I guess. So that includes things like Bluetooth, Wi-Fi direct and real-time. That includes things like Bluetooth, Wi-Fi direct and radio. But it could be like literally anything, as long as you conform to like an interface that we provide. And that interface is very simple. This is what our interface looks like. You implement a, why is it only showing hats with it? Because you're using the spacing on them. Oh, sorry. That's our interface. You basically have to implement two functions. It's the send and listen function. So I mean theoretically like, you can do that for like any form of communication. So you can even do it over ultra high-frequency, low-frequency radios if you want to implement that. So transports, they're interesting because in ultra light beam, we can support multiple transports at the same time. So like if you have a device that's Wi-Fi only, you have another device that's Bluetooth only, you have another device that's Wi-Fi and Bluetooth. The devices that are like only supporting one transport can also talk to each other by going through the second one and that makes it super powerful. So you can create like these massive networks that are in the macro scale are very short range, but then it connects like larger other magnets to form like a huge magnet over like radio or something like that. Currently for ultra light beam, we support Bluetooth low energy for short distance communication, which we will demo in a little bit, but soon we're gonna focus on Wi-Fi direct and get that working for Android. And so like we can do like a bunch of cool stuff. Yeah, diagram again. Now we talk about services. So currently like ultra light beam, like the goal with ultra light beam is to be able to like relay these generic messages, like these UV message payloads. But so services are things like we wanna make it so that ultra light beam can serve like specific application type things as well. So we wanna be able to like, as Greg said before, like relay transactions offline, like on a plane or something like that. And then maybe one guy has Wi-Fi because they rich and they buy it. Sure. They can relay those transactions on chain. What if you can start like an offline state channel like you're on a plane? Not sure what you want to do on a plane. I like this one. It's like you never get Wi-Fi, but you can start like offline state channels within like a plane and send people money on a plane. Or you can just do like a chat messaging. So these are what like services are. They define like how would these, like how to handle these messages if you're a node and nodes don't have to support all services. They can support sound services and if they can't support it, they just like send somebody else who's on their peer list and maybe they can support it and just keeps going and going. So a relayer, we have a concept of a relayer that's a node that generally lives like on the edge of the mesh network. Like for example, like in the, like in a like a festival or something like that, there is technically like, you know, there is like cell signal, but it's like super bad. But it might be good for the guy who's like maybe a little bit further out from like the crowd and that guy's internet. So like, you know, you might try to send like a Facebook message to your mom, showing it like you're partying. But you can't cause you're like in the middle of the festival. So you send it out through ultralight beam. It goes like through a bunch of people. And then if finally it's a guy who has internet, he relays it to the internet, gets a message back and does, you know, like tracing back to you. So yeah, generally these things like live on the edge of the network. I already said that. Yeah, so we have Bluetooth low energy right now. We got it working on Mac OS. It should be fairly simple to get it on iOS cause we're using only libraries that are core Apple and their cross platform. We're gonna do Wi-Fi direct soon. It's gonna be supported on Android and all that. So that's gonna be dope. Don't go to that. Don't go to that, yeah, you see. Yeah, so we were gonna prepare a full workshop and then we got here on the first day and we realized that the internet is shit. And so getting you guys to download packages and stuff like that isn't gonna work for us. So what we've decided to do is that we'll do, we'll try to do a quick demo live of how one of the relayer works just to show that this isn't completely vaporware, that we can actually send and receive messages. Did you guys download it? Yeah, dude. If you guys actually have Xcode, you guys can pull a repo and join our network too. But if anyone has a Mac with Xcode and internet, they could pretty much pull and join and see it in action as well. No, I don't know how. I don't have a plus phone. I don't have a plus phone. You need more than five times. I'll also say a little bit more, dude. Five more button presses. There you go. That's good. Do we have any questions thus far? Yes. Yeah, so I was wondering about the Facebook example. So these are asking messages, but can you actually initiate this and encrypt the H2P channel through communication? In theory, yeah. But that's like a lot of work. We've only been working on this, me and Dean have been coding this for the last four months and we've been spending 10% of our time, 20%, because we have day jobs, put food on the table. Yeah, we made design, is that our rationale behind our design is we made it generic enough such that you can do whatever you want on it. This is like, we just provide you a way to just send messages, but you can definitely encrypt messages. You can probably build TCP on this. You can probably build, you can do HTTPS on this too, probably. Is there a relayer up today? Yeah, just pull it this morning. You be a relayer. Yeah, so it's like super generic, should we're built it over? Yeah, built it. Going back to your music festival example, so the guy on the periphery who actually has service, does he need to be running this? Yeah, so everyone involved in that chain of, yeah, what's so good to have this. Yeah, so the idea behind what we've done is we're trying to make it as minimal as possible because that way any app could integrate the protocol itself as like a secondary app, as like a layer on top of an existing messaging service, right? So this isn't like, we're making another chat app. This is like, hey, please use this as a form to do your, this is like a way to toggle like, hey, I wanna like use the offline mode. So you're existing like chat app, that's kind of like the design idea. So in theory, if you went into that mode, you could essentially receive messages from other apps that support UV, right? So you can have your own the same interface. Like what in theory, if you know, Facebook would ever adopt it, you know, in theory, like what's app could communicate with like messenger on an offline mode, right? Yes. What about privacy, so can other ways to prevent, or can they really read the messages or? No, so you can do whatever you want to the payload, right? So the message itself, we don't define how, do we, we don't define how you use the message, but you can encrypt it however you would choose to, to ensure that, like we wanna be as less intrusive, as least intrusive as possible, so you can do whatever you want, you could encrypt it should you choose to. Yes, just your first step. How do you know where to send the message? Do you like broadcast it all? Is that not incredibly normal? So naively, we have this thing called root gossip right now, which is doing that. We're working on, Dean's been doing a lot of research with Oscar, showed up, Oscar, on better routing paths so that we can do more efficient hops and I actually like have less hops throughout the network itself. The problem though is that typically what you would, in a festival it's a little bit different. Festivals, there's not, people are typically standing still, so we can actually benefit from the fact that, I can assume that a device would probably last more than a minute and roughly, you know, like a five meter radius. But in a busier crowd, things get a little complicated because what ends up happening is you have people moving from, like you can assume, like we only have connectivity for like maybe 10 seconds before now the peer list might be changing and drastically changing. So what we have to find is a way to do an efficient, like one, like a DHT wouldn't work here because like it would be so aggressively updating all the time, that doesn't work. So you have to maintain like a really close peer list and find like better routing paths. So that's what we're working on. But if you need to have a static peer list, right, like there's only one guy, let's say there's only one guy who's actually got access to the internet. Yeah. How do I know the route to get to him? Like I would broadcast to my page. In magnets you don't know routes. Yeah, so I would. So mesh nets have the efficiency that you can pre-calculate routes. And in magnets because we assume a very short liveness of things or a very short liveness of the peers, we can pre-determine routes. So there's certain ways to, for every hop, pick the next best by querying their peers right before the hop. But like if there is like 15 people between you and the internet, you can do that. Right, so I would broadcast like potentially to 15 multi-byte times, high peer lists, they would be called that. Yeah, that's how it works in the worst case. In the best case, what we have right now is that you try to first send to the peers who have a specific service that you need and then hop further on. Like the worst case is, I don't think, yeah. Did you get it? Yeah. So what about cache evaluation in every message? Is there a pattern to know if they go to sale? Let's say I relay somebody else's message out, how do I know that I got received, especially if I go on a scale? Yeah, so we've toyed with the idea of kind of like an act where once we've seen it, we acknowledge, we like do a quick cache of it and say like we're not gonna like push this. If we receive it one more time, we're gonna like ignore and filter. Problem being is some, what that does is if your local, if your mannet disconnects from like a larger group, you end up pushing that really quickly and then the message gets dropped. So we've played with the idea of kind of like expiry times and stuff like that, but it's still kind of a big, open question until we can actually deploy this in a bit of a larger scale to actually like kind of see like how long does the message survive? You know, until it can actually get to its end user. One of the problems we've had right now as well is testing anything Bluetooth is shit. It would be optimal if we could like use something like white block and spin up all our nodes and run it, but that's close to impossible because of how Bluetooth works. Bluetooth, the way it works is like it's driver dependent, it's operating system dependent, and then those operating systems implement different APIs. And so like our Mac implementation would be really nice if we could just spin up fake Macs and test it, but we can't do that because also you can spin up Mac VMs because it doesn't exist, unless you spin up Hackintoshes, which then usually don't have the proper Bluetooth drivers. So the entire testing of this requires us to actually get together physically and test it, which has been kind of hard considering they live in Canada. Would you just do a simulation on physical devices? Yeah, we're gonna work on stuff like that. Yeah, if you have any MacBooks you're willing to donate, we'll take them. So here what happened is we're both running a relayer with just a basic service that implements just normal messaging between Eric and I. It's a chat app. Essentially it's a terminal chat app that just spans a main channel. It sends to a service directly so that anyone who would be connected to this channel would now just be receiving these messages in our proximity, which is pretty cool. Next thing I'm gonna do is I'm gonna show you the code to some of this stuff. This one is also too small. That's not how it works. So pitch, third unpitch. Oh wait, go, wait, what? Oh what? Oh yeah. Do you guys know how to use your fucking 90s? Oh. This is cool. Problem with presentation mode is you don't have a, you don't have a street. Yeah. Any questions while deemed, you know? So you do message replaying? Like if it gets partitioned and then reconstructed, you replay messages. Yeah, messages are re-transmissioned by nodes. Yes, you queue for a couple of times. Exactly, yeah. So right now what happens is a message will hop around in a network for quite some time until nodes no longer choose to re-transmit it. As said, it's a very naive sending algorithm which I will show you here. Here we go. That's some other code right there. So this is essentially the send function. And what happens in the first check is we ensure that the message, there has a recipient which is a device or a service which is like a characteristic like Ethereum transactions or whatever. The recipient is a identifier, is identified by a public piece so that one recipient can have multiple transports attached to it, kind of how multi-addresses work in the P2P. And then what we do is we try to serialize a message because it's a protocol buffer that's not really that important. And then we get to, we iterate over our transports and our transports have specific peers. And what we first do is we check if that, if our recipient isn't empty, we try to find a peer to send to that that has that specific peer ID. And if we do that, we return, we've done a successful send. We don't need to send it to anyone anymore. What we do otherwise is we look for all the peers which implement that specific service and we then flood that message to every single member who implements that service. And when we do a flood send, we ensure that we're not sending a message to the person we received it from with a person who originally sent it. So if, for example, Eric sends Greg a message and then Greg passes that on to me, I won't send it to any one of those anymore. But for example, if Eric sends Greg a message and then there's someone between Greg and I, Greg may receive that message again because we don't have the entire sentence we only have the first because that's the original sender and the latest because that's the person we got it from. There are optimizations we can do with this. And then we count how many peers we sent it to because if we sent it to none now, this is part of our naive approach. We end up just flooding it to everyone of our peers which is kind of ugly but it works for our current implementation use case. So that's pretty much architecturally, yeah. Let's go up the two different, Bluetooth versus Wi-Fi Direct with the geographical range. Talk about, do you have a different peer list and peer discovery mechanisms? Yeah, there will be different ways of, because for Bluetooth as well, Bluetooth limits itself onto eight peers. So we need to optimize that we're peering with the best possible peers at a specific time. With Wi-Fi Direct, you don't really have that. You can start direct connections with, I think almost like 16 or 17 devices at the same time. Bluetooth, you're limited to eight. So the way we peer right now is very naive but there is open research issues on how to best peer with other members. So because of the limitations of all these things, like we have naive implementations but we know of course that we need to have better implementations and discovery and routing will be different based on device, of course like path finding, et cetera. But yeah, that's pretty much the entire send function and this is pretty much the hardest part of ultralight beam. Like when you implement a transport, you don't need to care about this. When you implement a service, you don't need to care about this. We take care of that. Then I'll quickly show how transports work. Showed in a very rough way because there's a lot of ugly code on top of it. What happens is a transport asset implements the send and this listing function and they then have callback functions which is like the transport received certain data which the node implements so that when data is received the node tries to unpack it, checks if it is supposed to handle that data and then passes it one layer up which would be for example, your application. So the node does all that checking for you. So if you implement ultralight beam, you can be certain that you're only receiving packets that you know how to handle or that were sent to you directly and are not just packets that you're meant to forward because right now what we have ultralight beam nodes are all have a forward capability so that we can have this strong network. So even like if you were building a chat app and someone else is building a game for example and those both implement ultralight beam what will happen is your chat app might actually really someone else's game app packets and that way you can build like a really strong network. Like just imagine in New York City if WhatsApp and both Telegram had offline messaging you'd never waste data again because you just walked through the disciplines. So yeah, that's pretty much what we have. I'm gonna show the relayer code as well. A lot of this code which we have external in the relayer is gonna become a node native code later on. That's an open pull request right now but relayers are really simple as well. What happens is it checks if we have that specific service and then that message is processed by specific service. So in the case of our chat app it was really just decoding the data that we had in our packet and printing it out. But yeah, I don't know if I have that branch in code. See, if we had a ultralight beam we could use give out. Are you guys concerned that the relayers will just be passing too much through that they find it frustrating and they wanna like opt out and so there's this kind of... So what we're thinking of right now is like an accounting model that we do some form of tit for tat that you wouldn't continue relaying messages through for someone given that they have used up all their bandwidth unless they for example start paying. But the second we have some naive accounting model we can figure out the incentive models on top of that. So that's why we started it at S New York because we thought about this would be cool if we then also have payment channels on top of it. So that's someone like you pay for relays, right? Which we can do and it might be it would probably end up being cheaper for than having to get data into certain places. And they have like distinct kind of these in the peer list to say like they don't know how to get there and then you go out. Exactly, yeah. And then we smooth. Are there any questions? Have we lost on spam attacks on that group? Not yet, like we're very early stage in spam attacks and man, that's a relatively hard to solve. Have you looked into ways that are going back to the search engine, just like the one that you can use in the browser to describe the search engine or so you can actually solve the problem. It's called? Waze. So we were looking into a more traditional man-net routing protocols and there's three of those essentially that are used for man-net. Because the problem with a lot of these routing protocols is that they don't work the second you add in the aspect of connections being very short lived. So I don't know if Quazer can likely also be a problem with the tools in that person. Okay, thank you. Yeah, man-net routing is hard. It's, there's like three, yeah, as Dean said, there's like three different kinds. There's obviously trade-offs in like processing speed or like, yeah, like you can either have like very accurate routing or you can have, or where you would have to do like a lot of computations. So, yeah, one of our next steps is gonna be investigate like building on all of these different ones and do the measurements and testing them out. And obviously doing original research on routing and see if we can come up with something better as well. Also with, when it comes to the relays to kind of address like your question about like throughput that ideally in, let's say a spot in like a New York, let's use New York as an example. In a festival it's a little bit easier. You can probably get away with like, with just like a mobile phone or a tablet, you know, kind of doing that. In a dense city or in a much more dense area, let's say, let's use the protest going on, like a protest that goes on. We have like a lot of people running around. Ideally, what you could do in those situations is kind of set up like the actual devices that are meant to be relays. It could be as simple as like battery packs in a backpack and like a pretty powerful computer running in there. Relayers that are intended for dense areas should not be a phone. They should be something that can actively take a meeting and are expected to take a meeting so that you can actually get the throughput you need. And again, it's like specific, it's for the specifics. Would you be able as a normal non-relayer, ahead of time to say, I want to contribute to this. You do have the capacity to potentially do it, which, you know, wants some of the data and sort of take the hit for everybody. Yeah, so we'll do this. Yeah, exactly. So the beauty of all this is that you can choose which services transports you want to use. You can choose Bluetooth Wi-Fi. You can also choose what type of a node you're running. Obviously incentivization laws would be cool, but like, you know, I don't really want to deal with crypto-kinawness. This is like more of like a, you know, it's a good will or it's like a public good. Like, you know, when you need this, it should be used. I don't, we don't, it'd be beautiful if this is running all the time in like a subway, you know? But in ideal, ideally, and realistically speaking, this is something that should be used in like very, for the use cases at and like concerts and whatnot, to which like people are going in, understanding the conditions and like knowing like, this is just like a very viable way to like reliably communicate with peers. This isn't like, you know, AT&T in hand, self-coverage. I guess at a concert, you're also talking to other people at the concert. Yeah, so ideally, ideally, you'd never actually hit a relay. Like given there would be enough device coverage in a place like New York City, you'd never actually hit a relay because you would just halt until the destination was found. That's also something that I like, guess I glossed over, like, you don't actually need, ever need the internet in these use cases. We always say the internet, so it's like, oh wait, like your phone that's not connected can talk to people. But in reality, as Dean says, if like at a concert, you're just trying to coordinate like where you're standing, right? And like that's what's really powerful is that you can say like where you are, kind of like the same thing with like, you know, live protests or whatever. You can like, it's a lot easier to coordinate where you are when there's like a million people. You know, and the Raptors won the NBA title. I was trapped in the streets of Toronto and literally did not know where my friends were. It was awful. And like that's kind of like where the use case, like it becomes very powerful and that's why I say it's very like use case specific. I don't think that's something that should be like widely deployed 24-7, rather like deployed and very on a location basis. Yeah. Do you guys have any sort of like account mechanism besides like, I guess what would be like the blue two floater in your back of the device, right? So like, basically to make a sense like not a troll box, right? Because like a lot of concerts, they're like a million messages going through filter find in my friends, right? Yeah. You like to talk about identity basically, right? Yeah, something like that. Yeah, here, notes have identities. No, because so Bluetooth Macs often aren't exposed by high level APIs because of security reasons. So what ends up being exposed is a UUID that has changed for every device. So there's, devices have a public key, a private key kind of like in live P2P. So you have an identity that can be found on X transports. Okay, the UUID can be set. So I guess you have a public private key counts. Yeah. Is there any information like, if you're the tenant civilian, you're example of the rafters downtown and you're trying to find somebody else. Is there any information about when you receive a message, which direction that came from? So you could potentially use this for like a hot or cold or naive implementation where your friends aren't saying, here's where we are, you're trying to get to where that message initiated physically because of all these like, yeah, so in theory. Yeah, in theory you can do that because a group of people, I think there's two separate groups of people. One at University of Waterloo, one of University of Toronto, where they were actually, they're able to, this is theoretically possible. We don't have it right now. Where they were able to actually do indoor offline GPS by bouncing off of Wi-Fi and Bluetooth signals to understand where they are in proximity to the building. So it's definitely possible. And I do know that you do have access to a range in Bluetooth. Yeah. I don't know about Wi-Fi. Yeah, you have some sort of access to something, so you can. It would be Wi-Fi range. Right, exactly. That's a sign of almost strength. Yeah, but you have to do some like, pretty nifty accounting to kind of like, basically, you have to like, essentially like, re-tangulate the entire shape, right? Because you get some like, really ugly shape. You get some zigzag, and you have to basically find like, this straight line somewhere. How long would those jobs be based on if you're in a tech house? So Bluetooth, you're looking at with 35 feet tops. Yeah. Yeah, you have like 35 feet tops and you can like, realistically speaking, you can probably expect to get like, upwards of like, eight hops. Like if you're in like, close together, like within, I'd say, 100 meters, you can probably at least get eight hops, maybe more. So you're like, it's a lot of data to be also transmitting across the wire, because we don't keep that. I mean, that's the deal I was saying, we only keep the last recipient and the first one. We could pay to maybe add a counter to some degree, but you know, it's also, it becomes a very difficult like, yeah. You could also put a call on top of this, right? You can do it every month. And you can have like, message latency between the different peers, and then you get like, you know where somebody is. Yeah, for sure, you can like, attach like a bunch of metadata to like your packet, based on like, the previous sender. And then based on that, you can decide like how to, which peer to send it to next best, right? Like using like the RSSI example, I guess generally signal strength doesn't necessarily mean like, somebody's further or not. But I mean, sometimes it does. But like you can, if you were trying to disseminate information really quickly, right? You can attach like RSSI information to like your unique packet. And then you try, you prioritize sending it to like, the person who's furthest away, and then go like down on that. And in that way, you can like be sending information like super quickly, right? Cause you know that guy's far away. So then he tries to send it to his peers, just like pops randomly, you know? And then like, how do you guys think about using radio? One slide, talk about radio. Oh, we're going to do it as a troll transport. Someone's working on it right now actually. A troll? Yeah, because it's like, you know those obvious radio due to like send messages across Europe? Yeah, someone is working on a transport for that. But I mean, in theory, you can radio both a lot further, right? Yeah. If you've already established it, it's like you can use the acknowledge thing you were talking about earlier, and they found each other, potentially have something where then the radio signals trigger on some sort of frequency that's also whenever it's really light, payload, and then boom, you've got an actual direct path to radio. No, you should do. Go on our GitHub, there's a research repository. And if you have any ideas like that, write up an issue with like any research, interesting research ideas. Like we're trying to get as many people as well as possible to contribute on this. What's that company that does, I think they've done Bitcoin transactions over radio. They have like this little. Yeah, but the difference about their thing is you need external devices for their measurement. Do you know the name of the company? I keep hearing the bloody name. Don't know. Someone keeps sending it to us. Someone keeps sending it to us. Yeah, we've kept being like, we don't want to do this because you need separate devices. Okay, so it's something. And it only sends Bitcoin transactions. Okay, so it's specific to their device. Can't you generalize? No, it's a generalized thing that then someone built Bitcoin stuff on but it requires specific hardware. Okay. It requires your phone to be plugged into an antenna. And the list. Go to an antenna. It will go to an antenna. Go to an antenna, exactly. Oh, yeah. And it's patented. It's closed source. Oh, that's... Yeah, well, it's closed source stuff. The main reason we're doing this, yeah, there's like, obviously, I think during the umbrella... Well, no, now in Hong Kong, there's like, because FireChat used to exist. Yeah, and what happened there is the developer was told by the Chinese government to stop building on it because he's a Chinese citizen. And now there's like another one and they have an SDK, but it's a closed source SDK and you need an API key, which is kind of weird that you can have an API and an offline messaging. Yeah, basically, there's like, there's like two companies that are working on mandates right now. There's FireChat and there's like the other thing. But they're both proprietary, they're closed source. Yeah, Vergeified. Oh, yeah, Vergeified, yeah. They're closed source. They cost money to use. It's like, we don't want to pay for this. We just want to be able to like, just download and use it like we just did. Yeah, yeah. I think it's what, free open source software, technically. I think it's MIT. Yeah, it's all MIT licensed. Yeah, and that's the point, right? Yeah. A steal it, run it, use it. Like, this is a free public good for people, right? This is, and as you said, hey radios, that just means we can, as soon as we get better bands and higher, like, what low frequency goes further. Yeah, once we get more like low frequency bands, just like think of the possibilities here. We can literally be running like another sub-internet protocol. Like, because why would I want to use the internet when it's attached to an ISP? Right. There's a lot of possibilities here. Design space is huge, which is awesome. Yeah. Wouldn't you need to cache the unique idea of the messages that you're providing around because you can run it to an infinite loop with four offline nodes? Yeah. Yeah. So you guys are caching. We are caching right now in the naive implementation, but there's a discussion by our own on how we best do that. Oh, right, gosh. There's also a question of if we need to build a data sync protocol on top of it, something like TCP, so that we can assert that messages are somehow received. But the question then there is, how do we do that with all the hopes that are in between two points? There's a lot of ideas that we are floating around, but a lot of research that needs to be done to figure out optimal solutions. And like this Clover shows you could do that we've thought about. So if, for instance, you had the ability, you also had a low frequency band, we could, in theory, set something up where the acknowledgments go over the low frequency bands so that everybody can receive it. And we don't actually use it to actually disrupt the network and you go and use Wi-Fi and Bluetooth where you can send way more bigger payloads across. And that could be a way to cheaply do it. When the device receives a message, it goes, hey, I received it, fine, this is you, thank you. But again, these are all open questions and obviously becomes hardware challenges and we're trying to make it so that ideally it doesn't matter. You shouldn't have to have hardware. And we also have the challenge of battery on a mobile phone, right? Bluetooth and Wi-Fi Direct, you don't want that to be all the time because at one point you're gonna run out of battery. Yeah. So there's a bunch of those technical challenges. It should allow people to harvest the battery level through the layers. I can send a message and just get batteries left. Easy battery. That's actually a thing in Michigan. Yeah. Because you can attach weights to anything.