00:00 Hello everyone. I just wanted to drop a quick thank you to all of you for sticking with the show through a bit of a difficult season for me where I wasn't able to keep up with Opt Out as I wanted to. Your support through all of this has been amazing and I'm excited to get back into making shows for you, starting with the great chat I got to have with the beginning from SimpleX Chat on today's episode. I have two other episodes in the works that I also aim to record and publish soon and I'm very much looking forward to making more episodes of Opt Out moving forward.

Thanks again for listening and I look forward to hearing your feedback and comments on today's episode. Now, on to your regularly scheduled programming. Hello, I'm Seth For Privacy and welcome to season three, episode two of Opt Out. Opt Out is a show where I sit down with passionate people to learn why privacy matters to them, the tools and techniques they found and leveraged and where we encourage and inspire others towards personal privacy and data sovereignty. Have you heard of SimpleX Chat and curious what it's all about? This episode, we're going to sit down with Evgeny, the founder of SimpleX Chat to talk about SimpleX, privacy, data sovereignty, and his views on the future of computing. Welcome onto the show, Evgeny.

Hello, thank you, Seth, for inviting me. I'm excited to participate. Yeah, I was mentioning it before we were on air here, but I'm really excited to learn more about SimpleX and it's something that has been growing in popularity kind of in the circles that I run in and seeing more use for group chats, for direct messages. So definitely excited to learn a little bit more about SimpleX and I'm so definitely excited to learn a little bit more about it today to get the ball rolling. If you don't mind just introducing yourself and then telling us a little bit about what SimpleX is.

I'm Evgeny. I'm the founder of SimpleX Chat, as you said. I've done different things in my life. The last 10 years I've been doing engineering, leading engineering teams, and lots of things that led to this project. SimpleX Chat is a communication platform that lets users connect and communicate in ways that they used to without having any network-wide identity. So I'll probably talk a bit later how it exactly works, but it provides much higher level of privacy and anonymity on the protocol level.

SimpleX Chat is a communication platform that allows us to use the same platform as well. And at the same time, it's as usable, almost as usable as some popular messengers. So we believe it probably halfway there to usability, but still our users already think that they're going to be a lot more. say that we finally have a messenger that our parents can use, our non-technical friends can use, something that's highly usable and potentially much more private than alternatives that we know about. Yeah, yeah, thank you for that. And that's definitely a thing that I've noticed is it's not kind of the hard to use, hard to recommend UX UI that kind of comes with a lot of the more hardcore privacy messengers. And it's much more kind of signal adjacent in look and feel and usage, which has been been really enjoyable. But before we dive too deeply into SimpleX itself, I'd love to hear a little bit about the motivation and ideology of people who create tools like this. So I'd love to hear what it was that woke you up to the need for personal privacy.

I think privacy is important, but I always have seen privacy as a means to an end. When we begin talking to our users, the question I ask very often is what it means to them to be private. What's the value of privacy and the universal answer that was surprising to many experts in the field when I shared this answer was psychological safety. So I think what's critically important and what we seem to be missing in the modern world is freedom of thinking, freedom of speech is somewhat under attack. It's kind of fair to say what you think as long as you think more or less the same as much as you think about the world. And if you have different ideas about the world, about anything, really any, take any controversial subject, and if you share the views that are different from the views shared on mass media, then you'll be ostracized, deplatformed, you would potentially lose your job, you may lose your friends, etc. etc. And it's very sad to observe because in my system of values, I don't remember who exactly said it, I may disagree with your view, but I will die for your right to express it. Oh, maybe you remember.

So I think it's a little bit more. I think it's a little bit more. I think it's critically important for the survival of humanity to support diversity of views and opinions, even if they're very radically polar to what different people believe. And the main motivation when we started designing SimpleX platform was freedom of speech. And the privacy is a necessary condition to it. Because if you don't have privacy, privacy and if you express your views publicly, then you're likely to face some drastic economic consequences to your life. It may be legal, it may be lawful, but you may lose your job, you may lose the right to publish on a platform. So we wanted to publish a platform that cannot censor its users without due process, right? Because if you've been deplatformed on Twitter, for example, just read the Twitter files, right, in the past, you have no right to appeal, you have no due process, it just happens and you have no recourse, right? It's under terms and conditions of this platform.

And that's what fundamentally undermines the democracy, the freedom of speech and the simple possibility of our survival as suspicious, right? Because if you all think the same, we'll eventually die as a humankind. So yeah, so that was the primary situation and that was gradually warming up. I don't know when it started. My observation was that attack of freedom of speech, like quite aggressively started about 10 years ago in universities where the advent of safe spaces when there was a popularized view that if you're right, if your view offends me, then I have the right to shut you down. And in 10 years, it evolved to being a norm to shut down like critical thinkers, philosophers, journalists, the whole media organizations are being shut down from platforms, from expressing unpopular, or just different views from dominating political views. Again, I'm referring to the Twitter files.

Yeah, I definitely agree there. And it does seem like it's a more recent thing. I feel like it's been growing in academia specifically is where I've seen more of it before the kind of the digital implementation of censorship and de-platforming. But it's something where kind of the benefits of technology can quickly be used and twisted to use it as a tool for censorship, for trying to enforce right think and disincentivize wrong think and ability to strip people of their status in digital communities in order to try and push them to a certain belief system or a certain set of ideals.

Which I love that quote that you mentioned, I think it's often attributed to Voltaire and I just looked it up and it's from a book about Voltaire. But I think it's a very interesting aspect because I think a lot of people can assume that when you're anti-censorship, you just want everyone to be saying all of these things. hateful things or everyone to be able to say things that are wrong. And it's not that I agree with everything people can say. It's not that I think that everything is good or beneficial, but it's more that when we avoid censorship and we debate these ideas kind of in the comment square, when we actually have these debates, have these conversations, and we talk through them, I think that's the best way that we actually defeat true misinformation, true falsehoods, like true hate and harm. And it's much more effective than this censorship approach that's been taken. But that is a really key aspect. And something we've talked about, I could have been on the show, is that idea

of self-censorship too. So just because, and you mentioned privacy as a tool for psychological safety, which I think is a really valuable aspect of it, because a lot of it comes down to what you say and even what you think will be altered if you assume that either this will come back up in the future, that someone can pull this up in the future, that someone is watching or listening to that conversation. If you assume that you don't have privacy in a conversation or even in your own thoughts, you're going to alter the way that you behave. And like you said, you're going to alter the way that you behave into whatever is popular and accepted, which ultimately makes us kind of a monochromatic people that will have issues. Because as we, like you said, as we become more uniform, we become less robust, less able to withstand difficulties. And it's a very interesting piece of humanity that I think we have the potential to preserve through technology, but also have the potential to lose through technology right now with the approach to censorship. So privacy is definitely

something that's becoming more and more important. And I love the approach that you've taken there. Absolutely. So we've learned a little bit about why you care about personal privacy. Are those kind of the driving forces behind why you wanted to step up and actually create SimpleX? I think so. Yes. So the idea for a unifying communication platform that is as robust to operations as email or web is, is what was driving it. The probably genesis of this idea is quite old, but ultimately we wanted to evolve communication protocols in a way that would kind of be decentralized and, you know,

10:00 decentralized i mean there should be no necessary shared state so like there are several levels of decentralization and my definition of decentralization makes every single public blockchain centralized because there is a single shared state that the network has to have consensus about which makes that's the point of centralization so we want to see decentralization on the level of gns or email or web when a single network can also operate if it's multiple partitioned networks right without ever connecting but they can connect so without a need for any shared state so and that would create uh much more resilience to network-wide attacks and much more resilience to uh much more resilience to censorship etc etc so so i do see privacy as a means to an end but our admission we don't see our mission as to build the most private tool because i i honestly believe that as technologists we kind of betrayed humanity and not making it granted right to me privacy should be hygiene factor nobody should even worry about or talk about right you're not talking about like you

come to somebody's home and say oh do you have a toilet obviously everybody has right or sewage or electricity right so i mean if you come into the modern house this is not what you talk about right you talk about important things and we made a hygiene factor a topic of the hottest debates the topic of legislators the topic of i think that privacy is a fundamental human right that should be granted uh without any discussion or uh should be ever talked about our mission is to end these conversations and to make it a hygiene factor and not a marketing advantage so of any product so we just like nobody will build a product that can't run a mobile device right so it's a hygiene factor that it can run on mobile device uh equally the fact that users have the level of privacy they want to have the level of anonymity they want to have we don't we don't aim to forever remain fully anonymous platform actually later this year we plan to build an insular but it will be optional and it will be verifiable unlike the insularies

and many other platforms so yeah fundamentally build the next generation communication platform and not just a private messenger yeah that's fascinating because i think that's a that's a big shift from the approach of of many privacy tools where the focus is build a privacy tool first and then slowly approach kind of ux ui try to make it more approachable but i i definitely do agree even one of the the things that's been central to the way that i approach privacy to the way that i approach privacy within cryptocurrencies is is defaults matter and i want people to have privacy while using a tool that's easy to use that's approachable that maybe they don't even understand they're getting privacy it becomes much more powerful when it's not something that people jump onto because they understand the need for privacy but when they just want to use it or their friends use it or it's the easier solution and yet they're gaining privacy at the same time because like you mentioned that the concept of having to consciously think

about improving your privacy is not something i mean that's that's not a a historical concept like that's something that's become the norm in the last 20 years the rise of technology and this creeping shift towards kind of corporate surveillance and government surveillance but historically you you just had privacy it was just assumed i think that's a key reason why like when you look at like the constitution of the u.s privacy wasn't a key focus there because everyone had privacy you had your home you you had conversations there were no phones to surveil there was no no twitter to uh de-platform people from there wasn't any of that in existence at that point so it very much has been an assumed i think assumed human right in the past but something that we're having to fight for more and more but i do think it's a it's a really important and useful focus to to have privacy not necessarily be the selling point but have it be a useful and extensible platform that also provides privacy as the default and is a key aspect of how

it's been built out absolutely uh the problem is that if you require a special technical expertise or some strong ux compromises or accepting that you have to use inconvenient tools to have privacy then inevitably you end up using a tool that very few people use proportionally and if you're using something that is used by very few people then you automatically have much less privacy right because fundamentally the level of privacy is somewhat correlated with the size of the network right the bigger network the more privacy you have and if the network is very small then you simply cannot have much privacy right so that's why it's so important to have a widely usable tool and even though right now SimpleX SimpleX is a product for enthusiasts with with some compromises and with some limitations we absolutely don't see it as the destination we think we're probably like halfway there in terms of level of phrase we can provide and halfway there in terms of level of usability we can provide by my own standards

this product is like not like barely half done yeah yeah definitely good to keep in mind as we walk through kind of what SimpleX is today and i know y'all made massive progress since kind of the the first time that i had heard about y'all and like i think you were somewhere in your your second version of app release at that point but um yeah that's it's interesting to see and i i think i'd like to talk a little bit about kind of your roadmap for what you want to do later on um but if you had to pick a single thing from SimpleX what's what would you hope that users get out of using it so if i if i were to choose a single thing that people will get is uh security and privacy without compromises or unconvenience it's not the one thing but i think that's fundamentally what users are looking for so they can talk to their families they talk to their friends they can use it in professional contexts and do not worry too much about the level of privacy they're getting so i think that's fundamentally the ambition to create a product that

allows to not make such compromises you know i i i wasn't actually planning to talk about that but i i don't know if you've seen my you can uh you can cut it out if you think it's relevant so uh but let me tell you the story i wasn't going to talk about that but it's kind of uh related of vision technology compromises is related to another open source project which became hugely successful that i did so several years ago probably seven years ago i started building a library for data validation because there were like 12 competing libraries and they all were either fast and not particularly standard compliant or kind of standard compliant but not very standard compliant and very very slow right so and by building a product that uh has very strict standard compliance and at the same time the best possible performance it's faster than the fastest was that existed before this library came to dominate the space it's called library called hva it's got grants from mazillion microsoft it's used by every single modern javascript application these days with 350 million

downloads today every month uh and the simple genesis of the success as i believe was like relentless of a relentless avoidance of the compromise between uh performance and standard compliance which were both very important and i think that private like messengers today uh experience the same trade-off oh and i'm not willing to accept this trade-off so i either have to choose highly usable messengers that provide you zero privacy telegram is excellent whatsapp is excellent right but i have no privacy if i'm using them or i have to use messengers like say catch or session and first in my kind of phone assessment i don't see this design as particularly private because it's based on a fixed user identity right what does it mean if i talk to alice and i talk to bob and alice and bob talk between each other they know they talk to the same person and there are lots of contexts when i don't want it to happen right so for example if i talk to retailer a and retailer b via messaging platform i don't want these two retailers know that i'm talking to

both of them it doesn't necessarily this desire to isolate your communication context doesn't necessarily mean that i want to do something illegal it just means that i want to protect my communication spaces it has economic consequences from not doing so right if i'm negotiating with two parties and both parties can collude because they know i'm the same person they can use it against me so it's very important to have quality when i control each identity shared even in commercial contexts and none of the messenger is provided literally none they may have content privacy they may protect it from observers and catch for example is doing an excellent job but they do not protect me from having my two communication partners from knowing they talk to the same person and the only way i can get this protection is by creating multiple user profiles which is simply inconvenient and it's lots of hassle so we wanted a product that gives you maximum level of communication context isolation without utility compromises because otherwise this just

grows into complex communication hygiene nobody follows it etc etc so we'll see how it goes but but but i think what users say that finally this is a messenger our parents can use is very pleasant that's that means that we're on the right path yeah i think that hits on kind of the difference between privacy and anonymity because like when i look at something like signal it provides strong content privacy um there are definitely some

20:00 drawbacks to the metadata privacy but the core issue that i think most people have with signal is it does not provide anonymity between you and the people at your messaging because especially because the phone number is linked so not only is there a static user but you're also linking a phone number that's often in some way connected to your user identity obviously most people can't get access to the information but it's something that that certainly could be correlated i think that's one of the the key downsides of the signal and well like i love signals approach i love the simplicity and the usability and i've been able to get lots and lots of friends and family using it because of that like for instance i have a private signal and a public signal and i have to run those in two separate user profiles in android and have to have a separate phone number for the second profile and it just becomes drastically more complex even to have pseudonymity and not even anonymity because even then the people can can tell that i'm the same person talking to them if they collude but that's i

think one of those key differentiations and that's a a piece that's only come like the anonymity side has only been possible in some of like the very hardcore messengers things like like briar i think coach can do it as well but again there you're sacrificing and not to bash those projects because i think they're they're very valuable especially for very specific use cases um but the actual user experience is not something that i can recommend my my mom or even my wife to to use or anything like that so having the ability to have both privacy and anonymity that you choose while still having a strong kind of user experience and a simple approach is is really really important um and having that that optionality around both privacy and and anonymity um i really love so i think that's a key focus and i'm glad that that's not something you've compromised on you're absolutely right and actually not only the phone number is the problem right we've all seen in the last several months what artificial intelligence

machine learning can do right with language processing so if you have a visibility of the connections graph even if the peer identifiers are completely random numbers there will be a lot of correlation in activity in a pseudonymous network even if these are not phone numbers with existing public network right so you uh take a public social graph from twitter which is public and you correlate it with a social graph on uh whatever other network which seems to be pseudonymous and you'll be seeing some relations and similarities and some identities will be revealed and some kind of separated communication contacts will also collapse right uh there is some anecdotal statistics that some telephone operators share that it usually takes five phone calls on average on a burner phone to identify a person uh so because because of who you're calling to right because because you may be using different identity but your communication partners are not using different identities and therefore your efforts at pseudonymity collapse because your

communication partners don't necessarily apply the same efforts so we wanted it to be a default so effectively uh we we can talk a little bit about protocol design but fundamentally to have a network design when peers in a network simply do not have network-wide identities of any kind because this default allows to build much more uh diverse communication scenarios and including those that require identity yeah i think this is a great time to actually kind of do a a quick dive into the protocol and approach that SimpleX takes to actually providing privacy and anonymity um and we can we can talk a little bit about about limit limitations and comparisons to other apps after that but i think this would be a good chance if you don't mind kind of um maybe giving us the the quick intro into how SimpleX works how it's designed to provide those things that that you've been talking about uh it lasts quite some time to define what is that uh network topology that we build because it's clearly not a pure peer-to-peer network and neither

it is a federated network and obviously it's not a centralized network so what it is so one uh reviewer has used the term uh proxy peer-to-peer network to describe our design and i like it very much because fundamentally it is a peer-to-peer network uh with the presence of second type of nodes relay nodes uh which proxy all communication between peers uh so in this in this network design clients never communicate with each other directly they communicate through proxies and proxies also don't communicate with each other they even don't know about each other existence so from the view of the relay servers this relay nodes that are present in the network network doesn't exist all servers know is that somebody can create a mailbox on this server leave messages for another party to pick up but that's all you know right those those mailboxes or messaging keys as we call them uh are identified by anonymous credentials and access to them is authorized by anonymous credentials so there is nothing on the protocol level that

creates correlations and that allows to peers in this network not to have any identities of any kind so because their connections effectively have identifiers so instead of having identifiers for peers we have what's called pairwise identifiers so each connection between peers in the network has sent an address and receiving address uh in one direction and also sends an address and receiving address in another direction so yes so you want to send a message to somebody you negotiate and agree which servers will be used to send messages uh they tell you where to send the messages and you tell them where they should be sending the messages and the clients usually choose two different servers for uh direct and response traffic uh if if they know about more than one server uh and and that's it and from the user experience it looks like normal conversations you have contacts you have you may have groups et cetera et cetera so it looks like a uh it's a very usual communication graph but this graph only exists on your device uh and servers have zero

visibility of this graph uh and all servers see is this unidirectional messaging cues because you use different cues for direct and response traffic and there is no correlation between them outside of client devices so yeah that that's that's that's that's in a nutshell how protocol works uh it's very simple it avoids any user identifier it has uh all the qualities of uh otr of the record messaging protocols there is no there is quality of reputation so you like you cannot prove to a third party that your contact sent you the message you cannot prove it to yourself but uh because it uses double rated protocol with symmetric encryption and other good qualities is it's the same protocol the signal uses for intent encryption it achieves a high level of content security same same level of signal achieves but much higher level of metadata privacy because there is no shared metadata between different contexts and not just between different contexts the way protocol is designed it's it's also not trivial to do traffic level correlation because all the

content is paid to a fixed size and there is no identifiers or ciphertext even in common on different sides of the server even if if you manage to somehow compromise cls so it's all well described and there is but there are multiple security layers uh and we keep improving it still hope it makes sense yeah yeah please ask questions yeah it's a it's a it's a complex protocol for sure and i'm glad that you mentioned that it's not just uh it's not just like a signal clone or something like that like there's a lot of differentiation in the approach that you're taking to the to the network itself to the way that you're handling encryption to the way that you're handling hiding metadata specifically i think are really fascinating and i'll definitely link to your white paper white paper in the show notes because i love the threat model section specifically i think it's really really helpful to be able to walk through and see under specific threat models who can know what about the communication that's

happening um and obviously i've done you'll have done a lot of work in preventing even in pretty advanced threat models uh an entity from um definitely from knowing content of messages but even from knowing who's talking to who uh how much they're talking the contents of messages by trying to do traffic analysis like you mentioned you are are padding every block of information that gets sent to and from these relays so that it's hard for even a global passive adversary to be able to make um concrete claims about traffic based on the analysis of the actual size of data that's happening uh i think it's a really interesting approach i think i think the main question i would have um would kind of be what's the reason for going with a proxied relay network rather than going directly peer-to-peer um like something like maybe a briar or something like that that uses tor directly peer-to-peer kind of what's the key advantage that it brings by still having servers um but preventing the servers from

knowing practically anything about the the messages there uh i've analyzed a large number of network designs and i genuinely do not believe that pure peer-to-peer networks can uh solve their fundamental challenges right so the point of centralization for any peer-to-peer network is addressing

30:00 space right it's a unified address space and every single peer will be assigned a single address space and every single peer in the network is reachable so if you have a uniform network with nodes of one kind when any node can reach any node then you automatically get two types of attacks possible first it's a civil attack when you introduce lots of malicious nodes to network and at certain level you compromise the whole network or you can do what's called something like redistributed uh attack when when you when you make clients network to rebroadcast your traffic if even network design so for example prior users say that you can wake up to two gigabytes traffic overnight right that's a that's exactly how like redistributed denial of service attack would work so and it's impossible the problem is it's impossible to solve right so every single network that managed to solve it solved it by introducing a central assert authority there's been lots of effort to minimize uh the probability of network-wide attacks but no comprehensive solution

and like logically i don't see how comprehensive solution is even possible right because if you if anybody can participate in the network there is no barrier to join then ultimately a well-funded attacker can overwhelm the network so and that makes it uh highly centralized because you have single address space so i i wrote about it in our gethub repository uh about fundamental weaknesses of all peer-to-peer designs and not just some specific periods for example tor solve those problems by introducing central authority and tor is a great network but it's not exactly decentralized because it has a central authority that can and then there is a list of all relays right so there are there are upsides and downsides the examples of fully decentralized network would be quite few it's it's dns for example which doesn't have uh which which can operate in a fragmented state so fundamentally we wanted the network design when network can operate in a fully fragmented state when connectivity of the network is a client-side consensus and not server-side

consensus and that requires the presence of relays that introduce this kind of structure and breakdown in in the network structure fragmentation in the network structure so i think network fragmentation and ability to operate in fragmented state is very important quality for a decentralized network and neither blockchain-based networks nor peer-to-peer network don't have this quality because effectively if they go into a fragmented state and don't achieve consensus about the state they will be useless right so they have to eventually reach consensus about the state so another big problem of majority of peer-to-peer networks these are solvable problems but most networks didn't solve them is simple message delivery right so neither patch nor briar i think allows you to send messages when the recipient is offline but this is a fundamental problem if you imagine even scenarios that require ultimate privacy like some whistleblower submitting a report right there may be a window of opportunity to submit this report

and the lack of connectivity to the recipient may undermine the whole effort right or if you're talking about activists who needs to send message to somebody but whatever it is somebody is not online right so you can compromise uh whatever value that network is created by by not being able online and it's not something that that's as easy to control so so yeah so we think that having uh relay proxies is in in the network design is the only way to solve those problems of pure peer-to-peer networks and it also as a nice side effect and obviously design objectives it also achieves peers to not have any identities because again if you have pure pure peer-to-peer network then to reach a peer you need to know peer is address and it again means if if you talk to two people in the network then they know you're the same peer right and the only way around is create multiple profiles but it's not what everybody will be doing we discussed it just before uh and the lack of addresses creates different level of anonymity and

privacy yeah yeah and it's it's interesting i've been doing kind of a deep dive into this network approach because a a new protocol that is it's not focused on being privacy preserving at all but it has the similar concept of um accepting fragmentation being okay with that being a relay based network it's called it's called nostr and it's something that's been built out mostly by bitcoiners um and right now kind of the key focus is decentralized social media and decentralized um ability to basically share information it's it's a very broad generic protocol but has that similar concept of relay based network where you can either try to achieve global state by connecting to lots of relays and being able to to read what other people are sending quite broadly or you can completely fragment off and have your own private relay that only you and your friends use and you can run your own version of everything in that segmented piece um so it's been interesting deep diving into that and now seeing the similarities

a bit with with SimpleX but obviously the key difference is SimpleX is built for privacy preserving messaging by default so it's a focus on privacy while still maintaining that um that relay based network i think which is really fascinating because one of the things that i've i really appreciated about signal specifically is that they've just accepted the centralized server architecture and built out using cryptography tools that prevent the centralized server from having as much visibility and control as possible which is a great thing obviously but it also means that all signal users are still reliant on signal servers and that you can't just like run your own signal server and easily connect to it and use it yourself or fragment off and have your own private version of that so it's a tricky piece of it and that way that means that you have to trust those centralized servers and that you are reliant on that that entity but i think one of the really useful things and we'll get into this a little bit too

is that with SimpleX you can host your own server and you can have your own separate network that like you said you there's no shared state you don't need to be able to communicate back to SimpleX's servers and you can still have all of the same usability of the feature set all of those things by using your own separate relay which is an important piece there but i i do love that that flexibility that comes with that approach to the network and still embracing the benefits of a server based architecture because like you mentioned i mean that's a key pain point for me when using something like prior and one of the reasons why i don't really use it is because it's hard to actually have that window where you're online and the other person is online like we've gotten very used to messaging being asynchronous where we're able to send messages whenever whenever receive messages whenever and handle it freely like that it's a lot more complicated and disruptive to normal life to have to both be available to be able to chat so that the benefits of servers

while still minimizing the visibility that servers have to contents and to metadata is really really fascinating there let's take a quick break from this episode to chat about the sponsors of opt out Cake Wallet and LocalMonero Cake Wallet is a key tool that i use daily as it allows me to easily and quickly use monero for private by default payments it's available in both ios and android it is a fantastic way to get started buying and using monero with a simple and easy to understand user experience i regularly onboard new users to Cake Wallet and hope that it will help simplify and ease your journey into cryptocurrency if you're interested in purchasing monero for the first time or helping to bring others into a parallel economy i'd recommend you look at using LocalMonero like i do to buy and sell monero while maintaining your privacy and avoiding invasive exchange surveillance LocalMonero is entirely peer-to-peer and is an important part of opting out of the surveillance state and into a parallel economy thank you to both sponsors for their incredible support and partnership

and i hope you'll take a moment after the episode to learn more in the show notes or at optoutpod.com sponsors one more question about the architecture itself so you've mentioned a few times that there's no there's no user identifier even two contacts that you talk to if they collude they can't clearly see that that you're the same entity or they can't see that you're the same entity um so how does that actually work in practice like if i want to connect to someone i mean normally when i'm using signal or session or threema i'm sharing a static id that i give them and they're able to connect through that so when i want to connect to a contact within SimpleX how does that actually work how are they able to to find me and communicate with me if i don't have some static id or something well the key is they are not able to find you you have to take initiative and generate a one-time invitation which represents an address on this relay server where you will be receiving messages from this person so once you generated this invitation

an invitation is initially generated as public anybody can send messages to it but it's random and it's unguessable so whoever you share this uh invitation with either as a link it's just a url format for convenience uh or as a qr code uh people would use this invitation and send you a simple confirmation message to the address that you provide this confirmation message would contain both the key they would use in the future to send messages to verify messages they send not sign but

40:00 confirm to the server they have authority to send messages, and also the address of the reply queue for you in encrypted format. It's already end-to-end encrypted, this message server cannot see it because the invitation link contains all key necessary, all keys, all cryptography keys necessary to negotiate double-wretched encryption between you and the peer. So when they reply, they already send an end-to-end encrypted packet to you that would contain both the reply address on some other server and the key they would use on this first server to send messages.

So what you do, you first notify the first server that, okay, sender will use this key. After that, nobody else can send messages. And you make the same process with their server. You send them confirmation messages. So it's a two-step handshake, technically. But from the user experience, you share a link, they scan it, you connect. So it's user experience is seamless, right? So you just have to generate one-time invitation. You share it with the contact.

They scan it or paste it into the app. And connection establishes in a matter of less than a second. Underlying protocol is multi-step. We also support long-term addresses. There are lots of communication scenarios that require long-term addresses. For example, you want to publish your address in social media. The way it works, if the address is long-term, then instead of using it to send messages, it will be used to send an invitation link. Effectively, it increases the handshake on one step, and your contact would send you their invitation link to this address.

In which case, in the app, it will appear as a connection request that you can either accept or reject. And if you accept it, the connection will be established. The good quality of those addresses, they are optional, they're temporary, and unlike real addresses, if you remove this address from the system, all the contacts that are established via this address will not be lost. They will continue functioning. Because this address is not used for message delivery, it's only used to establish the address message delivery.

So that's about how it works. Yeah, that's fascinating. That was another question of mine was how the static long-term addresses worked. Because that's a very helpful piece of onboarding people, but that makes sense. So that you're not actually revealing anything about yourself in that long-time link, but you're inviting other people to invite you to connect, essentially. And at that point, then you can make that connection through relays with the two-way message queues as well.

So yeah, really, really fascinating. That's how that works. And I guess there is that little bit of extra UX hurdle there, and that you can't just in the app find someone by an identifier and connect. So you are having to share something out of band, whether that's in person with QR code, like you said, or sending the invitation link to them through some other messenger or something like that. But because that invitation actually doesn't have any identifier or anything like that, it's not dangerous to share that outside of that.

And seamless, once you do share that, that is one kind of caveat, is you have to share that invitation out of band. Yeah, it's a very common question, actually, how secure it is to share this invitation while are insecure channels. So, and it's a trade-off, right? Because when you share one-time invitation link, you know who you shared it with, and you know who connects it to you, right? If you publish a long-term address, you really don't know who will connect to it, right?

So you only know that whatever profile information they want to share with you. And we have this incognitive mode that allows to generate random profile names for each connection, so it may be a random name. So you're not learning much about it. But if that's the communication scenario you want, for example, you are a journalist, or you are a business, or for whatever reasons you want to advertise a connection point to you, that's what you will find convenient, right?

So about these links when you share them through insecure networks, as long as this network is secure to active attack, and the link cannot be replaced, you just need it to be authenticated. So you have to be confident that whoever receives this link is the person you intend to have communication with, and when they connect to you, you can validate that you're connected to them via the same alternative channel, because obviously, before they use this link, anybody can use this link, right?

So because the connection, it's effectively erased, like in a Panda key exchange, whoever first uses this link will connect to you. So, but once they're connected to this link, this link doesn't have any, it only contains public keys, there are no private keys in this link, so it's not insecure against passive attacks. But if this link is substituted by the attacker, for example, you send it via some channel that will be intercepted, then whoever substitutes this link can potentially proxy all the conversations for themselves, right?

And they would see your messages, et cetera, et cetera. So an app has a solution to that, which is the same in signal and same as WhatsApp recently introduced, is a security code verification. It compares the hashes of associated data in many words. Anyway, it validates that your encryption is direct to each other, right? If your security code, you have an app for your contact is the same as they have for you, then your connection is secure. It means that the link was not intercepted, so you can validate it in the app after the fact.

So if you did, and this might be a little bit too into the weeds, but if you did have an attacker who was trying to substitute that link in proxy messages, how would you verify that verification code without doing it through, I guess you'd want to do a different communication method than you shared the one-time link to prevent the same attacker from substituting the verification code with their own? Absolutely. You're absolutely correct. Yeah. So it kind of gives you the second factor. And if you were, you believe your first out of band channel may have been compromised, then you can use another out of band channel.

And obviously if attacker compromises all the outgoing communication from you, there is no defense from that, but it's extremely sophisticated attack. Yeah. You have bigger problems if all of your outbound communication is tampered with. Exactly. Yes. And compared with, I recently wrote a blog post about why we need to redefine privacy and build it based on pairwise identities. And among other things, it has some ruminations on the key exchange. So I think the key misunderstanding that people have about end-to-end encryption, they don't understand the conditions under which end-to-end encryption can be secure.

So an important condition that the key exchange is not compromised, but we traditionally in all communication platforms that provide us end-to-end encryption use, like imagine you pass somebody a locked box, right? Uh, via courier, it would be sensible to use some other courier to pass a key to this box, right? And of course, this couriers can collude between each other, but if they don't even know who they are, right? If they don't know about each other, it's quite hard, right?

But if you use the same courier to pass a locked box to your contact and say, okay, this is a locked box and this is the key to the locked box, right? Uh, they obviously can look inside this box without you knowing that. And unfortunately, that's how we do end-to-end encryption today. We use the same operator to pass messages as we use to pass our public case. So technically, nothing prevents, uh, operators that provide end-to-end encryption to compromise the end-to-end encryption by substituting the keys.

And yes, there may be verification steps to validate that it didn't happen after. And, but that's not what everybody does. So I think it's very important that initial key exchange happens out of band. And I think it should be a norm that we kind of try to establish our initial connection through another channel than the one we're going to use to communicate. Yeah. Yeah. I like that distinction. And I, to be clear, so what would happen in that scenario of someone intercepting, like for instance, the one-time link, uh, even if they like substitute the verification code or you didn't validate that is that they could, um, proxy messages, read them, and then send them on to the person who you think you're communicating with.

Um, they couldn't create false messages because they don't have the private key that was used by the person you're connecting with, but that they can read and proxy those messages and just essentially intercept the traffic at that point. Frankly, nothing stops them from distorts and communication as well, because like imagine it's like, it's almost like where you shouldn't play chess by, by mail, right? So you, you just read messages, you send whatever you want, you read what you receive, you send whatever you want. So you can distort it as well. So because, uh, uh, you delay or not send messages as well would be the, you mean, you mean, you mean there will be a delay if you think too much. Yes, you have to be pretty fast, but if it's a computer that reads and forwards messages that computer may introduce distortion as well in this communication channel, not just interception. Yeah. Fascinating. Yeah.

There's a lot of different pieces there. So I do like that, that key piece of separation when you do share that, that if, if you're concerned about that, that channel being compromised, making sure that you do the verification through another out of band method, um, for extra protection, it's an important key there. So one more question around kind of the design of SimpleX before we dive into some comparisons with other messengers. Um, but I'm always curious if there are any kind of key limitations that jump out at you that users should be aware of with SimpleX. Absolutely. Yes. So we, uh, initially set out to design an application level protocol that provides application level protection of the identity and a primary source of criticism that have been experiencing since, since day one, that we did nothing to provide transport level protection.

50:00 By transport level, I mean IP address or session address because they also identify users. To some extent, we obviously added support of Tor integration and we added some transport isolation. So for example, when you connect through two different profiles, they will use different TCP connections and even different Tor circuits. But fundamentally still, the current design of SimpleX doesn't protect your IP address from the recipient's server because you connect directly to the recipient's server.

So if you connect to the people who you know and trust, that's not a concern, right? Because if they host their own server and the server sees their IP address and they potentially may log it, but it's not a big problem. But if you are using SimpleX today in some adversarial scenarios when you want to protect. So first you can obviously see which server is used for connection and refuse the connection unless you want it. But the app has a feature that allows to change the server later at the same time.

So fundamentally, you must use Tor today. If you want identity protection on a transport level today, you must use Tor. There is no way around it. We know the solution to that and that's going to happen in a fundamental protocol design within less than a year, probably this year, when we will add a second type of relay proxy into network design. So today there is only one kind of proxies. This is a proxy chosen by the recipient that holds messages until the recipient is online.

There will be a second type of proxy in the network design, the proxy chosen by sender that will hold messages until the recipient's proxy is online. Because recipient proxies can also be offline and it may have low availability. And at the same time, it will protect, provide IP address protection because you will be choosing the server that forwards your messages to the recipient proxy. And that will give you protection of the IP address. At the same time, we're planning to design it with the same low trust to server's approach.

So, for example, this delivery proxy, we call it delivery proxy. The delivery proxy will know the servers you're communicating with, but they wouldn't know how many addresses you have on which server because they would have some end-to-end encryption channel. So they would only forward packets that are end-to-end encrypted between you and the recipient's proxy. So to some extent, it's not that dissimilar with onion routing design, but we want to make it first application specific and fundamentally simpler than onion routing.

And at the same time, it will achieve much less traffic because instead of connecting to, let's say you have 100 contacts, they use 50 different servers, your client will have lots of traffic, right? So delivery proxy will aggregate all this traffic. You communicate only with delivery proxy. Delivery proxy communicates with all those 50 servers. That means your client will have much less traffic. And also if the connectivity is bad, it's not your client retry and now it's your server retry.

So, and that segue to another most common complaint. So today battery consumption and traffic consumption of the app is still suboptimal. It's not as bad as some peer-to-peer apps, but it's not near as good as Signal. So it's probably twice worse. So I say we absolutely see how we can reduce it at least twice or three times before delivery proxy appear, which will reduce it further. But that's still, if traffic and power consumption is not the price you're willing to pay for privacy, then that's probably not yet the app for you to use.

So there's a second limitation. The third limitation, and it's actually interesting comparison with Nostr protocol. So we don't have any redundancy in message delivery today. We do have redundancy possible even in the core applications, not just protocol design, but currently each message is sent through a single relay. If this relay will disappear or become unavailable, then these messages will never arrive to the destination. This is also something that will be improved in a network design within less than a year.

There will be different level of redundancy that the users can choose so that you can deliver messages through two or through three servers, which obviously will have some traffic costs, but at the same time you will be able to have less, more reliability in message delivery. So I think these are the main limitations for the platform. Also another limitation is file size that we support. We actually recognize it right now. So currently files are sent through the same channels as messages.

That's been an early design compromise. We didn't have any standalone solution for files. It's kind of private and secure, but it's relatively slow. So we limit the size of the files you can send to eight megabytes and it takes a bit of time. But we plan to release within less than two months, a very robust file delivery solution, which will be also very exciting. We're actually going to be releasing the prototype CLI client to deliver files within less than a week.

So it will be cutting files in pieces, putting them to different servers. This is probably the most private file transfer design that exists. Yeah, it sounds almost like a file transfer mix net in essence. It's really fascinating. Yes. Awesome. Well, thank you for diving into those. I know it's not necessarily the most fun to talk about limitations, but I think it's really helpful that people understand those kind of going into using a tool like this.

And I also specifically like hearing that you have a plan to address each of these limitations, not just something like, yeah, it's a problem. We'll get to it. It's definitely something that's planned there. And the IP address privacy was an interesting one that when I was digging into that. But I think that is somewhat mitigated and that it's not a true peer to peer design. I mean, that's one of the dangers of a direct peer to peer network is that you're directly revealing your IP address to the people you're talking with.

And if you don't trust that person, that is information you probably don't want to give away. So obviously within SimpleX, you're revealing it to the relay that they provide, which could be a malicious relay. But if they're using like SimpleX as relay, then they're not getting your direct IP address, just the relay itself, which is an interesting compromise. But I love the Tor native functionality as well. And I think that's a very important option for people to have.

Maybe not what everyone needs to use, but a very important one to have readily available and easy to use as a piece of that. Definitely curious to see the delivery server piece as well, especially from like power constraint and network usage. I think that's a very important piece, especially when you can make it very easy to self post to be able to have that and offload a lot of that work to that server and improve availability as well. So it's great to hear that you have a lot of stuff coming up to address those few limitations that you mentioned.

Yes, I actually think it's very, very important to be super transparent about your limitations. Commence it earlier on threat model. So that's thanks to one of our advisors, this document exists. So I think it's exceptionally important to be transparent about what doesn't work or what has limitations. Yeah, yeah, I definitely agree. It's invaluable. And that's one of the benefits too, of being free and open source as well as the code itself is available for other people.

So even if you maybe didn't see a limitation or something, it's something that others can come in and inspect and not just have to trust close source binaries or something like that. So another important piece there. But I think pivoting to one of the questions that will be the most interesting and applicable to people is just, I'd love to hear your thoughts on how SimpleX compares to some of the other common privacy preserving chat apps. Specifically, I think Signal and Threema would be ones that I'd love to hear a little bit more in depth.

We've actually, I know, talked a good bit throughout today's conversation about comparing different details. So maybe if there's just any kind of high-level things that you'd like to point out on the comparisons between SimpleX and those other apps for people. Fundamentally, both Signal and Threema are centralized platforms, right? They have a single operating entity that wouldn't allow you, as far as I understand, to run your own server and still be the part of the same network.

So you can run Signal server and you can create a closed network using Signal code, probably, but you wouldn't be able to have your server participate in a network that Signal runs or Threema runs. And I think that's a fundamental limitation. And ultimately, you have a shared ID for all your contacts that you would use to connect to them. So that's a primary distinction. So Signal did use a lot to the security of communications. And without Signal, we would live in a much worse world, right?

So the double-ratchet is completely ingenious and extremely elegant design. And I think every single communication platform absolutely must use it. In our early days of experiments, we tried some ad hoc approach. We've been torn to pieces by one of our advisors for doing that. So, okay, just use double-ratchet. Stop inventing what you're not good at, right? You have message routing protocol, which is exceptional, right? Just use that. But end-to-end encryption, nobody does better than Signal.

And when we looked deep into their design, it is exceptionally elegant and not trivial and not obvious design that achieves qualities that I don't know if even they can.

1:00:00 achieved another way so like first it's forward secrecy right so like you cannot decrypt past messages so then there is break and recovery so even if attacker takes hold of you past keys then if they don't have continuous access to the device then then they would the device will recover by generating random keys and exchanging keys as part of communication so yeah it's it's a unique design so signal has put some attempts into protecting communication graph as well but uh unfortunately uh and i understand the reason is protect against spam and malicious sectors but when you request a key bundle and signal your identity is still captured so signal servers whether they preserve it or not they see not just your uh phone number but also who you're connecting with by signal so so fundamentally signal doesn't protect your connections growth and and i believe three one doesn't do it either so and i think that protection of social growth is exceptionally important right because that's exactly what all advertising models work on what occasionally some

prosecution is based on the guilt-based association is not lawful context concept but unfortunately uh it does happen when you're being prosecuted based on your association without any other proof yeah yeah that's something that we've we've seen more and more in the privacy space is that while content protection is very very important for a very long time especially like state actors are mostly just working on metadata which would be things like who you talk to how long you talk to them for um when you talk to them in the day the those sorts of things are often more than enough to leverage against you whether in a court of law or outside of the legal system um so protecting that simple metadata is usually as important sometimes more than content encryption although obviously encrypting the content is key as well um but that's a it's an important consideration on that that really has to be part of the design of of any tool that's claiming to be privacy preserving because if that if that metadata is freely available uh even if it's to a trusted

entity that that opens up a lot of risk to the end user um because metadata is is king and uh xnsa guy is famous for saying that they kill people based off metadata so it's it's certainly uh not a not a trivial thing or something that should be overlooked in in designing applications like this yes awesome one last quick question about SimpleX and then i want to get into a little bit of the philosophy that we've been talking about directly that you've written about a bit as well um but the last quick question around SimpleX is i don't know if you've touched on this but i'd love to hear a little bit more about um what self-hosting the SimpleX relay servers is like um and what that actually provides to you as the user if someone decides to self-host that uh it's somewhat a compromise between control and privacy right so if uh it's it's almost impossible well it's not actually completely impossible but it's usually hosting something to some extent reveals your identity and if identity protection with what you care about and by hosting

server you making it potentially less private for you but at the same time if you host your own server it means you control the information that captures about your communication parties and if you want a closed communication network then that's exactly what you would want right so that's that's a trade-off that people have to choose for themselves there are some interesting decentralized infrastructure platforms out there that may allow you hosting service privately as well uh technically it's it's super easy i i believe hundreds of people have done it already with uh our servers uh we there are lots of downloads on docker hub and on github so it's it's as simple as running docker container on any virtual machine uh figuring firewalls that's the traffic on this port through initializing the server uh which the uh it's it's it's a single executable fundamentally unlike many other communication platforms that require database server we from the very beginning thought all right to make it simple to make it easier to manage

it should be single executable it has in memory persistence so so messages until they delivered their story in memory with append on the lock to dump them on restarts so they're not lost on restarts so it's it's fundamentally self-contained executable that doesn't require any other third parties dependencies to run so you can spin it up in minutes i believe plus there are some hosting providers that give you one click delivery already we discovered the tor surprise like a yana host or how do you how do you pronounce offers one click delivery of s&p servers i know quite a few people used it so it is it is very easy yeah i dug into that a little bit i think i'll be spinning up a server hopefully later today or this weekend because it is very straightforward it's something i'm just going to add into existing docker compose that i have and it'll be very straightforward to expose so i'm thankful that that again has been a key consideration in you building it now it's obviously not just a throwaway like yeah you can host this if you want but it's something

that you have put thought into and the the documentation around spinning it up in docker is very straightforward so i'm thankful for that as well so like that's a key consideration and often it is just kind of a throwaway afterthought but i think that's that's very important and i think that's one of the like we talked about before one of the benefits of the the relay style networking approach uh within SimpleX that i do really like so we'll be spinning that up and i'll be sure to share that with uh with other people as well to host group chats that sort of thing so fascinated to dive into that a bit more um but getting into a little bit of kind of the the philosophy i know when we were when we were chatting you mentioned that you see privacy data sovereignty and the future of computing being exceptionally well aligned um i thought that was a very interesting concept and you explained it on a little bit there but do you mind kind of uh fleshing out that concept and and kind of why you think those things are well aligned moving into the future i think i think you

know when i was 12 years old i dreamt about a device that would fit in my pocket uh and meet 12 years old is quite some time ago it was in the 80s last century uh and that would have this device would have all the books ever written all the movies ever shot all the songs ever sunk and it wouldn't depend on any it was somehow magically have it inside so and i think we're kind of halfway there to this vision still because obviously uh i think the original ipod that apple created was closer to this vision than the current iphone because the original ipod uh tagline was a thousand songs in your pocket but now you don't have songs in your pocket you have access to songs uh which is very different really so it means that you don't have internet you don't have songs right so i think uh the future of computing is very client centric and it's central to the price in a way because if if your internet or traffic or data consumption is visible to the observers then the privacy is limited but if your device have the

whole copy of the whole internet updated continuously irrespective of your maybe not the whole internet but a big part of internet you might be interested in right uh then then your access to this internet is private right on the interaction is not private but access is private uh so i i think the term that you you said on the on your podcast is surveillance capitalism right so i think uh and that kind of makes capitalism about thin i don't think capitalism about thin right capitalism is a system that ultimately rewards uh ability to create value right and it's not ethical or unethical in itself people are ethical or unethical and clearly if people are not ethical they use capitalistic methods to do an ethical fence and that creates an impression that capitalism itself is unethical i don't think it is so today capitalism have to do surveillance because it's the only way they can deliver value in digital platforms because technically neither networks nor your device have capacity to bring enough data to your device to avoid doing surveillance right

surveillance right so you can't run sophisticated machine learning networks you can't run you can't store the whole netflix catalog on a single device so you have to have it on some high powered servers and you have to run machine learning models on high powered servers in order to deliver value so and so in order to deliver value capitalism has to do surveillance because if they don't they will send you some random content and you wouldn't pay for it and they would die so i don't think capitalism per se is interested in not delivering your price i think quite the opposite because people recognize privacy as a value and whatever people see as a value businesses will eventually have to provide so so to me a vision the future of computing is that they have extremely like high power by today's standard devices with standard devices with, say, petabytes of RAM memory storage.

1:10:00 and having terabits of traffic as a minimal or maybe hundreds of terabits of traffic. And if you just extrapolate how technology was evolving, yes, it seems like huge and wasteful, but so are today's devices comparing with what we had 20 years ago or 30 years ago, right? I started using internet 30 years ago and I had 9,600 bit a second modem, right? You can't download the sound via this channel, leave alone, so all you can do is send text or images and everything take ages.

It was completely unusable and now we have gigabit networks, right? So, and, but it's not that we can do all the things we can do today on the internet because we have those networks. It's quite the opposite. Nobody would have created those networks if the vision didn't exist. I think vision starts at first and that's actually, it's interesting that this story has been become more popular lately. You may have heard about a company called General Magic.

- I don't think so, no. That was an Apple spin-off created on Silicon Valley. There is a great documentary on Amazon. It's covered in the book by the guy who created iPod, iPhone and after that, Nest thermostat, the same person did that. He was in trend at this company. So their vision was a pocket device, giving you access to everything. It's actually a modern iPhone. They did it before .com in 2000. So it was 90s when they had this vision, right?

And now that 20 years later, this company failed. It lost 100 millions of industries. They didn't know how to build products step by step. So I think that fundamentally the next generation of computing will be client centric with central processing unit architecture that allows us to execute smart contracts locally. So the whole way, I don't think blockchain of today has any viable future because it's the opposite of privacy. But the ideas that's been explored in blockchains today, smart contracts, ideas, blockchain, and some immutability of your agreement, I think that's the foundation for the future CPU architecture.

So, yeah. So effectively you will live in a world when you will be able to consume digital content and pay for it without internet connection from your device in a way that all machine learning models can be executed locally on your device and advertising the work how you want it without anybody knowing what you do on your device. And producers of those contents will be paid. Content will be paid without necessarily knowing who consumes what and on the scenes and aggregates.

So that's for me the future of privacy and the future of computing, which is very client centric that would require much higher network capacity and much higher device capacity than what we have today. And in a way, what we have present today, the platform we build today is already very client centric, right? So like the SimpleX design I have today, I think it would simply not run on smartphones that are 10 years old because you do lots of cryptography, you have to create lots of keys, you have to generate lots of random keys.

I think the first generation iPhone would simply not run Simplest Chat. I think the first generation of devices that can run it and capacity and network traffic is less of a concern. So it's a viable design, right? So the design that brings the data to the user, not when the user needs it, but when the user just may need it, or regardless of whether the user is needed and just make this data available, lead to much more resilient network. And again, if we move into the future when we're going to colonize other planets, we simply cannot rely on network connectivity as a condition to information access.

I think information access should be possible in the absence of network connectivity. So that's where connectivity. I've got to say that is a unique view that I have not heard at all about kind of the future of why a world with privacy will come about. I love that really optimistic vision about advances in computing actually being able to lead us full circle back to a private by default world because we don't need the things that feed into surveillance capitalism.

And I definitely agree on the ideas around capitalism. It's a system that works reasonably well, but it's flawed because humans are flawed and we introduce problems to it, just like any other kind of economic system that you could build. But I think that's the, it's a very interesting thought to think that they do that because it seems like a necessity to them to build business, or maybe even is a necessity to them to build business and kind of the, the middle ground that we're at right now, where you can easily have access to everything on the internet, but you can't store it.

everything locally. I think there is that shift that's happening more and more of client-side computing. I think we've seen that a lot with Android and iPhone specifically, a lot of the computation, a lot of the machine learning around voice models and those sorts of things are starting to be done again on device where they couldn't have been done on device before, but because they're able to build out better compute on the devices, because they're able to build out specialized hardware that's built around these things, they're actually able to offload more and more from their servers onto your own device, which is inherently private by default, as long as that's not being sent out, which normally it isn't in these architectures, but we are seeing that shift even already. So that's a fascinating view and one I hadn't really thought of, and I always enjoy hearing an optimistic vision of the future for privacy, because I think often we can get kind of bogged down the potential dystopian future around privacy, but I think it's really, it's helpful to look at and

envision and, like you said, lay out a vision for what the future could look like in a positive sense with privacy, and I think that's a very useful approach and a good optimistic one. So that's a fascinating one for me. I'm a technologist and I have been probably doing product development all my life and products is about solving problems, right? So the world doesn't, you need some conflict or innovation, but ultimately you want to solve conflicts, right? And there is no fundamental, I think it's, it's wrong to demonize businesses as wanting to hurt people, right? Ultimately businesses exist to create value for people and and yes, we live unfortunately in a world that rewards unethical behaviors, but it will change, right?

But the problem, the fundamental problem is that today we do not have technology that allows both business and consumers to get what they want in a way that protects interests of both sides, because businesses to run need information about consumers and consumers to want privacy. So what's the solution for that? So, so yes, I was thinking a lot about it for probably the last 10 years, what's the way out? And to me, client-centric computing with high-powered devices that have a local copy of the whole intranet continuously maintained is the only answer. And I don't see why it is not technologically possible.

It's just multiply the current capacity by several thousands or, and that it'll be that. And, you know, we stopped actually following the Moore law, right? You remember there was such a thing called Moore law about computing capacity and memory capacity doubling every, what, five years? He said, but the problem is we lost motivation to grow the capacity. We lost vision, right? So we built today's computing on the vision of connected devices. I think the next generation of computing will be built on the vision of disconnected devices that only connect to update information, but don't connect to access information. Yeah. Yeah. I love that concept and yeah, casting that vision, will help to build things now that will help to become that vision in the future.

Yeah. Getting away from streaming services and actually to owning our own data again and actually having that data locally and not under the control of some third party in any moment will be a, that'll be a beautiful thing to return to. So I'm definitely, definitely looking forward to that, to that future. I'm hopeful that that will play out. I'd love to hear, like, with that being your vision for the future of privacy, data sovereignty and computing. How do you see SimpleX fitting into that and how does that affect how you build SimpleX today? Fundamentally, it's affected the initial design, right? So your profile is stored on your device. One of the most polarizing subjects in our users' community is that we require mutual consent for messages to disappear or to be deleted, right? That's lots of written and it's literally splits user community in half and half of users very strongly believe that the sender owns the information and half of the user believes, well, it's my device. I own my device

and the data on my device. And the real answer to that is for the future is smart contracts, right? So when you attach a contract to the message that can be executed on the recipient's device, so like, if you agree that it has to be deleted, it will be deleted, right? Even if the recipient changes their mind, which is not possible to enforce today. So even messengers that kind of do deletion without consent, they can be modified on the recipient side, the deletion won't happen, right? So one of the things, one of the big things we're going to ship, deliver this year is community platform, right? So current, for example, limitation, we talked about limitation, one of the big limitations that the large groups don't really work on SimpleX platforms, because the platform is fully decentralized, you cannot broadcast, you don't have content of your messages stored as elsewhere long term. So to send message to the group, you have to send it to every member of the group. And if the group has several hundred members, you have to have to send the message

several hundred times. It kind of works okay for a couple hundred members, it definitely doesn't work well for a thousand. So for the

1:20:00 public groups that we're going to deliver and a bit later private groups because internet encryption in groups is not a solved problem still. So for public groups, when you join the group, we will offer users the ability to download the whole content of the past. So we wouldn't necessarily consider that the source of truth of the public group should be on some remote server. It may be the source of truth, but you should have a local copy at all times. And then if you do some searches in this information or you do some browsing of this information, your browsing history will not be visible to whatever servers that host this content because you will do searches and browsing locally. I mean, if you want to use your device capacity for that and get more privacy, we definitely offer it as an option. So for example, today you open a Telegram channel to read the past channel or to search the past channel, you have to go to the server. You don't actually store the content of this channel, right? With our communities and public groups, you will have an option to store the whole content of the channel locally on your device,

in which case your browsing history or your search history will not be visible to the community owners. Yeah, I love that optionality because it provides privacy by default because it's client-side computing. I think that is a very important piece of that. I mean, that's the core of even how most cryptography works is you're computing things client-side and sending them in a way that doesn't reveal that information. So being able to download that data locally and then browse is a key aspect and I think that will take a bit of a shift in mentality as people have gotten so used to the that is the kind of a programming approach. So I think that's the kind of a programming approach of not needing to store much data, not relying on anything local and just being able to connect their account anywhere and having everything show up instantly. So it's definitely a change, but taking that personal responsibility into hand and also building tools that make it as easy as possible to take that self responsibility. But taking that understanding that you have ownership of your data with all of the benefits that come with that and some of the downsides will be, I think, a bit of a shift that will have to happen in the mentality of people that approach things.

But really, it has to happen for us to embody that future of client-side computing and that optimistic vision of privacy for the future. Yes, people still do care today about the amount of traffic and about storage being consumed, but that's because I think we still live in a world when memory and storage is artificially expensive. So we could have had much more of either of those at the lower cost if there were applications for that. So, yeah, so you're absolutely right. This change to, so my estimate that the change to client-centric computing we're talking about will take two decades at least, or maybe more than two decades. But that's, as you also said, we also observe it already happening, right? More powerful machine learning being executed, more capacity being available. So yeah, it's absolutely a long process. It's not something that will happen overnight.

Yeah, definitely agree there. Well, just a couple more questions and we'll go ahead and wrap up here. So the last two are ones that I ask kind of every project that I have on and I think are important so people can understand both what drives a company financially and how they can help out themselves. So the first question is just really simple. Just how is SimpleX funded? We've been fortunate even before it became a full-time job for me. It was a hobby project. We started receiving donations.

I just set it up, set up open collective account for SimpleX Chat without expecting any donations, but people started sending it when project was in embryonic state. There was badly wrecking terminal up, which kind of still, terminal still exists. So donations today more than cover hosting costs. So in terms of operation costs, it's already self-sustainable. They obviously do not cover development. And we thought a lot about what's the best way to finance it. And nonprofit models are very popular. And there is some beliefs that nonprofit models protect independence better. And I'm not sure I agree because I looked at many nonprofits that are many commercial companies and how much innovation both of them do. And we very consciously decided that we want to build a commercial business that will be one of the operators on a new kind of communication network that we create. We will absolutely be looking forward to emergence of other operators when it's a commercially viable business and we'll be like integrating them into

the network. But that's the network. But that's the network. But that's the model for venture funded startup. At the same time, the core intellectual property that we create is will remain the protocol design will remain in the public domain. So the core software for reference software. So the core software for reference software implementations will be most likely owned by some nonprofits who are exploring legal structures for that. But high capacity servers that the commercial operator will operate will be available on their service-type public license. That's the same model that Mongo and Elastic have. Right. So if you want to run the server for yourself, not the current generation server, but high capacity messaging servers, which we plan to develop soon.

You can run it for yourself. But if you want to run it for yourself, but if you want to run it for yourself, you can run it for yourself. But if you want to sell it as a hosting provider, you can run it for yourself. But if you want to run it for yourself, you can run it for yourself. But if you want to run it for yourself, you have to buy another license. There is some controversy around service-type public license. For example, the commercial operator will be available under service-type public license.

But high capacity server is available under service-type public license. That's the same model that Mongo and Elastic have. Right. So if you want to run the server for yourself, not the current generation server, but high capacity messaging servers, which we plan to develop soon, you can run it for yourself. So if you want to run it for yourself, you can run it for yourself. And if you want to sell it as a hosting provider, you have to buy another license.

There is some controversy around service-type public license. For example, some foundation, so it's not proper open source. And then you look at the list of sponsors of the foundation and you see Microsoft, Amazon, and Google, who are the major cloud providers. Clearly, this service-type public license benefits creators of the software and not the data center operators. So we think it's the best possible model. So last year, we raised a little bit of Angel and VC Fungeon. We'll be announcing it in March, exactly how much and when. And we plan to raise more money this year again as a venture funded startup registered in the United Kingdom.

So that's our function model to create value via operating the network without owning the network. Yeah. Yeah. I think that's a very interesting compromise. It's, I mean, that's one of the hardest things to answer in the open-source space. And in the privacy spaces. How are you going to build something that's sustainable, but still usable and accessible for the end user? And open-source as well is an important piece of that. So that's something that I think everyone's still kind of wrestling with the ideal approach there.

And even the elastic situation that you mentioned was one that was interesting and divisive and understandable when their shift from a more traditional open-source license into the licensing you mentioned. Because essentially their business was being just destroyed because companies were just taking their code, running it and offering it as a service that was a paid service to their customers, which was causing them to not be able to sustain their business.

So that's, it's an interesting piece. And it's always one that's tricky in this space. So I'll definitely be curious to see the approach that you'll end up taking. But thank you for laying out kind of your vision for that at this point and the VC funding and the donations that have been key to the success up until this point. Yes. So I think we don't plan to make a paid app. We like what signals it for donations. For example, you choose to donate or voluntary subscribe and you get some badges or premium application icons, but not something, for example, the telegram model of premium, I find weird, right?

So like artificially limiting up features in order to charge you money. So I kind of fully applaud when some extra functionality is provided that cannot be provided without additional costs. For example, cloud hosting, right? So we will be adding file transfer and that may evolve into cloud hosting and the long term file hosting is costly. So it is likely to be a premium feature if it happens, right? But just limiting the number of profiles, like people ask how many profiles you can create and can you create and see, however you want. We're not going to make number of profiles a premium feature because it's just, I find it like extortion, right?

So I'm going to turn off the functionality in order that you pay my money. I'm not going to create. So instead of creating value, I'm going to take value from you and that will motivate you. I just find it unfair to the users and unnecessary because you can always find ways to create value and get paid for it. Plus users are willing to pay money even without badges or icons today, right? People donate through Open Collective and we're hugely grateful for that. That helps a lot because it shows that network can be sustainable.

However, small donation, it doesn't matter. The fact that people set up recurring donation for using the app without us asking, without us putting any conditions to that or giving anything in return. I think if this didn't happen, then SimpleX just simply would not exist by now. We would not be able to raise funds. We would not be able to make it as far as we did already. So this is a fantastic and huge help that users can sell well and not just to use, but also donate money for using the app.

Yeah. Yeah. I love seeing that users have skin in the game and want to see SimpleX succeed enough that they're willing to actually give over money to help drive that vision that you have for the product. So it's really encouraging to hear that and along the same lines. Last question for you today, Evgeny, is just how can listeners help to support what you're doing with SimpleX today? Well, the huge and the biggest help is just using the app.

1:30:00 It's an early stage product. It has limitations. It has some rough edges. And by using the app, by helping to improve it, by giving us feedback, ideas and criticism and hammering us for not doing good enough job, they're always helping a lot. I hugely appreciate it. So I think the most serious critics we had, whether they became, many of them became evangelists, many of them remained. It's fantastic. I never shut down any criticism of what they do. We're not obliged to change because of the criticism. Maybe we disagree with that, but it helps to decide what to do.

So this is the biggest support. So create a group on SimpleX Chat. Invite your friends to this group. Have a conversation, whatever you want about. This is the biggest help because the growing usage of the platform is a strong signal that the business that we're building in parallel with the network we're building can eventually become sustainable and generate investment value. So that's the only way it can succeed. So this is the biggest help. So spread the word, use it, create groups, send messages. If you want to donate, great. If you don't want to donate, that's also great. That's great regardless. And spread the word. I think that's the biggest help that's already happened. And I think we've been hugely fortunate by having lots of people talking.

And, you know, and to me, like a tangible shift in social media, like I remember I make some posts on Reddit and there is lots of incredulous questions and people calling us security clowns or saying like what you're saying is just impossible. Like how can you deliver messages? So there's news, right? And you're just lying. And I spent endless hours in the early months of this project explaining how it actually works. And that they're not lying to anyone. We're just doing what we do. It does what it does. And it's so kind of satisfying to see that other users now jump into those conversations and give the same answers that I was given.

I think the fact that it's growing organically is overwhelming. Like I'm hugely humbled. You know, I don't believe I deserve this success, right? We do this project because we believe that's the vision for the future. But we obviously have our, we're doing it for ourselves ultimately. And the fact that users pick it up and use it means that we're doing something right. So if you're doing something wrong, we want to hear about that. For example, when we did some terms of service, we're throwing it in the community.

We want to say, you don't like anything that our terms of service say, please tell us, right? We will change it. We want to have an open and fair relationship with our users forever. We don't want to become a corporation that's close to criticism, that shuts down the debate. Like I was, I wouldn't be pointing fingers, but like one of the private messengers was banging users for discussing SimpleX Chat. Then users told me that I said, you must be lying. I said, no, no, come to the group. They came to the group. They banned me.

I said, okay, fine. Not pointing fingers, but I was a little bit surprised. So why not banging users? Like, I don't mean, obviously we don't even, we don't even see users grow, but for example, the groups that we maintain and moderate and actually moderating tool coming in next release. If people criticize SimpleX Chat, that's great. Right. So that's the only thing that can make us better. It will never shut down this debate. However critical or even if it goes into personal attacks on me, I don't mind.

Yeah, I love that. I love that approach. And I think that the, the idea of building together with your community is such a vital one and will make a much more useful, much more broadly usable product at the end of the day, because there's so many different perspectives of people jumping in with different threat models, different needs, different desires, being able to, to weigh those things and help to build a product together, which is a, an amazing piece of actually building that organic community.

So I'm glad that you've, you've had that organic growth and looking forward to seeing it grow in the future. But that's all I had for you today, Evgeny. Thank you so much for coming on. It was a real pleasure to chat and to learn more about SimpleX. It's, I think one of the most fascinating and intriguing tools for me right now in the privacy space. So that's what I'll, I'll continue to dive into and I'll share a longterm connection link in the show notes as well for anyone who wants to test it out by, by shooting me a message.

But thank you so much for what being willing to come on today, Evgeny and chat about SimpleX. Thank you, Seth. That's been a pleasure. And thanks a lot for very deep questions and for the effort you're putting into understanding what we do and helping popularize it and promote it to your listeners. This is, I was absolutely thrilled to get your invitation much earlier in a product lifecycle that I think we deserve this level of attention. So thank you so much. It helps a lot.

Yeah, absolutely. And looking forward to chatting in the future as well as you release some of the features you talked about, expand, definitely be a situation where I'll want to keep checking in and hearing more about what you're building. So yeah, thank you again. Have a great rest of your day. You too. Thank you. Thanks for listening. And I hope you enjoyed this episode of Opt Out. Well, if you did, please take a moment and subscribe to the podcast.

Or if you're already subscribed, share it with one friend or family member this week. As always, you can check out the link to the guest content and contact info, as well as links to all of the tools we discussed in today's episode. Now get out there and opt out this week.