We built a P2P app with no servers. 1M users didn't miss them | David Mark Clements, Tether

This talk covers the development of a peer-to-peer communication platform called Keet, which allows JavaScript applications to operate without traditional server infrastructure. The speaker discusses how the platform uses hole punching techniques to enable direct device-to-device connections, eliminating the need for centralized servers and providing users with greater data privacy. The PAERS stack, which supports these functionalities, is introduced, detailing its components and operational architecture for deploying applications across different devices. The platform aims to empower users by ensuring they retain ownership of their data while also addressing potential monetization strategies that do not rely on cloud services. The speaker shares their experience refining the technology over four years and mentions a growing community of developers engaging with the Keet framework.

For the past 4 years or so, um we've been working on making something that works point-to-point, device-to-device, with no infrastructure at all. And we've made a platform, we've made an app, and more apps on top of it. And we've been dogfooding it, we've been we've been iterating. So much iterating. But we've gone to a point where we've distilled down what it is that we need to do

to the smallest possible touchpoints in order to enable any JavaScript application uh to be peer-to-peer and to be deployed peer-to-peer. So, what that means is you you you you you don't you don't need servers. Uh You think you do because of the availability problem. But that's a solvable problem. Uh you don't need the cloud. You think you do. There's been immeasurable budgets spent on making you think

that you do. and you don't need masters. all you need is some ability to make some front-endy stuff. uh some the ability to step into a different paradigm, a different way of thinking about technology and about how technology can interact. And you too can make peer-to-peer apps with no infrastructure. Where the data lives on the user devices, which means you can't exploit the users by their data

anymore. Sorry. But, while that does create a firehose of money, no question, you don't need to direct that firehose of money into OPEX paying for So, if you take both sides of the equation, it turns out you can actually monetize apps in different ways. There's not just one business model. >> [snorts] >> So, like I say, we've been refining this down for 4 years now. The whole

thing has been in the works for about 15 years. Um but we've been working on it intensely for the last 4 years. Uh Tether partnered with us. Tether's a 100 billion plus uh cap uh stablecoin uh that is investing very heavily in uh decentralized technology and technology that empowers users. And it it's it's really just a pragmatic thing. Everyone else is taking control and power away from

users. We want to give it back. That's an excellent USP. So, here here's the distillation. User module. Deploy peer-to-peer. That's it. No cloud needed. Just device to device. Uh so, the app that we've built on this is called Keet. Uh it's like meet with a K. Or key with a e t and not a y. Uh or like uh parakeet. Or actually, the thing we've built is

called Pair, and the app we've built is called Keet. So, if you say Pair and Keet a lot, it's like parakeet parakeet parakeet Uh when the Twitter bird died, Keet was born. Really literally around the same time. We are the reincarnation of the bird. Uh recently we've been getting uh a big uptick in users because the secret sauce that allows us to uh allow devices to connect

to each other is something called hole punching. So, what hole punching is is is where uh it's a statistically guaranteed algorithm for uh punching through NAT traversal policies on home routers that stop users connecting to each other. It also punches through the firewall of China. Uh so, it we have about a million use new users per month at the moment on Keet and and and growing. really

really large user bases in countries where the internet's being shut down a lot. Um and but you know, users users beyond that as well. Uh you don't need a phone number to to use Keet messenger. For every other app you need to give them your phone number. We don't want to know your data. We don't We don't want to know. We just want you to use the

app and benefit from it. you don't need to provide an email, nothing like that. So, this is built using the PAERS stack. Which stands for peer-to-peer embedded application release stack. If there's no cloud, there's no fees. If there's no cloud, there's no outages. This is a more robust way to build technology. and it's a way to build with lower cost. >> And it's a way to build

with different incentives. >> Uh if you're on Keet already or if you'd like to get Keet, keet.io, this QR code gives you access to the PAERS development group, which isn't publicly online or anything. This is just for developers. Uh it's currently about 7,000 plus people in there, members. Uh fairly active crowd. Uh a lot of people building a lot of different apps on this. Uh [snorts] a

lot of experimentation, a lot of research, and then sometimes things emerge out where it's like, "Yo, that's a That's a full app you've built right there." And uh there's [snorts] many there's many in the community. and more and more coming all of the time. This QR code will be on the uh slides uh down in the bottom corner, so you can keep on uh getting keen and

scan it. so, here's the stack. We have a a module called pair runtime. You npm install that into say an electron app, right? you give it a key uh actually a link with a key in it. So, it's like a pair link and then just a string. You put that in the upgrade field of your package.json. And then um it listens over a DHT using something called

hyper swarm on that topic for update events. And you use pair, the command-line interface, to then deploy to to your application. And when you when you deploy, it creates an update event among all of the peers, and then the the peers receive that update event, and there's a swap on disk where they press a button, it calls apply update, it swaps on disk, and they have the

update. Um it's really as simple as that. There's no servers in between. on top of that, there's bare. That's right, it sounds like pair. It starts with a plosive with a B, and the logo for it is a bear, but it's spelled b a r e. And the reason it's spelled b a r e is because it's very bare. There's no standard library like in node. It's

is a node-like runtime that runs on mobile, that runs on desktop, that runs on embedded, that's specifically built for peer-to-peer applications as a first-class citizen. So, it had support for UDP and UDP plus, which we we use for the transport before it had support for TCP and HTTP. It has that now, too. But, support for any of these things comes through as a module. So, if you

need to use the file system in node, you just use the FS module. But, in bare, you install bare FS, and then you use it. So, there's sort of a natural sandboxing thing here, too. Like, if you don't need it, you don't install it, and then there's no chance of it being exploited to end some kind of supply chain attack if the primitives aren't even there to

do it, right? There's more sandboxing for us to do on that, but it's I like that it's naturally as minimal as possible. There's not even a process object in bare. You have to install that separately, too. then there's the bare module ecosystem, which is all of those things like bare FS and bare UDP or whatever, but we also have things like bare FFmpeg, and so there's there's

there's add-ons that go beyond what the node core library would provide, also. But, the the the bare module ecosystem is basically like the core library for node, but more. Uh and then there's the hyper ecosystem, which is the peer-to-peer capabilities. This is things like hyper swarm, which is for connecting two peers over a distributed hash table via a topic link. Uh there's hyper core, which is the

persistence layer, and then there's a bunch of things that can be built on top of that, like hyper drive, which is a peer-to-peer file system, hyper B, which is a peer-to-peer key value store, hyper DB, which is a peer-to-peer database, auto base, which is a multi-writer peer-to-peer linearization library, uh which is what we use for Keet. Because one of the big problems for messaging or anything that's

that's that's eventually consistent, which all peer-to-peer things are, has this problem of conflict resolution. And that's what Autobase solves. You have an apply function, and your apply function determines how things should resolve. >> So, the module is for desktop, mobile, and terminal applications. You just install it into your project. Receive and apply over the air updates. It also comes with peer-to-peer storage management because if you're doing

something peer-to-peer, you need to use disk. And it comes with a method called pair.run. And what that does is it starts a a bare runtime worker. So, you don't need to install bare separately on your system or anything like that. It comes as a native dependency, but then it starts as its own runtime. The reason we do that is because architecturally, we found that we can write

the exact same back end what what we call it a back end, but it's actually local. We call it a local back end. So, it's on on the mobile device and on the desktop device, you have the exact same back end code, which runs in this this worker, and then you just talk to that over IPC. So, then you can have a React Native app that's talking

to that on mobile, and you can have an Electron app that's talking to that on desktop, but you have all of your peer-to-peer and business logic lives in your back end, and then all of your view materialization logic lives where it should in the view. So, it means it's really easy also to like add new things on top. So, we could add like a terminal app that's

like keep like IRC style Keet or something like that, right? Very easily by just reusing the same back end. So, what the pair runtime module gives you is the peer-to-peer updates, but also an like, an architectural set of very simple primitives. That that's literally all of the primitives to to make across platforms and devices. The CLI, you can install it right now with MPX You don't need

node to run pair. It's its own build of pair, but we use NPM because everyone's got NPM, right? Uh, to just just to get it bootstrapped. Uh, so you've got your pair runtime module in an app, and then you basically use these pair commands to deploy it. The this is literally all of the commands that you need to have a full end-to-end deployment flow with a staging

environment, with a pre-release environment, and with a production environment. So pair touch creates a pair link. That creates a key. That's a topic on the DHT that I was talking about. Pair seed exposes that link. It's just the same as with BitTorrent. If you're seeding a file and someone else is taking that file, it's literally the same. It's next generation of that technology called Kademlia that this

is all based on. Pair build creates a multi-arc deployment folder. So you can you make your build on Windows, you make your build on Mac, you make your build on Linux, and then pair build brings them all together in this single format. Pair stage, you stage your build folder where it basically synchronizes from disk into a hypercore structure which is seeded by that that by that pair

link. Once you Once you're doing that, immediately you can now build take that application, put it on another machine, run it, stage again with an update, and your update flow works. That's your internal staging environment. You can just stage your key anytime, send it to another developer and say, "Hey, can you check this out?" Or and you can all have in one team a single stage key

that you're like, "This is the staging environment key." Once you're happy with the way things are on the staging environment, you go to pre-release. So, pair provision creates a pre-release link. All that's doing is stripping out intermediate operations. A hypercore is an append-only log. So, everything that happens, even deletes, is appended to the log. What a provision does is it just takes a snapshot of the state

of of of the data and block syncs it across. So, then you have a much smaller deploy, which is going to go on to users' machines. that's a pre-release key. That's when you're getting really serious. You go to QA. You like make sure it's really really good. And once everyone's happy with that, then you go to pair multisig. And what multisig does is say say we've got

five people that are stakeholders of an application. And you need three out of the five people to say, "Yes, I'm going to put my career on the line and say this application is ready to go." And I'm going to sign it with my public key to say, "I have verified that this application is ready to go." You get you you gather the signatures and then you do

a multisig commit. Boom, you've gone to production. And that's the entire end-to-end flow that you need. That's what we use for deploying keys. And as I said, like we've we've got a million users coming in a month. It's getting very stable at this point. There's always like you know, UX bugs and stuff, but like it's it's getting it's getting very very firm at this point. So, we're

very happy with this the the process that has shaken out us actually doing this in practice over the years. >> [sighs] >> So, this is the geo distribution model. As you can see, you have vendor signed distributables. What that means is if you're on uh, Mac or Windows, you need a Apple key, you need a Microsoft key license key to actually build applications that you can then

give to users, right? That's non-negotiable. >> So, you can do that, and then you can put it out on the app stores, you can put it on your website for download. But then once the user's running the they're connected to your pair seed, uh, and then any updates that you make go through the peer-to-peer deployment flow, and then go over to your users over-the-air peer-to-peer updates. Also

coming soon is a pair install command, so you can just install peer-to-peer as well. But this means that like as far as your user's concerned, they don't care. Like they're just installing an app as any other app. But for you, you've [clears throat] eliminated all of your infrastructure costs. >> I've talked about Bear quite a lot already. I think I've covered a lot of Um, you can,

uh, play around with it with npm i Bear, but that's just for like the REPL and like try and stuff out running tests and things like that. The whole point of Bear is for it to be embedded, uh, in something else, like in the Electron app, or in a on mobile, or IoT stuff. Here's a bunch of the, uh, Bear ecosystem modules just to give you an

idea of, of, uh, what where we are. The green ones are supposed to be like this this is like your Node core equivalent, and then, uh, some more stuff beyond that as well. This is the Hyper ecosystem. So, you have, as I've mentioned already, Hypercore. You have HyperDHT, which is direct peer-to-peer connections. And then I have Hyperswarm, which is topic discovery over the DHT. Data structures I've

mentioned, HyperB is the key value store, Hyperdrive is the file system, Autobase is multi-writer linearization, and then these utility modules core storage for managing multiple hypercores. Local Drive is the file system equivalent to Hyperdrive. So you can mirror from a peer-to-peer file system to a local file system and vice versa, which is also what Mirror Drive provides. Here's the deployment layers. So you you version your app

like you you bump the the package version just the way you would with a module or anything semver. And then you make a new build and then you use pair build to create the deployment directory and then you stage that the deployment directory and that's your staging environment that we talked about earlier, which is this this middle tier here. Once you're ready, you go to pre-release. That's

provision and then once once that's ready, you go to production and that's multi-sig. we find this to be very effective. Then there's the release cycle. Again, you version, you make the distributables, you build the deployment folder, you stage, you provision, prepare the request, get the signatures, verify the signatures, commit, go to Once you get in the reason I keep saying the same thing is because once you

get into the pattern, it's like oh this is really easy. Once you start it up, it's like ba ba ba ba ba ba ba ba ba ba. And it's like a it's like a flow state and we've been in it for a while and it feels great. Don't have to deal with like service being down, the staging service down or like someone's pushed to it and now

it's like broken and stuff. You don't have to deal with any of that. So if you'd like to play around with this stuff, we've got some boiler plates. The hello para electron boiler plate shows you is just you clone it as a repo, you just clone it and then you can just follow the instructions and quickly get a peer-to-peer enabled electron application set up straight out of

the gate. If you already have If you already have an electron application, take a look at this and you can see how to put it in there. It's like a couple of steps. Get it in there. Uh and you've got peer-to-peer updates. We've just recently there's a blog post on on uh uh pairs.com/news about this. Uh we've just released the Hello Pair boilerplate. Uh and what that

does is it's peer-to-peer over-the-air updates for terminal program processes. So, like a CLI, a REPL, uh uh a daemon, service. All of these things can be written uh as standalone executables. No peer dependencies, no node needed, nothing else needed that you can just give to your user through like like website download, apt-get sources, brew, whatever you want. And then from there, you they've got instant peer-to-peer updates.

They never have to update again through another channel. Another mechanism. And what we also have coming soon, we have this working internally. It's just a case of applying rigor and making sure it's good and and [snorts] checking it all works out. Uh React Native boilerplate peer-to-peer over-the-air updates for mobile applications. So, they get their app uh from the App Store. They put it on their phone. You

You do a release to the mobile app. You know that can take a couple of weeks to go out and stuff, right? Cuz it's got a whole review process. That goes out onto the App Store updates and store and you've got that update there. But, at the same time, you can peer-to-peer over-the-air update your users to the latest thing so they don't have to go through that

App Store flow. And at that point, uh especially when you're using a shared back end, it's fantastic cuz you've got one back end and then you just over-the-air deploy that same back end to your desktop application, your mobile application, and if you want, your terminal application as well. Or or your IoT applications. So, other Other apps we've in production, we've got PairPass. PairPass is a password key

a key password manager. >> [laughter] >> if you're sick and tired of keyword passwords managers leaking clear text passwords, try PairPass. Because PairPass can't leak your passwords unless you leak them yourself. The data's on your device. >> Another one in production is Qvak. This is local LLMs with a focus for uh decentralized uh usage. So, uh it's it's it's more of an SDK and it's something that

we're starting to integrate into Keet as well for like things like translations and stuff. But, the point is our our whole ethos is you should own your data, you should the LLM should should work for you, not for someone else. That's that's really where it's at. So, uh Qvak is is is doing some amazing work in making uh high-quality local models that can be models of higher

parameters on prem somewhere. Um check it out. And then of course there's Keet, which I've I believe I've mentioned. Um really really good app. One other thing I'll say about Keet is um when you go on a video call in Keet, and you have a video call with someone, you're kind of like, "Wow. I didn't realize I've been living my life at such low resolution." It's sort

of like when you have Italian food for the first time in Italy, you know? if you have a server and you have people connecting for a video call through that server, what are you going to do? You're going to start constraining your costs by constraining your resources by compressing the video feed. If you have a video call on Key and you compare it to video call on

Google on anything else, it's it's night and day because if there's no server, there's no need for compression. And that's that's a thinker, right? Like what else is like that? >> [clears throat] join us on Key in the pair dev group. Uh pairs.com/news, check things out. docs.pairs.com Everything you need to know. We are hiring. So if you're into this, if you're into this paradigm, if you're into

this kind of area, uh talking about P2P, working on P2P stuff, great. Come talk to us. Come talk to me. Connect with me on Key. but also if you're like traditional stack, node, senior uh software architects kind of style, we have projects within Tether that we're we're helping out with as well. So we we we we've got a whole range of of of uh needs for really

good talent to come and join us. Um front-enders as well. We have a lot of front-enders working on on Key because it's it's Electron, right? So that's web API stuff, mobiles, React Native, um and uh UX. Look, if you if you work if you're in this room, we'll we'll we'll we'll hire you, okay? Thank you. [applause]