The Messaging App With No User IDs (SimpleX Interview)

SimpleX Chat is the only messaging network where users have no identifiers—no phone numbers, no usernames, no user IDs at all. Henry interviewed founder Evgeny Poberezkin about how unidirectional message pipes create a network where servers don't even know users exist, why this isn't federation, how it compares to Signal and Session, and why the company is based in the UK despite encryption battles.

🔗 SOURCES & LINKS
• SimpleX: https://simplex.chat
• Evgeny's Website: https://www.poberezkin.com/about.html

⏱️ TIMESTAMPS
00:00:00 INTRO
00:01:31 SIMPLEX NAME
00:04:20 SIMPLEX TEAM
00:05:10 SIMPLEX VS. MAINSTREAM MESSENGERS
00:08:05 WHY THIS APPROACH?
00:11:14 THE FUTURE OF SIMPLEX
00:14:28 SIMPLEX NETWORK + FEDERATION
00:20:46 REGISTRATION MODELS
00:23:11 GOVERNMENT REQUESTS TO SIGNAL
00:25:42 REGISTRATION MODELS (CONT'D)
00:27:52 MESSENGER DISCUSSION?
00:29:54 SIMPLEX LIMITATIONS
00:31:00 WAYS TO USE SIMPLEX + SCALING
00:37:27 OPEN SOURCE
00:42:21 SIMPLEX ENCRYPTION + DENIABILITY
00:54:00 SIMPLEX METADATA
01:00:53 IP ADDRESS OBSERVATION
01:05:02 USABILITY CHALLENGES
01:09:53 MESSAGE DELIVERY
01:10:58 OUTAGES
01:13:14 MULTI-DEVICE SYNC
01:13:56 DESKTOP ONLY?
01:18:10 BATTERY IMPACT
01:19:44 BACKGROUND SYNC
01:21:50 FUNDING + SUSTAINABILITY
01:30:38 JURISDICTION
01:31:56 LEGAL + LIABILITY
01:40:37 PRIVACY AS A MEANS, NOT AN END
01:41:55 PRIVACY FOR THE MASSES VS. THE FEW
01:45:27 WHAT'S NEXT FOR SIMPLEX?
01:50:57 HOW TO FOLLOW
01:52:09 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

Evgeny

SimpleX Chat

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.

it's very dangerous for people to have an illusion that nobody observes their IP address. There will

be always that somebody, they have a choice of who this somebody is. Hello everybody and welcome to

Techlore Talks. Today I'm really excited to have Evgeny on who's the founder of the SimpleX chat

platform but it's also more than chat as we'll talk about a lot today. He's going to talk about

the decentralized network and how it works, the privacy and security implications, why this

decentralization exists and how it's different from other decentralized models, usability challenges

multi-device functionality. Pretty much, if you've never heard of SimpleX, or even if you have heard

of it and you want to learn a lot more about the nitty-gritty details, this is the place for you.

Of course, we're going to zoom out a bit too and touch on the broader implications of privacy

technology in society and the challenges faced by developers in navigating the legal landscape.

One small disclaimer, Evgeny does reference other projects like Session and Signal quite a bit,

and this interview was recorded a couple months back before things like Session's V2 protocol

concept was released. So please keep that context in mind as Evgeny covers it. And now to the

interview. Welcome to Techlore Talks. I've been meaning to have you on for the longest time. Do

you want to introduce yourself and say a few things? Hi, Henry. Thanks a lot for having me

here at your show. I'm Evgeny. I'm the founder of SimpleX Chat that many people believe is the most

private and secure messaging network. We've been working on it for almost four years now.

So, yeah, so like I think everything that happened with me before is not so interesting.

Got it.

Yeah, so when I put in SimpleX into my search engine, sometimes your Messenger does not pop up.

So do you mind explaining the name of SimpleX and the origins of that and the branding?

Sure thing.

So we came up with a novel design for the messaging network long before it even started as a project.

It was probably late 2019 when this design emerged.

The idea was to create a communication network when people can connect without having an identifier on the network.

That kind of flips the traditional network design completely upside down to the point that when I was kind of explaining the idea to many even technologists,

they were saying, man, you must be lying.

It's just not possible because you need to some identifiers to connect to people.

And the reason it got SimpleX name for two things, right?

So first, it's simplex means unidirectional as opposite to duplex, right?

You know, like all those old ham radios when you have to press a button to talk and it

transmits signal only in one direction.

And also high security networks are also designed as unidirectional network when the data can

flow only in one direction.

So the whole network is constructed from rather simple messaging pipes or queues that can

only transmit messages in one direction.

And to have a conversation, people

have to have two of those.

And literally every single connection of the network

is constructed from two of those pipes.

And they can use different servers, actually

a pair of different servers each.

So yeah, so that's where the name simplex came from originally.

And then we made a pun on simplex because simple

is probably the simplest message queue design

I've seen comparing with the existing message queue designs and also X for secure.

So that was the origin of this name.

Very nice.

And yeah, for people who looked it up, I went in there.

It is not the crypto thing.

It is the SimpleX Messenger.

That is just to be precise because I...

Correct.

We call it SimpleX Chat.

And it has nothing to do with SimpleX Cryptocurrency, even though some people get confused.

And many people say, when on earth are you going to change the name?

And a small hint to the future, this will happen, obviously.

And SimpleX will remain as a name for the underlying network.

But we're going to consider, kind of have a good candidate for a new name for the opt-in mail-in.

Got it. No, I definitely want to touch more on that.

Because it sounds like, to myself and many people, when I say SimpleX Messenger,

it's kind of just all one thing.

But it sounds like it's a bit more nuanced than that.

So I definitely want to touch on the architecture side of things.

Before that, what's your team size? Where are you guys based? What's your structure?

We have a very small team. At the peak, we had six people, and currently we have four people in the team.

So we're trying to be as lean as possible without any single geographic location for the team.

Everybody is in different places, which we're not advertising.

I'm personally in the United Kingdom. The company is registered in the United Kingdom,

which draws lots of criticism for, which I disagree with strongly.

We can talk about it if you're interested.

We can talk later about that.

So I think I honestly agree with the view that was recently published in some post

that jurisdiction doesn't really matter if the code is open source

and the network is decentralized and nobody should care about where this is all happening.

Got it.

And so, you know, to someone new to this podcast,

before we start diving into the technical stuff,

Just very quickly, what would you define as the core difference between your messenger and just a typical mainstream messenger, something like WhatsApp or Facebook Messenger or even Telegram?

We don't even see what we built as a messenger, to be honest with you.

We created a new network topology and designed for transmitting messages over this network topology.

But messages is a building block for any internet application, right?

And it doesn't matter what it does.

It can be access to content.

It can be communication.

It can be any commerce activity.

And we just wanted to build the fabric for those applications,

which would allow people to build decentralized applications

that can work over the internet,

providing people out-of-the-box authentication

so you know who you're talking to.

If you connect it at the same time,

providing them security from the network operators

so that while users have security and authenticity between them,

the network operators don't really know who uses their network

and they shouldn't know that

because otherwise that undermines security of the users.

And that's a fundamental difference.

So we're not a platform

and they're not a messenger and they're not a service.

We created an application that philosophically is the most close to the web browser.

Currently, there is only one new generation of application which we develop,

but it doesn't mean somebody else can't create this application

and connect the same network using this application.

And anybody can run the servers and anybody can have conversations or communities or channels.

And currently, the biggest development that's happening right now is robust support for large content channel or large communities, which was the biggest point of criticism because the network wasn't built for large communities.

So, yeah, so I think fundamental difference from WhatsApp or Telegram is that they own everything.

They own the users.

They own the content that users post.

They own the conversations.

And they can do what they want.

And with us, we see ourselves as technology providers.

We don't own the content.

We don't own the users.

We are developing technology which people can use to create

and to have conversations between them, to distribute content between them.

But our role here is effectively a user agent.

The browsers are called user agents.

So something that allows users to connect to this network.

and we develop client software and server software,

but we do not see ourselves,

and we are not a service provider on this network.

Got it.

So why have you taken this approach then?

But what do you feel like is missing from the space?

Like, what's the value that this brings a regular person that you're seeing?

Well, open web is the only decentralized network design

that really managed to become mainstream,

And open web is still to date remains the network design, which gives its users the largest amount of freedom.

How can they use the network?

Right.

You don't even think about it as a web.

For most people, web is Internet.

Right.

And when they use the browser and go to some website, this website can do anything they want.

I mean, not any specific website, but generally the web as a network can provide any sort of utility, right?

It's not seen as something to access content on, right?

There are social networks that run on the web.

There are commercial sites that run on the web.

And there is no limits to what people can develop using web as a network.

But web has kind of reached limits in its development because of bureaucracy, because of lack of vision for what the web should go further.

And we see more and more than the web is being replaced by large centralized applications.

And a lot of user activity is now centered not around the open web.

And they control, like you remember the old days.

I do remember the old days.

You create a website.

You're a webmaster of this website.

You control this website.

You own this website.

You have 100% ownership of what happens on this website.

Yes, it's very basic.

It's rudimentary.

But you own everything you put there and you own connections with people who come to your website, right?

And now if you create a community on, you name it, Facebook, Discord, Twitter, whatever, right?

You don't own this community.

The platform does, right?

You can do only what platform allows you to do.

This platform can take it from you at any point.

That's what we want to fix.

We want to build a network when people own what they create,

when people own connections with the users which they create,

which gives them exactly the same utility they can get from Facebook

or from Twitter or from Discord,

but without surrendering ownership to content that they put there

and without surrendering ownership of the connections

with the users that they build.

It's effectively, I've been saying to my supporters,

investors from day one, like that we're not building a messenger, we're building the next web,

the network that enables connections between people, the network that facilitates distribution

of content and information in the same way as the web does, but accounting for evolved

expectations and requirements, because we don't want to author HTML anymore. We don't want to just

publish documents. We want to exchange messages. We want it to be much more interactive and instant,

right? So you can think about it like new kind of instant web. Yeah, so okay, I'm getting it,

but it's not very tangible to me and probably some people listening. So can you maybe just give

a short example of what a day in the life might look like for me if, you know, looking 10 years

ahead, if the SimpleX network is widely adopted, how does this look? I don't know. Honestly, I have

I don't know what 10 years from now it will look like.

The closest thing that you're describing to me is if I want to host a website on OnionShare.

I open the OnionShare desktop app, I load all the HTML documents there,

and then it's kind of going through, it's Onion-routed, it's decentralized,

and then someone else via an OnionLink can access my website.

But how is what you're doing different for that and definitely hopefully more streamlined than that?

Correct. We don't want people to be technical to be able to build those communities. We want to provide people some composable primitives to construct the point of presence on the internet. We can call it site, right? So for example, your site can be just your channel, right? You publish your posts there daily or hourly or weekly and people can come and read them and people can come and comment there. So it's indistinguishable from your Twitter feed.

And how would they access that? Is that accessed via the ClearNet or do they have to have something that utilizes like a SimpleX protocol?

We're actually going to offer both. And when you say ClearNet, SimpleX, we're not sure what we call ClearNet, right?

So yes, it will be something that utilizes SimpleX protocol, but we are going to offer option to the owners of the channel to make them viewable by the browser.

So let's say if you created a channel and you wanted, like, because there are pros and cons, right?

By making it viewable via the browser, you get more people access your content, but you don't know who they are.

You don't have any feedback loop with them.

They can't comment.

So some channel owners may not want it, right?

Some channels owners may want to only offer a preview of the channel and say that you have to join via this app to connect to this channel, right?

So what we are saying is that ultimately the owner of the content or of the channel or of the community should make 100% of decisions.

What is the user experience of people who come to this community?

Do they want it to be just a stream of content?

That's fine.

That's really possible.

Do they want it to be a group and people can participate and comment?

That will be possible.

Do they want it to look like multiple rooms when they can have multiple conversations, which may be interesting for large communities, right?

If your community is over 100,000 members, then you probably don't want them all to talk in one room.

You want to offer them some variety of ways they can consume information and engage with each other and with you.

So what we will give people, you can think about it's like a modular constructor to put these elements together and make it look.

I think the closest analogy you can think of is a Discord server.

but with 10 times more flexibility about how the user experience will look like for people who come

to you. Got it. And so that's if I look in many years ahead. Yeah, yeah, yeah. I assume so. And I

definitely want to touch on, I guess, timelines for things and what the future looks like. But

when it comes to the architecture, and then kind of the federated aspect of this, how does the whole

relay server model actually work? I think I think federation is the wrong term here, because

Federation is, by definition, is a unity of multiple networks, right?

So to federate, you have to have multiple isolated networks that decided to connect with each other.

And that happens if some owner of the server or some operator has multiple user accounts,

and they can all talk to each other using this particular server, right?

And the network is not federated yet.

And to make this network federated, there will be some other operator with its own users,

And then they can allow users of each other to talk to each other.

And that's what we call federation.

But each of the server owners, they own their own cluster of users and conversations.

And they can decide to leave this federation or join this federation or to restrict federation with some operators.

And we see how it leads to actually more censorship in federated platforms than in centralized platforms.

If you compare the level of censorship in Mastodon, it's stronger than in some centralized platforms,

exactly because censorship decisions of multiple operators of Mastodon multiply each other.

So if I own the server, I can decide to censor my users, but I can also decide to censor users of another server,

and I can also decide to censor the whole server if I want.

So in a way, while the federated model kind of promised initially more freedom of speech,

it de facto resulted in less freedom of speech than some centralized platforms.

Just because moderation decisions, censorship decisions of different operators, they compound with each other, right?

They add.

Yeah, I guess it depends on the definition of freedom of speech because that can vary a lot.

I know some people's view of freedom of speech is that it's just from the government.

And so by their definition, actually, a Mastodon person deciding how they want their platform to be run is actually a perfect use of freedom of speech.

But I can understand how to a user in terms of whatever they say, they don't know if it's going to be blocked by the platform or not.

Federation gives them actually a little bit less control than some centralized platforms might.

Exactly. So what we did is not federation by this definition.

we see operators, server operators, as there are no user accounts, right?

And the user is not attached to any particular server.

From the point of view of the servers, users don't even exist.

All servers know about is this small dump unidirectional pipes that transmit messages.

It's user devices that know which pipes to use to reach their contacts,

to reach their friends, and to reach their communities.

And the user devices know how the network is organized.

But server operators don't know any of that.

They simply provide the messaging pipes.

And currently, like if I talk to you on simplex,

we'll have one messaging pipe, depending on one operator.

And that obviously creates some problems with reliability,

because if the server goes down, then we can't talk anymore,

et cetera, et cetera.

So we obviously plan that it will be, A, using multiple servers of different operators and also automatically rotating them to create reliability from any technical malfunctions or from some unreasonable censorship decisions.

So I think it would be fair to say that the design we're moving towards from the very beginning would be closer to Nostra design, which is also not federation.

So rather than choosing which server to publish a content on

and then let servers design decide

how the network should function, right?

That's the federation approach.

It's effectively the network of servers.

Nostra takes another approach.

You as a user decides which servers to use

to publish a content to

and the network is formed by the users, not by the servers.

And the simplex has similar approach to network topology

when it's users who decide how network is structured

and not the servers and servers don't even know about how network is structured because all servers

see is connections but they don't see the nodes of the network right they don't see how those

connections organized are into the network and the users are free to rotate change operators use

multiple operators at the same time so effectively we want network operators to be a disposable

redundant portable commodity right that you bought you can buy off the network or there may be some

free capacity allowance to you but you effectively buy it as network capacity rather than as a service

from a particular company so you you don't necessarily choose one company like if you use

email you have to choose a mail provider right if you use mastodon you have to choose your mastodon

provider right if you use master you don't have to choose which master provider you use because you

multiple and simplex has similar approach to the design you're not choosing which network provider

to use because you you can choose the long list of them to use and use them all at the same time

and some conversations will use one operator some other conversations will use other operators

and the future will look like each conversation will use more than one operator concurrently in

parallel to provide redundancy it's already using multiple operators today right so like because

There is direct messages, response messages.

They would use different servers of different operators already.

But in the future, there will be redundancy and message pass.

And every time you send the message, it will be sent via several channels to ensure that it reaches the destination, even if one operator has malfunction.

Got it.

And so to make this more tangible to especially myself, but I'm sure some people listening as well, can you maybe go through the different models?

Because right now, you know, it's pretty confusing for people, especially if they're not more technical.

Do I use Session? Do I use Signal? Do I use SimpleX?

So can you kind of walk through very, very briefly?

Like, we don't need to get super thorough into each one.

But what does the model look like when someone registers for Signal?

And how does that compare to Session? And how does that compare to you guys?

What's actually going on behind the scenes?

So, look, Signal has managed to build a fantastic product that everybody uses as inspiration.

And they designed a cut-on-edge protocol algorithm for end-to-end encryption called also Signal, which people obviously confuse with Signal, the product, right?

But the Signal protocol remains state-of-the-art in end-to-end encryption, provides some very important qualities, right?

And we use it as well.

We also use Signal algorithm.

We have slightly different approach to post-quantum encryption.

think what we do is a bit more secure than what Signal does, but Signal recently improved and

caught up to a slightly better level. So when you go to Signal, you know what you do. You provide

your phone number, right? And Signal verifies that you're the owner of this phone number,

and they create a username for you, and that creates your account on Signal. And when somebody

wants to connect to you, they have to go to Signal servers. They can't go anywhere else.

And Signal would effectively see inevitably, because that's how a network functions, who connects to whom and how often messages are being sent.

At some point, Signal introduced the interest in cryptographic scheme called sealed senders that was supposed to hide information about who it took to whom.

But long story short, it doesn't work.

I mean, it is not providing protection on all system layers.

It only provides protection in a specific component, but not in the system as a whole.

And it also is vulnerable to statistical analysis.

So I would strongly, I can comment more on that if it's interesting to somebody.

But generally speaking, we should consider that it's not something that really works or

provide any meaningful protection.

So fundamentally, Signal knows what's your phone number and knows who talks to whom.

So while Signal provides very strong content privacy of your messages, Signal does not provide

protection of your conduct from itself and from any parts that may get access to signal information.

Just a quick note there before we move on to session. How come if a government, you know,

asks signal for what they have, they only give two pieces of data?

They might not hold on it. I don't quite understand was there a compliance requirement

and for how long they are supposed to store this information. But if they diligently deletion this

information if they're sticking to their privacy policy then they obviously would not be able to

provide this information on request it doesn't mean that anybody who compromised signal can't

access this information it doesn't mean that some malicious parts inside signal can't make a

recording of this data we're talking about possible attack vector it's not about what actually happens

so i i do strongly recommend people in many cases use signal we use signal as a fallback channel if

something happens with our servers right so signal is objectively is one of the best products out

there because of its like longevity because of how long it was developed because of how much money

was spent on developing signal so i certainly do have very strong recommendation to use just but

people have to be realistic if they if they do not want their communication provider know who

they're talking to which may be very important for a large category of people for different reasons

then they shouldn't use Signal, right? Or for example, if people do not want to be reached via

Signal, because Signal allows to reach out to any user who you know the username of, right? Or the

phone number of. And you know what spammers do, they just guess, right? You don't need to know,

you just send messages to multiple numbers, some of them respond, and then you can build various

scams or attacks or whatever, right? So simple accent comparison makes it an option. You can

create an address, a public address that multiple people can connect to, but it's an option. It's

not a requirement. You don't have to have such address. And even if you created such an address

and suddenly you start to receive lots of spam via this address, you can just disable this address.

You will not lose any of the contacts that you created via this address before.

So in simplex network design, we see address that you created as first optional and second

disposable. You can delete it without any consequences to already existing conversations.

Very cool.

With the signal, your address and your contacts, they're all intertwined.

You can't delete your address, right?

If your address became public, you may start receiving spam.

There is nothing you can do other than changing this address, and that will undermine all

your existing connections.

So that's the problem with any design that requires users to have an address.

And then what about session?

Session started as a fork of Signal app, which was great.

They made a copy of the code, it had signal protocol inside, and they removed the requirement

to have a phone number to use Session, and the network of service was more decentralized,

obviously, and that was a good start.

But then later, around 2021 or 2022, I think, Session decided to remove signal protocol,

right?

And they are on a defensive since then about this decision, right?

So I think it was a very big mistake to remove signal protocol without adapting it to the decentralized network design.

The argument was that it's hard.

Yes, it is hard.

The hardest thing with signal protocol is not decentralization.

It's multi-device, right?

So because you have to make some decisions around how, and we still didn't solve this problem for multi-device on simplex network, right?

So signal protocol obviously stands in the way of using the same user profile across multiple devices.

Session's decision resulted not in just removing Signal protocol.

Unfortunately, it became literally the least secure end-to-end encryption implementation across the board.

There is literally no other messenger with end-to-end encryption that has recent end-to-end encryption than Session has.

Many are happy people for me saying that, but that's just objective reality.

It doesn't have forward secrecy. It doesn't have break-in recovery.

It doesn't have any patent to this encryption.

There is no key rotation at all.

Messages are stored long-term,

and the key used to encrypt these messages

is easily accessible through the device.

And also, unless you put a pin on your app,

then the device can be easily,

this encryption key can be easily accessed

and cloned to another device,

and whoever got temporary access to your device

can, from this point forward,

read your messages forever.

We've been discussing that,

And I don't know if they want to fix those problems or what's their plan.

But I think at this point, saying to users that Session is secure is just gaslighting, unfortunately.

It'd be interesting to get you all in a room to maybe discuss these different implementations.

Yeah, I would be happy to.

I actually offered that.

I'd be happy.

I know all the arguments that Session has against simplex design and the argument that simplex design is less decentralized than Session.

It's an interesting comparison.

And we can go into that.

have something to say on that as well. But I think the big difference with our approach to

problems that we have is not to hide the head in the sand and to remain in denial about these

problems. We listen to what users say. We make objective assessments about whether we think it's

a problem worth solving or we want to live with that. And we acknowledge that and we talk about

that. And then at some point we may solve it. We recently evolved from the design that didn't

protect user IP addresses from each other to the design that not only protects user IP addresses

from each other, but that also prevents any of the network operator observing which IP address talks

to which IP address. So that was a major change. It was a very complex change. We launched it with

like zero breakages to connections or any kind of negative consequences to the users. So currently

the design to have it both protects your IP address from your contacts.

And also it prevents network operators from seeing which IP address talks to which IP address.

So you like, they know which IP address is connected to their, so like, for example,

one of the criticism that I don't know who invented this simple X servers can see users

IP addresses, I guess.

So can Tor relays and VPN providers, it literally doesn't matter how you use the network intranet,

right? There will be some servers that will see your IP address. You can only choose which one

will do it. So yes, if you connect to simple like servers directly without any overlay,

like VPN or Tor or any other overlay network, then yes, the servers you connect to will see your

IP address. That's true. But what's important that the servers will not be able to see which

IP address connects to which IP address. Got it. And so what would you say is the

limitation in your guys' approach compared to the other two options? I think the big limitation is

obviously this this this this approach decentralization creates lots of technical

complexities and that makes it harder to scale the network we're currently right in the middle

of process of scaling this we did find a solution obviously how to scale it but i would say it's

way more complex than using a traditional approach when user has an identity on the server and server

knows who the user is, this traditional network technology is much simpler to develop the code for,

I would say. And it also makes it much easier to scale. So I think it's harder on us, better for

the end users. I think that was fundamentally the trade-off that we bought into, like that will do

harder work to make better value for the end users. Got it. So before I touch on the encryption

and security and kind of go into how you guys use the signal protocol and all this stuff.

I had two notes as we were talking here, scaling and different ways to use SimpleX,

because when I open SimpleX, I think I have the option to use just a regular, you know,

default operator.

Please correct any terminology on my end.

You can self host something, I believe, as well.

So if we can talk about scaling and then also the different ways to use SimpleX and kind

of the trade-offs between them.

I think it's not a very connected subject, but let's start from how it is.

So currently, if you just use the app without making any advanced configurations,

then you will be using two different companies as network operators.

One of those companies will be us.

We provide some servers.

And another company will be Flux.

They also provide some servers.

We have the same privacy policy.

We have an agreement between each other, obviously,

which obliges them to adhere to the same privacy policy as we do.

And when users agree to conditions of use, they agree with both of us.

And that provides more privacy than if there was just one operator.

This is objectively worse than having 100 different known,

10 different known operators who commit to the same terms.

And that's the model of the network we work towards

is when we build the commercial model into the network

that will incentivize operators to offer their servers.

And by incentivize, I don't mean maintain some shit coins.

No, I mean like community owners funding their channels

in the same way they fund websites

and that provides revenues to operators.

So we don't want to skew the balance, right?

So that's something that we're working towards right now.

So there will be some big announcements.

So effectively, we want to be in a world

when without any advanced app configuration,

by default, you're using tens or even hundreds

of different known companies

who contractually obliged to stick

to the same privacy policy.

That's the future.

We're not there yet, right?

We currently offer only two companies

and we're in conversation to add a third,

which may happen rather soon.

But that's, again, that's objectively worse than having 10 or 100.

Now, if you compare it with network designs like Tor or Session,

on one hand, you have hundreds of nodes there, right?

And traditional view is that this is the better model of decentralization.

The problem is that you don't know who runs nodes,

and your whole security model is based on the assumption

that these nodes are run by different parties, right?

But you don't know that.

And second, they don't have any contractual obligations to you.

They don't promise you any privacy terms.

They don't promise you anything at all.

Absolutely.

They can log IP addresses.

They can log them.

They can do whatever they want, right?

So all the networks with anonymous operators in comparison to what we did has the downside,

right?

So multiple nodes can be run by the same party and multiple nodes can cooperate and share

data in order to determine and effectively de-anonymize user connections.

They wouldn't violate anything.

They would violate the spirit of the network, no doubt about that.

But since when it stopped people who are commercially motivated, right?

So like if there is a demand for Tor traffic data and there is demand for Tor traffic data,

there are suppliers of Tor traffic data or session traffic data, there is demand for that,

then there will be supply, right?

Like some operator nodes will be selling their traffic data for aggregation.

That effectively undermines the model.

And the argument is that a small share of nodes will be owned by malicious parties.

Yes, that's true.

But statistically, if you choose the nodes randomly, we published this calculation somewhere.

So let's say even if 2-3% of nodes in a large decentralized network are controlled by one party,

this party can't subvert the whole network.

So when people think about Sibyl attack, Sibyl attack is not possible unless there is a huge number of.

But the problem is we're not talking about civil attack.

We're talking about determining who talks to whom through the network.

Because the purpose of Tor network or session network

is to hide this information, right?

Because people don't connect to each other.

They connect through intermediaries.

And the purpose of the network is to protect those connections.

But even if a small number of nodes are run by the same party,

then this guarantee no longer holds.

Like after many random choices,

you will be hitting multiple nodes controlled by the same party eventually, right?

Just because you choose them randomly, statistical occasion is this.

If you have 2% of nodes controlled by one party, you have to make something like 700,

1,700 random choices to hit nodes of the same attack, which is not too many choices, right?

Like you use the app for, say, half a year, and eventually you'll be hitting problematic

connection paths.

So again, that's answering the question

of how people use on decentralization model

and what's the alternative, right?

So many people use the app by their own servers, right?

So we know about lots of like work groups or teams

that run their own simplex servers

and use their servers to connect to each other.

The great thing about the design of the deal

is that users decide which service to use.

Like when you use Tor, it's hard to make those decisions.

When you use Session, it's impossible

to make those decisions, right?

like the app decides for you.

We give this control to the users, 100%.

So users can configure the app,

which operators to use and how to use them.

And they can be their own servers.

So users can, for example,

use our servers to store messages in delivery

and then use some low reliability servers

as a proxy for connections or vice versa.

They can use their own servers for delivery

and our servers as proxies.

And we've heard about all those combinations.

So we give people configuration about which servers to use and how to use them in which role on the network.

What we don't yet is we don't have currently the same level of configuration for custom servers as we have for preset operators.

That's coming very soon.

But nevertheless, lots of users use their own servers in combination with servers that are pre-configured in the app.

I see.

And I always forget to ask these questions early on because for me, it's just obvious.

But, you know, everything you guys do is open source, right?

A hundred percent, yes.

Yeah, okay.

No, look, I have been doing open source for a very long time, you know, and I think it gives you much higher quality.

It gives you much, like I was saying many years ago, long before we had ChatGPT4 or Grog4,

that there will be very little benefit of having closed source code

because we're moving to the world when advanced LLM can take your binary code

and literally reverse engineer it and write it.

So by hiding your source code, you're only protecting it from small players

who don't have large LLMs, and you're not protecting it from large players

who have large LLMs at all.

So there is very little benefit.

So licensing works, right?

So like if you license your code under,

like for example, we license under AGPL V3,

which allows people to use it,

but it imposes the requirement on them

to make code available to their users

if they modify it,

which provides both security

and also protection from any kind of changes

that users wouldn't know about.

So yeah, so it's both the app code

and mobile apps code

and core of the app

that does cryptography and messaging.

and service code.

And we had quite a few situations

when users were pointing a box in those code

before the release,

and we had quite a few important contributions to it.

And I think literally 100% of people

who are in the team were contributors

who literally found the project,

liked the project, did some contribution,

then did some other contribution,

then they said, like,

why are you not working with us 100% of time yet?

So I think I see only upsides.

I don't see any downsides to the code.

The whole idea that if you don't close your code, you can't make a commercially viable business is just wrong.

It just means that you have to figure out a commercial model that's not based on the idea of hiding your code.

And your competitive advantages should be not based on hiding your code, but should be based on something else.

But we want the competition to exist.

We are competing with such big networks that we absolutely cannot compete if they are the only developers.

So we literally are moving to the point when developing alternative apps will be easier.

Because again, obviously, we move very fast, right?

The protocol documentation a bit lags, and it's really hard.

So we didn't do what Matrix did, for example, from the very beginning.

When Matrix development started, it started from a point, okay, let's make a protocol.

Let's make it public.

Let's create a committee that decides on the protocol evolution, right?

And let's multiple people build multiple apps.

In a spirit of open source and transparency, et cetera, et cetera.

The problem is it's a dead end, right?

Because you get products to some early adoption this way, right?

You may even get faster early adoption

because multiple developers develop, promote, et cetera, et cetera.

But then you realize you need some fundamental protocol changes.

And you have, let's say, three or four different apps.

You now need to agree those changes.

It's almost impossible.

And the whole conversation about how we evolve it from the one to the two, and then from the two to the three of the protocol becomes really, really, really hard.

So we kind of want to do what happened with the web more like when, you know, when there was a moment in the web, in the history of the web, right?

Before the 2000s, there were like 30 odd competing browsers, more than 30 startups that were competing with Netscape at the time.

Nobody knows their names, right?

So Netscape took it upon themselves.

They said, all right, we have a web protocol.

That's great.

It's not suitable for a widely used product.

Let's evolve it.

Netscape single-handedly added SSL, which is transport encryption, right?

TLS now.

Then they added cookies.

People think cookie is a bad thing, but cookie is abused to be a bad thing.

But without cookie, a website can't function, right?

The fact that you can log into Facebook depends on cookies, right?

It wouldn't be possible.

Anybody would be able to log into your account, right, if there were no cookies, right?

The cookie allows Facebook to recognize you.

And then they edit JavaScript, right?

So fundamentally, Netscape in a matter of a couple of years and many millions of dollars

and losing completely compatibility with the rest of the browser, they created a new product

based on the web, and it became a mass market product because of that.

So we see currently the protocol we have, Mastodon has, Magix has, is kind of version

one, right?

It has to evolve quite rapidly to version three with much more funds and with much more

but with an absolutely ruthless focus on doing what users need

and not trying to have competition across development teams.

Yeah, so on that note, you know, let's talk a little bit about the encryption

that you guys use and the security model.

I want to start by Signal.

So why did you guys pick the Signal protocol?

And are there any modifications that you make to it?

You know, I think we've been super lucky.

When we designed the Signal, it's like it's almost an anecdote.

I'll tell you that when we designed the network design, it was before it was widely used.

We just developed some early stage prototype of conversations.

And there was circle.

It was all in terminal.

There was no user interface, et cetera, et cetera.

And then I asked Mozilla.

Mozilla gave me a grant to my previous open source project library for the day.

It's a very successful library, by the way.

So I just asked them, can they maybe recommend me someone to look at what I did?

Because I don't understand cryptography much.

I don't.

It was like early 2022.

And they gave me somebody who eventually became our advisor on protocols.

He looked at it and he said, I don't want to help you.

I said, why?

He was very like, he was very reticent to give me any feedback.

I said, look, man, I have a tough skin.

You can tell me how it is.

I don't need nice words.

I just need you to tell me what it is and maybe we can make it better.

So he said, all right, what you've done is a complete shit.

You have a good seed of the idea there, which is message routing.

You invented a fantastic message routing protocol like nothing I've seen before

and your cryptography is a complete shit and nobody does it like that anymore.

That was early 2021.

Right.

I said, all right, how everybody does it?

So everybody uses Signal.

Signal a state of art, Android encryption, just use signal and stop inventing shit.

Don't invent stuff you know nothing about.

And then he said, and also he pointed out some other possible attack vectors and everything.

And he eventually became our advisor.

So I think what he was surprised is that we actually did all that he suggested.

We switched to signal protocol in a matter of less than two months.

and we fixed all the vulnerabilities.

So when we released SimpleX Protocols version one,

it was a complete full rewrite of the whole,

like it retained the engine for message passing

and it retained some semantics,

but fundamentally we changed more than we kept

in the core of the network design, addressing everything.

And that's why Signal,

simply because it provides three very important qualities

for what is end-to-end encryption.

So one is forward secrecy.

What forward secrecy is?

It means that if somebody somehow manages

to crack encryption of a single message,

maybe via brute force,

or maybe they obtained the state of your design

from some date and they have the key

that was used to encrypt this particular message,

it wouldn't allow them to decrypt past messages.

I find this terminology very counterintuitive

for the wrong people

because when we talk about forward secrecy,

actually talking about the security of past messages from the future compromises. Maybe

that's why it's forward secrecy, but it's about security of your past, right? From future attacks.

That's what forward secrecy is. And forward secrecy is very widely used. Like every modern

browser uses forward secrecy. So literally every single person on the planet, one way or another,

uses forward secrecy. And it's like a staples of encryption. So forward secrecy is exceptionally

important because otherwise your whole correspondence, your whole history of messages

becomes compromised from a compromise of a single message.

But Signal doesn't stop there.

Signal invented a different attack vector.

He said, all right, because very common attack is a break-in, right?

When attacker gets temporary access to your device.

Break-in attacks are easier than compromising your device permanently

because to compromise your device permanently,

you have to install some software in it,

and there may be some protection from installing software, etc., etc., right?

So, although, and then there may be some network connectivity issues.

And what Signal Protocol does is regularly rotate encryption keys in such a way that if your device was compromised, then your future messages will become protected after some time.

And this quality is called post-compromised security or break and recovery.

I prefer the term break and recovery because it's a process, right?

It's something that protocol proactively does in order to recover the security after the compromise.

and after the specific type of the compromise, which is break-in.

Because obviously, for example, I've heard the argument from many people

that we don't care about protection from long-term key compromise

because if your long-term key compromise, everything is compromised.

But this assumes that attacker retains access to a compromised device,

which is a harder attack, right?

And there is a separate class of attack called break-in for a reason

because in many cases break-ins are easier to execute than terminal compromise.

right so so like this post-compromised security of signal and breaking recovery in signal protects

uh recovers the security after compromise happened and that's actually exactly why

running multiple devices hard with signal because if you even if you make a copy of your database

from the point of view of encryption algorithm it's a compromise right and if you try to run

this copy in parallel on another device one of them will stop working because it will be seen as a

compromised copy. There are solutions, right? For example, SignalUp has a very elegant and simple

solution with its own downsides, but it works literally making every conversation a group,

right? When you connect with somebody, then each of your devices affects a separate participant in

this group. And there is break and recovery between devices, but they all kind of send messages to all

participants in a small group. So like you say, we have three devices, I have two devices,

We will have like five participants in this small group that from the user

experience will look like their conversation, but from the protocol design

point of view, it's a group.

So that's what signals are.

That's what probably we will do as well.

The downsides of this approach, obviously, is that you can see which device was

used to send the message.

There are various attack on this.

So there are some downsides.

Okay.

So, and the third thing about a signal also very important called the non-repudiation.

Sorry, repudiation.

Non-repudiation is ability to prove who sent the message.

And repudiation is lack of such ability,

which means that if you send me a message on my device,

then I cannot prove to a third party that this message came from you.

I can prove it to myself, but I can prove it to myself

only because I know that I didn't send the message.

But I have the same encryption key, and I could have encrypted that as well.

So I do not have a cryptographic proof to another party

that you have sent the message.

And I technically can fake messages on my device.

So I can construct a proof that the look on my device as if you sent the message.

And it will be indistinguishable from if you, in fact, did send the message, right?

If you didn't send the message, you can deny it.

And I can't prove it cryptographically.

Now, many people say, okay, this is not an important call.

Let's say this was never successfully used in court.

This defense was never tried.

I find this all mode point.

The whole kind of concept of deniability was invented less than 20 years ago, right?

If you look like off-the-record messaging, this whole concept was published as a paper before 2010.

Signal was the first messaging application that adopted this approach in Signal protocol.

And it wasn't even mass market up until when?

2020?

Probably 2017.

Even now, Signal is used by maybe less than 2% of the population, right?

So the fact that it was never successfully used in court is irrelevant because court precedence

sometimes takes many decades to evolve, right?

But the problem is, if you're a high-profile person, right?

Imagine you're a CEO of a large company that runs multi-billion contracts.

So somebody will try to abuse the communication with you.

Somebody will be trying to fake messages with you.

or somebody can use the messages you sent on confidence against you or fake messages against

you. So the liability provides an interesting defense line in the court of law. I think it

should be used by some people sooner or later, right? Because if you, in fact, didn't send the

message, then the other party will not be able to prove it. Today, the common practice today is that

people accept screenshots, people accept device copers, people don't go into high profile

expertise to establish if deniability is important quality or not. Technology usually is many decades

ahead of law and legal precedents. I see deniability as an important concept, right?

SimpleX network provides full-stack deniability, so both on server levels and on client level.

And I think that there will be some profile cases when this defense will be successfully used.

Yeah, maybe it'll be some of the people in security positions in the US administration.

For example, for example, a journalist claims to be in a group with all of them, they could say, well, exactly.

We never sent those messages.

It's not real.

Exactly.

For example.

Right.

So, again, I'm not I'm not advocating that people should lie in court, but nobody should lie in court.

Right.

You should say the truth.

But you understand that your message can be taken out of context.

Right.

And what you say in context can be interpreted and misconstrued to mean exactly opposite to what you have said within the context, right?

And if that's what is used against you, you would be right to say, I didn't send this message.

Because, yeah, you may have sent exactly those words, but the meaning of those words was completely different, right?

And they cannot really.

And then you have a choice.

Either you can say, okay, this is the whole transcript, but this transcript can reveal other sensitive information.

or you may take a defense line okay this is not what i said so i would say that there will be there

should be high profile cases that would rely on this technical parameters of signal protocol and

it's also very important parameters so anyway so so we it's a long kind of journey around how signal

protocol is different from everything else there is nothing else comparable today which would combine

all three equalities i just like listed and node-based signal protocol right and nobody so far

managed to improve on top of that say okay we have this three quality but then something else as well

there's literally no alternative today if you want to have a secure end to encryption you will be

using signal radical as a huge credit to inventors of it most moxie moran spike and i think trevor

perrin was uh the other guy so i think i think that's that's their huge contribution to technology

and to encryption and my today understanding of cryptography obviously it's very different from

early 2022. We understand cryptography really well. We amended Signal Protocol with post-quantum

encryption before Signal did it. Signal did it just recently, but we did it on the same principles,

right? So we created some very strong cryptography around short links that we recently introduced.

So we now understand how we should design cryptographic schemes. And every time we get

through, like we had two security audits, we'll have security audits next year again. So I think

we get so far a rather encouraging alignment with much higher cryptography experts about us doing

a good job when it comes to cryptography. Now, one thing, you mentioned Matrix earlier,

a really big criticism that I have actually, and I see a lot online, is that the home server sees

a lot, a lot of metadata, not just, you know, there is end-to-end encryption if you enable it

in Matrix, but there's still a lot of other data there.

So what does Relay see in SimpleX?

What kind of metadata protection is built in

when someone's messaging on it?

- I think it's wrong to compare Matrix

and SimpleX message directly.

Because Matrix server provides you a place

to host your conversation.

And in particular, if your conversation is public,

then you don't want to hide content.

The problem is that in Matrix design,

you have the same server that's used as a transport

and as a hosting for the conversation,

if you understand what I mean, right?

You connect to the server, it delivers your messages,

but it also hosts the actual messages, right?

And that's the problem, because in this case,

I'll get to the question.

I'm just trying to explain why, what's the real problem.

The real problem is not that the server in Matrix

sees some metadata, but it's the same server

that also sees the message content.

So it not only sees who sends messages

and it not only sees what messages are,

it can connect sender identities with messages.

And that's where the fundamental problem happens, right?

Because if somebody says something problematic,

but nobody knows who they are, it's not a problem.

And vice versa, right?

If somebody sends messages,

but nobody knows what they sent,

again, it's not much of a problem, right?

Something is being sent.

But when you can connect identity to content,

that's when the personal security gets compromised, right?

So with our current messaging relay, they obviously don't see the content.

They don't see the conversations.

And they, of course, see some metadata.

I think protecting metadata is just an oxymoron, frankly, because you cannot protect it if you

use metadata, right?

You have to use some metadata to deliver messages.

And what you want is to minimize the metadata, not protect, but to minimize the metadata that

you use and minimize the metadata that you can observe and minimize the metadata that

you can record.

So if you're talking about metadata and communication, we're talking about three different things, right?

Metadata you can observe, that's one thing.

Metadata that you actually need to transmit messages, right?

You need some metadata.

And metadata that you record long term.

And they can be three different things, right?

So if you connect to MessagingRelay, they obviously can observe your IP addresses inevitably.

They don't record this information.

We put it in our privacy policy.

We don't have any need to record those addresses.

so we don't record those addresses, but technically they can observe the IP addresses.

They cannot also observe connection times, right?

They know when you connect to the server and they can see when each address connects to the server.

Again, they don't use this metadata and they don't record this metadata,

but that's an observable metadata.

And the same will be true for any kind of network.

Tor relays can observe the same, session relays, VPN providers.

It's all kind of universal, right?

What they do use, what they can't observe, though, is very important.

They cannot observe the message size.

Because SimpleX network is probably, I think it's the only network that uses fixed packet size of a rather large size in comparison.

Kitech also uses fixed packet size, slightly smaller.

So every single message you send is 16 kilobytes.

It's paid to 16 kilobytes.

Doesn't matter how large it is.

It can be a long text, which takes, it can be like image preview that takes

six kilobytes, or it can be just a thumbs up reaction.

Uh, what network will observe will be six and kiloby traffic, which is

purposely wasteful.

Uh, and obviously you don't need 16 kiloby traffic to send thumbs up

reaction, right?

You need several bytes, maybe a hundred bytes, but this design prevents a

correlation by traffic, uh, across the network, right?

Because if you send messages of variable size, then it becomes very easy to determine who talks to whom simply by seeing how those sizes correlates on different parts of the network.

Right.

And if every single message has the same size, then network observers can't establish who talks to whom.

And servers can't observe it as well because they don't know their real message size.

They only see the fixed block size of 16 kilobytes.

They obviously have like destination address.

But again, destination address is not the user.

it's the messaging queue and the user can have tens of thousands of those message queues

and they wouldn't, the server that sends,

wouldn't, they wouldn't necessarily know which, how queues correlate to users.

But the whole idea is like every time you send the message, it goes through two servers, right?

And the first server knows your IP address and it knows the destination server,

but it wouldn't know the destination address on the server.

So, cumulatively, you send to this other server 100 messages, but they wouldn't know to how many contacts.

It can be 100 messages to one contact, or it can be 100 messages to 100 contacts.

The first server wouldn't know not which contacts nor how many.

And the destination server would see the addresses, destination addresses.

It would know which queues to put the messages in, but it wouldn't see which IP address sent them.

And they wouldn't know even, like, again, is it, let's say, if messages arrive to 100 addresses, do they arrive from one user or do they arrive from 100 different users?

They wouldn't know that.

And the protocol is designed in a way that they simply can't share this information with each other.

So they don't observe it because there is an end-to-end encryption tunnel, not just between the users, but between user and the destination server.

There's a separate end-to-end encryption, like, not end-to-end, but let's say user to destination.

is a separate encryption tunnel.

It's kind of how Onion Routing is designed

when you wrap encryption layers one on top of each other

to protect information from intermeter relays.

So in a way, SimpleX Network functions

very similar to how Mixed Network function.

It's just low latency Mixed Network.

And the difference is it's very tailored

to the problem of transmitting messages, right?

It's very specialized to this particular need rather than being a generic.

And it's very different from Tor because Tor establishes connections, right?

So even if you connect via Tor, there will be a persistent circuit built via Tor

and everything you send via the circuit can be attributed to you as a user.

When you send your messages to the destination, there is no persistent circuit.

there is just packet level encryption and security rather than circuit level like with Tor.

If anyone is listening and they don't like the idea of their IP address being collected,

I'm sure we can recommend people use VPNs or Tor when they're using SimpleOS.

100%. We're not collecting them. What I'm saying is the IP address is theoretically observable,

but that would be the same whichever network you use.

If you use VPN, your VPN provider may be observing your IP address as well

and may be collecting them.

And if you use Tor, then your entry node on Tor is also able to observe your IP address

and also collect your IP address.

So the choice that people should be making,

I think it's very dangerous for people to have an illusion

that they can use intranet in a way when nobody observes their IP address

because there will be always that somebody,

they have a choice of who this somebody is, right?

and they have to make the correct choice there.

And yes, you're absolutely right.

In many cases, by combining multiple parties,

you may increase your security, right?

But you can also reduce your security by combining multiple parties.

Right.

So I guess my question and what some people might be wondering is,

is there a reason you haven't opted for built-in IP protection

that would change the party away from, I guess, a relay?

I know you already explained it to people,

But I know some messengers might opt to do like a Tor onion routing.

But then I assume that's just going to add a huge amount of complexity.

No, it wouldn't add complexity.

I think Tor is, I don't want to couple the message bus and network design to transport protection network design.

We're currently allowed to use the app with Sox proxies.

And Sox proxy allows to obstruct this transport network.

So you can use, if you want to use Tor, you can use Tor.

if you want to use I2P you can use I2P right or if you want to use some other design that we

don't know about you can potentially also use it or you can use your own SOX proxies

we just think this problem should be I think this problem should be kept separate and by putting

both protections in one app we're not increasing the security we are reducing it right because there

is no bulletproof sense right torque protection is not bulletproof so like if you wanted optics

and look like, we don't want to look like the most secure message.

We want to provide actual real security.

And while optics of embeds in Tor may look good for some people,

reality is bad because it means that now we're responsible for shipping Tor code, right?

Now we're responsible for security updates in Tor code.

Now they depend on us to provide integrity of Tor code.

To me as a user, it all sounds like a horrible deal, right?

Because if I want to trust Tor, I want to get Tor code from Tor developers, not from

SimpleX developers, right?

So they provide me the code.

Because in this case, that provides additional security.

Even if it do make some mistake, then I have Tor to protect me, right?

But that all kind of predicated on the fact that I get Tor code from Tor developers and

not from why would I, like, I'm putting myself in the shoes of a user.

Why would I trust me to ship me Tor?

I don't develop Tor.

Like, why should I embed it in the app?

It looks good for non-technical people, but reality is it's bad.

And for even non-technical users, the time it takes to start using SimpleX Viator on Android device is exactly one minute.

You go to the App Store or Play Store or AppDroid, you download Orbit app, you press start, then you go to, like, it's literally like it's a one-minute instruction.

And if people find it technically complex, they honestly shouldn't use Tor at all.

That's my strong opinion.

Because Tor has some limitations to its threat model.

You have to understand the limitations to the threat model, right?

If you think that this kind of install the second app is technically complex, you'll make so many mistakes with your AT security that Tor is not going to help you.

It's only going to hurt.

So I generally think that by embedding Tor, we're doing a bad service to our users in all means.

Got it. And then, you know, let's pivot more into the usability side of things, I guess, to go away from the technical side.

So what are kind of the usability challenges right now? Because it's a complex network and it's a lot of stuff going on.

So where do you feel like that's kind of increased complexity on the usability front?

We're still in the world when many new users who don't come via the introduction find it

difficult to connect to other people because obviously you can't enter the phone number

as they used to.

You can't search for users in the app.

You need to somehow search them outside of the app.

And we can see that if people come via the introduction of somebody who already uses SimpleX,

then normally they successfully get on boarded.

they start using it and they understand how to use it.

But if they simply download the app from Play Store or from App Store,

then the most common question we get in support, support contact is embedded into the app

so they can connect to us.

And one of the most common, not the most, but one of the most common questions is,

OK, how do I connect to people?

And we've iterated this user experience for new users many times

and we're still looking for better way to explain to the new users that,

okay, you have to create the link, you have to pass it via some other channel, just because

that provides security from us. And then you have this somebody else have to use this link in the

app. And even though we recently improved usability of links by a lot, right, we had like

huge 500 character links, which everybody considered malware. Not everybody, but everybody's

non-technical consider them malware. Right? They look at this, oh, look, it looks scary,

I'm not going to use it.

So now they're short and nice.

And if you tap it, you see the name of the person you connect to before you connect.

And you can send a message together.

It's really, really nice compared with what it was, right?

So still, it remains a challenge.

That's literally a simple thing, how people connect.

That's a basic thing.

And we still didn't figure it out after four years.

That's embarrassing, frankly.

But it's complex.

That whole kind of fundamental innovation that we created in unit work topology

when users don't have identifiers,

which means that you can't find users,

you don't even know how many users are there on the network,

that obviously creates a UX challenge that we didn't crack yet.

That's probably the main, remains the main thing.

So, and the second most important thing

is what is the complex development

is just making large groups work

because the current groups on SimpleX platform

is a client-side broadcast, right?

It's like mailing list under the hood.

You want to send a message to the group,

you have to send it to each member in the group.

It all happens automatically.

It looks like the usual group, but it creates lots of traffic.

It also means that messages may reach some users,

but not to reach some other users.

And then they see messages in different order on their devices.

And they can also see replies to messages they've never seen.

And it just comes with the territory.

So if the group doesn't have a single source of truth

that is reliable and always online,

then different people in the group are likely to see

on what divergent histories in the conversation.

So we are working on that.

That's technically complex development.

So we are going to introduce

what we call chat relays now.

So effectively a special client of client

that would probably act conceptually similar

to Matrix Server,

but unlike Matrix Server,

it will be based on client technology

and you'll never connect to it directly.

You would still connect to it

via simple X messaging network,

which means that even though this chat relay

They can see public conversations.

There will be end-to-end encrypted conversations as well via chat relays.

But even though it can see public conversations, it wouldn't be able to know which are the users

because there are no direct connections between the users and chat relays.

So if you use Matrix Server, you have to connect to it directly via the internet.

Yeah, you can use Tor or whatnot, but you still have to connect to the server via the internet.

In case of chat relays that we're developing now, you will be connecting to them as if they were your contacts,

meaning via two servers, messaging servers.

So there is no direct connections.

They don't see your traffic.

They don't see your IP address.

They don't know where you are on the network.

So that will address one big usability challenge with the groups.

But we can still see the interest of groups grow.

We have a small directory of groups approaching 500 groups

that people create on SimpleX Network.

Some of them have more than a couple thousand people.

And this directory is since recently available as a web page.

And that kind of makes it much more accessible.

It's easier to search for them on the web page.

We offer a chatbot that allows to use this directory,

but it's also available as a web page since not so long ago.

Got it.

And so a really, really quick one.

Is message delivery about the same speed as what people might expect from their typical app?

Normally, yes.

Normally, latency is determined by the network conditions.

And yes, people with slow network connection find it slower simply because of fixed block size.

So if your network is really bad, you will see it as slower than most other app because when other apps maybe send in like 100 bytes of data, you have to send 16 kilobytes of data, right?

And if your network is really slow, then there will be some difference, right?

But if your network is reasonably fast, which is like modern 4G or 5G networks, mobiles or Wi-Fi, then you would not see noticeable delays in message delivery.

And like, for example, when I send a message from my desktop client, I usually see second seek meaning that it's delivered to another device.

And I got the response confirming it was delivered in under like 300 milliseconds many times, like certainly under one second.

So, yeah, it's on par with more usable messaging apps.

Yeah, and on this note, you know, Facebook has outages, and Signal has had a couple outages.

Normally, when they get a huge influx of users, how does that work with your model?

Is it possible for SimpleX to be down, if that makes sense?

100%, yeah.

So, I mean, the whole network can't go down because it fragments it, right?

And each connection depends on some server.

And right now, if this server is down, then some of your contacts will be down.

Not all of your contacts.

So the simplex as a whole can be down because we don't control all servers.

Nobody controls all servers, right?

But because each conversation depends on just a specific, I mean, in each way, right?

So you can be in a condition when you can receive messages but can't send

or the other way around to a particular contact.

You can send but can't receive, right?

So because one way you will be using one server, another way you will be using another server, that they are both down is very unlikely.

We have a status page that shows the historic downtimes for all servers.

They are well over 99%.

Normally it's like 99.98% for many servers.

But they do have maintenance windows.

We recently migrated to new storage approach that reduces maintenance windows from minutes to seconds.

So that improves deliverability.

but the migration itself was painful.

So yes, so effectively people experience some downtime

with specific contacts

when this particular server is restarted.

And our answer to that going forward

is that each contact should use multiple servers,

not just one server to send another to reply,

but let's say you send each message through three servers

and each server lives with different operator

in a different data center in a different country.

the probability of all of them going down together is like literally zero.

Rather than having each connection, each contact on one company,

you will have a dependent on three companies.

And for it to stop working, they all three should stop working,

which almost never happens.

So we don't want to be in a situation when Facebook is down, right?

So like right now, a segment of the network can be down,

but we want to move to the design when even some part of the transport network

going down will remain completely unnoticeable by the end users.

Got it.

And then how about multi-device sync?

How does that work with SimpleX?

It doesn't.

No, we have a technology that allows to use mobile app from desktop interface as a remote

access.

But that requires that both devices are on the same network right now, meaning both mobile

and desktop.

And it's effectively just a convenience feature that allows you to type messages from bigger

on a bigger keyboard through the profile that you have on mobile device.

It doesn't fundamentally create any synchronization problems or anything.

You just use it as a remote connection to mobile device when you're using the desktop.

That works for some users.

Just to be clear, you can also just not use a mobile device and make the desktop client

your main device as well.

Correct.

Yes, you can.

But then you wouldn't be able to use this profile anywhere else.

So you have to pick.

yeah so for example for for our support we do an interesting thing here so we run our support client

like support is the account the profile that users connect to through the office says ask

simple x team in the app right so it's a it's a client that runs in the cloud online 24 7 and

whoever will be replying to those support requests will be connecting to this client in the cloud

via the same remote connection from desktop.

We have it documented somewhere.

So we effectively allow, like, we have an approach

that allows multiple people use the same profile

and reply to people in turns.

But what many people want, like, I have this profile

on two mobiles or on mobile and desktop,

and I can use them both together or in any order,

and I don't need to do anything to connect them.

That doesn't work.

So we consider several approaches,

And most likely will go with somewhat strengthened approach of Signal.

What Signal did is rather simple, as I explained earlier, right?

So they just put all devices in a conversation into a group under the hood, right?

So what for users looks like conversation between two people is effectively a group between five devices.

Let's say four devices, right?

That's a viable approach that has downsides, such as you can see which message is sent by which device.

That also has some attack factors.

So far, it looks the most reasonable and the most viable compromise for most people.

What we want to avoid and it's possible to avoid is the attack vectors that Signal introduced,

which allows to add device unnoticeably to the end users, right?

So like Signal relies on pin verification when adding another new device.

And that's effectively depends on trust to Signal, which I think is a bit thin generally.

If your security depends on trust to provider, then it's not very good security.

So our whole philosophy is that your security should depend on cryptography and not on an open source code and not on trust to a particular provider.

There is an interesting paper published.

I can send you the link if you're interested.

There is a good paper that cryptographers published about this vulnerability of signal around 2021.

I think it's really important that they address it because it effectively allows any attacker that managed to somehow compromise part of signal infrastructure to add a device to any conversation.

And the problem is users don't get notification when the device is added.

And they can see it in the list of devices, but you have to proactively look for it to see it.

Got it.

And the way the paper describes it, it's rather worrying a tech vector that I think Signal should address.

But Signal was good at addressing various vulnerability community was pointing out recently.

It was not very good maybe a couple of years ago, but I think nowadays Signal is a bit more responsive to community criticism.

And to me, that multi-device vulnerability remains the biggest downside of Signal security model.

And the solution is really simple.

Just let users scan the security code, even if you had another mobile, right?

So it's actually make trust between devices established on the client level without Signal

being involved, right?

So anyway, so if you go this way, then we'll obviously do it like this, and it will be

secure.

And the only downside that cannot be addressed is that your contacts now can see which device

you're using.

That's the main downside of this Signal model, right?

which may be okay for trusted contacts, but they may be not so good for participating in public groups, right?

Obviously, the future chat relays make it less important because only chat relays now can see which device you use,

but other members wouldn't be able to see.

So I think once we move to the new model for public groups,

this signal approach to multi-device becomes acceptable from a security point of view.

Great. And then how about, we're almost done with the usability,

And then it's just like business, finances, legal stuff.

But for battery impact, is there a battery impact for having to do background sync for things like notifications on mobile devices?

Is that different from something like Signal?

I think we reduced battery usage by a lot in the recent releases.

I think we did something rather stupid on Android early on by never releasing awake logs.

And we recently realized that.

I think the current Android releases do like much, much better and better usage than like even three months, maybe four months.

When did we do it? Several months ago.

Decentralization adds to better usage without question.

But I think 90% of the damage was self-inflicted through engineering mistakes.

We copied our approach from NTFI op in like NTFI op that is effectively used as a broker for push notification delivery.

And SimpleX app does the same on Android devices, right?

So we copied our approach from them.

And then they fixed this bug like about one year later.

And we didn't fix this bug.

So, yeah, so that was the story.

And then recently we discovered that, again, it's embarrassing, but here it is.

So right now, I think most users right now see usage as acceptable.

It would not be exactly the same as Signal.

You have larger block size.

But everything has costs, right?

You have higher security guarantees.

you have better decentralization.

But I think fundamentally,

the biggest usage comes from group decentralization.

And once we move large groups to chat relays,

the better usage will be on par with Signal.

Okay.

And then do you do background sync on iOS?

No, we do do background sync,

but iOS is very restrictive in how you allow it to...

We will periodically sync in the background.

It's effectively only works if you use the app a lot.

On iOS, we use push notifications using Apple push servers.

So it's a completely separate part of the network that unfortunately cannot be decentralized with Apple model.

But that's the only way for iOS to provide push notifications.

So we have a special service that we host.

Only we can host it because it has application keys on it that can push notifications when it gets notified about messages existence.

It's a highly secure approach, obviously.

The notification server doesn't see not just messages.

All the notification server sees is end-to-end encrypted metadata.

Not just the message, but the metadata itself is also encrypted.

And that's what you use on Android, but not on iOS.

That's what we use on iOS, but not on Android.

For iOS, we use push notifications using Apple servers.

Or Android.

You're saying you use on Android.

No, we don't.

Sorry.

Android just runs background servers in the same way as...

It's not background refresh.

No.

We use the same...

We use effectively push messages in the same way as NTFI...

Like, you know, the unified push system, right?

Yeah.

NTFI app, right?

You guys use unified push, but then...

We don't.

We don't use unified push, but we use the same technological approach as unified push.

And effectively, simple X messages and servers work as push servers.

You don't have to pull messages.

That's not how it works.

When you message, you remain open connection.

This connection can be maintained as open even when the app is slipping.

And if the message arrives, the server pushes it to this open connection.

And the app then wakes up and shows you a notification.

That's how it works on Android.

So that's the same approach pretty much as with NTFI app.

Got it. Pivoting over to the business and sustainability. So I always like to ask about

funding models. I've read some of your blogs. They're pretty spicy. I don't know if I'm on the

same page, but I still want to hear kind of which one. Which one do you mean? I think your takes on

VC funding. I'm not fully on the same page as you are, but it's an open podcast. We're open to

different opinions here. So I'd love to hear kind of your guys's funding model, your views on it,

and kind of the pros and cons between your guys' approach and other organizations?

I think the problem with investment is not who makes the investment,

but what is being surrendered in exchange of investment.

Like every investment deal is about two things.

It's economics and control.

And many inexperienced business people, they care about economics of investment,

is how much profit you share, but they don't care that much about control.

And investors like control.

They like put some control provisions into the investment agreements.

they give them the escape page if the business goes in the direction they disagree with that

allows them to replace executives etc etc and that's what's dangerous for the integrity of the

mission and when people criticize VC investment they effectively criticize not the economics of

VC investment they criticize control of the VC investment and many people believe that control

is inseparable from investment.

But that's just not true.

The world of small early stage business investment

has moved on dramatically

from this control-centered investment model

simply because there were lots of successful entrepreneurs

that have proven their investors

that by doing things investors disagree with,

they're making those investors more money.

So for example, if you look at like Snapchat pitch,

like literally like 99% VCs

who have seen Snapchat pitch about deleting messages

after they were sent.

They said, this is the stupidest idea we've ever seen.

Or Airbnb.

Many hugely successful startups had very kind of...

And whoever agrees to invest this idea,

they understand that they really would not be able

to meaningfully contribute to running this business

without disrupting founders' visions.

So the world of investment is hugely split

between investors who do want control

and investors who don't.

So when we were raising money in 2023,

I was lucky enough to have Jack Dorsey

offering this investment and some VC fund.

But there is literally zero control provisions there.

They don't have board seat.

They don't have even remotely close to control and share.

Like it's really a small stake.

And all they have is information rights, literally.

And again, when I say financial rights,

I mean information rights.

I mean like financial information.

We don't have to disclose corporate secrets.

We can have a Chinese wall.

We don't need to disclose who our kind of partners,

contractors are in place.

So they literally cannot participate in running the business in any way.

But they offer a huge resource of advice.

They offer a huge resource of support.

They offer a huge resource for introductions.

And you not just get money to build a business,

you get free advisors as well, which is fantastic, right?

So I think when people say that we see investment universally bad,

they're really talking about bad decisions that founders have made

when they surrendered control early on to wrong investors

who they're not necessarily strategically aligned with.

At the same year when we raised money in 2023,

we had two more term sheets.

We could have raised like three times more money than we raised.

And they both wanted control and they said no to them both,

even though economically they were very attractive.

So that's if you're talking about investment.

But investment doesn't really create financial model for the business, right?

So investment literally gives you money to do what, right?

Why investors?

Investors invest in your ability to figure out how to make money eventually.

And at this point, we have viable, our early theory about how to make money was traditional,

we should use premium features.

The problem with premium features is that people don't like them.

And when they are universally introduced, it gets into, like, the product gets incentivized, right?

The product starts getting optimized in order to sell those premium.

How do you sell premium features?

Premium features.

You get experience with everybody else's voice.

So, like, that's what's happening with Telegram, right?

So, unless you're a premium user, you get some progressively worse experience.

And that's the only way to drive the revenue up is to make your experience worse.

So at this point, I think that the commercial model we are going to build is not going to be based on premium features for the end users.

We may offer some badges, we may offer some tokens, but that's not the core of our strategy.

The core strategy is, again, we're going back to the principle of open web.

How open web got commercialized, right?

It created a platform for people to build businesses and communities.

And those communities are effectively, and businesses are paying customers of the web.

You don't pay to use the web, right?

You don't pay for the browser.

You don't pay for accessing the website.

Some websites try to charge for access, but that's their own decisions, right?

But fundamentally, the web is free to access for everybody.

But it's not free to host.

If you want to host a website, you have to pay some money.

What you get in return, you get 100% control of technology you use.

You get 100% control of your audience.

you get 100% control of your content.

You don't surrender IP ownership in any way or shape or form.

You have 100% control and ownership.

That's a classic what's called B2B2C model.

So we as a business want to see our customers,

other businesses or non-commercial communities

that use the network to host content,

to host communities, to engage those communities,

and they will be their customers.

My view is very simple.

this community should somehow cover the hosts and costs

in a way that creates profit for hosts and operators.

How will it cover the costs?

Maybe the community is created by somebody

who has some spare cash and want to spend it, right?

Or maybe the members of community will donate.

So we run some estimate, unit economics work.

So estimate is very simple.

So if community has, say, 10,000 members

and hosts, say, 10 gigabytes of file,

the price for this community on SimpleX network

will be something around five to seven dollars a month that will provide very healthy profit margins

for network operators privacy to community owners how they cover this five seven dollars a month i

honestly don't care but they get an exchange much more than they get for effective so effectively

for a price of website maybe slightly more than website but with website you don't get technology

right you get technology and the hosting and that's all in the ballpark of the website but you don't

have to develop messaging, you don't have to move files around as you described, it just

works out of the box, right?

So that's the model they're going for.

When communities effectively cover the costs of the network and the end users use, some

of the end users may donate to their communities and that will cover their costs, right?

So how they, or maybe it's communities run by the business and it's marketing expense

for them.

It shouldn't, it's like in the same way as web browser developers and web service developers

don't care how each website does their business and what source of money they use to cover

their costs, right?

Each website has their own commercial model, but all the hosts and companies care about

that they pay their bills, right?

And they're rather small bills.

If it's a small site, we're talking about several dollars a month.

If it's a large size, it can be substantial.

So the good thing about this model compared with premium model, premium model is rather

uniform, right?

Each user on their own, and you can't get too much money from a user.

But communities usually follow the parallel distribution, right?

Like every health network, you get 80% of traffic created by 20% of communities.

80% of traffic is created by 20% of groups, right?

So it means that you can make the rest 80% of group free.

And you only lose 20% of revenue.

So you charge the heavy users, you get free for everybody else.

And that kind of creates profits for everybody and sustainability for everybody.

without asking them to surrender any intellectual property right,

without asking them to accept the risks that they can be z-platformed,

because each community can also use multiple operators.

Even if one of them decides to z-platform, the end users wouldn't even notice that.

Got it. And then if we put it to kind of the legal side of things,

so you guys are legally based in the UK, right?

Correct, yes.

So with the, you know, I'm sure you get this a lot, and I'm sure people are asking,

I'm doing a lot of coverage as well on the channel about UK's attacks on encryption,

what they're doing against Apple, ADP, age verification, all of this stuff.

Does that impact you guys at all?

How does that impact what you're doing, if at all?

I don't think it impacts us in any way.

We are legally, we have very good legal advice from top tier firms.

We did it early on and we did analysis of all the applicable legislation.

So we are legally in a category of web browser developers rather than the server providers.

So we do not, like, the part of the business that provides software is not really providing any service.

And the fact that users can use our servers today is very temporary and coincidental, and we really cannot conflate this too, right?

So, like, can you oblige under the existing legislation web browsers developers to undermine

encryption in the browser?

The answer is no.

There is no legislation for that.

Not in the UK, nowhere else in the world.

Yeah, what about, because I'm seeing, definitely, you know, this is early on and it's very

preliminary.

It's just a concern that people have.

But you see cases like the TornadoCache developers where potentially the development of software,

even if other people do something malicious with it,

could still jeopardize the people who develop the software,

if this makes sense.

Are you guys concerned about a situation

where you can be held liable

for what someone else even does with your code?

I think what matters is the intent.

We actively develop features that prevent criminal usage.

We actively remove illegal content from our servers.

We actually do a lot to prevent such usages.

And I honestly think that what happened with TornadoCache developers is really bad, and

we should all be against that.

But I think TornadoCache was positioned really as something that would facilitate crime,

and nobody was particularly shy about it.

And we see what we do as a technology that protects people from crime.

Criminals can use any technology, right?

You can buy a car and start killing people, or you can buy a table knife and start killing people.

They're discussing in the UK that you should provide an instance to buy kitchen knives, right?

So criminals can use anything.

That's the problem, right?

But if technology is purposely developed to enable crime and it's not doing anything to prevent criminal usages at all,

then the question of neutrality is being raised.

I disagree with, I think technology should be seen as neutral regardless, right?

My personal view.

But I'm just like, also, while it's concerning to see that creators of technology

are being prosecuted for actions of other people,

and I don't think it should happen at all,

I think we take a rather different stance than neutral,

and our focus is to create technology that protects people from crime.

The fact that you cannot reach out to the end,

For example, the common subject, and this was being used in a lobbying of child control legislation in Europe,

is that children are being exploited, right?

But they're exploited by design.

The networks where the children are exploited are designed in a way that children are reachable by anybody.

And there is an open criminal case against Meta in multiple U.S. states.

It's a fascinating read if you look at this kind of witness statements and evidence materials

about how Facebook and meta technology knowingly enable traffic of children to child abusers

because it creates engagement in the network.

It's horrendous.

I think technology should play an active role in protecting its users from crime,

and it should avoid developing technologies that have purely criminal usages.

And that's a moral rather than legal view.

That's what I'm taking.

And it doesn't mean, even if technology is created in a way that...

So I think you follow what I'm trying to say.

I think the prosecution of trying out a developer is completely wrong and corrupt,

and the legal system should not be doing it.

It stifles innovation.

It stifles investment.

It has more harm than good.

And in no case, the developers of technology, rather than service providers,

should be prosecuted for whatever usages this technology has found.

That's my very strong view,

which doesn't mean that technology developers

shouldn't put some thought into how to protect their users from crime

and how to prevent criminal usages.

And again, it's not because they're legally obliged,

but because I think we're morally obliged

to find the ways that protect our users.

Earlier this year, for example,

we published the approach that we're going to take

how we can do privacy-preserving content moderation.

We believe that both community owners, but also server owners,

which have means to respond to user complaints and remove content that they find objectionable, illegal, or whatever, from their servers,

but it doesn't mean that it has to come by compromising user privacy.

So we had lots of conversations about that, and it's very controversial.

But what I'm thinking is we understand the risks, and we understand that there is some war in legal developments,

but we'll do our best to navigate it and to protect our users.

Yeah, I wish it was discussed more because it's a bit of a,

it's a subject people don't want to talk about in the privacy world,

how there are legitimate situations where there are bad things that are done

that can actually be prevented within reason without even invading people's privacy.

And I feel like that is something that should be discussed a bit more.

One of the big reasons that we shut down our matrix server back in the day

was because we kept getting spanned with CSAM all the time from people online.

It's a problem that many other people who host matrix servers were having as well.

And it's not a healthy community to ever be a part of or join.

Or like, you know, my goal is for people to associate privacy and digital rights

with something that's a universal thing.

And then if they join a server or a community that we are officially endorsing that's part of us

and they get spanned with CSAM, that's just bad for everybody.

It's just not a friendly environment.

So I'm glad that that's something that's being thought about because...

We're not just thinking about it.

We're very active in developing measures to prevent criminal usages without compromising privacy and security on everybody else.

I honestly think, right, like having been engaged with privacy community for four years, I'm going to say something extremely controversial.

And I think like if I'm not yet hated enough, some more people probably will hate me for that.

I honestly think that privacy community is compromised and corrupted as a whole.

Hard to say by whom, but probably by big technology companies.

And it really has completely lost its direction, right?

Because ultimately, any kind of leadership should do what benefits most people.

And most people in the world don't care about privacy, right?

They see privacy as a hurdle and inconvenience at best.

And they see privacy as an enabler of criminality towards governments.

And mass media is very united in attack on the right to privacy using this perception, right?

And what I see in privacy community is some reasonable people who really want to help everybody,

educate people, explain them why privacy is important and why it's not a means to an end,

but it really is the way to have individual security, right? Because imagine all your

financial information becomes public. You're likely to lose some money. You're likely to become the

victim of financial crimes, right? Or imagine that your children, like, whereabouts become public.

Again, you're putting the lives of your children at risk, right? So, and this is something everybody

cares about but i think privacy community is very focused on technological aspects of privacy and

legal aspects of privacy and completely doesn't talk to people about how it is a means to an end

that provides people individual security and freedom right ultimately right freedom to live

their lives without effect and and what we see is that the same lobby groups finance privacy advocates

and chat control legislation or non-profits that lobby chat control.

You can look at the list of non-profits that are lobbying,

actively lobbying chat control legislation,

and the sources of funding are exactly the same.

And what we got to is that privacy communities

become completely isolated from the rest of the world.

Literally, it doesn't care about the rest of the world.

All it cares about retaining the narrative is that privacy is a great thing,

everybody else is simple.

That's what we observe, right?

So I honestly think that the narrative of privacy is dead today.

And the best we can do is to refocus our efforts

and to provide some people individual security

and technology that protects them, protects their lives,

protects their children, protects them from cyber crime.

We're not going to compromise on privacy.

But again, I honestly think selling people privacy today

is almost like selling people HTTPS.

What is it?

Who knows what's HTTPS?

But you go to the website and you know it's secure because of HTTPS, right?

You don't know what HTTPS is.

You never heard about it, right?

So I honestly want to be in a world

when people don't know what privacy is.

Don't need to know that.

They just use technology that protects them.

Yeah, there's a lot there.

Yeah, I think, at least on my end,

I think there are a lot of people who see privacy this way.

And I see it a lot.

I know a lot of the listeners on our show

and stuff like this see it that way.

I feel like the people who are chronically online all day,

who like the identity becomes privacy

and then privacy is an end instead of a means.

That's where you see the problem.

But those are also typically the loudest people.

So it's really hard to make sense of everything going on.

But there are a lot of people who see it this way too.

100%. Look, I think what you do is really important

because you're trying to connect the world of,

and you're being criticized a lot for that.

Instead of being focused on the privacy elite,

you're trying to connect those technological concepts.

You're trying to connect the concepts of security

to mass market people, right?

So our engagement with each other

started that you said, I'm not going to recommend SimpleXUp because it's not ready for our audience.

Look, I'm not criticizing.

And when people said, like I said, that's fantastic because it means that this man cares

about their audience more than he cares about a small niche of privacy enthusiasts that nobody

cares about, which is critically important, I think.

And we see it in the same way.

We want really to build technology that will benefit the majority of people and not purely

a niche tool that can benefit only a tiny minority and half of them will be criminal users, right?

Unfortunately, right? It's a mindset shift that people need to make. So I just yesterday at the

time of recording, I put out a video on how F-Droid put out a blog pretty much saying, hey, due to

Google's new developer restrictions, it might kill F-Droid. The whole concept of F-Droid because

Google is essentially trying to end the whole... It's horrible. Yeah, of sideloading. And a lot of

people in the comments, and I actually addressed this because I already did coverage for this

back when Google announced this measure, and now FDroid talked about it, and then I covered FDroid's

response, essentially. A lot of people are saying, well, guess it's time to move to a custom ROM,

or good thing I'm going to move to a custom ROM now, or, you know, it's all about,

it's not about what's, like, the workaround, you know, it's not about what you can figure out to do

for yourself. It's about the fact that like 99% of people are never going to install a custom ROM.

Don't even know what that is. Don't even know what we're talking about. They don't know what

sideloading even is as a concept. To them, installing an app is just going to the Play Store.

And they don't actually know what they're losing because this is a pretty new concept to them. So

it's much more important to figure out like how to take this message and apply it to 99% of people

and make them realize, hey, there's this beautiful thing on your Android device you don't actually

know about that Google's trying to strip away, which is going to over time ruin the ecosystem

on Android and you're not even going to see it happen. That's a better argument. That's something

that needs to happen more than, oh, so how do we get around what's going on for each of you

500 people who know what you're doing? So side rant, but it is something I do see. But again,

when you do speak to the right people, the message is a lot louder. Like that video I put out

yesterday, it's reaching a lot more people than it would be than if I just said, here's how to get

around the F-Droid restrictions that might happen next year. That'll reach not even a hundredth of

the people as if you actually speak to the masses. So I think it's the right approach you guys are

taking as well. Yes. And we want, you're absolutely right, Henry. And we want to build technology for

majority. And that's why we are looking again to raise more funds without losing control again.

And this time we're going to do community-driven fundraise.

There will be, again, we're going to innovate cryptocurrency space as much as we innovated messaging.

So we have created a new design for payment solution for infrastructure capacity.

There will be utility token raised next year.

So there will be some big announcements from us this year.

So we'll announce this with lots of details, how the payments work.

I was talking before about B2B2C model, but that means that people have to pay for these services.

So we figured out the design that protects privacy without going into any compliance and financial regulation territory.

So yeah, I think it's really important to build technology for a wide range of users because then it can have security.

Then it can have resources to provide users.

And it's simply impossible.

If you stay in the niche, you die in the niche.

You simply never get enough resources to get a high-quality product.

People compare what we do with Telegram,

but Telegram has, what, 100 times more investment in the product, right?

Or WhatsApp, which has 500 times more investment into the product yet.

So it's literally impossible to build great and polished user experience

with the niche users, right?

You need to grow beyond this niche to improve quality for everybody.

So, yeah, that's why it's important to build for everybody.

Yeah, so what's next for you guys?

You kind of teased a new payment thing,

but is there anything else that people can expect that you can share?

Our current focus is channels, development focus, right?

So people will be able to host Telegram-style channels

that actually will work and scale to tens

and probably hundreds of thousands of followers.

We see a lot of interest from Telegram communities

to migrate to SimpleX network,

exactly because it gives them ownership of content,

ownership of the audience and control and security.

so that that's one big development that should land this year and at least as some better experiment

and uh for utility token asians this is something that will happen uh next year preliminary plan

end of march but there will be a preliminary registration for this token race so we kind of

working on the detail of this and the announcement should happen within probably this month we don't

have exact date for this announcement.

We're recording in October, if all future people are listening to this.

Yes.

So if it goes live in about a month, you may even have the link to the announcement put

next to the video, what we're talking about.

But I think it's great because I looked at lots of tokenations and they all look like

a scam to me, frankly, right?

Lots of money being pilfered by the people who create tokens.

absolutely we literally want to create a utility token that will be have one current and variety

of future usages that will be used to develop and to provide the technology where uh the team will

not get any any extraordinary financial rewards and no tokens allocated to the team other than

just from growing the business growing the technology growing the network so super transparent

super focused so we effectively will be doing token issuance in a very very focused way and it will be

used to both provide some services straight at the point of issues so that's why it's utility token

so people will be able to pay for channels and for communities to increase hosting capacity to

increase the number of members it can hold so yeah and but but that will also allow to develop the

future technology when the same payment mechanisms will be able to provide payment security and

privacy. So effectively, even if you use usual money to pay for your community, you still can

preserve the privacy of your identity. That can be very important for some situations. You may

publish completely legal content, but it may be sufficiently controversial and you don't want to

be exposed, right?

And if your payment connects to your usage, then somebody can leak this information as

we've seen happening, right?

And then people get attacked in real life for whatever opinions they publish online.

So I think for freedom of speech, you know, it's interesting that my whole motivation for

developing this network was not privacy.

I never thought privacy is an interesting thing, frankly.

I was more interested in freedom of speech.

I historically have a long history with publishing.

In my old life, I owned a magazine.

I worked in several publishing organizations.

Then I led the development team in MailOnline.

So to me, publishing and freedom of speech and messaging are all like two sides of the

same coin.

And I was looking for technology that can really provide freedom of speech and control

to small publishers, right?

Because there is literally no platform in the world when a small publisher, an individual

journalist can engage with their audience and have control of this audience right so that like

whoever gives them service can't delete them from existence like it happens on social networks right

so they either have to trust facebook or twitter to not delete them or they have to go to work to

some large publishing organization which will have their own views about what's right and what's wrong

and to me uh it's interesting that this starts at approximately the same time as noster

If you look at the first paper about Nostra, it was published pretty much at the same time we had the first design of the protocol.

But to me, it was more important to protect people's real identities to achieve freedom of speech than to provide technical censorship resistance.

Because Nostra focuses, okay, let's put the content on multiple servers so it's hard to delete.

That's simple.

I was always seeing it as a simple problem to solve.

And that's not the core problem.

The core problem is not content being delisted, but people being attacked in real life, right?

Their bank accounts being closed or they're being fired from their jobs because they say something unpopular, right?

Or they literally get physically attacked in real life.

And if you really want, you know, like Oscar Wilde said, you want somebody to say the truth, you give them a mask.

If you want the man to say the truth, you give this literal quote from like more than 100 years ago.

Nothing's changed, right?

it's only possible for people to be open and honest about their opinions if their identities

are protected it's really hard to discuss controversial subjects if your identity is

known and it's very important that we can discuss those identities freely and securely

because otherwise society will stagnate it wouldn't be able to get better right so that's that's

That's fundamentally the mission and the vision and what keeps us working.

Right.

So if people are interested in you or SimpleX, where can they find you?

I have an website called simplex.chat.

There is an app called SimpleX Chat on App Stores.

You can connect to our tip right by the app.

You can find some communities on SimpleX Network-wide website.

They're really interesting and vibrant discussions about interesting things.

most are focused on technology and cryptocurrency and privacy and security but some also like about

lifestyle for example there are like some communities about algorithm or whatever so yeah

so so yeah i think i think i think we have a very interesting very small yeah that's very early days

it's less it's close to 500 less than 500 communities there are groups listed in the

directory they're very selective because we really have limited resources to observe but they're great

people. They have their engagement with them and they're contributing a lot to product development

as well. But I mean, opinions, advice, suggestions. So I'm hugely grateful to all these people who

made SimpleX Network what it is. Without people, it wouldn't exist.

Very cool. Well, thank you for your time. I know we were recording two hours. It's going to be a

long one. Henry, I really appreciate you doing what you're doing. That's fantastic. Thank you so much.

And thanks, Evgeny.

And with all of that said,

I want to thank you all for being here

and learning more about how the technology you use

works behind the scenes.

And so you can better educate yourself

as well as the people around you.

I also want to thank Evgeny for being on.

And if you like these free interviews

and you want them to keep coming

and you guys get a lot of value from it,

consider supporting TechLaur.

We have a lot of ways to do it.

There are free methods down below on our website,

which include using affiliate links,

sharing our content.

And of course, there's paid options

like becoming a TechLaurian,

getting access to some of our exclusive communities,

and also getting access to early content

and other things out there as well.

So go check out all the ways to support Techlore.

And thank you all for watching again.

I'll see you next time on Techlore Talks.