Build Peer-to-Peer Applications with Pear Runtime

Welcome to the PAIR runtime workshop. This is an introduction to this thing we built, which is called a hole punch, which enables you to manage, deploy, create peer-to-peer applications. No central service required at all. So, we're going to get into how to use it in different things and we're going to build a little chat app, peer-to-peer chat app.

We've got seven exercises, and they're pretty straightforward. The workshop will be either three hours or however long it takes to get through the workshop and whichever is less. And then we're done. And you'll have a ton of information. So, let's get into it. If we go to the link there, hole punch to PAIR workshop GitHub repo, there's some setup instructions. We're going to be talking about Keating this, and, Keat, you can share multiple screens. Yeah, so if you go to the repo, and we've got some setup instructions.

When you're setting up PAIR, what you're actually installing is a whole run time. So, PAIR isn't built on Node. It's built on something called BEAR, which we'll talk about later. But if you have Node installed, and you'll need Node installed to do this anyway, because once we start setting up dependencies, we use NPM install. So, if you don't have Node installed, get that installed now. If you're on Linux or Mac, MVM is good for a rapid setup. MVM.sh will take you there. And on Windows, well, on Windows, do what you do. You can try MVS, but if you've, this one, you can't do that, because you don't have the basic interface in GNNVS. But if you've, or Jen, sorry, if you've, you know, if you're a Windows user, this might work for you, or, you know, do it your own way. So, let's take a moment to go through the setup.

So, using PAIR, sorry, using Node to install PAIR and hit Return, and what that does is it installs a very small CLI that then bootstraps the rest of PAIR from peers. So, when I run this, yeah, right, that's gonna obviously run my normal PAIR. So, I'm just gonna hack it out for a second. Never do what I just did, of course. So, what it should look like for you is this. Maybe a bit slower, because it's gonna be running from peers, and I have peers very close for this, because I'm the one seeding some of it. So, once that's done, you should be able to just run PAIR, and it will output the help. The first runs a little bit slow on macOS, because of the way macOS works with binaries. Run it again, it'd be nice and fast. Also, because it started the cycle, but we'll get into that later. Okay, I'm just gonna see if there's any questions or anything. Can people ask questions? Yeah, Abby asks, what's the longest stream as a version of PAIR? Yeah, we're gonna get into that. But we have two types of versions with PAIR. We have, so if you type PAIR-v, you'll get the version breakdown, where you have key, fork and length. But you can also type PAIR-info, and you'll get the latest changelog, and that is a SEMver version. So, we have a tag for SEMver commit and a PAIR release version also. They're all connected together. Okay, so, anyone struggling to get set up? Has everyone been able to install PAIR? How do I ask this in a way that, if anyone hasn't been able to install PAIR, please speak now in the chat. Yeah, Oleg, we're gonna get into all of that. Not into intense detail, because this is about how to use it, but the same principles that a PAIR is built on and the same building blocks, as in modules and libraries that PAIR is built on, are what we use to build the apps also. So, it's turtles all the way down, you know? Okay, some are still installing. That's fine. It's probably to do with distance from peers, right? But, long and short in terms of BitTorrent, drinking a carbonated drink, in terms of BitTorrent and IoPFS. So, we're gonna use this module called HyperSform in part of building the chat app. And HyperSform is a DHT module. And at the base of that, I think it's at the base of that, maybe other things as well, is Codemlia, which is kind of like a next-gen BitTorrent protocol. But, there's more to it than that. It's in terms of state and different things we have HyperCore. We're gonna be talking about this more as we go. There's a whole section on this in building blocks. But, there's overlaps, of course, because it's peer-to-peer. But it's the way that it's arranged and the way that it's done, the execution of it, that seems to be working very well. Yeah, so at the minute, if you want to know which peers, it's by key. You can know because it's all just open source code. And the keys are held at state that you can look up on the libraries that are doing the bootstrapping. But, if you're thinking in terms of bad actors and so forth, with this technology, that's not possible in terms of encryption-wise. But I don't want to get too deep on those details because we need to get into how to use this thing. Okay, so let's go back to the slide screen. So what is PAIR? PAIR is, we call it PAIR Runtime. But it's a platform. I'm doing a talk on the 13th for JS Nation where I talk a lot about the different things that PAIR is, all at the same time. But it's a development tool, it's a runtime, it's a build tool, all for building peer-to-peer apps. And it's also kind of an ecosystem for building peer-to-peer apps. It's built on something called BEAR, which is a B-A-R-E. I know, PEAR, BEAR. That's a JavaScript runtime that's very, very lightweight. The original goal of Node.js was a very, very small core. And then everything else in the ecosystem. And the way that BEAR starts out is the core is so small that it is just the module loading piece, not process, even. Process is separate. So that module is just a module loader that then loads other modules into functionality like file system, net, whatever. It's got first class support for P2P primitives as well. So we built those at the same time. We were building PAIR while we were building BEAR. So PAIR was originally on Node.js until we were able to meet where BEAR was. So this translates really well to then going further and building PAIR terminal apps. So you can use BEAR modules like BEARfs with a PEAR terminal app. And this gives you a pretty neat opt-in security by design model where if you don't install the native and you don't use it, then you can't use it. It's not there to use. So but the main initial thing that we built PAIR for was desktop apps, and those terminal apps, but desktop apps. We're also going to have at some point a story around mobile apps and how we can integrate that all together. But we have a desktop app called Keete and a mobile app also called Keete, both. It's both Keete. And so we have P2P tech on mobile also. In the near future, PAIR is going to, it's really a case of documenting in some integration code for working along with that as well. It's more besides that. You could say in a way it's a movement, but we'll not get into that. Let's get into the first exercise instead. So PAIR in it. This is the first command. I'll switch my screen again. So if we go into the first exercise, if you're in the read me on in the PAIR workshop repo and you go into exercise zero one, PAIR in it, and we're going to initialize a PAIR desktop app. So I'm going to do make the chat. And then I'm going to do PAIR in it dash why. Why is this saying yes to all of the defaults? And that should output something like this. And it should put into the folder what it says it's created. So we have an app JS, an index.html, a package JSON, and a test folder. So this bootstraps our P2P desktop app. If we just take a quick look at the bootstrap code, very simple. App JS just turns an H1 element into a PAIR, and then some HTML. And that's it. No dependencies apart from a development dependency. We use British for writing tests. It's a tab-like library that we wrote. So okay, now that we've generated that, that's the exercise complete. We're going to run it in the next exercise. Was everyone able to initialize their application? Or was anyone not able to, I should say? Next exercise, we're going to go into, if we go from the README again, pair run. The pair run command, it runs an application from a link. And that link can be either a file link or a pair link. If it's file link or if it's a path, it will be converted to a file link.

Then it runs the application from the directory path. The package.json has a main field in this generated package JSON that we've generated with pair init. And it's set to index.html. Usually if you do npm init-y, you'll create a package.json with index.js. So index.js was chosen because index.html was the default for web servers. So we've gone back to index.html being the default main for desktop applications in pair. So when you do pair dev, sorry, pair run, you can use the dev flag and that will enable dev mode. And I'm going to use the dot, which is a file path, which will get converted to file link absolute path. And that should run a generated app.

So that opens the dev tools immediately. And we've got this Paulie color-schemed chat app. And when I click it, it turns into the pair emoji. And we can see that it's just dev tools. It's Chromium dev tools. So if you're familiar with working with Chrome, you're familiar with working with pair desktop apps sort of. And note that the link, sorry, the address is a local host HTTP. So pair runs something called a sidecar in the background. Whenever you start an application, and then that sidecar talks to the P2P structures, and it talks over the DHT to other peers. But the application itself is just using HTML to local host to retrieve all of the stuff. So in this case, it's only retrieving index.html.app.js. But it can load all the things. So it's a great way to leverage really common skill sets starting out like this. So that's pair run of a file path. We can also do pair links. So a pair link will either be pair key or pair aliases. There are only two aliases at the minute, key and runtime. And pair runtime, you use as a final setup step. So you can do pair run, pair runtime. And if you don't see this screen, or you see something like this, but you see a button that says complete pair setup, after you run this, you can click that, and it will set pair to your system path. So what it's doing, even though it works before that, what it's doing is it's spawning node to spawn pair. Once you do complete pair setup and you set it to your path, when you open a new terminal, it will be running pair directly. And because pair is on bare, the initialization time is much, much faster than node by a factor. So, yeah, do that. But what we can also do is what's in the exercise there is pair run pair colon forward slash forward slash keys. And this runs our flagship P2P app, Keet. So that's all my personal stuff there. So try not to look too closely. If you didn't have Keet installed, it doesn't matter. It will still run Keet, because you have pair platform installed. Pair platform starts, and then it loads Keet from peers over that HTTP to local host bridge I talked about. But I also have Keet installed from the website, and I can just start it like this. And it's the same app. It's the same exact app. So the way that that works is when you install, when you download Keet from Keet.io, you get this tiny distributable. We don't want to make it any smaller, we're concerned, we could make it smaller, but we're concerned people will think it's a virus because it will be too small to make sense conventionally. But I think it's about 50 meg or something now. And so you install that, and then that pulls in the platform. And then platform starts, and it just pulls in Keet in the same way. So when I run the app on my system, all it's really doing is pair run pair Keet and a few other flags. And that's amounting to the same thing. It's just, it's branded with the Keet icon and Keet text in the menu. So that's really cool because it's like, we have these like peer to peer applications, and then we have a way to create very small distributables for, for users, you know, who don't necessarily care about the technology necessarily, or they don't want to get too deep into, into it and don't want to use the command line of course. But it really is just all working the same way. It's just pulling, pulling the, the, the, the applications from, from peers.

What is the UI built using? It's a telebrowser and electron platform. So the, the, the, it's a multi-layer question. If you go, it's all open source. So we have, we have this thing called, we have, so short answer, it's a build of, it's a build of electron. It's a vanilla build. And then we, we basically pull that in from that, that vanilla building from peers, from the same, from the same peer to peer storage. And then start that with the same, a single entry point, the same, the same boot JS files, the CLI and the desktop app. But we, if you look at the code, you'll notice that like the electron, like touch points are very, very light. We're using as little of electrons as possible because our next steps are going to be to move over the desktop side to both bear and chromium. At which point we're, we're pretty much at our target architecture, but in much the same way that we use nodes to prototype and bootstrap into the, you know, the pair runtime being on bare for starting the desktop applications, we're going to do the same thing. And then like it's that thing where code can run anywhere as well without any, any conditionals. So.

So comes asking, can a pair up the package with a large optional data file and still be installed quickly? Yes. Yes, absolutely. Cam we're, so this is later in the workshop, but we don't have pair build quite yet. So pebble will be doing the distributable thing. We're going to go, we'll show you everything else. And by the time you finish your app, you'd probably pay bill to be available because we have like 90% of it. We're literally just it's windows man. Like sometimes you hit a thing on windows and it, and it just, it just eats time. So we're, we've got to fix the thing to make it work on windows to do with it. To do with native build stuff. But once that's, once that's, once that's done, pebble would be out. So we, we should be, we should be able to get our 10% done before you can build like a full on app that you want to send to users.

So Hey, pro calls emphatically not on top of HTTP, not at all on top of HTTP it uses. You think would UTP, which is a U is somewhere that, which is somewhere between UDP and TCP. It's its own protocol, but not on HTTP. Okay. Shall we make the app? So if we go to exercise three, making the app. So the first thing we want to do and chat folder, make sure we're always in the chat folder is we want to install the dependencies we're going to be using. So this is hyper swarm, hyper crawl, crypto and B4A. So hyper-swarm I've talked about. We're going to use that for joining a topic on the distributed hash table. Distribute hash table is the mechanism by which peers can discover each other in a non-centralized way. The only thing that's needed to connect to the DHC DHT is a bootstrap pair. And a bootstrap pair is the same as any other pair that there is nothing special about a bootstrap pair. Any pair can bootstrap, but you need the IP addresses of that initial, of those initial bootstrap pairs. So we have a couple of bootstrap pairs hard coded, and then from there, everything else can work over the, the gossip mechanism academia. At some future point, you'll be able to set your own so for completely private DHT, but this is using the public DHT. The hyper core crypto module is just a module for hyper core related. Basically, hyper core has a, has an API and some of the API is, is cryptographic.

So let's take a look at the index dot HTML. We're going to, we're going to do the recording. We're going to put the recording online. Don't worry about it. Okay. So we're going to take the HTML from exercise three, and we're going to just pop that into index dot HTML. And so you'll notice there's this thing called pair control here. So pair control is an element. There's only one of these. We may add more, but it's a custom element. The pair supplies to the environment, to the, to the desktop application HTML sort of environment. So this is just for setting the, the traffic lights on Mac OS or the, you know, the close minimize maximize buttons on like windows and Linux putting them on the right side and all of that. It's a weird, weirdly hard problem to do to, to deal with. So we've made a little component for that. The rest is just a form and a pair control. Now. So let's take a look at the JavaScript code. We take this and put it in. To ask. So before I go on, let me just say in the chat, doc's doc has on. Go to doc's doc pairs.com. You'll you'll find all of this documented, the stuff about per control. This is the thing we're going to look at here. It's all documented on doc's doc pairs.com. You've got the reference, you got API, you've got guides, you've got how to's you've got, you've got explanation about each building block. There's, there's plenty to go through. So I've JS is what it's doing is we're importing the, I've JS is what it's doing is we're importing hyper swarm. We're importing crypto before a. The pair API, the programmatic API is exposed as a global called pair with a capital P. We're only using pair tear down here, but you can find the full API on doc's doc pairs.com. We can show you that. So application. A minute interface. Here we go. And messages for a message bus, pair media for access control to camera and desktop sharing and stuff. A versions pad, tear down, pat out our original application. Clean up and is to be called when an application begins to unload. So pat down, we'll call the whatever functions are passed to it before unload time. So you can do clean up.

So pat down, we'll call the whatever functions are passed to it before unload time. So you can do clean up. How restart? Updates. We're going to talk about later, but it's, that's a very powerful one. A wake up is for if you've got a, if you've got a link that's clicked in a browser, that link can open your application. We support the clicking of pair links so that they, that they can deep link into a pair application. And you use the use pair wake ups to, to catch those, those link clicks when your application is already running windows and views, you can manipulate windows and views. And yeah. And that's pretty much the whole API. We try to keep the API as tight and small as possible as well. Because the, the idea again is to get as much as much supported in the ecosystem because then, you know, we're reducing our chances of breakage because we don't, we don't want to break, we don't break stuff. So. Any questions so far? Chuck them in if you have them and I'll keep going through this code.

So when the application is about to close, destroy the swarm. We set up a hyper, a hyper swarm here, assign it to swarm. We're listening to. Sorry, got a question. Can you repeat the answer to the question? What is the UI built using? Is it a tailored browser or electron or platform native? It's it's electron, but it won't be soon. And it's very light touch on electron. See the repo, a whole bunch of two, four slash pair on get hub. Okay. So swarm. Every time you have a connection come in, it means that a pair is connecting to to you. We look at the remote public key of the pair. And then we listen for data on up here, and we've converted that remote public key into a name. I call this function on message added. So from is just used to like identify the pair. We're using the remote public key. And then the message is just added to the content of this development. And that's appended to the messages element in index to HTML, which is it. So inside this messages field will be appending messages from peers. This is also called when you send a message. So we've got a send message function. That is the listener for the submit event on the message form in index HTML. And when we, when the current pair sends a message. It's added to the content, you know, just as as you and then we loop through the connections and write the message to each connection. So the pair, the pair objects that are that are that are returned or that are sorry that are held in swarm connections and the pair objects that are passed through the connection listener are streams. So duplex streams. So you can just write to the stream and you can just listen for data. It's a simple well known API swarm on an update. So hyper swarming emits an update event when there's a new new connections. And so we can use that to determine the amount of peers that are connected. Got a question from Cam is peer remote public key and peer info. Public Key the same as is the best way to identify a device. Don't know the answer to that off the top of my head. But the best way to identify a device is by its discovery key, which is what we do in practice. So hyper core has. I had actually hyper core crypto has a method called discovery key and you can pass a hyper core crypto key. Hyper core ID. Sorry. Encoding. Sorry. Key into that to get it sticky. I think because the discovery key and keeping the discovery key and the key separate then means that you keep some privacy around the original key. I don't fully understand that side of things quite so much, but take a look into that sort of area. No worries. You need to you uniquely. OK, well, we'll talk about identity later. I think it's quite a big topic. It's on the card, so it's at the end of the outline. If you look at the outline, we talk about identity. OK. So. Join chat room. Basically, cause join swarm with a topic buffer, create chat room, create a topic buffer and cause join swarm with that topic buffer. So. What the app does is it you can either use it to join or create. If you use it to create it, just create a topic buffer string and automatically joins the DHC under that topic and then someone else or you or whatever, another pair. Then joins that same topic string. And now you're both connected. Well, connected is a loose phrase because it's more that you're both subscribed to the same topic. In join swarm, we're simply calling join with a topic buffer and setting it to both client and server so it can act as a full pair. This is something I don't. I just know that you have to do this the way you have to wait until it's flushed before you do other stuff. Otherwise, there's a race condition, like a syncing problem. Don't actually know the reason why. Because it was actually quite a long time I worked on hyper-swarming. I can't remember. Topic, topic, topic. Yes. So then it's just setting that topic. Let's take a look. Oh, shoot. I need to push something. Hold on. Sorry. I forgot to push that bit. If you refresh making the app, there's a final piece. Checking the app. So we know how to run the app.

We do pair run. And if we want dev mode, we do dev. And we say the directory, which is dot in this case. The current directory. That opens in dev mode and here we can see, we can drag the application. We've got the traffic lights over here on windows and Linux users probably have them over there. And we've got create and join. Before we do anything there, I want to open another terminal. So this is another terminal and I'm going to run the same app again, this time not in dev mode. Here we go. So now I've got two instances of the same app. The first one has got dev tools available to it. The second one doesn't currently. If you want to turn dev mode on, you just go up to pair run time. Dev mode and then you'll have this dev menu up here. And then you can select your thing. Open it. No, no, many topics per swarm count. One swarm, really, one mega swarm. So now what we can do is we can check that this all works just on a local machine. So in one window, I'm going to do create. And here we are, and I've got the topic. I'm going to copy this. And then in another window, I'm going to do join. And then the peers should be able to talk to each other, each application instance. And we see that just identified by the remote key in this case. That's the first slice.

OK, anyone not been able to replicate this? No, no, no, no, no. Wait a minute, Jordan, get ahead of yourself. Also, before we paste keys, before we get to anything like that, just a disclaimer. Only run code that you trust. This is the same stuff. It's peer to peer. But like only even more so in a way, you know, only run code that you trust. So think about the incentives and so forth. I'm going to paste the key at some point so that you can run my my, my code. Don't don't run anyone else's. In my case, it makes sense. You're seeing me do it. Why would I why would I do a workshop just to like, you know. So. Right. Thanks, John. I can't copy and Windows I. Don't I. Sorry, man. Like Windows, you're just going to you probably got some something in store or something to stop you copying. Well, I'll get someone to look into it on Windows to see if that's a thing. But it might be it might be a Windows specific thing for you, man. You should figure out a way to copy it. If not, you know, it is small enough to type. That's the great thing about these topics and the pair links as well. Like sometimes I'm in a situation where I'm like, I can't get it. I can't get across. So I'll just because it's like a like a like a weird device or something. So I would just sit there and type the whole key out. And like, it's not that hard. It's not crazy. Because it's not it's easier than typing out a long link. OK, well, I know. So if you get a syntax error, it might be that when you copied and pasted your app, JS code or something, you're. You had to you had a you have a problem in it, so just make make sure it's good. Re copy and paste it if you have to. We have an application. That that can do peer to peer things. So. Sure, but the fact that the pair can run from a pair link which can run from a key. Means we can take this to the next stage and make the application itself. A thing that that's also in its own peer to peer structure, that's also seated on its own topic. Let's do that. Oh, but before we do, sorry, there's one other thing, the building blocks. So Dr. Pettit com. If you look over at the building block section, you've got hyper core, hyper be. Drive. Auto base. I put the HD and the IPs one nano. I'm going to tell you how to watch changes in a bit. With it, it's cool. You'll see. So. These building blocks are the foundation, foundation libraries of the pair way of building peer to peer applications. Hyper core has been over 10 years in the making and comes from even before that, the community and the project. So it's it's a very, very mature. P2P core library. Literally, it is core in many different ways apart from the centralization way. So. On top of hyper core, you can have hyper be hyper drive and auto base. These are all for persistence. You can persist with hyper core and you can replicate with hyper swarm. Hyper DHT is a. It's not really something you need to use that much, to be honest. It's like the guts of hyper swarm. If you if you want to just do direct connections, you can use hyper DHT. But I just want to do the topic stuff. Hyper be is a B3 based key value store, a database. On top of hyper core. So hyper be plus hyper swarm that gives you a peer to peer database. Hyper drive is a file system. On top of hyper core. So hyper drive plus hyper swarm gives you a peer to peer file system. We actually don't know if we've released this yet, but a dev and hole punch Rafa built something called Drive Explorer. And, you know, you would pay to pay to pay technology just for your own devices. Even you can send terabytes of information. If you're like big into like, you know, high quality videos or music or whatever it is, a lot of cloud services will charge, charge you a lot to to transfer that kind of data. But even with key, you can you're unlimited, you can transfer as many terabytes of data as you want because it's just between your devices. Auto base is the mold is that is the multi writer library. So this is what gives us the the chat capabilities and the full chat capabilities with. Persistence and conflict resolution of. All that kind of stuff. Also, identity, I think, is an idea in order to base it again. Talk about that later. So these building blocks go from a simple primitives up to quite chunky primitives, but still nevertheless can be used as their own little block to build with, which is why we're building blocks. We've also got these helpers. The helpers are sort of adjacent. So CoreStore is a big one, and that allows you to use multiple hyper cores. And we use that in platform because all of our impair platform, because of all of our application storage.

And when you're installing an application like it, it's all state saved as individual hyper cores inside of a core store. Local drive is hyper drive, but for the file system. So that plus mirror drive means it's very easy to mirror between a hyper drive and local drive is is really great for syncing state. Secret stream is what it sounds like. The rest are a bit more deep. So, or a bit away from p2p, but just helpful. So those building blocks we've used hyper swarm to create this chat up. That's a femoral. You close the chat, all of your state's gone. If you want to get to replication systems, we're not going to we're not going to get too deep into that in this workshop, because this is, I would say, introductory, but in the how to's here on dotstoppairs.com, you can go to the replicate and persist how-to. And it goes into the details of and breaks down how to how to create a writer app and a reader app. Also, the stuff that I mentioned CoreStore. This is the multiple hyper core stuff. Here's how to create the append only. Sorry, everything's append only because hyper core is append only. But the key value store with HyperB. And here's how to create a p2p file system with HyperDrive.

Okay, that's a good lot of information about what you can do in terms of building apps. Now, what I'm going to do is we're going to stage the application into its own pit structure. So if we go back to the workshop and we go to exercise for a stage. I also need to give you. Is this going to work? No, I could send the PDFs to everyone. We'll figure out a way to send the PDFs later. So, if you're going into exercise four, and you're just using the chat folder, and for you're going to want to run MPM install, because it's just it's just set up in the in the state that it needs to be for you to be able to run pair stage. So if for any reason you weren't able to get your previous exercises working, just run MPM install in that chapter. If you're still working on the same chat folder, you don't need to run MPM install. So what pair stage does, is it mirrors? I told I just went through those building blocks and I mentioned local drive and hyper drive and mirror drive. So, really, what stage is doing is it's doing a mirror from your local drive file system, the directory that you're in, or specified. And it's and it's just mirroring that directly into a hyper drive, which, remember, is just a peer to peer file system on top of hyper core. So when we stage an application, I'm going to do pair help stage. So when we stage an application. We can specify the channel or key when you create a new application. You don't have a key for the app. So you want to specify a channel and you use that channel every time after that. The channel and the package name or the application name are what form the basis of the generated key or they form part of the basis of the generated key. So so I'm going to do a stage and I'm just going to use the channel my app because we just you know this is demonstration purposes. Right. You're going to do it. Yeah. OK, so what happened there. So we run pair stage. And then it. That's our application key. And it said the current version is two with release set to zero will learn more about that in a second. But then it outputs the def of the file disks. So sorry, I was fired if so any files that have changed between the disk and the hyper drive. Because this is a fresh stage is all just pluses but plus minus and then the squiggle tilda to say there's been a change in the file. So we can see the node modules that are being added some stuff. We don't really want to add. They care about support that poor and you can add an ignore field to the pair field of package Jason the pair field of package Jason is the the config object. And you can set that to ignore stuff that you don't want to put in some some reason. Dev dependency in there. We didn't do any is fully dependencies as weird but this is the great thing about going through the death of what you stage. What I should have done also is dry run it first. So. I'm just going to do this and I should have put on the exercise to. I'm going to do my up to because I will do my app with the dry run and you'll see it does nothing because we've already staged everything. And and there's no there's no death but it still runs as a driver on it won't it won't commit the changes. That's what a dry run is. If I do that with a new channel name we can see that it's now it's now made that that you know I've done that death. If I make a change to index to HTML. And then. Her stage with the same channel. We can see that this time I've got to try run again never forget to do the dry run. When it comes to doing the pair releases. This all works the same way so I have to almost remember to the dry run. But yeah, that's a cool side point actually what I'm showing you with how we mirror the content of the application into the. The structure is exactly the same with we stage pair. Using itself to stage pair from myself into itself to release itself. It's kind of cool when what you also might have noticed is you've got this warming up thing. So for desktop apps it runs the application. It just opens it and closes it waits for it to load and closes again and then we record what the critical path is like everything that needs to be looked at to get that in it. So say you've got like like a four gigabyte video or something right. You can have that with a play button. It's not going to play automatically. You use a clicks to press play so that won't be part of the warm up but like you index to HTML you critical CSS. Anything that's not lazy loaded will be part of the warm up and then we store that in a special field on a beaky. Remember Hyper B we stole that on a beehy and then when you when we load the app we prioritize that stuff first. So because Hyper core is and hyper swarm work on sparse replication. So you don't you don't need it. If you don't need it. You don't download it. So what the purpose of the warm up step is to say this is the stuff we definitely need. And then we like if we download that while the apps like immediately. And so the app starting and initializing we've already started downloading your critical stuff. That's what the warm up steps for. So now. Now that we stage the app we've got this key. So what we're going to do is see that. Let's go to the next exercise.

So, when we seed, we can see it by channel or key. If I'm in the chat app, I can do Percy's. You have to reference the chat app. That's why you have data because it can still be relative. But if you seed by key, you don't have to reference a directory at all. So, when I do Percy my app because I'm in the chat app, it knows that this channel and this key are all the same thing. Now I'm seeding it and I can do pair run with that key. If someone connects and runs the app successfully, we'll be connected in a chat. Copy and paste that command pair run per key. You can't copy from the Zoom chat? We'll figure out a way for you to get it. If I paste the key and then you can put that with the paddling, that's the key for the paddling. We're going to have to figure out a way to send you the PDFs. Just run that command. Here's the link on its own. But you need to run that link with pair run. Once you're up, if you put that topic into join room, you should be able to join me in this chat room. The principles are the same all the way through. If you couple that with the replication stuff with hyper core, it would work with your own chat version. We can definitely do a broadcast room to the entire planet. The largest group room we have at the minute is the Bitcoin room. Let me create a QEET chat so I can send you the PDFs.

The command I've just put in the chat there we go. We've got someone in so copy and paste that command pair run per key. That's the key AVI. So I've got one person run in it. Does anyone else know. No I'm not pasting the key. I'm not pasting the key. Yeah I'm pasting the link with the pair on command. Yeah. You just run that command.

Here's the link on its own. But you need to run that link with pair run. Bruno. There's the link but run it with pair on only one person only one person has run it so far. Why would you have to type all of that. Copy paste it. You can't copy from the Zoom chat. That's great. You can copy from Zoom chat right. What. The Zoom's blocking it. Huh. OK. Well we're going to have to figure out a way for you to get it. OK. So we'll go backwards then. Yeah if I paste the key and then you can put that with the paddling that's the key for the paddling. Absolutely. That's what this is all about. Well I was gonna I need to send the PDA so we can move to keep me to send you the PDA. Oh sorry Jordan. Wait hold on sorry I might have been in the wrong fucking. I got the end and it just put me in that DM forever. How's that. Did that work.

It's all right. You just did it again though. I'm coming out. Here we go. Here we go. We got peers joining. Yeah we go. All right. Now once you're up I opened. Don't do this from the dev one. You can do it from the dev from the directory one if you want but it's more fun to just load it from the from me. If you put that topic then into join room you should be able to join me in this chat room. First we got a first. Got four pairs. Any more for any more. Nice. I'm going to leave you. I'm going to do I'm going to save my voice for a second I'm going to leave this on for a minute. No no no video yet dude. Like if you want to turn on video we'll go into the key. This is just like a femoral text chat between two pairs. That's that's that's what this is. But the principles are the same all the way through. If you if you couple that with the replication stuff with hyper core I was talking about. Yes it would work with your own chat version because it's just it's just about the topic. In fact I didn't get this far but like what I could have done is I could have converted this so that it actually generates a topic the same kind of topics that key to generates because a key link when you when you create a key to invite like for a meeting. Once you start bringing state into it it's obviously a bit more complicated in QEET we we've solved the planet scale. We can we could do definitely do a broadcast room to the entire planet group rooms that the largest group room we have at the minute is the Bitcoin room and that is how many people are in there now.

Correct. But the last time I checked it was there was over a thousand people in the Bitcoin room. I think a lot more now. I was going to count them. No. Anyway let me let me create a QEET chat so I can send you the PDFs. And you can see as another. So what I'm going to do is I'm going to go. You see in QEET we've got create or join room. You see this is the same kind of the same kind of situation. Right. So I'm going to do create room. We can do a group chat. And I'm the room admin. Yeah we also in QEET you can do moderation. You can do kick in and stuff like that. Again all with this persistence layer. I want to do. Workshop is. So that's the room. And then I'm going to take. We'll put it we'll have a two hour invite length. So get it while it's hot and I'm putting it in only in the peer to peer chat. So. What you can do. I think this works. You just try it should work.

Of course this works. What you can then do is you can do pair run. Keat and then the. The topic is at the end of that link. That's the invite code. Now I'll get you into the room. So you can go pair run. Pack heat. I'll put the Bitcoin room into the into the P2P chat you got to join me on the P2P chat together stuff. We have people we got. We've got seven pairs. Is anyone else joining? How many people are in the call. We got we're trying to get a few more than that. Oh, we got some people join in the key room. Dope. Everyone has got one white T-shirt on.

Yeah. Yeah. How's that. This is going to be a great pinball game. 573 members. You cross posted it. Can't control for the pairs. I love a bit of chaos. Storyteller gets a pair. But the. I'll put the. So. Been asked what is the best way to save messages hyper core append. That's a complicated question man. Because like. Hold on let me just put the Bitcoin room in there. So. What's the best way to save messages hyper core append. That all depends on what you're trying to do. That's why we have drive. That's why we have. Hyper B. That's why we have auto base. Like. Also base. You could say is the best way to. To deal with any state. Because it has all the multi rights of capabilities auto base plus core store. And that is what Keith is built on. So. I would say that's the best way. But in terms of like getting started and stuff and you want to look at the nuts and bolts then. I've got a pen. So it's. It's really like. What your goal is. And where you sit. But like you're gonna you're gonna you know you want to want to experiment you know. If you'd like. I can start.

Well we don't have enough. Where are we at where's the. No, because we're recording on zoom so. That would be silly to move to keep now. Something that Keith needs is a record button and you know it's in the works. Yeah we do have three we have three chats now. Yeah. And while this one is being shared on zoom. We're actually we're actually doing a live stream. And so when we're doing a live stream, we're actually using a technology that's called hole punch. And that's a technology that's been shared on zoom. Like this is the two of them are private. Two of them are completely private because we're using secret stream. We're using that kind of stuff is direct peer to peer connections. The company is called hole punch. And what that does is it statistically guarantees that it can punch through. The security. That just blocks out all different types of connections. And so because we can do that. We can. We can always make sure peers can have access to this. So because we can do that, we can we can always make sure peers connect for like 99 percent of situations. And that's why we're called hole punch, because that's our that's our secret sauce. That's our magic. And it's why we say that pair apps are unstoppable because it's statistically guaranteed. You you come you can't beat it. Aviates keep users WebRTC in Chromium, but it's as a as a as a sort of platform platforming drop jump off point where it goes into. I don't I didn't build this part. Our CTO, Andrew Walsh did. But it goes into. Our stack at some point between WebRTC and our video, our video stuff. I'm sorry, I can't I can't be more specific. I didn't build that bit. I've been building the actual platform piece where which is all of this stuff with like staging and seeding and all that stuff.

The CLI and the desktop integration, that's that's the stuff I've been working on. So we got. OK, well, where are we at now? So we got 21 people on the call. We've got 13 people on the ZIP code. So it's one people on the ZIP code. That's right, it's juries. You get it. You got it. So we got 13 in this one. We've got eight in this one. We've got 21 on the call. That's not bad. That's not bad. OK, so. That was connecting peers. We've done that one. That's exercise six done. Paralyze. So help release.

I did help release to just show that the help out. You specify a channel or a key. Sorry, let me just say one thing about proceed. I forgot to say. If you specify a channel, I'm going to give you a key. I'm going to give you a key. If you specify a key for proceed or a pair link in future, very near future. It recedes it. So if you want to recede another project, you just the key that you run it by, you can recede it by and you just pass out to proceed. I'm sorry. So, OK, so help release. So what this does is it marks a release point. Remember that question about the pair version. Well, we can also look up that same stuff. For the application key, which is, there we go. We don't have learned to that yet. It's not out yet. Oh, you can in a very soon to be released version, you can do pair info with this and you'll be able to see the length of the key. We can get the length from somewhere else. If I run the app. I already have it running, sorry. So if I go into Dev mode in the app like this, and then I open the console, I've got the pair global, right? So I can use the pair API. So I'll do pair versions. This. Now I've got the platform and the application version. And so we can see that the app has a length of 1278. Fork zero. Fork is if you truncate. So you can, you can, it's an append only log, but you can append a truncate message to the log, which creates a fork, right? And so that would plus one to the fork figure. So we've got. So if you've got pair, if I run pair stage my app again, I'll do it with dry run because you should always do it with dry run first, which I didn't didn't do before. This is 1278. And we say, OK, well, I like I like 1278. I think that's ready to go into production. So once the first time you run pair release, like you like like that marks it forever. You can't on release after you've released. So if I make it a change to the application. I can restage that change and you can restart the app and then that change will have happened. In fact, let's just do that really quick. So I'll change the background color. Right. And anyone who's running the app can restart and restart the app. I'll just let you know to restart it in a second. So here's the background color. I'll just change that to like this color. Right. Take a quick look. Oh, OK. Just changes the title bar like that. OK, that's dope. So I'll do a pair stage my app. And if I'm seeding it, pass seed my app, make sure I'm seeding. One other thing, actually, just to answer the question about or to just introduce what I'm going to talk about in a minute, which is the pair updates API. So.

Because I have access to the pair API, I can just use dev tools right now in the app that we're running, as I already did to do versions, but I'm going to use it to watch updates that come in. So I'm doing pair updates and then I'm passing console log to the app. And that gives me a subscriber, which is a stream. So. So now if I stage, we should see an update come in, be logged out on the console here. So I'm going to, because I'm seeding. So do a pair stage my app. Doing the warm up. And then I'm going to do a console log. Yeah, so we saw this update come out, right? We got two, but it's a stage thing. Don't worry about it. When you do release it locks. It doesn't do this. So we see that the latest version is 1 2 8 0. We went from 1 2 7 8 to 1 2 8 0 based on my background change. Now, I can say, OK, you know, I'm not going to do anything. I'm not going to do anything.

So I'm going to do a background change. Now I can say, OK, oh, wait, before I do that. So now I can say, right, I need to I want to restart my app. I'll just use the API again so I can say pair restart. And now we've restarted and we've got we've got that updated color. So anyone else is running the app, if you want to open DevTools, you get a dev mode. You can do it like this and then go to the window, developer tools, open the DevTools, and then you can do pair restart and it will restart with the update. That's not release. So let's say I want to lock that in at that version. So the version is pair stage dryer on my app. So the version is one to eight. So I'm going to say pair release my app. And I'm going to say the release. So the length went from one to wait two to one to eight one because writing the release marker into the append only log. And now when we. Now, if I make a change and I try to stage that. I'll remove this new stuff thing here, it's an older change. And let's let's change the color against something else like this purple. Now, I'm going to try and stage that again. To try first. OK, and this is why I changed good and a stage that. I forgot to do the update thing, but I wouldn't have got an update for that. And when I restart, we'll find that it's still the same color. And that's because I released the release marker is pointing to one to eight one now. So I now have to update the release marker if I want to see. If I want to release the latest state. But you can preview the right latest state with pair run checkout. So I can say checkout staged. And. That's the same key. And now I have the purple title bar. So when I run it, when I run it with checkout stage, it's running from the latest, which is one to eight three. But generally, you're going to have your users wanting to run from checkout released. So if you're developing completely open source, this is great, because it gives you because it's super easy to use. You can use one key for everything. If you if you have like an internal and external situation, then you just use a different key for your internal and a different key for your external. It's just options, you know, I like using an internal key that I never release because every state is always the latest. And everyone who runs it doesn't need to run it with a checkout flag, but this is great if you're just like using one key. It's kind of there's benefits to both, you know. So I can go, OK, well, actually, I like the purple, so I'm going to release again. And now when I run it, it's purple. Makes sense. Rune has got a question about the release. Rune has got a question about aliases. So what we have at the minute, we got pair run and this key thing, then we've got pair run pair keep, which is using an alias instead of a key. So pair run, pair keep just is at the minute is hard coded into the platform code, where it sees key to just converts it to keeps production key. And the same for runtime, and those are the only two supported aliases. But what we're going to do is we're going to have an index. We actually have work ongoing at the minute on an internal username service. And once that's done, we'll probably flip that into an alias service. The pair runtime app itself will... Don't quote me on this, because you know how you have plans and then things go the way that they go. It's an organic process. But pair runtime itself, the actual desktop app, is probably a good place to have the mechanism for requesting aliases to keys on the index. Yeah, so let me talk about that, Nanna, about watching. I think that's up next any way. Yes. So we have this API called pair updates. And we have this concept of a hyperdrive. And because we have hyperdrive, we also have local drive, which is the same API over the top of a disk. So the way that we've done watch, the file system watch, and the way that we respond to changes in the P2P structures, as in the hypercore, is exactly the same. The pair updates API is just called. So if I go, for a second, I'm going to go to the actual pair repo. This is fine. In the pair repo, we've got a couple of examples. We've got a desktop example. We've got a terminal example. And desktop example is just a basic example. But what I'm going to do is, yes, we've got this. In app.js, we've got a few uses. In app.js, we've got a few uses of the API here, right? And we can see that we've got pair updates being used to listen to updates. So if I run this, I'm going to put dev mode on. What's this? Oh, sorry. And now, because our code is already listening for updates, if I change a file, we see it says update available. And we have a diff of that file. So we can use this to do watch reload. And we can also use it when we stage an app. Or when an app is released, depending. So when there's an update that's seeded out, it's the same exact API, it's the same exact objects you're getting back. So you can do more interesting things with that. I'm not saying you should do this, but it does open the door to very trivially doing live reload of assets on production apps. So that instead of an update button saying, oh, the app's updated, you've got to restart, which is what we're currently doing in Key. At some point in the future, we should be able to do certain types of updates that just say, ah, you don't need to restart for this. Just replace these images inside the app. So there's this module. And what we can do, I can do this with you, Nana, right now, and anyone else who wants to follow along. Is in the chat, I'm going to install something called... I think you should probably dev install this. But I'm just going to install it. Pair-hotmods.

So pair-hotmods works with the pair updates core API. And then gives you hot reloading. Although it's more for... So this is something, let me take you, actually, rather than doing that, sorry, let me reverse out. I can't show you that, because that's proprietary. Shoot. Okay, let me talk through this pair-hotmods code then. So you can see that it's just doing, it's listening to pair updates here from global pair. It looks at the diff. And then it re-imports when it needs to, based on what it's watching. And then it tells you what you need to reload and so on and so forth. So, in key, we combine pair-hotmods, and we check pair-config.key doesn't equal null. And if pair-config.key is null, then you're, you don't have a key, you're loading from disk. So if it's not null, then you load pair-hotmods, and tie that into... We use Preact, so we've got this thing called Prefresh with Preact, that does the hot module loading piece. So what pair-hotmods does is it allows you to tie this in with any other reloading-like library. So you just call hotmeep, here it is, pair-config.dev, but I would say pair-config.key was null these days. It needs to change that. On this one, it's the Prefresh example, so you're waiting Prefresh core. You specify the components you want to watch, and then you just have this reload things happening here. And then you call Prefresh-replace-component for those things. So it's, there's probably more to do to simplify this further, but also the main primary goal of all of this sort of pair development stuff and pair ecosystem is to provide primitives that make it easy for... that just get out of the way and that make it easy to integrate. So to be too opinionated on that is to then sort of violate that principle. So we can be more opinionated, but we need the primitives first, and then we need to add these other things on top of the primitives. But what I'd like to see is the ecosystem growing from people using it and building their own things against these primitives.

Can I talk to an external site from pair app like a fetch and a call pair up like a remote service on the web? You, you can at the moment but I don't, I think it violates a security principle. And so we had a module recently in Keat that, oh, by the way, don't forget there's the mobile Keat app as well. Like if you go on the mobile app store on iPhone or on the Play store on an Android, you can go and find the Keat mobile app and you scroll down and it says, this app is collecting no data. So it's been verified by Google, it's been verified by Apple that the app collects no data. That's that's one of the killer features, of course. So you can get the mobile app. And, and you can, well in a second, I'll talk about identity, but you can use that to connect up a simple of your devices. So let me just get this question there. Yeah, so I'll sorry. So like calling out to HTTP stuff. We had a weather dependency that that was was doing a call out to HTTP thing. We had to remember what we did, but we had to do something to block that because you know that's a security breach. Like you know you're running your own code on using machines. So when it comes to peer to peer stuff right. It's all about trust. It's all about trust. So you don't want to do something that violates users trust and I think it is a violation of users trust to call out to the clear web in a peer to peer situation without explicitly saying that that's what you're doing. If you're saying that's what you're doing. That's okay. But I can't guarantee that you'll have full support that moving forward because of the other security side of the story implications. Rooney says, can you build any existing centralized app into a pair of all. Yes. So really like absolutely. Anything that you can think of there is a peer to peer way of doing that. But it's you. Monetization of such things you have to think about it differently because in the centralized context. You know, you fish swimming in water. We all are. And so the assumptions are baked in on how you monetize these things these days. And unfortunately, I don't want to get into it but it's a very dark way of living. But with a peer to peer alternative. I think the monetization strategy these days is you can disrupt one of them is anyway you can disrupt existing apps by out competing them on features and value. Because for two reasons. One, there's no infrastructure cost. There's no time spent on infrastructure. If you think about the fact that say Telegram, I don't know exactly what the numbers are. But it's something stupid like 650 million a year to run. Right? It's a cost per user metric. So the more users they get the more it costs them the more infrastructure they need the more people they need the more organizational complexity that grows. If you don't need any of that. You can move a lot faster. The second reason is, we're at a point of saturation with the traditional tech industry, where the system has begun in, like increasingly is encroaching upon the user. And and initial initial phases of these industries, to get people to use apps and stuff was all about user values. It was the it was the time of UX design, like, what's the what's the nicest way for this to feel for a user because it's all about getting them to use the tech. Once you have them all on the tech. Now, this encroaching on the user like what extra things can we put in their way that make us more money. So I think a p2p solution can easily outcompete existing solutions. But you won't, you will take market share.

Because for two reasons. One, there's no infrastructure cost. There's no time spent on infrastructure. If you think about the fact that say Telegram, I don't know exactly what the numbers are. But it's something stupid like 650 million a year to run. Right? It's a cost per user metric. So the more users they get the more it costs them the more infrastructure they need the more people they need the more organizational complexity that grows. If you don't need any of that. You can move a lot faster. The second reason is, we're at a point of saturation with the traditional tech industry, where the system has begun in, like increasingly is encroaching upon the user. And and initial initial phases of these industries, to get people to use apps and stuff was all about user values. It was the it was the time of UX design, like, what's the what's the nicest way for this to feel for a user because it's all about getting them to use the tech. Once you have them all on the tech. Now, this encroaching on the user like what extra things can we put in their way that make us more money. So I think a p2p solution can easily outcompete existing solutions. But you won't, you will take market share. But the, the, the potential for profit and the potential for, for any anything else is, it works differently because you're not in the middle, you can't middleman this. So you have to, I think the approach, and it's the approach that the whole punch is taking is to create ecosystems, and then participate in those ecosystems. And I think that you can do something as a lifestyle business.

Yeah, two separate paths can talk to each other, of course, I'd be like it's just p2p like as long as they're using the same protocols, of course, they can and if they're using the same building blocks, then they absolutely can. So we're very interested in though is is is going more nested and saying like, Why can't we run. So we've got this new API company called pair worker, and that runs a pet terminal app inside a worker process, and you can call that programmatically from a desktop app. So that means that you can run a bot, essentially, that can then log into the chat. Beyond that, like, I think it'd be cool to have visual extensions and different things like that. So that rooms like keep rooms can become other things like what happens when people build a website like an e commerce website or something they put in, they put in a live chat feature don't they, like I think you just put it the other way around. everything starts with connection, everything starts with chat. And then you can build structure and visuals on top of that. And I think with with key, that's, there's an interesting way forward on that. And again, like the possibilities are really, really flexible, because you don't have this infrastructure across you don't have this big lump of of of complexity that you have to keep on like moving around with your with your front end solution.

Is there anything missing from pair to build a blockchain so cam. There is a big difference between what pair does and what Bitcoin does. Bitcoin as you know, you mentioned blockchain. So Bitcoin is about a consensus mechanism for establishing global state global truth. Pair is essentially the opposite. It's about local connection, local state. The combination of both together, by the way, is going to be incredible. But you need both actually to have a system that gives you everything. synchronizing global state is expensive. Bitcoin by design is expensive because of for validation purposes. So, but local state very cheap. This also plays massively into Conway's Law and stuff like that, but another rabbit hole.

So if you look at pair help in it. We've got this W flag. And so you can do pair, I'm not going to run it but you can do pair hell. Sorry parent in it with node and then why. And that will you know I'll do it let me create a new folder. And it w node dash y. And what the transfer. Oh yeah, should have the, I guess that's okay, that's the fix. We've got it might be fixed in the new and the latest any internal one. We've got it coming but basically it does what you said it doesn't know path stuff with bear path so you can very very shortly you'll be able to initialize a terminal app, with all of the bear modules to mimic a node app. Does power building blocks for offline first apps and sync with something like CRD t. I'm Bruno. Peer to peer is offline first. Yeah. I'm not sure what CRD t is. Oh there there are possible appear to career approaches ruining for sure. I mean, we're engaging in them but it just gets a bit esoteric and long winded to talk through and also proprietary in certain cases and I don't want to say things I shouldn't perhaps and talk to each other, that's by design.

Is there anything missing from pair to build a blockchain so cam. There is a big difference between what pair does and what Bitcoin does. Bitcoin as you know, you mentioned blockchain. So Bitcoin is about a consensus mechanism for establishing global state global truth. Pair is essentially the opposite. It's about local connection, local state. The combination of both together, by the way, is going to be incredible. But you need both actually to have a system that gives you everything. synchronizing global state is expensive. Bitcoin by design is expensive because of for validation purposes. So, but local state very cheap. This also plays massively into Conway's Law and stuff like that, but another rabbit hole. Rooney, how do you model things like customers and orders in traditional apps and Hyper-Quality Framework? Exactly the same way pretty much. Let me talk about identity in a second. Let me talk about that in a second Rooney. It's not exactly the same way. But let me talk about a second. Can two peers talk connected in LAN or even Bluetooth? Through LAN? Absolutely. Alberto. Theoretically over Bluetooth, but also through Hyper-Quality Framework and also through, through the system itself. I haven't, Avi, I haven't looked at, I purposely haven't looked at any other projects because I don't want to subconsciously borrow from them in any way. Because we've had a very strong vision about how we're doing this and any overlap needs to be due to parallel thinking, not due to copy pasting or not copy paste. But you understand, like, I don't I don't want to subconsciously digest those. I'd say this is different in that I don't think any I don't think, show me Keat on those, because that's like the sort of functionality we can get on Keat is exceptional, in my opinion. Let's see. Yes, we're going to talk about identity right now, I think. Yeah, well, I've pretty much covered that just before I talk about identity, though. We're, we're about to release Pair Build. And Pair Build will be able to create those, the, like the wrapper that we have for Keat. So you can provide your own iPhone and your own P info sort of stuff. And then you can sign your own application, say on Mac or whatever. And then you can basically just create pair apps that can be distributed on the App Store, the Mac App Store or websites or whatever you want.

Okay, so this is crazy, the identity thing. If you install Keat on your mobile phone, the first thing it will ask you is to set up your identity. You can skip that and you can just use it as a device, right? But once you set up your identity, you get your seed phrase, same as a Bitcoin wallet address kind of seed phrase situation. We do it as 24 words. You store those 24 words. Once you've done that, you set up your identity, which is just a key, your key, your identity is just a key, the same way that a room is just a key. That key is, you can then use that, you can generate a QR code between your desktop app and your mobile app. And then you can scan that and they'll both sync up with your same identity. You can get all of your devices on your same identity, your messages, your rooms, everything will sync. So we have identity. We have this cryptographic, completely peer to peer identity on top of Keat. We can cryptographically prove that someone from a certain room has taken a certain action. Right. So, authoring. Sorry, any questions about Keat identity first? Rooney, Keat already supports Lightning payments. Jordan. Maybe. Are we blockchain issues, etc, etc, etc. But these are long, long since debated things. What I'm saying is that pair can work with local state can work with global state in ways, in fully comprehensive ways. So you can amortize the cost of a bitcoin transaction by putting lots of transactions into one transaction. And you can do that by storing a reference in the global state that is related to references in local state. Yes, we will be releasing live before identity. I believe it's auto based, but I need to catch up with Andrew on that. But yeah, just look on docs.pair.com or in the pair on time up and click documentation. You should find everything that identity is coming, though, in terms of documentation. Okay, so let me talk about authoring then and this is a new feature that we're going to I'm working on this feature this week. As one of the things. So what we're going to do is we're going to have a button in Keat and that Keat button says become an author. And it takes and you have to have an identity to do this. So you have to create your identity first. And then what it does is it it shares a sub identity from your root identity. Every device that let me start again every device that you have that you've synced with your identity is a sub identity from your root identity and your root identity is that seed phrase, which you keep safe. Just that you have to self custody in exactly the same way you would self custody a Bitcoin wallet. So we introduce a button into Keat. This is coming. And you click that button. And it shares your sub identity with Pair. And then when you stage and seed an app. It's signed by your sub identity. So when someone runs an app, they can say a dialogue is going to pop up and it's going to say you've not run this app before.

Do you trust this? And then you'll have we already have it internally, where it asks you if you want to trust the app just the key itself. So you can trust on a key by key basis. But you'll also be able to trust the author. And if you trust the author, then any key that that author gives you, you'll run. And so this gives us the the web of trust. This is the web of trust. And we can use this for creating pair applications, but as we go down the line, we'll be able to use it for modules. So we can have a P2P registry. The same thing with all of the aliases. So you've got the username aliases, you've got the the pair link aliases. And then you've got the like author aliases, I guess.

Anyway, got some questions. Yes, if someone becomes untrustworthy, you can't revoke. I mean, we can we can we can say, okay, stop trusting this author, right? So you won't trust any more keys, we can, we can remove that. But anything you've already installed will be installed. And yeah, we can put some extra stuff in there for like removing a no longer trusted author. It's a good point. We'll do that.

Yeah, absolutely. We don't want more shit coins in the world. Like, if we wanted to do a shit coin, I wouldn't even be talking to you, right? Because I wouldn't even be involved. Like, the shit coin would have just been done, and it would be over. And, you know, like, that's just capital making capital out of out of gambling addicts. We're not in that business. We're in the peer to peer business.

The dev team is, by the way, we're all hiring, we're always hiring. The dev team is, we try to keep it small. The key teams bigger. But it's also difficult to measure the pair team because you've got myself, if you look on the open source repo, you'll see the contributors. And that's, that's pretty much the team. But we also have people in lateral and adjacent, who, you know, are doing, you know, like, metrics and analysis and, and different things as well. So it's hard to say the true number. But no, no more than say, like, 12 or so. And then we got the key team as well, we got the mobile team. And on pair, we've got we've got people so on on networking stack. And, you know, it goes deep down into the the this the hyper core stuff as well. So we kind of got lateralists and specialists that sort of all work adjacent to us. We're, we deliberately created a culture when we started holepunch that the prioritizes autonomy of individuals and that the deal is like, we figure out what we need to do. And then we do it. And like, you have to do it. And we try to, you know, keep it short. And we try to figure out how you can contribute. Like, that's what it is. That's the most effective, efficient way. When you're, when you're writing something from scratch. Then we started to bring in sprints for a little while, but it's still very light touch. We don't do huge retrospectives. We don't do like, massive backlog pruning or anything like that. It's just fast moving, getting stuff done. And the sprints are just for tracking purposes to keep, you know, this is, we know what we've done. It helps me work with the change log and stuff. No limit to sub identities. But I would know, it wouldn't be per major release. But like, yeah, anything's possible. Anything's possible. Not yet, Rooney, but we'll schedule, we'll schedule something to be added. We also have a docs team for Pair as well, of course. Again, same, same answer. I think autobase and identities are related, Glenn. There's the Pair Worker API as well. And that is, that's coming, that's coming also. The Pair Worker API allows you to run a terminal app. In fact, let's just take a quick look at a terminal app. I think we're getting there. The pair worker API allows you to run a terminal app. In fact, let's just take a quick look at a terminal app. If I go to, I've got an error in my, the reason that's erroring is because I'm running a terminal app that's built for a new version of pair. This is the terminal app code. You'll see we've got this pair worker pipe. It says, if I'm a worker, then I'm going to listen to data and then I'm going to do this thing here. Again, this isn't out yet. The desktop app demo example also has this little arg check. Then it says like, okay, I'm going to set the pipe and I'm going to pass in this worker link which is stored in the config. That worker link is actually just a terminal app. What you can do is you can say, okay, I want to run this terminal app as a sub-process of this desktop app, and then I want to talk to it. There's lots of cool things you can do with that. You can basically have bots that you just spawn out from your application. By the way, sorry, one other thing, the mobile app, we're having the same pair API exposed in the mobile app as we have in the desktop app. The mobile app will also have this pair worker in the end. It means that because bare, the JavaScript runtime works on both desktop and mobile, because it's so lightweight, we can run this exact same business logic code or computer science code, whatever you want, in this worker process from the same key in the desktop and the mobile app. Then the front end, you just plug it in, the front end piece, talking over a pipe. We'll probably have some nice modules, like ecosystem modules for communication and over that pipe as well. Then you just got this really nice way of introducing extendability. We're going to use that in Keap so that we can easily allow people just to opt into certain chat bots and stuff that can work for them. Imagine a chat bot that every time you post in your own broadcast room, a broadcast room on Keap is where only you can talk and that scales to everyone in the planet. If you had a broadcast room, I sure forgot what I was going to say. What questions have we got? The video calls question. What else we got? Find a different template, something like customers and a key pair hyper-core. All right. So customers. Yeah, that's a good answer, Cam. Yeah. But if you just store customers in a hyper B, you can have an ID per customer, that's the key, and then the value can contain the state as a simple one. But your customers would be referenced by their identities. Here's the thing, with the growth of Keap, and we can see a certain amount of growth because we can see a certain amount of SWARM connections, the best number we can do is, and the SWARM is like a shared space, but it's growing faster than it would have grown without Keap because it's growing so much, that it can't be anything apart from Keap. So we know that Keap is growing fast. With Keap identity as well, it becomes its own peer-to-peer social space. So you can do business with customers who have Keap identities. And those sub-identities, like I say, you can grant a sub-identity from one Keap app to another app, but you can also have a Keap identity from a Keap app into a Keap extension, right? Because a shopfront and a chat app aren't really that different. Like say you have a Keap pairbot, right, a worker, running as an AI shop owner, which is just a local LLM that's running on your machine, it doesn't have to be that advanced. And that runs your shop for you as a chat app, and users go into the shop with their identity and they go, Oh, hi, I want some fish, please, can I have some fish? And then it's like, Oh, hi, Dave.

Yeah, here's some fish, we've had that fish sent. But just press here and pay and then the fish will be sent or whatever, you know. So that's really not far away. Like that's really not far away. The sharing video calls, that's a really intricate question. And we're doing peer to peer, right? We're not like, to a certain extent, right, if we... There's some stuff that we're doing that we're keeping to ourselves, because we need to get far enough ahead and create enough of a... We have to engage the network effect to get enough people using Keap, so that we can fully open... I don't know if we're open-sourced. We're open-sourced in a whole version or whatever. We have to be careful about the risk there, because it's very, very simple for someone to just steal it and shitcoin it. And that's the problem we're trying to avoid. So we don't want to get this far and then just like, you know, lose it all at the last hurdle. So like stuff like the video stuff and all of that, I'll talk to the team and see what we can turn into libraries, but like, it's not the highest priority. That's something that you've got to figure out as an app developer, right? It's just like, we've not done anything special. We've not done anything magical. It's like, it's Electron, Chromium, and kind of stuff you've got to figure out.

Avi, not yet. So Pair Worker is coming, and that is the first type of a sort of bot plugin, if you like. But for sure, in the future, hopefully we will, unless we take a weird turn. Because like the other thing to note here is anything I say, like is not guaranteed at all, unless it's already out, because things are moving very, very quickly, both with our development and what we're doing, but also like out in the world, like, and so we have to constantly be on our toes, so I can't guarantee anything. But I think that that will happen, but I can't guarantee anything.

Distributed Search, yeah, great. Oh man, I'm big into the Distributed Search thing, right? But we're not quite there, right? Because what is Search? What does it Search? What do you need to Search? You need an index. So, as I was talking about with the alias indexes and the user name indexes and so on and so forth, once you have indexes and you have indexes of indexes and so forth, you're looking like, now you can do Search. A key chatroom, in a way, is a type of index, if you put links in it, right? Like, you can put other pair links in a key chatroom. You can put other pair key links in a key chatroom, so you can have a chatroom that's a link that has lots of links to other chatrooms. So that's the kind of index, right? But we need to get a bit more structured for Search and stuff, but again, it is structured. It's just chat data in a structured format, so we could search it. I think what I'm saying is, we need usage to organically grow for that to make sense to do, but it's on the menu.

Rooney, you don't need to know Node.js. You do need to know JavaScript, and it would help if you know Node.js, because similar principles. At the same time, you're gonna need to unlearn stuff to use pair. Node went from being a very small core-focused project to wanting to support web APIs, and that's a big arc. So, don't expect to be able to use fetch and pair, like globally, ever. Except in the desktop, because that's a web API. But in terminal apps, no. There should only be one way to do something, generally, particularly in terminal apps. And we don't think web APIs are actually a great way of doing things. Well, some of them are. Some of them are. That's why we're using them, but you know, like putting web APIs into a node, a non-UI scenario, isn't that smart, in my opinion. Or, no, I'm not saying it's not smart, because Node made that decision for very good reasons to do with community, and to do with engagement, and stakeholders, and all of those kinds of things, and that's totally fine, but what we're trying to do in the way we're trying to do it, it doesn't work. Or isn't what we would want to do. Pair desktop is just running code in Node, as opposed to paired on it. Yes. Yeah. Simon, yes, exactly, you're correct. The next iteration, when we get to this, will be to pull Electron out, and replace it with Chromium and Bear. So you will be going onto Bear, but PairWorker, which is coming out very soon, it runs code in the terminal app. So when you have a separate PairWorker, you can run all of your Bear code in that. But you can also do that thing with Pair init W Node, again, it's gonna need to come out in the next release, so wait one week. You can create Bear apps that run with Node code. So you can go the other way, and you can use a Node code approach in Bear and Electron, if you like. But you can also just run it in a worker. And I think the target architecture, and we're not quite there ourselves yet, but we're working towards it in Keyed as well on desktop, the target architecture is to have this separate worker with all of your logic. And then you have all your UI logic completely separate in the UI, in the renderer process, and just keep those separate. And then that Bear code, that's gonna be Bear, and that will run in the terminal, in your worker, in your mobile app, and you don't need to change a thing about it. Like, it'll be the same thing everywhere. There's many ways to skin a cat, man. Bugatfa. Bugatfa. We use Autobase and Course or I don't exactly know how it works, because Andrew is the man for that.

Avi, the answer to that question. Can I package external executables into a pair app? No. No external executables. You can. You can put anything you want in there and then you can spawn it, but I wouldn't recommend it. Multi-platform's an issue for a start, right? So if you were to do that, you would have to have builds for every platform and then you'd have to figure out how to spawn the right one for your platform. So you could do it that way. But what Bear also has is support for native add-ons. It's similar to how Node has native add-ons. So you can integrate C libraries in a terminal app with Bear. So that means that we actually, while it is a JavaScript environment for peer-to-peer apps, actually, you could write your whole peer-to-peer terminal app in C and just load it as a Bear extension and that would be very, very fast also. Yeah, nice one, Simon. Yeah, next week or shortly after, it'll be out. But remember, I'm not a reliable narrator. Anything I say should be taken with a pinch of salt.

Yeah, Rooney, so we didn't use React to start off with, because we didn't want to get down that BuildFlow.jsx kind of rabbit hole, right? So we used Preact. It's not the fastest, though. If you use Compile.jsx, it's faster than using Preact, like in the browser. Like the front-end web frameworks, a lot of them are set up to be performing in the sum total of the round-trip from server to client and how fast it works in the client and how fast it works in the server. And there's this sort of trade-off of things. So at some point, I'd like to actually, I don't think I'm gonna be allowed to do this, because, you know, like, priorities, but I'd love to write a front-end framework for Pair. I probably never will. But yeah, our plan is to support everything. Preact is good to start off with, though. That'll get you there quick. Once we have Transform supported, we'll have like a JSX flag or a JSX config set or something like that, so that you can, and by the way, there's like 70% done as well. We need to pick that back up, actually.

So like, once we have Transforms as well, like, you know, React and JSX, if you like. Or personally, everything that I've written is vanilla. Like, I like just using custom elements. Like, okay, it's not the prettiest API, but like, damn, like, you just create your custom component, create a bunch of them, use them. Yeah, I mean, once you get high-scale, you might be thinking, okay, I wish I'd done React components and used like a Redux-y thing or whatever. But again, like, front-end is an unusual, is a very large space with very strong opinions sort of around the place. And I think that paired development over time should hopefully trend towards less, not more in terms of what we do, what we have to do, what we use, and so forth. Because I think we're too, we've gone so far down the, you know, down the keyhole, whatever you want to call it, that it's very bloated these days. And I think that's bad for new learners and different things like that.

Rooney, if you think of Keat and you think about where Keat's going and you think about the things you've just said, we're at the intersection. We're at the intersection and this is the beginning. Do you see what I'm saying? Yeah, Rooney, so we didn't use React to start off with, because we didn't want to get down that BuildFlow.jsx kind of rabbit hole, right? So we used Preact. It's not the fastest, though. If you use Compile.jsx, it's faster than using Preact, like in the browser. Like the front-end web frameworks, a lot of them are set up to be performing in the sum total of the round-trip from server to client and how fast it works in the client and how fast it works in the server. And there's this sort of trade-off of things. So at some point, I'd like to actually, I don't think I'm gonna be allowed to do this, because, you know, like, priorities, but I'd love to write a front-end framework for Pair. I probably never will. But yeah, our plan is to support everything. Preact is good to start off with, though. That'll get you there quick. Once we have Transform supported, we'll have like a JSX flag or a JSX config set or something like that, so that you can, and by the way, there's like 70% done as well. We need to pick that back up, actually.

Rooney, you don't need to know Node.js. You do need to know JavaScript, and it would help if you know Node.js, because similar principles. At the same time, you're gonna need to unlearn stuff to use pair. Node went from being a very small core-focused project to wanting to support web APIs, and that's a big arc. So, don't expect to be able to use fetch and pair, like globally, ever. Except in the desktop, because that's a web API. But in terminal apps, no. There should only be one way to do something, generally, particularly in terminal apps. And we don't think web APIs are actually a great way of doing things. Well, some of them are. Some of them are. That's why we're using them, but you know, like putting web APIs into a node, a non-UI scenario, isn't that smart, in my opinion.

Like once you've registered your app with an alias, you're de facto in the app store. And then you can open the pair on time app. So you've got your documentation, you set up, you've got some debugging tools in there and we'll add an app store or so, I'm not sure what we'll call it, but something like that. All of this is gonna take time. We're building so many like, hardcore like primitives kind of stuff that like with a view to doing all of this, but like, the stuff that's definitely something that should be done that we're never gonna do because we have to focus on core business. And that's where the open source community comes into play. That's where the open source system comes into play. Pair itself is completely open source. It's running applications over HTTP in a Chromium browser. And pair is open source. So if you're comfortable with loading a website, then you're comfortable that you don't, that you've not read the open source for, then you're comfortable loading an application in pair. It's loading through Chromium over HTTP. As long as you trust the author in both cases, you're fine, right? You don't have to trust him that much. But pair itself being open source, that's all of the nuts and bolts. That's all of the stuff that's touching the system. That's outside to the sandbox. That's part open source and that's why you can trust it because you can read through all of the code, you can pay, or you can pay programmers if you're starting a business. You can pay programmers to go through all of the code. And look, we also, in pair, keep our dependency tree as pruned as possible, as small as possible. It's about 80 to 90% of our own dependencies at this point. A few others to work out in terms of production dependencies. So it really is just like code you can trust all the way down. Rooney, if you think of Keat and you think about where Keat's going and you think about the things you've just said, we're at the intersection. We're at the intersection and this is the beginning. Do you see what I'm saying?

Avi, are you using ExpoDev for Keap Mobile? Is it, what's Expodev? Oh, yes. Funny you should mention that, Avi, because I was talking with Jordi, who is one of our mobile guys. Jordi loves Nirvana. Just mentioning that because he loves him so much, he's going to enjoy mentioning it. Grandma, take me home. I want to be alone. So, we're looking into Expodev at the minute. We're not going to use it, but we're looking into how we can do watch reload via paired desktop on mobile apps. I think this technology can revolutionize mobile development space as well. We can reduce so much of the friction and overhead there with this stuff. Also, the pair build command that's coming for desktop will later be updated for building mobile assets and the pairing command will be updated for creating mobile projects. So, mobile is coming to pair in terms of all of the integration features, but we're also already building a pair mobile app using the pair building blocks, you see. Oh, Nirvana is a band from the nineties, a grunge band. If you just look up Nirvana on Google, you'll find them. Yeah, yeah, yeah. Rooney, I'm not sure what your question means. With flat, you can prototype apps? In terms of prototyping apps, yeah. I mean, like Electron is actually good for prototyping apps, right? And pair is just running on Electron. There's no Electron APIs exposed by pair, of course, because we are moving off of it, but there's only ones that are vicarious, like the media ones that use Electron APIs, but we'll obviously build native support for those ourselves. It's been talked about onion routing stuff in the key community general. If you had to add some sort of anonymization support, do you think you'd build your own onion routing and sort of IP address as a malware? Okay, so the problem with the onion routing is it's super slow, and I'm not entirely sure what we're doing with that. There has been conversation, but it's a case of, we're doing like 99.99% of security is there. To use onion links as well, it's gonna give you another.9 maybe, but you're gonna take a hit on functionality in terms of your speed, that it's, for most users, probably not worth it. But at some point, we could maybe make it an opt-in for power users that wanna do that. Yeah. Oh, okay, it's a Python library, okay. Anonymous has said, sorry, got in late. Could you explain some details about key architecture in depth? Oh, that's funny. Yeah, it'll be recorded. Okay, I think that's pretty much, man, these final, I wish I could, Ankit, you can share the slides as well. Oh yeah, that's right. I was gonna share the PDFs. Let me share the PDFs, because these slides are dope. Made by Ignatius, really good. There's the PDF in Keet. I'll put the Keet link, another Keet link in here for anyone who hasn't joined, who still wants to join. If you want those PDFs, you gotta download them now, because as soon as I close the app, you won't be able to download them for me, because it's peer-to-peer, right? Just one note about that. What we do for messages, to make sure that you, if you send a message to me, and I'm not online, your message gets held by another peer that's doing something called blind mirroring. It can't read what's in there. It's just holding it until I come online, and then it sends it to me. We do the same thing, it's pretty much the same mechanism for blind pairing. So when you want two people to connect, they don't have to be online at exactly the same time. But for larger assets, at the minute, that's not gonna get blind mirrored, because the peer doesn't want to store a large amount of data that it doesn't care about, right? So for that one, you need to be online. It's just like the same way you need to be online to do like a video call, right? But in future, what we can have, this is opening up a new marketplace for peer-to-peer services, right? So I was talking about bots, I was talking about different things, chat rooms and different things, but there is this sort of commoditized market here as well for just pure resources. Like, I'll pay a couple of sats a month, maybe, to this service, this peer, who will blind mirror files up to one gigabyte. And now I can send like large files to my friends and not wait for them to download those files from me, right? So you can go from that to compute resources, so that one's storage, you can do compute resources, you could have LLM, like AI kind of like processing resources, and then you can go from beyond like commoditization to services that have extra things on top, like payment services and so forth, right? So, because of the nature of peer-to-peer, it requires the collective working together in order to support it. The more users, unlike Telegram, the more users it has, the more robust it becomes. And the more opportunities there are for this stuff. So yeah, I mean, that's just, again, that's just food for thought. But like, we are at the beginning of a very interesting evolution of how we do everything, maybe. Questions, final questions? The only thing about Key is you can't record, but what you can do in Key is you can share multiple screen shares. So then I could've shared the screen for the slides and shared my screen for a lot of the code. It's crazy that in this year, that you can't do that on Zoom, it's mental to me. Sorry, Blind Mirror is already a thing. I don't know if it's only in source yet but it's already a thing that's out. Yes, Alberto. Yeah, I mean, it all works similar to BitTorrent. It's like next gen BitTorrent, but yeah, it is very like that. And it will download from multiple peers too. When you see one gig of data, won't that use your internet bandwidth? Absolutely it will. That's how it works. Yeah, yeah, yeah, you can set up your own stuff. Yeah, absolutely, yeah. I need to reintroduce this but when you do an MPX pair, you install pair, right? I need to reintroduce a non-GUI flag so you can install headless pair. So you can run a lightweight, like one without all of the GUI stuff. I mean, it won't run the GUI stuff but you don't wanna install all of that on a Pi and take up all the storage when you don't need to.

Yeah, we have talks about a pair phone. Yeah. I laugh, but it is serious. Also, it's like a, is it like a pair drive? Some very simple, easy to audit hardware that just runs pair would be amazing. Dreaming of a Merrill and Virginia to bring our PDVS to the device. Yeah, so for me, what I would like to see and again, not reliable narrator, this isn't vision. This isn't plan. This is just me spitballing. But I think a really cool piece of hardware would be a robust wallet that has messaging capability, has works over radio, peer-to-peer, but also has internet connectivity and has an E-ink screen, uses very little battery. And like the Nokia's of old, just like you can smash it on the floor and nothing doesn't break it. Doesn't scratch it. Something like that would be really cool. Just like a little bit text messaging, the ability to do payments completely peer-to-peer. You don't even need an ISP. On that device, it would be super cool if it had all of the open source stuff about that we have all of the documentation, all the explanations, the videos I've made, episodes of the pair report, this episode, this workshop, literally everything stored on it. Or if it's not stored on it, it's like accessible peer-to-peer, like there's references for it. If we could figure out how to make that and make it real cheap, like you basically have an apocalypse insurance policy because say you have an event from the sun, a solar event, let's just keep it just that. There's so many reasons we could wipe ourselves out. Like the Fermier paradox all over. But you have a solar event, that EMP is everything, but you've got this wallet in a, what do they call it, a furrow cage? Even if you die in the chaos and all of humanity is wiped out apart from a few humans, let's say. Let's say it's EMP, a couple of asteroids, whatever. Society has to start again and then when that happens, you start from primitive knowledge, what you can find around about the place and maybe you'll have a little bit of a head start on starting from scratch, but not much of one. But if you find this device, you can communicate and you're starting off as a high-tech civilization, but it's just peer-to-peer based. So I think a device like that would be really cool to make just because it's, and to just make cheap and just mass produce because it's something that you can throw over the hedge, over the apocalyptic hedge, you know? Just as a fun exercise to think about. But yeah, another thing is a wifi router, right? A pair router so that you just put that in your home, it's got your router identity on it or a sub-identity of your identity, but that's your main identity. And then that can do all of your syncing or store all your files and stuff. Something like that would be really dope, it's really easy to make. And then you could get like a Linux WRT like kind of base router and just like model that, you know. Oh yeah, archiving, yeah, for sure. Yeah, absolutely. And it's also, obviously it's all cryptographically provable. It is its own kind of chain, right? Uses Merkle DAGs, I think to verify, but again, that's more Matthias and Andrew's area. Yeah, Rooney, I can't totally wrap my head around it either, to be honest, like I'm still only wrapping my head around it. It's anonymous, your questions are... The plan for payments is to do it at some point. I use HyperDrive to mirror data, please, if you can explain to us how. HyperDrive, it just loops through the latest data and sends that over a swarm connection essentially, and then gets integrated in the other side. Look at the code, man. I'm gonna wait a little bit. Yeah, thanks for ruining it. I'm big into the wallet deal. Don't know if we've open-sourced the blind mirror thing yet, Simon. I'll find out. Yeah, we don't really need anyone really in it. You know, having that sort of sway on a communication app, I think that it's really important that... I think it's really important that we can self-describe collectively as a species. Vagafa, take a look at the readme, take a look at the source code. Yeah, I know it's... Oh, yeah, yeah, yeah. I wanna do the VR thing myself, but the problem with VR is you're always too early to do VR, and that is still the case today. Yeah, key on phone with Bluetooth is not as simple as it sounds, mate, because the phones are locked down. That's why we're gonna deal around pair phone in the end. Oh, dope. Yeah, I've not looked at Wholesale yet. I've heard about it a few times, but my head's been down in the coding stuff, but it sounds really cool. I like it. I might actually start using it for controlling other machines. VR peer-to-peer should be possible, absolutely, yeah. Possible and within reach. I'll do different things, right? Technically possible, technically within reach. Logistically, legally, what's been built, it's proprietary, a lot of it's proprietary, so it would be huge, huge, huge amounts of investment, but not impossible. Even after saying that, it's not possible. Yeah, well, Wholesale's dope. Okay. I think if there's no more questions, I think we can probably wrap up. Did everyone get this PDF? Don't know when the next time is. We'll keep that a mystery. I've got my head down with the code a lot. When we meet again, I'm doing the talk on June 13th. It's gonna be a seven-minute talk, and we're not gonna get into all of this stuff, all the technical stuff, but it's gonna be in-person, and it's gonna be breaking it down to everyone that this thing is available, because I think a lot of the thing now is people don't know that this is even possible yet. So being able to get people to understand that it's possible, that it changes the dynamics of the entire game, that the data exploitation model is basically a legacy way to monetize, and thanks for that, because I just don't wanna live in a world where that's what we do to each other. So yeah, Thursday, 13th of June, be there. Ha ha ha. Best hair and P2P, love it, thanks, man. How can we help? Oh, thanks for that question. Build stuff on Pear and open source it, tell us about it. Thank you. Well, this has been Pear Workshop. Have a good time, everyone. Enjoy it.