How Peer-to-Peer Apps Stay Free Forever (Holepunch Interview)

Peer-to-peer networks have no servers—just devices talking directly to each other. Henry interviewed Mathias Buus Madsen, CEO of Holepunch, about how BitTorrent handled 40 million users without servers, why their messenger Keet can't go down even when usage spikes, their new P2P password manager, and how P2P apps are more energy efficient than data centers.

🔗 SOURCES & LINKS
• Holepunch: https://holepunch.to/
• Keet Messenger: https://keet.io
• Pears: https://pears.com
• Pear Pass: https://pass.pears.com

⏱️ TIMESTAMPS
00:00:00 INTRO
00:01:25 WHAT IS PEER-TO-PEER (P2P)?
00:03:16 BENEFITS OF P2P
00:05:38 GETTING STARTED IN P2P
00:08:43 NEGATIVE P2P ASSOCIATIONS
00:14:13 P2P CENSORSHIP RESISTANCE
00:17:14 P2P SAFETY
00:21:29 KEET (P2P MESSENGER)
00:26:21 OPEN SOURCE?
00:27:12 BEING SERVERLESS
00:31:04 OPEN SOURCE VS. CLOSED SOURCE
00:34:05 ARE UPDATES P2P?
00:34:33 IS THERE AN APK?
00:35:37 BACKGROUND SYNC
00:39:27 WHAT ELSE DOES HOLEPUNCH WORK ON?
00:42:04 MORE INFO ON THE STACK
00:45:00 FUNDING + TETHER
00:48:09 P2P PASSWORD MANAGER?
00:54:48 AUDITS
00:55:57 AVAILABLE ON LINUX?
00:58:33 CENTRALIZED/HYBRID P2P?
01:01:49 P2P DOWNSIDES?
01:05:01 APPLE FINDMY NETWORK
01:07:16 ENVIRONMENTAL IMPACT
01:11:48 SERVICE DOWNTIME
01:12:52 HOW TO FOLLOW
01:13:59 OUTRO

🎥 VIDEO
Watch on YouTube

🧡 SUPPORT TECHLORE
Keep Techlore Talks independent & growing: ★ Support this podcast ★

Creators and Guests

Host

Henry Fisher

Runner, artist, musician and digital rights activist. Owner of Techlore

Guest

Mathias Buus

Holepunch

Editor

Tori

Techlore

What is Techlore Talks?

Techlore Talks brings you in-depth conversations with the experts at the forefront of privacy, security, and digital rights. Hosted by Henry Fisher, founder of Techlore and long-time digital rights educator, each episode features meaningful discussions with the people building, researching, and advocating for digital freedom.

From cybersecurity researchers and privacy tool developers to open-source advocates and digital rights activists—if they're shaping how we protect ourselves online, they're on this show.

Topics include: privacy tools and technologies, cybersecurity threats and defenses, open-source software, surveillance and digital rights, encryption, tech policy, and digital sovereignty.

New episodes released regularly. Subscribe and join the community at techlore.tech.

You can't shut down a peer-to-peer network because when you try to shut down a peer-to-peer

network, it's kind of like this whack-a-mole where you can, you know, you can spend a lot

of time to shut down one node.

Hello, everybody.

Today, I have the honor of bringing on Matias, who's the CEO of Holepunch.

They develop a ton of different peer-to-peer technologies, P2P.

Many of you know this.

It's essentially the concept of you connecting to other people.

He explains the principles of P2P, benefits for people like you, and the importance of

privacy and security in light of everything happening in the world.

Matias also shares a little bit about himself.

challenges of building peer-to-peer messengers, and the role of open source in fostering innovation.

Without further ado, let's dive into the interview.

Hello, Mathias. Welcome to the Techlore Talks podcast.

I'd love if you just said a few things about yourself to get started.

Yeah. Hey, thanks for having me. Of course.

So I'm Mathias. I'm the CEO at Holepunch, which is a peer-to-peer company.

We work on exclusively peer-to-peer technology.

And if anybody who has ever heard me before know that I like to say the word peer-to-peer.

I've been working with peer-to-peer my entire career and throughout my open source career.

And I'm a very, very big believer in changing the status quo and how we distribute and share data and build systems online.

So I'm really, really excited to be here and get to talk about this kind of stuff a lot.

Yeah, Nen, I want to talk a little bit more about your history in a second.

But if somebody's new here and they want to learn, they never heard of peer-to-peer before, do you mind breaking down peer-to-peer very simply for them, as well as how that compares to maybe a traditional technology that most people interact with?

Yeah, sure. It's interesting, right? Because it's two words and a number.

So those two words are the same. So peer-to-peer.

Actually, I'm Danish, and we actually had a discussion recently

what the translation of peer is,

which is a really interesting question, I think, in general,

because it's a word that has a bunch of different connotations.

But basically, it's systems and apps where there's no servers,

so you don't have any infrastructure anywhere

or running somewhere else.

It's just devices, and you use the devices to build networks.

That's the peer, so everybody is kind of like the same in a network

and have the same kind of capability as everybody else.

And you then solve through technology the problems that arise from that,

like security, authenticity, and stuff like that.

But by doing that with technology, you end up building these really,

really resilient and powerful networks that are also very,

very cost-efficient because you just have the devices

and scale it very naturally.

And it's also one of those things where you can hear when I talk about it,

I'm a technical person, I love talking about tech.

It sounds a little bit technical, but a lot of people are actually exposed

to peer-to-peer a lot.

In the past, probably through things like BitTorrent,

if they ever tried that.

That was very, very big in the early 2000s,

which was the peer-to-peer network to distribute media.

It still is, but was very big back then.

And also there's been like various apps

that's been using peer-to-peer over time

to do different things like, you know,

multiplayer games back in the day used to do it a lot

and things like that.

And so it's technology.

Basically, we build networks

where everybody has the same capabilities up here.

And yes, it's super cool.

And it's a really, really powerful thing.

Yeah.

And what's the core benefit?

If somebody is listening to this and they just use regular technology, they don't think they're using Peterpeer, even though they probably are at some point or another.

And maybe you can touch on some of those scenarios.

But what is the real benefit there for a regular person?

It's almost like when you use existing apps online, especially today, like what's the real disadvantages of those apps?

There's always these things they don't tell you.

Because when you use existing apps, there's a lot of infrastructure behind the scenes, especially that has to be paid.

You know, when you're using apps where you upload images or things like that, who's paying for that?

Who's storing it?

What's the incentive for those guys making that app for you outside?

You're just using it when you're using it for free.

You know, people always say, you know, because you're the product, people are trying to like data mine you to make ads and stuff like that and read you data.

So the real benefit is that in P2P networks, you don't have that because you don't have any like behind the scenes actor other than obviously there's a developer making an app.

But like there's no infrastructure.

It's just these self-regulating networks.

So there's basically nothing hidden in that way.

It's just natural networks that solve things.

So you can actually have a much more private and forever free experience.

So, again, if you look at something like BitTorrent, which I'm sure somebody has heard about before, that was a network when it was at the biggest.

I don't know how big it is now, but at the biggest had like 30,

40 million nodes in the network, like a P2P network that was massive.

Imagine 40 million computers connected in a network that's like an insane

amount that's probably bigger than the biggest data set out there.

Everybody's sharing, giving a little bit of capacity to that network,

which means that the total capacity is really, really big.

And that's why these networks can keep existing and keep serving you.

And it gives you this benefit of basically, like I said,

no hidden stuff so like nobody's like doing surveillance behind the scenes or trying to

data mine your data is your data is true you can kind of like make up your own rules at my company

we make a chat app p2p is really good for that because then we can have like these unregulated

conversations between each other where it's just between us and nobody else and not having to to

worry about things like you know people you know that feeling when you're you know writing messages

on whatsapp and you're talking about fridges and all of a sudden you get ads from fridges and stuff

like that you don't need to worry about that in p2p networks because it's just actually truly

it and stuff like that. So it's a really, really powerful thing and it's also been around for a

while. But also it can be a little bit technical, I guess, which is why a lot of people can be a

little bit confused by it. When did you get started with peer-to-peer technologies and how did that

lead to where you guys are today? I tell the story a lot, which is like one of those very true stories

that just affected my life a lot. So I actually started programming, so I'm a programmer now and

And I started programming in my career, I guess, relatively late.

I only started when I was at university because we had to do mandatory programming.

I was studying math and they didn't want us to come out and be unemployed afterwards.

So they were like, we need to do some real things also.

And as part of that, I had to take a course in computer science.

And that was very, very interesting to me because it unlocked this thing inside me that I think is very, very excited about computers in general,

which is kind of like this extension of yourself as a person who wants to do things in your career,

like entrepreneurship.

All of a sudden you have a computer and now you can produce much more

and you can make things open source and you can put them online

and you have this like just real sense of the power of one.

And that was really, really exciting for me as a young person

that you can kind of like just be like, oh, the faster I work,

the faster I can build things and the more impact I can do in the world.

I don't need anybody else.

I just have everything that I need.

And I stopped feeling that a little bit when I learned about networking and deployment,

because all of a sudden you had all these things where, sure, it was just me and my computer,

but I had all this other stuff also going on where I had to buy servers or rent servers back then

and get my credit card out and kind of stifled my development here.

And you would make services online.

I used to do that, made a couple of startups.

And as they gained traction, they get more expensive to run.

And then you would need to upfront think about business models to kind of cover that cost.

just turned into a whole different creative system, I think.

That was interesting.

So as part of that, I started dabbling a little bit more with peer-to-peer.

Because, again, back then, BitTorrent was really, really popular,

so everybody knew about that.

And I started reading about how that worked.

And actually, as a programmer, started re-implementing a BitTorrent client,

which was really fun.

It actually unlocked that sense again in me where, like,

oh, now I have this network, I made this software.

And I can just distribute the software to people,

and they can just run it.

And we're all part of this bigger network,

but nobody's really running it.

So it's kind of like this.

Every time I write a piece of code,

that kind of unlocks more potential

and more potential and more potential.

And if it goes rival tomorrow, it's fine.

It's going to scale really well.

If somebody tries to shut it down

because they don't like it,

they're going to have a really hard time.

So that also unlocks this power in you.

So I basically unlocked that basically

in a weekend, that feeling.

And I didn't stop because I was like,

wow, this is it.

this is how things should be built because this is just so powerful as an individual, especially,

that I've just been working on it ever since. This is now 10, 15 years ago, right? And I'm

still dabbling it down. And obviously there's like a lot of things in between there and now,

but that's the main thing. So I think it's really, really powerful for anybody who's

interested in technology and like open source movements and things like that.

Yeah. So you've brought up BitTorrent a lot. And I think the regular person,

if they hear BitTorrent, maybe, especially if they've never used it before, kind of the common

associations is it's illegal, it's not good, and also it's unregulated. I think people actually

enjoy some of the perceived safety of having a company that they can trust to handle their data.

So do you mind commenting on a bit of that association with peer-to-peer tech, as well as

is it actually, like what's stopping someone from joining this network and doing something

malicious on the network.

That's also, I think that's some really good points in general.

I think, so, you know, like I said, BitTorrent, I said BitTorrent a lot because I grew up with

that and it was very big back then and also like a big technical inspiration.

But BitTorrent was like a network where you made a peer-to-peer system that could be used

to share media.

And in the early 2000s, like for 10 years around that time, before these big streaming

services we have today, this was a very popular way of sharing content.

And obviously a lot of that content, I think, had copyright issues and stuff like that.

A lot of people got in a lot of trouble for that back then.

But one thing it really showed was that you can make technology where if there's a demand in the market.

So back then there was no other way of, if you're in a small country like in Denmark or in many places in Europe or even I'm sure in the U.S. places,

it was actually just really hard to get a lot of content, even if you wanted to pay for it.

So there was a real market for like digital.

That's still an issue nowadays.

You know, Adobe, if you bought the lifetime license to an old Adobe product,

they still remove the download links from their website.

So the only way to download that software is to get things like BitTor.

Yeah, just side note.

So it's technically like a never-ending license, but you can't get it.

That's classic.

So, yeah, and also like I moved recently to Switzerland from Denmark and also here there's also a small country and then they limit what kind of like translations you can get and like subtitles because they think everybody speaks Italian in my region and stuff like that.

So, I don't know, it's like there's a lot of really, really weird choices in content distribution in general that we can talk a lot about.

But basically like back then it was even harder and there was a real demand in the market, right?

And the thing that stepped up to fill that demand because companies weren't doing it, probably just a lot of reasons, were self-made products like BitTorrent.

So, you know, products where you could just share these things.

Obviously, there was a lot of legal issues with that.

And they got very, very big.

And they got the industry, media industry, got extremely scared because they're like, oh, they only saw the negative part of that, which, you know, I can to some degree understand.

Like you're just seeing a lot of content being distributed for free.

Fair enough.

That's very scary.

They could see their livelihood going away.

Right.

So they tried really, really hard back then to shut it down the network.

And they realized over time that you can't shut down a P2P network.

So they went on different strategies.

Because when you try to shut down a P2P network, it's kind of like this whack-a-mole where you can spend a lot of time to shut down one node.

But then another node pops up and shut down and then two other nodes pop up.

And it's just basically impossible.

Just when you hear those numbers, like 20, 30, 40 million nodes and everything is a process.

It's basically impossible.

The reason why BitTorrent then went down a little bit since then is because we got other alternatives today, like Netflix and things like that, to kind of help solve that demand in the market.

And now they have a lot of the same issues, like we just discussed, like fragmentation and content not being available and being removed and stuff like that.

So I'm sure it's going to go like this.

But from a technical point of view, like peer-to-peer was the way to show that we can just do this without waiting for people.

We can just do this with networks where we don't have to bear like insane amount of content costs to distribute things.

Like there's no like one person who pays a bill and stuff.

So really, really interesting, really, really powerful.

Obviously, with this kind of like unregulation, like you said, there's also interesting things that happens because you can just share whatever you want, right?

This was like in the Wild West period of the internet.

but there's also a lot of people who just got bad copies of movies

and stuff like that, I'm sure, and things like that.

So definitely there's definitely not just a technological solution

to something, and you still need to think about these other things

also in these networks.

But as with anything technology, you can always build something crazy

and scary and bad, but you can also use the same technology

to build powerful, simple apps to try to solve these things still

because there's no reason why the technology can't be used for both.

That's actually one of the things that I've been involved with

my entire career.

It's kind of like saying, what if we took the ideas that were so powerful in BitTorrent,

but then try to not couple it too much to just kind of like to file sharing,

but just kind of like say, these principles are clearly extremely powerful.

How can we take these and make any kind of apps, any kind of content run with these ideas

without just having to like disregard all the other things we know that are very needed for like app development?

Like you said, like easy understanding of content.

Like you don't want to search and have 50 versions of the same thing.

You want to have some sort of ideas there.

Some things do need some regulation if the app developers want, like, you know, kind of like in our chat app, we have a way for people to be moderators in chat rooms and stuff like that.

You can make up your own rules, but like anybody can kind of like set up their own rules and stuff like that.

But I kind of like still running on the principles of peer-to-peer so you can make these things, make them powerful and make them unstoppable.

Nice. And yeah, I definitely want to touch on the Messenger and the other stuff that you guys are working on in a sec.

But you've been bringing up some interesting stuff that I want to ask a little bit more about.

So you mentioned the concept of not being able to easily shut it down.

So can you comment a bit on censorship resistance of just P2P technologies in general?

Yeah, sure.

So it's basically like I'm sure there's some eloquent principle in this that I will find after this podcast and start quoting a lot.

But it's this idea that, you know, everybody's the same, right?

So it's kind of like this crowd mentality that's been working for humans for generations.

Once you get to a critical mass of a movement, you can't shut down a movement because you can't, like, lock up everybody, basically, right, if you're being dramatic.

So peer-to-peer really works in big networks because everybody's the same.

There's literally no difference between nodes in a network when a peer-to-peer system is built correctly.

Sure, some networks will be a little bit fatter, has more content than others, but the idea is the same, right?

So it's completely unrealistic for once, just like by the law of numbers, once the networks get going.

it becomes completely impossible to shut down.

And again, if you look at stuff like Bitcoin,

because it's just such a good case story.

And actually, I'm surprised that not more has been written

about just the implications of these networks,

not so much in tech,

but also just kind of like human behavior in these networks.

Because I think it's very, very interesting.

It's very interesting how also those networks

from people who wanted to shut them down,

that battle was fought.

Because in the end, the thing that there was some success with,

I think in BitTorrent, in terms of limiting these networks,

was trying to attack the few centralized point of use on that.

And I think that's actually very hard for normal people,

like non-technical people, to understand.

So in a network like BitTorrent,

people were trying to find Torrent files back then through websites.

And they would go to a website, they would find content there.

And the way, in the end, that this war was also fought

was trying to shut down those websites.

A lot of times, very successfully,

There's a lot of good documentaries around that with the pirate bay and things like that.

By getting the websites delisted, and how are they getting delisted?

By just attacking the centralized part of the internet, which is the DNS registry,

like the thing that translates your name to a website.

Because there you could just go with a normal process and be like,

I don't want this website listed anymore.

Here's a bunch of legal reasons why not.

And then some legal process would say, yeah, that's correct.

This is legally not okay or whatever, et cetera.

And then users would go to that website and the browser would say, no, it doesn't exist anymore.

So the network would still be running in the background.

And people who knew how to still get access to listings or content would still work.

But by attacking these things, the one piece of this network that was centralized, it was pretty effective on that part, I think.

Also a bunch of learnings there, kind of like how just one piece of centralization kind of like tends to unravel you from a user's point of view.

And how it can get very hard to understand from users really fast.

So again, like really, really interesting use cases here and like things to learn also from my resilience point of view.

Yeah. And then the last question before we touch a little bit more on what you guys are doing.

You mentioned the concept of bad movies. This is something I've had to share as well.

It's not an issue exclusive to peer-to-peer tech, but I feel like it is a little bit more of a Wild West.

And it's maybe a little bit more likely for someone to download something that's malicious if they're not careful.

So how does someone assess safety if something's peer-to-peer?

Not just from making sure they download the correct thing,

but I don't know if this is technically peer-to-peer.

Jack Dorsey released his Messenger, which I believe uses a mesh network,

but I don't know if that's technically peer-to-peer.

But either way, when it was first launched, it's gotten much better since then.

It had tons of vulnerabilities.

It wasn't even using proper encryption.

They themselves even came forward and said,

you shouldn't be trusting this with anything sensitive.

But something being peer-to-peer isn't alone any kind of metric of safety.

So how can someone still assess safety when they're kind of responsible for their own safety on a peer-to-peer network?

Yeah, for sure.

I think actually an easier way to think about that is kind of like saying there's like the technological aspect of it,

which is kind of like you have some content in a network and I want to access that content.

Can we do that securely?

And if we have no box in the software and we've done this for a while,

that's actually the problem we've been solving for a long time.

And it's a surmountable problem and very boring in some degree.

But then the much more interesting question also becomes,

also from a UX point of view, is kind of like,

well, I can get a virus from you or some bad piece of software

and I can get that cryptographically verified

and it can be super secure to get it, but it's still a virus.

So it's kind of like it doesn't really help me

that the network is trying to make this really good.

And what's the solution to that?

Well, the solution to that is like, obviously there's a technological aspect of it, but it's also much like a product design thing.

And like, how do we think about these things and products?

So I think if we think about the content way, it's really good, right?

Because it's like in a content app where you're sharing something that to some degree has a known origin, let's call that.

So like, you know, let's say we were building like the Netflix of peer-to-peer and we had, you know, we're not trying to be pirates.

We have the rights and we just want to do this this way because it's like distribution-wise,

like much stronger model than putting it all on the server.

Then you can still make systems in a P2P network where you add like a stamp of approval to content.

So you can have like an index being served, like a search engine being served that is coming back to me saying,

yeah, I approve of this index.

So this is Mathias' index.

This is what I say things should map to.

So if you search for this thing, you can get some trust that if you trust me,

you're not getting the content from me, but you're getting an idea what the correct content is.

So you're getting that direction to get to your content.

And we see this all the time in existing apps and social networks.

Even in things like, if you think about recommendations, it's almost the same thing.

I can't remember, there's this very popular recommendation app for movies that I can't remember to lay out right now,

where you will search for things and it will say, oh, your friend likes this one, so you should probably watch it.

And then you can go and find it on Netflix or whatever.

It's kind of like the same thing.

This idea that the people in your social group or even people you trust elsewhere can give content these stamps of approval.

And then in a P2P network, you can just expand a little bit more and say, well, it's not just about approval of like, is this a good movie or not?

It's also like, this is the right thing and this is the thing you should be looking for.

The cool thing about it is that that actually is a really cheap thing to do in terms of like network effects and technical complexity.

Because you're not really, that doesn't have to be tied together with the fact that I have all the rights for all the content.

It just says that if these rights are distributed correctly, and that's obviously a thing, I will approve that this stamp of this file is correct.

And then you can build some very strong networks like that.

That's really, really powerful when used correctly because social proof and even extending that also to third-party validators is really, really powerful.

And it's all over us in modern society.

And I think we tend to forget that in general.

It's kind of like back in the day when you could go to a blockbuster and buy a movie.

That's how old I am.

That's how I got my content in the early 2000s.

You would also trust that the movie that Blockbuster has is the correct movie.

Why? Because it's a big brand and you would trust that they're not switching the disks with something else.

The same idea here that would just translate into a network where you say,

I can have the digital version of that, but I can still have the content being distributed peer-to-peer afterwards.

That's really, really powerful.

Pivoting over to what you guys are doing.

So I've tried the Messenger, Keet, I believe.

K-E-T.

Do you mind covering, I guess the first question I'm sure a lot of people are going to ask is, why another messenger?

So maybe you want to expand on what you guys are doing that differentiates yourself and kind of how it's going so far.

Yeah, for sure.

So like I said, I've been working with peer-to-peer my entire career and I'm very, very invested in it.

And around like four years ago, we decided to get really, really serious about peer-to-peer from not just a technical point of view,

but also kind of like adoption.

How can we get this ball rolling

and get this technology out to everybody

and try to disrupt the industry,

both from a software development point of view,

but also like a product point of view?

Because like we already discussed,

like peer-to-peer has been around cycles before,

but been kind of tied to these use cases

like piracy and things like that in the past.

But like expand that and not just do that,

but like, well, like not do it at all,

but like build like real apps that do it.

And so we founded our company, Holepunch, back then,

and we were like, let's set a goal to make the hardest possible app

that kind of encompasses everything in terms of what an app should do

so we can both just solve a real use case

and also validate that this thing works technically in every case.

And we very quickly, after a brainstorm, decided that a messenger app

is actually one of those apps that is incredibly simple.

A messenger app is like you just type.

But once you start going through the requirements you want from a messenger app,

you quickly realize that it has all the requirements of every piece of software ever, right?

It's kind of like you and I want to be able to chat,

but we also want to be able to chat securely without surveillance and like in a private way.

I want to be able to have a private chat with you and just send you what I actually think,

what I'm thinking that if somebody reads this, that's not us, that this, you know, has consequences.

Messengers also have file sharing, obviously, right?

Because, you know, we send content all the time.

It's a very natural way to send content.

whenever I send, you know, movies and stuff like that,

it's always to my parents of my kid and media and stuff like that.

And that also ties into like, it should be private.

It should be secure because I don't want that stuff to go anywhere else

because it's private stuff.

But it also has this like scalability aspect of it.

If I wanted to share that for some reason with a very, very big chat group,

like with thousands and thousands of people,

it should still work and still be scalable.

Check on that one.

It's like a really high one and very, very important.

And then also we've been seeing in the last, even before that,

But especially in the last five years, just the world turned to a much, much darker place in terms of like the digital rights we have in these kind of apps.

Like there's more and more stuff going on where both from like a data mining point of view, trying to like read our internal thoughts behind the scenes so we can get better advertisement and stuff like that and sell more products.

But also just from a, for lack of a better word, control point of view, like, you know, having an idea of backdoors and surveillance, even in like pretty liberal places, traditionally liberal places like Europe, recently it's been turning very, very dark on that.

So very quickly we identified this as like, oh, this is something we need to solve.

And we decided to build a chat app.

And it's been really, really exciting to build that out ever since.

And like tackling all these problems up front and get it to scale and get it to run and like get it to run on devices.

And again, without any infrastructure, just devices.

So like no hidden, you know, server gets backed up to or anything like that.

Just devices that can talk directly to each other.

And then with a big, big UX caveat on top that the users should never really be aware of this.

It should just work like any other app.

We don't want it to be like a technical niche app.

We want it to be like an everyday user app that just solves this from a user's point of view.

So that's key.

And we just shipped our latest version of it just before this podcast, actually.

We're shipping like crazy.

It's been really fun.

And it's still really fun.

And it's getting really good and really powerful.

So when you make a peer-to-peer app, you don't really know about scale and stuff.

Because, again, there's not a server I can log into and be like, how many users are online right now?

And what's the scale?

Because it's like just devices talking to each other.

So it's kind of like you hear it through the grapevine.

You hear like, oh, this is happening and this is happening.

And you try to figure out what's happening to get a sense of like, is this going well?

Is this going bad?

What's working?

What isn't?

It's very, very social.

You have to talk to people.

But we recently had a big onboarding of new users due to links being shared in Eastern Europe.

And it was really fun to see the app grow a lot and the network grow with that.

and stuff like that. So it's been very exciting. Yeah, my assumption is you can probably see

analytics from App Store and Google Play Store downloads and maybe on your site. And that's about

it. And then we have a few public rooms in Keats that we have a link to that you can click on if

you want to join and we get a sense of both community in that. But also, it's also been a

very big learning that when you have a big room on a big network, just bringing the whole world

into a single room can be very intense for sure, just with different cultures and stuff.

And everything's open source, correct?

So our entire stack is open source.

Our key front end is closed right now, but 99% of our engine is available on GitHub.

And if you're interested in P2P development in general, you should go check it out.

It's really a beast of an engine these days with all kinds of stuff.

Because like I said, we've been having to solve just so many things that you don't think

about also when you start like, you know, getting devices to sync having the same state, getting

files, getting big files to work, getting push notifications to work in a peer to peer

environment is really hard on devices, getting them to run in the background, all this stuff.

So if you have like a weekend where you're not doing anything, I would definitely start

on GitHub and end at the other end of it.

Here, I've quite a few questions to ask that came up.

The first one is, can you explain the concept of something being serverless?

Because even somebody who, I think there's this dangerous middle ground that a lot of people have fallen in, where they might know what a server is as a concept.

They know it's maybe like the company has this thing, I'm talking to the company, and then the company sends a message to someone else.

But the concept of cutting that out and you directly talking to somebody else is a bit different for people.

So do you mind explaining how that works in something like Keet or just in general?

Yeah, for sure.

And also, it's even more confusing because I'm sure if you Google serverless, there was a term that was very popular like five years ago, four years ago about using servers for other things.

So it's a confusing space.

But basically, serverless now context here just means run things without servers.

What does that mean?

It means that we have a bunch of consumer devices these days.

You know, I have a phone.

I'm sure you have a phone.

Everybody has a phone.

I have a smartwatch.

Some people have that also.

I have a laptop.

Some people have that also.

And all of a sudden, us as consumers have accumulated a bunch of devices that over the last 20 years, 30 years have become incredibly powerful compared to what they used to be.

So, you know, like my laptop and your phone like has, I don't even know how many magnitudes more power than we used to go to the moon in the 60s, right?

It's like, you know, one of those ridiculously incredible numbers that just baffles the mind.

So we just have a lot of compute power very close to us all the time.

And we seldom use it because, you know, how often outside being very active on your phone spends most of the time being in your pocket or your desktop also be like idols most of the time.

And they're also much more powerful than, you know, it's not like when you use your phone that is like just running at 100% powered 24 seven.

So they have a lot of space and stuff and they're only getting better.

So we have a lot of devices, but still as software developers and like people who think about products, we kind of still have this mental model of like, if we don't from back in the day, but we should, instead of like using more computer devices, we have external servers like data centers that does all the compute.

And then, you know, when you and I in traditional apps would send data to each other, we would say, well, first of all, let's get it to that big server and then have the server do it and then have the server send it back to us later.

So when we have no internet, things stop working.

Or if we get blocked or banned or that the data center catches fire, things stop working.

It creates these absurd situations a lot of the time where, you know, I mean, I have an office here.

And when me and my co-founder sits in the office here, I sit at this table.

He sits at a table like two meters next to me.

When we use Slack and I send a message, if you just think about the travel of that message,

it's like one of those big adventures in life where that message will go, even though there's only two meters to him,

will go from my laptop to some data center somewhere, be backed up and maybe another data center.

and on some servers, and it's probably crossed three or four countries by this stage,

only to be dropped down on the other side of the computer, on the other side of the table,

and then with a ton of still processing power, when in fact we could just take the direct line,

which is just my device, to his device.

So that's basically what peer-to-peer is trying to do.

And it's also kind of interesting because it's how computing used to work.

If you go back and think about original computing, this idea of a server is kind of made up, right?

Because a server is just another computer.

Everything is just computers.

So P2P is just good old fashioned, cut out the middleman.

There's just two things directly.

And then the only other thing that's a little bit sophisticated is that obviously as you add like three, four, five, six computers, you don't want to have to talk to all of them.

So you need to do a little bit of technology to make that smart.

But at the end of the day, that's just technology.

So cut out the middleman and make everything fast and simple.

Nice.

And then in regards to key, add a few more questions before we touch on other stuff you guys are working on.

So you mentioned on the open source side of things, you have the open source stack, but then the closed front end.

So why is it structured that way?

Yeah, good question.

It's also something we get asked, not a lot, but like obviously technical minded people have this question a lot.

We're trying to make Keat as an app that your parents, you can use, my parents, myself, and anybody can use.

Basically trying to take this very sophisticated piece of technology, which peer-to-peer at the end of the day is, behind the scenes, and make it work for real people.

That requires also like kind of like going back to the thing we had in the beginning about like how do you got the right movie and stuff.

It's the same for like crazy peer-to-peer apps.

We need to make an experience that's really simple for people to understand.

We need to have an app in the app store that's like always the latest app that's like easy to understand, that has a brand that people can go to as we bootstrap this network.

So we don't kind of like get stuck in the small phase

with like a thousand different clones of this app

where every one of them is out of date

because they all bundled the P2P app,

but not the latest version.

And like nothing really works

because there's like too much proliferation too fast.

So we're thinking a lot about that UX,

how to make this like not a nerd technical product,

but like kind of like a mainstream product.

And that's a big reason why we try to keep the front end close

so we can iterate really fast

and have the experience, like everybody's up to date.

If you try our Keet, this is the thing that the biggest complaint I get

from my in-laws who uses Keet a lot, I talk to them in Ukraine a lot,

which Keet works really well there because the networks are pretty bad.

The biggest complaint I get is like every time Keet updates,

it tells them to restart and get the latest one.

And we update a lot.

We update every two weeks.

And the reason why we do that is because by doing that in this like bootstrapping phase,

because, again, all the software you need to access the network

is literally on your device.

There's no other software somewhere.

So, like, the full stack is on your device,

which is kind of incredible to think about.

So, by keeping everybody up to date in, like,

in a bootstrapping phase and stuff like that

makes it so much easier for the product to move fast

and, again, go into this mission of, like,

attack the mainstream, change the world.

So, we're very, very focused on that

and just keeping the front end closed and iteration heavy

is a really, really big part of that.

Now, I've written so much open source code in my career,

like incredible amounts,

because that's basically all I did for like 10 years,

just produced open source code.

And I've seen every aspect of it,

but I'm a big, big believer of it.

And that's why we didn't take literally that 99%

that the rest, so people can review it and contribute to it.

We have a lot of really good contributors

and help push that part of the stack forward.

It's not always the easiest thing to contribute to peer-to-peer

because some parts of it can be tricky

because it's like cryptography,

but we do get a lot of good contributions and stuff.

So yeah, so that's like the short answer,

like long but short answer, I guess.

It's like we're trying to make something

that's truly mainstream.

And by doing that,

we need to be a little bit aggressive on these things.

And that's why we do these things right now.

When someone downloads the app update,

is that download done via a server

or is that done P2P?

On the desktops,

we have a desktop build and a mobile build.

On mobile build,

We can do a whole podcast of this.

You're a bit more restricted because you're in the ecosystem of the app stores.

And the app stores have the stuff that app stores have in terms of guidelines and rules.

So you have to get some stuff from the app store always on update.

But we try to do as much as we can update-wise there.

Do you publish an APK on the Android side of things?

We publish an APK on Keet.

So we have Keet publishing the APK.

So it's like CryptoCraftically Verified comes from us.

So we have a chat room that's called the APK room that we maintain,

and that implicitly everything is verifiable from there.

And that we are published to Google's Play Store and the iOS one also.

And on desktop, we have our peer-to-peer platform also,

and that's fully peer-to-peer on the update.

So everything on that running peer-to-peer,

so truly mega unstoppable, nobody can take it down kind of situation on desktop.

And we'll get there on mobile also.

We have a big 10-year plan to kind of disrupt that thing also through various things.

But I think it's really, really important.

It's also very frustrating that you're a bit more limited on this side of mobile because there's no reason.

We could do it tomorrow if we were allowed to.

Yeah, I tested Keat only on desktop, and it was very clean.

And I guess it depends what desktop you're running.

If you're running a 24-7 desktop, it makes a lot of sense, especially with something peer-to-peer, because you're always online.

You have a reliable network.

I think it's kind of the best-case scenario.

Do you want to speak a little bit about background sync?

I assume on iOS, that's going to be a big challenge, or if it's not already.

When you're your own peer, there's no server, so the device always has to be running in the background, I assume.

So it's actually also equally hard on Android.

It's actually funny you say this because literally three hours ago, we rolled out our first big part of background sync on iOS.

That's exciting. How do you do that?

Is that using the new iPad background sync, or is that also on iOS?

So we do a variety of things because there's not really one solution on iOS.

And we also don't run it 24-7 in the background.

So just to dial it back a little bit.

So a couple of years ago, one of the first big things with it was release this thing in KID where other people can help you maintain your network.

It's called blind peering.

So a peer can hold your data fully encrypted, can't see it, but that helps you in a network where you're a very small network.

Like if you and I had a DM, that's a network of two people, which is the weakest peer-to-peer network.

Because if one of us is offline, 50% of the network is offline.

And like most of the time when you and I text each other, there's usually a device offline, a very high chance of a device offline.

So you want to have a system where a very, very small network can introduce a third peer.

Obviously, that's like fully private and just hold your data for a little bit.

And then, you know, I come online, we can get this from there.

So we did that a couple of years ago.

It's really, really good for small networks.

It's kind of ironic. I say this a lot, but like in peer-to-peer, the hardest problems is the small problems.

So like in a centralized network, that problem is really easy because it's like, oh, you have a server.

It has tons of capacity. So like two people, it's like tons of capacity.

But then as that grows in a centralized network, it gets harder and harder and harder because the capacity runs out.

In a peer-to-peer network, like if you're only two people, that's tricky.

But then you had three people, now it's a lot better.

And now you have four people, that's a lot better.

And all of a sudden, when you're 10 people, all problems goes away.

So it's like you want to have more capacity.

So we have that in there, and it helps a lot with these kind of situations where, you know, you can pick somebody else from the network and help that hold a bit.

And that's basically how small chats work.

Then, obviously, you want to have as much backgrounding as possible because it just helps the entire network also.

On iOS, we use, they have this general backgrounding API that can run once in a while.

But also every time you get a notification, you can run a little bit of backgrounding on iOS and things like that.

And you're also allowed to linger a bit in the background as you use the app.

So all that stuff adds up and actually gives you a lot of compute because we don't need that much.

It's kind of like you can imagine the data is on our side because there's many devices.

So every time we add a little bit, the entire thing gets higher.

So that works pretty well.

But it's obviously a challenge.

I actually find it personally really frustrating on phones because my phone is on all the time anyway.

It's kind of like I can get a notification at any time.

And I bought it.

I literally paid lots of money for it.

So why can't I, as a developer, do similar things?

Because all the arguments basically come down to we don't want you to

because we can do it in a way where it's as energy efficient

as receiving a push notification because that's basically what it is,

and stuff like that.

So it's a little bit frustrating, but over time we'll get there on that.

But it's not just a technical challenge.

And then on Android we do similar things.

Yeah, I guess what I've seen is apps like even Signal, Briar, if you don't have Google Play services on Android, they have this like always running 24-7.

It drains up quite a bit of battery approach because there isn't really an easy alternative.

I know Unified Push has been kind of getting a little bit more popular, but it seems like people don't really like the complexity of that either for end users.

You really need a thing where you can hook into the systems,

a low-level chip that says the network is running now

and they run a little bit.

That's a very good system, and they should just allow us to do that.

So pivoting over to other things.

So you guys are Holepunch, and I'll ask about your team

and a little bit more about you guys.

But what are some of the other things that you're working on?

So we have quite a big team now.

Like I said, we've been going on for like four years.

Also, we're hiring developers.

So if anybody's listening here is into programming,

you should definitely go check it out.

There's a lot of really fun and hard challenges to work with.

But Tether is, sorry,

Holepunch is a collaboration between Tether and us

in terms of trying to do this big push to disrupt the status quo.

If you don't know, Tether is this world's biggest stablecoin,

which is kind of like digital dollars to send things back and forth,

which is really, really cool.

And it's really well with a P2P of things.

So we're trying basically through that also to disrupt the entire industry

of both how you share data

and Tether does it on the financial side

and stuff like that.

Overlapping those things are very exciting.

But we recently did a big push of other apps also

to try to push the technology and just make,

there's so many things to solve on these things

that's really exciting.

So right now we're also working on something

in a collaboration with them called PairPass,

which is a password manager app

because that also I think fits the bill really well

and these like simple but very powerful use cases

of how can you take something that's extremely close to us right now,

a lot of things still require passwords and secure notes

and stuff like that, and keep it truly private and truly secure

without having to rely on any kind of centralization.

So we did a big push on that recently, trying to just take the stack,

like 90% of the stack that's also running, keep, again, all open source.

PairPess is fully open source to kind of show people also how to build things

completely from the ground up because it doesn't have that big mainstream thing

I just said earlier, it's kind of like it's more a normal thing.

Hopefully, you're not going to send many chat messages in a password app.

That would be kind of crazy.

So that's rolling out really soon.

Super, super excited to get that one out.

I've been playing around with it a lot myself.

I helped coordinate a bit of the code initially,

but the team has really been cranking away on that.

And it's just really, really powerful.

Really, really simple at the end of the day.

So super cool stuff.

Yeah, I'm going to ask about that because password managers are an interesting one.

I get a lot of people who leave comments and are concerned about the idea of a server holding their passwords,

even though we can verifiably prove that it's encrypted and it's theoretically no different than if you were to encrypt it yourself and upload it on a server.

And then I think the whole peer-to-peer aspect could be a bit scary for someone.

But before I get to that, I just wanted to quickly ask about the stack.

It sounds like the stack that you use for Keat can be repurposed to be used for many other things.

So what exactly is the stack really just the ability for you as a device to be a peer to connect to other peers and transmit data?

And then the actual data and the UX is kind of the only difference between any potential products?

So like I said in the beginning, we tried to do this big mission of like let's basically disrupt software development, how you make apps and stuff like that.

And so we quickly just put that into different categories.

Like, what do you need when you make an app?

You need like a database.

You need some sort of connectivity.

As in like, you know, kind of like right now we're recording a podcast.

We have a stream together where we can see each other, like a call.

So you need some sort of real-time communication.

You need persistence databases.

You need some sort of file sharing if you're doing stuff like that,

or at least components for that.

And the various other small and bigger components for that.

And we made just software modules for each of them that kind of like,

For a software developer, it has some normal-looking interfaces that makes it relatively familiar to make apps,

and then packages that up into a bunch and bunch of small modules so you can pick and choose what you want,

and then make that freely available for any kind of app that wants to be peer-to-peer.

Like I said, that's all there, open source, available on GitHub.

We have a website.

That's the only website we have outside KIT.io called pairs.com,

where we have a little documentation on how to work with this and make examples.

So theoretically, I can download that stack, develop my own messenger using the same stack.

Would that be its own network or would that actually still be part of the same network that everyone's using for something like Keap?

It would be its own network because every app is its own network.

We could then make a collaboration and try to bridge those networks if we wanted to.

There's nothing wrong with that.

But peer-to-peer, I think it's also good you bring that up because it can be a little bit hard to understand.

Because peer-to-peer is not like one big network.

It basically just means whatever you want.

So normally you would just make that kind of like everything is a little network by itself

and have your decisions kind of like encapsulate that.

That makes a lot of sense.

And also that's one of the reasons why we can just do this open sourcing for free

because that doesn't cost us anything to run it.

It's not like when you do that, like there's something we allocate on our end.

It also means that there's nothing for us where we need to sell you something when you do it.

So we can just have it be software.

It's not like there's a token or something like that you have to buy

and can invest in to kind of hope that helps the network.

Because again, this is just between you and your devices, however you define it, and you can do whatever you want in a good way.

So really simple infrastructural tech.

We have this internal, I don't want to say mission because this sounds wrong, but it's kind of like this mantra of saying, if we go bankrupt tomorrow and we shut down the company, everything should still be running.

So like everything is kind of like built with that mentality.

So it's truly just peer-to-peer.

So I don't want to say hosted.

I'm trying to come up with a different word because this sounds wrong also, but it's like self-regulating networks, I guess.

Yeah.

And I guess one quick question.

I know I kind of threw the password manager thing at you and then we quickly changed subjects.

But on the topic of funding and Tether, let's say Tether decides we don't want to keep doing this anymore.

What would happen to Holepunch?

So is there a strong dependence there?

So we have a big long-term traditional strategic partnership that we're very, very committed to, both of us.

When we started doing Holepunch, like I said, we came into this with this idea of like, let's make technology that truly has no infrastructure.

So it's a very interesting company because we actually don't have any infrastructure other than, you know, testing stuff here and there.

And it's also a very interesting thing to talk about financially.

I get asked this a lot on other podcasts, like how do you guys make money and what's the profitability on these things and stuff like that, which is very, very good questions.

Because right now we've been very focused on the technological side of it.

But something that's very interesting on that and also kind of like to answer your question is as the products scale and we add people, like I said, we're just onboarding a huge amount of new people that we think at least to keep recently, the company costs don't go up.

So we have this like idea that we have, you know, we have budgets, we have money in the bank.

We can kind of like look ahead and say, well, obviously we need to pay people salaries.

That's how the world works.

That's good.

But like, there's not like hidden, oh, if there's overnight success, what do we need to do to like keep things running and stuff like that?

And that's a whole different way of thinking about just both financial roadmaps and like profitability and like, and things like that.

It's a much more almost like old school way of thinking of things because we can have this idea that we can make technology that can scale really fast.

But at the same time, we can have the freedom to never really think about burn rate in that same sense because the burn rate is very flat.

And that makes our life really, my life a lot easier because I can just look, you know, on the runway and be like, that's it.

But also I can, when we make the products, focus on just like your product development.

So like, for example, right now, something we're rolling out in Keet that we just rolled out a very early preview version of and the latest version of Keet is like big podcast-style calls like this one, where you can do like big calls.

So normally if I was doing that on traditional product, I would be like, okay, so you and I are talking here.

That's like bandwidth.

That's going to cost money.

So if we host that on our servers, what if that gets really popular?

It's going to be a big bill coming in.

And Keelig would just do it because we're like, ah, it doesn't matter.

Because the network is paying for that by people just streaming themselves.

They've already paid for the internet.

So that just changes the equation completely.

We're very, very excited in general to partner with Tether

because Tether is such a beast in terms of financial kill bill.

I don't know if you follow it closely, but it just grows bigger and bigger

and bigger and bigger every month.

And that's basically the same kind of mentality we have with peer-to-peer.

We want to do something that impacts the world in truly an irreversible way and change the status quo.

I think that's a really, really good synergy there.

Yeah, with video streaming, I know there's still a centralized aspect to it because I still have to pay to host the videos on my server.

There's still a server.

But it reminds me a lot of PeerTube because when you go and watch a video, you're also streaming some of the bandwidth to someone else, and there's still a peer-to-peer aspect.

And I'm going to ask you about the hybrid solutions towards the end.

But I want to quickly double click on the password manager question I kind of threw you away earlier of the whole idea of potentially sharing password management, even if it's encrypted information with other peers on a network.

So first of all, I think with password managers, I think there's my friend told me this analogy one.

So I think it just fits really well.

I'm sure he heard it from somebody else.

But it's kind of like even with centralized password managers, if you look at something existing today where you have these apps that is like centralized solution, they all have very, very strong cryptography, I'm sure.

And there's a lot of like decent ones out there.

But my friend told me this thing that I always think about.

It's kind of like, well, if you have the world's best scientists, right, and they all have to travel somewhere, do you put them all on the same plane?

It's kind of like the plane is really safe, right?

It never crashes.

But like still, would you do it?

And it's like, there's always this like slight risk of like, well, maybe something went wrong

in the cryptography and things like that.

So you want to have options where you can kind of like define your own thing.

So in a peer-to-peer password manager, like Autopass, the true power, I think, is kind

of like in that aspect of options.

So the app itself has various settings you can choose.

So you can basically choose.

I just want to back this up with myself.

It's obviously all super strong, mega encrypted at rest and in flight and all this stuff.

that I, again, I'm sure also existing password managers have

that would then go to one centralized place.

Autopass doesn't.

So you can choose there.

I just want to have it between my own devices.

And then if I lose all my devices, tough luck,

my password's gone.

That's a feature.

Or I want to have it be backed up to my friends

through their social backups.

I'm sure we're missing a little bit of UX on that.

Or I want to have it be in this general blind peer networks

where people can kind of like, you know, anybody can help or choose these specific ones.

And I think we have a lot of options in the app.

I can't remember exactly what the final one looked like,

but like where you can pick very specifically where things go and stuff like that.

Because one of the powers of peer-to-peer is this idea that it doesn't really matter where things come from.

So that makes it very, very easy to build these things out without having to think so much about it.

Got it. So you're saying if I have three devices, let's say a desktop, a laptop, and a phone,

they, you know, let's say I'm coming from KeePass,

so I'm used to an offline experience.

Can I just have an offline database

that I can just manually, if I want,

copy and paste essentially onto another device?

Is that, I guess that's question one.

And then question two is,

it sounds like I can just have a sync chain

that's peer-to-peer across just those three devices.

It doesn't touch any other device.

And then I can also extend it to other people

and beyond if I want to.

Exactly.

So I think I called it Autopass before.

That's because our module is called Autopass.

The app itself is called PairPass, which rolls very well over an under-tongue PairPass.

But exactly that.

So you can build your own topology.

Everything in PairPass is fully open source also.

So you can even just also go in if you wanted to change something in that.

You can go in and edit it.

And the network will still work because the protocol itself, just peer-to-peer, is simple and super strong.

So very powerful.

But we also, we used this opportunity when we were making this to have it be audited by other people.

So we also got a security auditor on it also that we'll be publishing with the app and stuff like that.

That has been a good experience for us just to try to think through these questions that you say also,

how can we make this feel comfortable to everybody and make it powerful?

But it's really interesting to think about it that way.

Because even me as somebody who's, again,

understand the powers of encryption and stuff,

I think just having it sync with myself is really powerful.

I think that's a good redundancy factor

in how I can be very comfortable with these things also.

And the cool thing about a peer-to-peer network is

you can do that while still having the comfort

of a normal syncing system, if you know what I mean.

I'm a big, big fan of KeePass, as you mentioned,

but it can be a little bit cumbersome with the setups

because that's basically the future.

I moved away from it.

Yeah, but it's basically, and it's not to say anything bad with it, because it's basically a feature of it.

It's just, that's why it's so simple and powerful.

But it's like, you also want to have this like, oh, now I got to switch my phone and stuff like that.

So the combo is needed, I think.

It's actually quite interesting, because, you know, unless I started using a centralized cloud provider,

like if you just do manual syncing on your device using something like Dropbox,

the cleanest experience I ever had with KeePass was using SyncThing,

which I believe, I know it can work locally in your network,

but I believe also has some kind of peer-to-peer aspect,

if I'm not mistaken.

And so you're essentially just making that all-in-one

into the same password manager

and kind of adding in the P2P side of it directly in there?

Yeah, and I think it's actually a really good analogy

because basically instead of just saying,

hey, let's have things produce files

and then sync them with some file-sharing network,

What we're saying also with the peer-to-peer stack is saying, well, let's go a little bit deeper.

So let's make the infrastructure in the apps do this, right?

And then just have developers have the tools to make applications.

So if you look at the software for Pear Pass, you'll notice that it's not really peer-to-peer.

It's just kind of like interacting with a database, putting things in and out.

And then the software then helps make that peer-to-peer after.

So I think why that's really cool is kind of like the same idea you just described there.

You just make an app.

You make it look pretty.

You make it look simple.

and have it work locally and then let the peer-to-peer magic do its magic

and have that make it multi-device and stuff like that.

And that's where it gets really powerful because for me,

that just shows you that anybody can do this

and you don't have to have a PhD in networking or anything like that

to make these very powerful distributed systems.

So that's where I'm like, outside just having a really good password manager,

which is really needed, I'm just personally very, very excited.

Yeah, and I like that as well because I know I had this issue as well in sync thing where sometimes something wouldn't sync fully.

And then I had something that would be corrupted or didn't sync the latest version.

And so I feel like having everything being run in a similar environment would actually make a lot of sense.

I'm sure also just to finish on that thought, because I'm sure also in an environment like that, if you had, you know,

in something like a password manager where I have passwords to share with my wife and family and stuff like that for like joint things.

So if you have kind of like a Jerry Rick solution, like syncing things like that, those passwords

would get out of sync really fast in a system like that.

So you need to have some technology that does this magic on that also.

Nice.

Yeah.

And then a couple of questions here.

I guess this also applies to Keat.

Is Keat audited?

And do you guys do consistent audits or is it just a one-time thing?

So Keat is audited actually indirectly through this pair pass one because like I said, like

literally 99% of the code is the same, right?

So that's obviously stuff.

So you're auditing the stack, not the individual product.

And in Pear Pass also, we also ordered the product, but we explicitly went in and said, hey, we want to do an audit where we get into the mindset of doing it on the full stack because we want this to actually learn also.

And we said very explicitly when we did it, we want to know the issues.

We're not trying to just get a stamp.

We actually want to see if there's any issues.

Luckily, it went really well.

So that's good.

But even if there was something been flagged, that would have been success also because we're just trying to build the most secure product out here.

Yeah, we want to do more ongoing reviews as we build things out.

As anybody who's done intense deep tech will tell you,

like doing an audit too early will be counterproductive

because then like the next week you're like,

well, all that is gone now and like here's the new version.

So we had to get to a sense of like this is very stable now

and we can do it.

That's something we've reached in the last couple of years.

So it's been very, very good for us, but definitely 100%.

Great.

And then I just wanted to verify you guys are also on Linux on both of those.

We are on painfully many ones.

So we are on most of the Linuxes, like the various distors,

which as anybody who's working with Linux can tell you,

sometimes it gets a little intense.

Yeah, I mean, it's...

I can't...

I actually get very frustrated by it,

and I wish the Linux community would have some simpler way to manage this

because I can't even be mad.

I am mad, for the record.

I am mad, but I can't very easily publicly be mad

at companies, organizations, I suppose, like Signal,

because Signal just publishes a DEB.

That's it.

Yeah, I was going to say that's also the same thing to do.

Yeah, and it's like, oh, there's this unofficial community flat pack

for an end-to-end encrypted messenger.

Like, okay, I know it's safe.

It's been there for a long time, but I'm not going to use that.

Like, that's just, like, I care a lot about where my software comes from.

I like to verify, like, the hashes of where things come from,

And so I'm not going to trust just some unofficial community flat pack.

So it is a problem.

And I'm glad that you guys are doing more than one thing, even though it's probably a pain in the ass.

So it's interesting you say that because we try to solve this not by making another app store on Linux,

because then they would have four app stores or whatever.

But we have, so when you make like a pair app, which is what we call the peer-to-peer apps,

that's why everything is called something with pair.

Like I said, it's using 90% of this, between 90 and 99% of the same code always.

And we have now tooling that targets all these different app stores and stuff.

So that's how we distribute Keet.

It's just like, it's a general pair app.

And then we have a thing that produces whatever it needs to be in the Snap Store and an app image,

which is the old way and a flat pack that I don't know if we publish it, but we're going to publish and stuff like that.

But any kind of app built on the platform can do that

because an app in a peer-to-peer network

is actually just a cryptographic identifier of the app

and then the rest is pulled in by the network.

So if you're building and targeting things like that,

it actually can be really cool to do with peer-to-peer

because you get a lot of stuff for free.

It's almost like how when you make a website,

you don't really have to think so much about browsers

because you just know they exist.

And if you just have the link, it works.

That's kind of like how we're trying to do it

for peer-to-peer app development,

but it's also for native apps and stuff like that.

Kind of zooming back out a little bit and bringing everything together.

So I had a couple of questions come up as we were going.

So what are your thoughts on just companies in general who use P2P, but in a kind of hybrid, still centralized way?

So various examples, you know, some you did mention games earlier, but I still see it to this day how some Steam games will use peer-to-peer for app updates.

And actually, sometimes that can cause issues for people and they have to do things on the router.

And I'm sure that's a mess there.

But also even messengers, WhatsApp still has P2P for some calls.

And also Telegram does this, Signal does this.

A lot of these companies kind of pick and choose where to use P2P technology.

Do you see still an issue with that?

Do you think it's still good that they're embracing P2P in different places?

Or do you think a pure P2P approach is kind of the only way forward?

So I don't think there's a way to use P2P strictly wrongly.

It's a set of tools that you can kind of pick and choose.

I think the way I would describe most of the ways you said there,

to some degree or at least the vast majority of them,

is that it's cost optimization games.

So the reason why a lot of people do calls peer-to-peer

is because it's just very bandwidth-heavy to do a call.

So if you just put a dollar amount on what recording this podcast costs

in terms of bandwidth, it would be something that's like,

not bankrupt us, but it would be something where you're like, oh, that's interesting.

So there's some things where you just realistically have to try and do it,

and that's why a lot of people do it with calls and stuff like that.

The flip side of that is, I think, is that when you go extreme with it,

that's where the interesting things happen.

It's kind of like when you don't just do it for cost optimization,

but also start doing it into this unregulated, in a good way,

fusion of an app that can do all kinds of things that is like truly unscalable and unstoppable.

Then you start to think about this like cost of optimization in a whole different way,

like a concept before where like, well, if nothing costs anything, because everything

disappeared, you can also think about products in different ways because you can add interesting

things like why is, you know, a lot of services when I upload a file, it will be like, well,

it has to be 30 megabytes and everybody kind of just accepts that it's 30 megabytes.

And when I email something that's too big, my email will say, you can't do that.

And often you can even pay for it and it will be like, you still can't do that.

That's just kind of like this Stockholm syndrome we all have with centralization where we can't just say, oh, yeah, that's true.

And I guarantee you, I can even ask my parents, they will say, well, that's just how it is.

Because we're not thinking about this technology in like this unhinged way, which we need to do.

So once you start to go down the road, I think just much more interesting things start to happen.

And you just think about products in a whole different way.

And you also think about products in a way that's a bit more scary for companies, I think, to some degree,

because it's where you quickly optimize yourself out of the equation, which is why a lot of people don't do it.

Because if everything is distributed and peer-to-peer, then why do you exist?

Because the app can just, like I said, keep existing if you go bankrupt.

So yeah, but I don't think there's a wrong way of doing it.

I do think a lot of the stuff, messing around with your router and stuff,

is just because it's kind of tagged on and not fought into as a pure thing.

That's kind of where the technology starts to bubble up to the user.

That's not so good.

and there's like plenty of ways if you do like peer-to-peer right where you can avoid that but

yeah for sure you know are there any downsides especially you know when i think about in the

context of signal um one of the criticisms of signal is and telegram and whatsapp they all do

the same thing by default they do opt you in to this peer-to-peer aspect which also means that you

are exposing your ip address to the other person when you're doing a phone call and so if this is

something anyone's concerned about, you can just go into your signal account and just

toggle it on to always proxy it through the server. But my assumption is you can't do that with

something like heat or do you now have to use other P2P technologies like Tor and other things to

protect people's IP address? Yeah, P2P networks obviously inherently mean that we're connecting

to each other so we can, in some of those cases, see each other's addresses and stuff, also some

others. But I think it's one of those things where there's plenty of tools out there that are

pretty good, that layer pretty well, including VPNs, which are a good way

if you're very concerned about that, or even just normally concerned to

limit your exposure to anything. I would say

this is what I tell people also, or what I tell my parents,

if that's something where, in the context

of how you're using the apps and products, it's something you should be thinking about

in general, not pick and choose your features. I think that's a little bit dangerous.

So basically, if you're generally concerned about that, always use a VPN.

Because you're going to have IP exposure in the way you can't even imagine.

And it's kind of like it doesn't take a lot, you know, like tracking pixels, whatever, and things like that.

So in general, it's a good idea to be thinking about these things online.

And it's like there's plenty of scalable things.

We actually have a side project.

We're also working on a little peer-to-peer VPN for the same reasons because it's also a cool way to do it.

The opposite side of that is like in a P2P network,

you have more control.

So you can kind of like, for example,

when we talk about pair paths and stuff like that,

a network where you're sharing with yourself,

I would never think about it personally

because it's kind of like I'm just talking to myself.

It doesn't matter.

And like chat rooms with my family and stuff like that,

I also don't care.

And also me as a, you know, right now,

you can just kind of see my office and stuff

and we talked about where I am.

It's also like different kind of concerns.

So you kind of like, you know,

you need to use your brain a little bit,

but in general, there's plenty of really good tools out there.

like VPNs to ensure just that this is solved for everything you do online, which you should

be thinking about.

It's kind of like a consequence of how the protocols of the internet work, I guess.

Yeah.

So if two people are using KEEP, by default, they can see each other's IP address.

And then if they're concerned about that, then use a VPN or proxies.

Yeah.

I didn't mean not to say that.

Yeah.

So basically...

No, no, no.

I didn't really ask that.

The people you're talking to in a room could probably see your address if they knew what they were doing.

There were also plenty of ways in P2P networks where they don't have to do that.

Because actually in a P2P network, you don't have to connect directly.

You can do stuff where you route traffic through other people.

So you can build these crazy protocols that you want.

That's pretty cool.

So you have all the options.

But again, it's good to think about it in that way.

And there's definitely always a chance, depending on how the technology is put together.

So, yeah.

A very random question that came to me as we were talking is Apple's Find My Network, which uses Bluetooth between devices, technically P2P, or is that mesh? Is mesh different from P2P? Or am I?

So my definition of peer-to-peer is pretty broad because I think peer-to-peer to some degree is kind of like saying you, instead of relying on where data lives at a destination point of view, it's kind of like, you know, when I go to google.com, I'm putting in the destination, like the address of google, google.com.

And it's implying that I'm going to Google's server and doing something.

So that's not peer-to-peer for me.

But as soon as you take that coupling out of the equation and say,

it's not about where it is, it's about what it can prove,

then things start to become peer-to-peer for me

because then the rest, by definition, kind of comes from there,

like direct connection and stuff like that,

or even not because it doesn't matter.

So I don't know if Apple put on a bunch of specs on how that actually works,

but it's actually hard to answer.

The TLDR, as far as I don't know, I'm not an expert on this, but essentially any person with an iPhone that has Bluetooth on, their device is opted into this network.

And that's how AirTags work.

Because AirTags don't have GPS chips on them.

And all they have is a battery.

And it essentially is always pinging to see if it can find a phone.

And then that essentially functions as a way to track that device.

I would imagine that Apple does a bunch of cryptography things like that to try to make that private.

Yeah.

Generally what they try to do.

It's somewhat privacy respecting.

Yeah.

So I would, that's definitely a mesh network.

And I would also say, for my definition,

that's some, you know, variation of a P2P network in that sense

where, like, that's probably just a proof that it came from that device,

not where the device is address-wise.

So that's interesting.

I think it's also just worth noting on that, like,

for the same definition, you can also build not a centralized systems,

but you can build systems in the P2P world where, you know,

there is like a service running somewhere that you contact as long as you just, again, contact that

through some way where the service describes, you know, this is my data or like this is my

authentication versus like my address. So you can put all kinds of cool effects with that. But yeah,

sounds within the target, I think. Yeah. And I might have gotten some details

wrong. So if somebody wants to correct me, please do. I wanted to ask about environmental differences,

Because there's a lot of talk about centralized servers, especially now with AI.

And I'm seeing a lot more headlines and news coverage that even though we were finally moving in a renewable direction,

and we were saying, well, yeah, renewables are great.

We're starting to see coal uptick again because of a lot of the heavy demand that we're seeing for things like AI and these data servers.

So what's the environmental footprint difference, if any, with a peer-to-peer network?

Since it's distributed across many people, I guess I could see it going either way.

You know, if it's distributed equally across many people, maybe then it's lower energy usage.

But maybe having it centralized where things can be hyper-optimized is also better.

So do you know about this?

Is this something that has been studied at all?

I'm sure there is studies around the actual details of it.

I can't remember the exact things.

Also, I recently, it's actually funny because just before this call, somebody sent me an article about how much compute,

on average, like an AI generated image burns today and like put it in,

put it in context of like kilometers traveled in a car. And this,

I mean, I knew it was energy consuming, but it's surprisingly eyeopening.

But yes, definitely stuff to do there for whoever's working on that.

PHP networks is like, you know, by design,

cutting out the middleman pretty optimal because like you can build networks

where, especially in these kinds of environments,

like a chat where a lot of chat at the end of the day is very physically correlated also, right?

It's kind of like you chat a lot with your family.

Your family tends to be in the same places.

Cities have networks also, like your friends are usually in the same cities.

And then obviously there's these exceptions where you do these long random jumps everywhere.

But like things tend to be very clustered.

So just kind of like in terms of compute needs to be burned,

that network is very, very efficient.

Because again, we have the devices already.

And the device is already running.

And it's like, I've had people, especially in the early days of P2P, ask me concerns about like, well, if it's encrypted, then, you know, we need to run the encryption on the device.

And that sounds expensive in terms of energy and stuff.

But then when you're talking to servers today anyway, it's also in-flight encrypted because that's kind of like where the world moves.

So we're doing that anyway.

So it's actually the cost today is really, really small, as in like comparable on the transport.

but then we don't have to transport both not very far

and also not a lot because we try to be efficient.

So it can be built incredibly energy efficient,

which is really, really important.

Now, totally consider, I actually don't know the data on that.

There are some things that are obviously,

when you do it like big scale, it can be better,

but it tends to be more big compute things.

But also, like I said, you can also build variations

of P2P networks where you have services to do more.

So I think in general, you can just build P2P networks

in a way that can be extremely energy efficient

in a way where you just can't do it with centralized solution

just because the implication of the centralized solution

means that the stuff has to travel back and forth

and you need to have both the end devices

and the big things and stuff like that.

Whereas P2P just gives you more options.

But again, you can do variations of that,

but you can definitely make it very, very energy efficient

because otherwise also we couldn't do it on device.

So super, super interesting.

But I think it's also worth thinking about,

and we didn't really talk about that,

but also just in this context of like energy efficiency and data traveling,

even more than that also,

it's kind of like when things break,

like cables break or like, you know,

there's a natural disaster somewhere,

you know, the power goes out.

You really want these things to still work, right?

And so it's kind of like peer-to-peer is the only way for that

because otherwise this weakness also makes it very centralized,

just stops things really fast.

And there's been countless examples of that recently.

So, yeah, definitely.

Yeah, it seems like it just democratizes energy and accessibility a little bit more than a traditional system.

Yeah, we have tons of batteries over on our devices.

And if you ever looked at how much, it's actually a very interesting metric.

Because I remember I drive an electric car and at one time I was charging and I was kind of thinking,

I wonder just from a naive thought, how much power does my phone use compared to my car?

And then when you looked it up, you're like, holy moly, like your car is just like a bajillion times less efficient, a lot efficient by consuming.

So like running our chat app distributed is just so much more efficient than doing anything else in the world.

So like, yeah, 100%.

Yeah, I guess the final question.

So when Elon Musk goes on Twitter and says, hey, go download Signal, Signal goes down for hours because of the overwhelming number of people.

So if that were to happen to something like Keat, I assume, would the inverse happen?

Or would it just be stable?

Does the network get stronger when more people join?

Yeah.

So, I mean, it's like, the short answer is yes.

Like I said, we just recently had a big influx of users.

It's been very interesting to see because the things that were actually the hardest with having a big influx was just like we have some public rooms that started being very, very active.

So just kind of like the app was working, but the chat was running really fast.

So it's kind of like it's not very useful to be in that room, you know what I mean?

So it's kind of like there's a lot of these UX things we tend to forget sometimes that we're working really hard on.

But in general, yeah, it's like the network scales up as no people join.

And I tend to sleep pretty well at night thinking that because that makes my life a little bit easier.

It also makes it a little bit harder because it never goes down.

So there's very few breaks when you're like trying to do stuff.

But yeah, that's the future, I guess.

Yeah, and so if people want to check out what you guys are doing and try it out for themselves,

or at least look into the code or something like this, where can they find you guys?

So we have a website, like I said, our only website, two websites, sorry.

We have KID.io, which is our chat app, where you can go check out the chat app.

We have a bunch of very active development rooms on there also that's linked when you start the app,

so it gives you a suggestion to join these public rooms.

We have a lot of developers hanging in those and helping people building things

and just people sharing all kinds of crazy things. It's really fun.

So kit.io for that.

There you will download the app.

So you only go to the website to get the app

and then you'll be in the P2P network after that.

And then we have pairs.com like the fruit,

which is where we have our general development documentation

for our runtime.

And also we have a link there to pair pass.

And that link for that is pair pass.pares.com

or is it pass.pares.com?

I can't remember.

But it's linked from there and go check that out.

It's super cool.

And like I said, I'm on kit 24-7.

That's the problem with the peer-to-peer app

because it never shuts down,

because it never goes down.

So you can also ask me all the questions on there.

I'm very active on there as well.

Very cool.

All right, well, I'll leave links down below.

And I want to thank you for your time.

And it's been very interesting.

I don't think I've had anyone

who's talked about peer-to-peer tech

on the podcast yet.

So thank you.

Thanks for having me.

And that is the interview.

I want to thank Matias for taking the time

to explain a little bit more about his life,

but also the services he's working on,

as well as what things probably look like

for other messengers out there as well.

I want to thank you all for listening

and empowering yourself

by learning more about the services you use

and how they work

so that you can make better decisions

for your digital freedom.

I also wanted to ask for your support

in making these podcasts happen.

These podcasts are currently unsponsored.

We don't really have a real revenue model for them

outside of ad revenue.

And so if you like what we're doing

and want to see it grow and continue to expand,

you can do that by supporting Techlore.

We have free ways to support us

down in the description

as well as paid ways

via becoming a Techlorian.

Becoming a Techlorian comes with really cool access

to certain perks that we've developed for all of you,

and you get to support our mission in the process.

So check that all out down in the description,

and I'll see you all next time on Techlor.