A (3:40)

Hello Matt. Thank you very much for having me excited too.

B (3:47)

It's, it's a pleasure sir. I. By the way, Freaks, I think the, the way this came together is kind of cool. He found my Simple X contact on my website, Odell xyz and messaged me on his own app and reached out and then we got onto a phone call and I have to say the audio calls are working quite well now in Simplex and we set this up. Pretty cool how it came together.

A (4:10)

That's true indeed. Yeah, we're using Simplex Chat as the only communication tool obviously since we began building it. And yes, phone calls are fine there.

B (4:23)

I have to say sir, my whole life I've been fortunate enough to successfully have moved the majority of my communications to Signal, which is great. Massive improvement over regular phone calls and texts and emails. But when that thing goes down I feel quite vulnerable and we've seen a couple outages lately, so I'm very grateful that you're building Simplex. I think a great place to start here is just high level. What is Simplex? Why does it exist? Why should people care?

A (4:53)

I think my primary motivation to start this, to design the protocol and to build it, was never about technology. It was about all the sad state I've been observing the world is going to. How people were losing their jobs for stating the truths. And it all has become more and more pronounced in the last couple decades. So I should make some embarrassing admissions probably. I was never deep enough in any of the cryptocurrencies world. It was alien to me. I was never deep enough in privacy community. I didn't know it even exists. But I wasn't publishing. I spent a large part of my life in publishing from different angles as I worked as executive in publishing organizations. I owned a magazine in my home country. Then I worked as a head of engineering at MailOnline, one of the largest tablets. To me, publishing and communication was always one of the same. And to me ability to say the truth is fundamentally foundational for the society. Right? If we can't say what's right, what's wrong. If we can't say what's truth, we can no longer exist even, right? Because everything breaks. And when we were building the simple X retrospectively, we can say it's built pretty much on the same values as Bitcoin. It's sovereignty as primary value, primary foundational truth that we build on is sovereignty. Users should own their conversations, their channels, their connections, their identity, everything that they use. The fact that we build protocol by removing network wide identity for the users means that now users own everything, that now they're in full control. In the same way you hold your Bitcoin keys, you own your simplex identity, and your identity is what your friends see, what your contacts see. And it's not something that exists on the network, that's why you want it. And the second principle was that it's trustless, right? So we always thought that. I always thought that if a technology is built on the idea that for it to function I have to trust my technology provider, then it's not good enough. Because today technology provider can be practicing don't be evil principle and tomorrow some pressures come along and it all ends up quite evil. And we've seen it over and over again. So the only way to make it not happen is to architecturally prevent it. Right. To build technology in a way that single provider cannot act against users even if they want to. Right. So it's like sovereignty, and sovereignty has always been number one value here. So like, we had a lot of discussions with privacy community. Obviously privacy community was the first to discover what we built. And obviously they had their own ideas about how we should build it. And traditional privacy messenger would be like, you can always delete messages you send, even if they lend it on another person's dividend device. Right. And this kind of approach was kind of more and more pervasive and happens in telegram, it happens in, in imessage. I think to this, at this point we've been consistently refusing to do it this way because to me it was like, I have files on my computer, I have to allow somebody else to delete those Files. It's just wrong. Right. So I have sovereignty on my machine, right. Why should it happen unless I agree to that? And that's what interesting. So like whenever privacy and sovereignty were in conflicts we're saying sovereignty is foundational both for security and for priv. So fundamentally that's why we're building. We wrote some philosophical almost statement recently. It's on our website about we don't see privacy as some add on. Right. It's not like a shield and key, it's not a measure of protection. It's just literally a thing that always existed. Right. We always had privacy before the Internet. We could talk to people, right. And nobody knew that who we are talking to or nobody was tracking where we go, nobody was tracking who we talk to. And we could have genuine conversations. Because this whole ability to have genuine conversation with people is predicated on the fact that nobody else knows who is talking to whom. And that was the whole premise to return it to the. To return communication to pre Internet state. Almost right. When we can trust the. The environment.

B (9:20)

Incredibly well said. I mean this is something that I bring up all the time. I think first off people don't realize the human condition is to accept the status quo as something that's always been. But we've never lived in a society that is as digital as it is today. And it's getting increasingly more digital. Our lives are increasingly more online and as a result we've lost a lot of the implicit privacy and sovereignty aspects of non digital life. And we need to protect it. I like to distill it as I say, no privacy, no freedom. And no freedom, no wealth. They're all interconnected. And that no wealth piece I think is really important when we're bringing it back to bitcoin specifically. But if you don't have freedom, it's not your wealth. Someone else controls it. I just want to apologize real quick. I did mess up the intro so I'm just going to run through real quick. Today is March 20th at 1700 UTC. The current block height is 941454. Current stats per dollar is1432. That brings us to a Bitcoin price of $69,792. And one Bitcoin will get you 15 ounces of gold. Right now we're up on the one day, one week and one month chart against gold. Sorry about that interruption. I want to talk. So I didn't realize your background is publishing. Is it? Were you, were you an engineer involved with publishing? You came from the Free speech side basically, not the privacy side.

A (10:50)

It's hard to say what was my background. I, I always enjoyed coding but somehow it happened that I only did coding as a hobby for my own businesses. I, I probably am just entrepreneur who is doing what works. I spend a lot of time in different businesses. But yes, so I wasn't originally I was on publishing as an executive, not technology executive. I moved to technology full time about 12 years ago or a little bit more maybe 14 years ago. And yes, I was working at Mail Online on technology side. But yes, I came to this design from freedom of speech angle. And interestingly Simplex protocol was created, invented, you can say pretty much at the same time when Nostr protocol was invented. But to me, you know this XKCD comic, when one guy, one nerd says to another or his computer has like, you know, that's right, like 4,906 bits of RSA encryption.

B (11:49)

It's kind of the five dollar wrench one, right?

A (11:53)

Yeah, go get five dollar wrench. Right.

B (11:56)

We joke around in Bitcoin that with inflation now the Wrench is like $20.

A (11:59)

But yes, yeah, exactly. So and to me, to me like freedom of speech is just impossible if you cannot say, say the truth without revealing who you are. Right. So privacy is not about, I think it's like it's inside Cypherpunk manifesto, right? Privacy is about selectively revealing yourself to the world. Right. It's not about hiding.

B (12:19)

Right.

A (12:20)

And depending on what you say, you may want to say it under your name or you may want to say it under a pseudonym. And it's essential to ability to criticize powers, it's essential to ability to share some uncomfortable truths. And that's what it all was about. But when we designed the protocol for private, for, for publishing that's resistant to attacks on individuals, we said, oh, that's a messenger protocol. Clearly what we did. So why don't we make a messenger first?

B (12:47)

Right.

A (12:48)

And we are just now approaching to the piece of the technology that they always originally wanted to build as effectively as the publishing channels. Large communities that can scale where like weeks away from launching the first version of scalable channels on Simplex network, like

B (13:05)

a better version of telegram channels or telegram groups, right?

A (13:09)

Yeah, we had like large telegram communities that literally tried to migrate to Simplex network. Obviously that didn't work because like the current implementation scales to maybe thousands of members reasonably well after all the improvements, but not to tens of thousands as many telegram communities have. So yes, so we have a lot of interest from telegram communities Too to use the network because they would own that. Right. We developed in a way that each community can run on multiple relays. So in a way it's a similar design to Nostr with regards to censorship resistance, but it's very different design with regards to privacy because to publish on Nostr you have to connect to Relay. To publish on Simplex channel there would be no direct connection. The connection to Relay will be through the messaging network, which means the privacy is preserved on the transfer layer.

B (13:58)

Yeah, I mean let's dive in here a little bit because to me I've always considered the two protocols. I mean it is interesting how that works out, right? That they both get birthed around the same time, that they're more complimentary than competitive in terms of their feature set and use case. I mean specifically Nostr is kind of trying to solve this one to many problem as a broadcast protocol. First, if I want to broadcast to the world my thoughts, something like Twitter. Right. Would be a comparison that, you know, that's the kind of use case Nostr is trying to solve. And then also on top of that kind of goes hand in hand is an associated fixed identity that can be as public as you want it to be. Right. You can be, you know, it doesn't, it doesn't require permission to create these identities. You can have many disposable identities but most people are using it in a way that, that they're connecting it to some elements of their real world life and their real world identity and then they're using it as a broadcast medium and discovery protocol. And then with Simple X, you know, you have rotating identities, maybe you use different identities fluid in app with different people and different groups. And it's more like I would compare like if Nostr is like the soapbox that you're standing on the corner broadcasting your thoughts to the world. Simple X is maybe the dark pub where you're with your local community having a beer and talking about really important things that you maybe you don't want to be on the record about, but you just want to have free flowing conversation. Now when you start getting into the channels and stuff, it gets a little bit different. Right. Telegram channels, I would say Telegram is the behemoth in the room. That's why we're going to probably keep bringing them up. You know, they have 2 billion users at this point and they make a lot of privacy claims that technically are.

A (15:51)

Yes.

B (15:51)

So there's a decent amount of overlap in the communities. But Telegram channel. So Telegram first started as dms, then they had group chats. Group chats, I would say I would put more in the pub kind of scenario until they get bigger. Sometimes group chats get big. They're like a thousand person group chats. Then you're in like an auditorium maybe or something. But then telegram channels are like more of a competitor to broadcast media, whether that's Twitter or Noster or something like that, where the actual participants are not able to interact. More so than maybe there's a comment box or maybe there's emojis, but it's really one person broadcasting to a bunch of people. And the reason I bring this up is because net net, you want those telegram channels or large groups, I think you can kind of put them in the same small groups and, and personal messages. DMs I think could be in the same group and then large, large groups and large channels can kind of be in the same group. Net net, you want them to be end to end encrypted. But you always historically have the problem of all it takes is one person out of 2,000 people to be compromised or their, their phone compromised or themselves would be against whatever the group is and they can be recording everything that's happening in there. So as you move into that feature set, how are you thinking about, how are you thinking about privacy in that scenario? Right? Because like if, if there's a thousand person group you. Once again, I think it's important that it's end to end crypto regardless. It's the basis that everything's built on. But if one journalist is in there or whatever, just writing it up in the Wall Street Journal, then how much you know, how are you dealing with that? How are you thinking about that?

A (17:28)

I think Matt, we all have tendency to conflate what privacy means and here we're talking about two different aspects of privacy. I 100% agree with you that once group is free to join, right. And anybody can join, then it's unrealistic to expect any degree of content privacy in such group. And it's just dangerous to rely that there is a content privacy. Because if you expect privacy but there is no privacy, then you may be saying something as if it is private conversation. But beyond thousand, that's by the way, the basis of my scathing criticism of MLS as specification. Right. You know this message, layer secrecy I

B (18:09)

wrote, hey, I was going to bring that up by the way. It's not a surprise that you came out of publishing because your blog is one of the best blogs in tech to follow, by the way.

A (18:18)

Thank you you're too.

B (18:18)

Okay, continue. You have a blog about mls, which is what signal wants to move to.

A (18:24)

Look, I think it's nonsense, frankly. We can talk about it. No, actually what was implemented on top of NOSTR with white noise is a different thing. Right? Because they correctly identified the weak spot of MLS design and they completely sidestepped it because noster identity is the. So effectively authentication is bundled with identity, but I would even say it's almost like an edge case because in majority of systems people don't see key as identity. Right? People are not hardwired to kind of equate identity to the key. I mean, Bitcoin community is very hardwired to equate those things, right? Or just generally cryptocurrency community. But a normal world identity is a name, right? And how do you know that this name.

B (19:07)

Phone number.

A (19:08)

Exactly. So something secondary, something which is not cryptographically strong. And how do you equate this identity to something? So, yeah, MLS tries to solve the problem of key agreement in large groups, but it's kind of futile because it all depends on authentication service, which still depends on provider. Right? And the whole point of end to end encryption is to protect from providers. So effectively we need to trust the provider to protect from provider. And to me it's like a logical impossibility. I only wrote this post because I was asked by like 20 different times, members of our users were chasing me and asking me to explain why we are not adopting MLS. After I explained it like 20 times, I said, all right, it's time I write something about it. So it's not like I had some kind of vested interest in criticizing mls. But the point is, once the group goes beyond thousands of members, there are two possibilities. It's a public group, it's publicly available, and content is impossible to protect. And there is no point trying. And it's wrong to expect that's protected. Another possibility, it's a corporate group, right? It's hosted on corporate servers. Right? So however much we may all hate corporations, they exist, Right? And if it's on their servers, again, it's about protecting their servers and not end to end encryption.

B (20:20)

Yeah. And to be clear here, Google has 190,000 employees, right? So you can easily imagine a 5,000 corporate group.

A (20:28)

Exactly. Yeah, exactly. Right? Yeah. So, but why do they need MLS for this case? Right? So who are they protecting it from? Right? They just need security of infrastructure. They need discipline. They need proper OPSEC and Google. Right? So they don't need MLS for that. So they may Use it for some cases. But it's still, it's still unclear why would they use it? So, but, but reality, the main thing about privacy is participation, privacy, I think, Right. Because we've seen it all over and over and again that not only publishers are being like, deplatformed, debanked, fired from jobs. Right. Or worse. Right. So, like, it doesn't matter that, like, if you're being dragged to court for whatever you said in public. Right. It doesn't. I mean, it's kind of great that the legal system is not completely broken and eventually you are released without verdict. Right. But the problem is that the whole process is the punishment. Right. You're being dragged through interrogation, you're being dragged through court process. You have to waste money on lawyers, you have to engage with all that. Yeah. So the process becomes the punishment, and that's the problem. So publishers kind of learned if they publish something controversial, they have to do it behind a pseudonym. They have to do some reasonable OPSEC to protect their identity. Right. And rather, even if they say legal things, there are some strong and powerful people who don't like those legal things to be said. So they protect themselves, but their audiences may not do that. Right. And we've already seen people in various countries, it happens in some, even European countries, unfortunately. And it happens in Russia. Right. You like something and the next thing that happens, you don't even comment on that. You simply like something controversial and then you're being riddled with some fine for like and thin, which.

B (22:12)

Or maybe you're not even liking it. I mean, you're just in the group as an example. Yeah. You're in a far. You're in a. You're in a certain politician's telegram channel, and they're just taking a full list of who's in the group and using it against you.

A (22:24)

Exactly right. And that's what's critically important. Privacy of participation is very. So we currently live in a world when some powers believe that they have to regulate not just what's being said, but also what's being listened to. And it's even more dangerous. Right. So people want. And there is no law for that. Right? There is. No. It's. It's completely outside of legal process. So it's completely outside of any precedent we've had, we've seen in history. So people reasonably want to protect their identities and they don't want to conflate their identities. So in Telegram, if you follow 20 different channels, then everybody knows all the channels you follow. Right. There is a Picture, right? And next thing that happens, you're branded as a conspiracy theorist and it's not the worst outcome. So unfortunately Nostra has similar thing, right? So either I have to have a discipline and create multiple profiles and it's just inconvenient, right? I have to think about it and I have to go through the hoops and like all the applications don't really make it simple to create alternative identities just for participating, right? So you end up just joining with the same identity and now everybody knows what, what you're reading, what you're listening, what you're engaging with. So what Simplex protocol achieves is that every time you join a community, it's the next set of keys, it's the next set of addresses, it's the next set of credentials, and your participation remains private.

B (23:43)

If you want, it's a new identity

A (23:45)

by default, it's not even a new identity. The network doesn't operate on the concept of identity. I think, let me explain. I think, I think it's important to understand that we didn't really build one thing. People think that we built one thing. But even if you take our earliest white paper, like written in 2021, even before the business was started, so it says very clearly, so we built a network for delivering packets between applications because this was the missing bit in the World Wide Web, right? I was web developer, I just wanted a channel on my website, right? Right. So how do you do it? You need a messaging protocol to achieve that. To do publishing you need messaging. So we created a transport network that allows to deliver packets between the endpoints. And this transport network today already used beyond Simplex jet application, it's used by low end devices. People experiment with IoT devices using Simplex network. One substantial distinction of this transport network was if you look at the Internet, Internet is a transport network. What Internet does, it has endpoints like devices, right? And it deliver packets to the endpoints, right. And intranet uses what's called endpoint addressing, right? Each net, each endpoint is assigned an address, right? We flipped it upside down, this design and said, okay, we're not going to assign addresses to endpoints. For various reasons, it compromises their security. It also compromises their battery consumption. Because if you think about mobile devices, right? They don't have fixed address, they keep switching between networks, they assign dynamic addresses. So the problem that network initial intranet was quite symmetric, right? All net point, all endpoints had addresses, right? Fixed addresses. And now Internet evolved to the point that some kind of nodes we call servers, they have fixed addresses. But all other nodes and user devices, they don't have fixed addresses, they have variable addresses. And that makes addressing really hard. It makes asynchronous communication really hard. It makes all application really hard. Because in order to receive messages, you now have to, you have to go to the server and ask, keep asking, do I have messages? Do I have messages? Do I have messages? People believe that's how simple X network works, but that's not how it works. The problem with this asking is that you lose power every time you ask. So we said, okay, what if we design transport network in a very different way and instead of assigning identities to the endpoint addresses, we assign addresses to connections between the endpoints. And that's how Simplex network is built. We simply built a package routes in network when address is assigned to connections between endpoints. So every time you want to connect to endpoints, you create a connector and slap an address on this connector. And that's it. That's all the innovation was about. Flip the address and scheme upside down and instead of assigning addresses to Endpoint, you said the audience is quite technical, so I hope I'm not going to dip you tell me if I'm going to duplicate. So that's the whole idea, right? Assign addresses to connectors between endpoint and it solves two problems. It solves problem of endpoint security because the second endpoint address is known to the network, it can be attacked and it solves problem of power consumption because if Endpoint cannot have fixed Internet address, it becomes problematic how to connect. And what Simplex nodes are is routers that route packets between endpoints. So endpoints use these routers or routers, however, depending on which country you're in, I guess so to deliver packets between endpoints. That's what we built. And then we said, all right, I have experience of building open source applications and I know that if you build a component that's not used by end users, it's really hard to make it valuable. It's really hard to make it into every business. It's hard to get adoption because you're effectively built a technological cog in a large wheel and you have to convince people to use. I'm talking about my library for data validation, right? I built like starting from 2015, I built a JavaScript library that now has close to a billion downloads every month because it's used probably by like, I don't know, most JavaScript applications. Depends on it is right. It's one of the biggest used libraries because it's an independency chain of many applications. But most people don't know it exists because it's a little cog. Well, not so little. It's a highly reliable cog in the wheel that's surviving AI led attacks right now people try to find highly reliable. It's been highly supported, used by lots of people. My kind of thinking when we design this transport network is we'll have to build application in parallel. We cannot just build transport network and hope that it's somehow used. We have to build some application that uses this transport network.

B (28:25)

You're proving the use case effectively.

A (28:28)

So we build a Simple X Chat. And what is Simplex Chat? Simple X Chat is a peer to peer messenger that uses this transport network. And the fact that Simplex Chat doesn't need identities for the end users is a direct consequences of transport network not having endpoint addresses and instead having connector addresses. So and these two things have been evolving in parallel. They live in different code repositories. They obviously Simplex Chat application uses library provided by Simplex Network software. But for us it's always been like two things. They're evolving in parallel and try to make this whole ecosystem work, but together. Right. And that's the foundation of technology we built.

B (29:09)

That makes a lot of sense to me. I mean, so the dream is that you have that there'll be many different applications and use cases on top of this protocol. But Simplex is the first one and it's paving the way and proving how it works and how resilient it is. Right?

A (29:26)

Correct. Simplex. Yes, correct. Yes. We see Simplex Chat platform also as a potentially platform for applications similar to a browser. Right. We're already playing with the idea of adopting programming language that will enable to have widgets in a chart that have some custom interactivity, et cetera, et cetera. So Simplex Chat in itself is also like a platform you can develop on. And people already develop chatbots. Right. So there was like I was very excited to see that guys from Unstoppable, you know, you know this unstoppable wallet people probably. Right. So they developed a chatbot that allows to do swaps via Simple X Chat chatbot. And the good thing is like you're doing swap without connecting to any server, without exposing your IP address, without sharing your transferred information. You're effectively. Yeah, there is. It's not completely trustless, of course. Yes, you trust some swap providers. Right. But Simplex Chat itself is rather trustless. Right.

B (30:21)

And you, the communication protocol is trust minimized.

A (30:24)

Yeah, yeah.

B (30:25)

And private.

A (30:26)

Yeah.

B (30:27)

And I mean it makes sense because I mean I do think, you know, I think the truth is somewhere in the middle and there's a lot of hype. But I, I do think the UX of how people interact with a lot of these things is moving to like the AI chat interface. We're like going from, we're going away from the world of point and click and more to the world of ask and get. You know, where you're like just asking an agent for something and then it's the question becomes, and we've seen it with the openclaw movement, which is the fastest growing open source project, end user, open source project of all time. Everyone's using Telegram or DISC centralized and not private at all. Right.

A (31:04)

100% and I agree with you. You know, I was a CTO at startup that was selling fashion via WhatsApp. Right. To me, commerce moving to messaging environment, all interaction, the services moving to messaging environment was like inevitable future of technology because this whole kind of point and click interface that requires a lot of like thinking about what to point and what to click. Right. And sometimes just want to ask. And the constraint was always an intelligence of or like some ability to interpret our requests if they're set in plain language. Right. And we certainly passed the point when we can get very valuable responses from LLMs. Right. But the problem now is that the whole kind of communication pipes around LLMs are extremely insecure. Not just LLM provider can read what we say but like all the transport environment around it is not quite secure. Plus we are not private with that. So I think what we're building can be an interesting transport layer for interacting with models.

B (32:10)

Yeah, I mean you especially see it, the commerce as messenger in the developing world. Like whenever I'm in Latin America it's very obvious and I mean to tie it back to Bitcoin again the number one way that people do P2P Bitcoin trades is through WhatsApp is through existing messengers, not through like application interfaces. They're, they're going into WhatsApp. They have their broker, dealer or whatever and they're just messaging them directly there and exchanging information. I, so I want to pull it back for a second. The, so the key here, the, the simplex servers, right. Anyone can run a simple X server. The, they are, they're routers, they're routing the communication between each other. How heavy is that burden like and what trust is being put in the server by the users?

A (33:07)

The burden that router holds is very much Dependent on the traffic. If you're just running a set of routers for a small group, you can have single core virtual machine with like half gigabyte of RAM or even less super minimum. Yes, yes. It's extremely low resource consumption because all it does, it receives a message. We, our default implementation doesn't use any database layers. It can run on like it's a single executable that keeps the state in memory with a fallback state in a depend on the logs. So effectively it wouldn't lose the connections even on hard reset. It may lose some messages on hard reset, but if it terminates normally, it wouldn't lose any messages. It will persist them on stop. So we don't run this in memory servers anymore. For those that are preset and app we use postgres database for that. And we know quite a few people who migrated to postgres database as well who run them in their companies or in their working groups. So they use those routers for. With Postgres databases. With high traffic it's more efficient but still we're talking about relatively low power machines or virtual environments that can transfer millions of messages.

B (34:31)

So I'm just trying to like, I'm trying to key in here on what you perceive as. Yeah, go on.

A (34:39)

You said, you asked, the second question you asked was trust, right? The level of trust. Yes, I think, I think we probably thanks to our advisor, we have been very explicit about trust model. It's in our white paper. So servers obviously can routers disrupt communications, right? So we trust routers not to do it. But what they cannot do is important. They cannot compromise end to end encryption because they do not participate in key exchange. Key exchange happens out of band. They cannot drop messages undetectably, they cannot insert messages undetectably. So the best the service can do is just delay communications or like send loads of spam traffic to the end user's device.

B (35:22)

Like reliability and uptime is the trust basically, right?

A (35:25)

Yes, yes, effectively. And with servers with the routers that we run, we had not much problem, right? I had like very funny situation when somebody who I connected like on the day of the first mobile app launch four years ago recently messaged me and said hello. I said okay, it was like four years ago. The connection somehow survived through all this time. So yeah, so we aim to minimize the trust. And also if initial design had a single router in a message passing chain and obviously even though on a simple extra protocol layer, servers don't have identities, there is IP protocol layer. Right. And if server can. If router can observe IP address of one party and IP address another party, then they can see who talks to whom. So on IP address level, right, so we change this routing protocol. So now messages are passed always through two routers. So even though the first router and the message passing. Okay, so each conversation is four routers. Right. When I say two routers, it's a one way communication. Right?

B (36:28)

Okay.

A (36:29)

So I can be messaging you through one router and use another router to connect to yours. And when you're replying you also would be using two routers. So effectively you choose the routers to receive messages from and I choose the routers to forward the messages to your router.

B (36:48)

And they would all have to collude to connect the.

A (36:52)

It's really hard. Yes, they'll have to. And it's really hard because it means they'll have to do some coordinated protocol changes and introduce some additional metadata in the message envelopes. So I would say it's not impossible. Of course not. If routers collude, they can do time and correlation and compare those things. But. But the technical bar is quite high and the clients are already programmed to use router. Not just different routers, but routers of different operators. We introduced the concept of router operator. UP understands that and it will tolerate has two preset operators right now there will be more so and if you yet add your routers, then it will be a third operator. So UP knows this concept of not just router, but of router operator and it chooses different operators, so different entities. That was my biggest criticism of Tor, by the way, because Tor network is built on the idea that you choose three relays on a packet passing path. Right. But you don't control the relay choice or you have limited control over relay choice. Right. And we know that there are large entities separating those relays on Tor Network and we know that there are entities who sell traffic data as well. So effectively this whole kind of idea that different servers, different relays means that they don't collude is kind of questionable. Right.

B (38:11)

The whole model is based on at least one honest actor in the route. But if it's all the same actor, then the assumption breaks down.

A (38:20)

Exactly. Yeah. And given that you have limited control of those, again, there are some advanced settings, but by default you don't choose. And it means that you potentially don't have privacy of this circuit. I think it's important thing for simplex protocols. Like if you compare with Tor. Right. On Tor you create a persistent circuit. So you build a circuit and then all the packets come through this circuit and then the circuit can see all the packets and they understand, they all understand it's the same circuit, it's persistent circuit.

B (38:50)

Right, Right.

A (38:50)

So even though like for example, it's a session design. Right. So you may message different people through this network, but the server that receives your messages would know that they come from the same person because they come through the same circuit and you understand. Right. So like, because the session is the same, different packets come out of the same session. It means that you know at least that it's the same person communicating all these different contexts. Right. With Simplex Network, we designed it differently. We do the same as Mixnet do. So effectively there is no circuit, there is a packet level anonymity. And the recipient router, it doesn't know whether packets come from the same session or from different session. So it only knows that they come to different recipients. Right. And the forwards in router, again, it doesn't know how many addresses would be because there is end to end encryption between sender and the receiving router. Going deeper in technical details. So effectively they cannot establish who talks to whom on a cryptographic level because each packet is anonymous in this message person.

B (40:01)

That's awesome. Yeah. It makes collusion significantly more difficult by default, which is key because if defaults are what matter, most people are not going to actually be changing things.

A (40:13)

Yes.

B (40:15)

How do you, how do you handle the, like, the discovery problem? The. And by discovery problem, I mean, it can mean a bunch of different things. What I mean is you message me and I'm connected to a different router than you are. How does the path get determined? Like, how do you, how does it, how does it get to me? Right. You know what I mean?

A (40:39)

Your address, you published an address. Right. So we don't have, have anything in the protocol or in the app to help me discover your address. That's, that's the future.

B (40:52)

That's a separate discovery problem. That's not what I'm talking about here.

A (40:55)

Yeah, yeah, yeah, yeah.

B (40:56)

You went to my website and there was a, there was my, my address was there. So we just used a traditional website for that part of the discovery problem.

A (41:04)

Correct. The address. The way it works now, the way it worked before, the address itself contained the router address.

B (41:13)

Okay.

A (41:13)

The way it works now, the address contains a reference to an encrypted piece of data which contains the reference to the address which I have to message. So the address itself cryptographically bound to the point I have to Forward my messages to. So your router is determined by your address. And the router I choose to forward messages to this address packets is randomly chosen from my configuration, from my client configuration. So my client says, okay, I will choose any router, but it'll try to use a router of another operator than you use.

B (41:51)

Right.

A (41:51)

So. And that's what. And when I send the first message to your address, when the client sends the first message, it includes the reply address, end to end, encrypts it.

B (42:01)

So you're right. So it gives you a discovery path basically to get back.

A (42:05)

Yeah, your client learns where it can reach me when they message you. It all works rather seamlessly. And on a technical level, discovery is not a problem. Obviously, the whole idea is for us, we have a support team member who answers users request. The most common request is, how do I connect to people? Where do you type the name? Where do I type the phone number? How the hell. How is it even working? Right. So the whole idea that you have to create a link and share the link with somebody else in order to connect is alien to absolute majority of people. We are doing a lot of redesign of this initial connection experience right now to make it easier to understand. We don't change them yet.

B (42:46)

I would say the in person is more intuitive.

A (42:49)

Yes.

B (42:49)

Than not. Because in person you just scan a QR code.

A (42:52)

Boom. Yes, yes, yes, yes. That's. That was like. That was literally version one of the app had nothing else. Right. It was. You could scan the QR code and you can start sending text messages. That was what we released four years ago.

B (43:04)

But yeah, that makes sense to me. Okay, so one of the things that MLS does attempt to solve is, is this idea of groups scaling poorly in encrypted chat. So a lot of times the most basic. And you know, you can correct me where I'm wrong here, my most basic interpretation of how standard encrypted group chats work, whether it's signal or matrix or any of the existing ones, is I'm basically. If there's 50 people in the group, I'm sending 50 individual encrypted messages every time I'm sending a group text. But the UI is making it look like it's just one message in a group text. But in the background, what's really happening is every message has to be sent to every group member and private, you know, encrypted separately. My understanding is part of the MLS spec is trying to solve that scaling limitation, because maybe it works at like 20 people, maybe it works at 50. But once you get to like 2,000, 5,000 people, it's insane. You're like basically ddosing each other and then the servers would obviously have a lot more overhead attached to them. So how are you thinking about that? Is that a real limitation? Is that and how are you mitigating it?

A (44:22)

Okay, so there are several questions. I'll try to answer all of them. So first, that's not exactly how a signal works, right? You're not sending messages to each member. What you do is you generate a random key for this message and then you encrypt the key itself for 50 people, but the message is encrypted only once. So for example, if your Message is like 200 characters, but your key is rather small, you don't need to send message 50 times and you don't need to send message to 50 people and signal. You encrypt message with the same key and then you encrypt key with different. So effectively. And then you send one Bundle which contains one message encrypted with this key and 50 encrypted keys, but they're small because it's like a fixed sized 32 bytes by its key. Right? So it's not exact. And then the server does the fan out the broadcast right. To the recipients and server has to do it anyway. However you agree keys, Right, because they

B (45:23)

have to see the message, right?

A (45:24)

Yeah, yeah, exactly. So it's either like in simple. Yeah. So if you communicate via signal or matrix, then the whole way it works, you send the message once and then the server distributes it to all the group members. Right. Server obviously has more power than your mobile device and that's why it's working. Right. And the fact that you have to send 50 different keys encrypted for each recipient is not the same as sending messages 50 times. It's obviously some overhead, but it's not as much overhead. So this approach scales to some thousands of members. All right, it doesn't scale to 50,000, but it scales to several thousand.

B (46:03)

But am I right that there is a bit of a. I mean, I will just say I've been in very large encrypted matrix groups and maybe it's something else with how they have it implemented, but it like becomes, it becomes nearly unusable as you get to the higher numbers in terms of people and like not that high, I don't know, like 1200 people or something.

A (46:27)

Content, Good consciousness. Comment on why matrix works, how it works.

B (46:32)

Fair enough, yeah.

A (46:33)

So we'll leave it on their on their conscience. So, yeah, so I think it can be done reasonably usable for several thousand people. But the problem is that we discussed it before, right? My view is simple, right? Once your group gets past 10,000 members, you need a trusted server, right? You can protect participation privacy, but there is no reasonable way you can protect content privacy because somebody in the group has it anyway. Right. And trying to design communication protocol that protects you from server is an interesting direction, but MLS doesn't solve this problem because MLS arrives to the point that in order for this to be protected from the server, you still need a trusted server. They just call it authentication service.

B (47:20)

It's a different trusted server.

A (47:22)

Yeah, yeah. You still need some trust, right? And kind of that's questionable and they acknowledge that and it's ongoing area of research and they agree that this is a serious limitation because that's kind of the whole foundation of trust. Because the idea of end to end encryption is that you are protecting content from your messaging provider. And if messaging provider can inject a participant into the group, then you're not protecting content anymore. And that's what lack of trust to this authentication service achieves. You can have participant that is injected. So yeah, so the problem of simplex design for groups is different. We do not have a broadcast thing at the point, right. If you have a group on simplex, you really need to send message 50, 100 or a thousand times every time you send a message. And people still use groups on simplex. We have lots of like we host a small experimental directory ourselves where people can submit groups. It's kind of our early access view on what it may be. So there are groups with 5,000 people and they kind of work, right? Yes. To send the message you have to incur lots of traffic, but people use it anyway. And the design for channels we are now doing is effectively adds in a chat relay that would be doing this rebroadcast. So end to end encryption in such groups is possible via the same approach as signal does, right. When you encrypt not the message but the key and attaching multiple encrypted keys and then the relay does all the rebroadcasting. So that's a viable approach, I think realistically to me, pairwise ratchets, like pairwise double ratchet. So for each member you encrypt separate key, it scales to quite large numbers. It scales reasonably well to even 5,000 recipients. And that's how we see large groups with end to end encryption in the future, Not MLS spec. But effectively what signal does so Signal Works, Signal Limited at 2000 because they have like tens of millions of users and some of them are on really bad intranet and they don't want to have and very low powered devices. So they don't want to go beyond thousand with end to end encrypted groups. But I think even 5, 10,000, it's a tractable approach. If you only encrypt keys and not the whole message. But beyond that it's just like it feels like you're not like you cannot remember 10,000 people. You don't know who's in the groups, you don't know who reads it. Like what's the point of end to end encryption? I kind of agree.

B (49:58)

Right, so then we move into the channels, right?

A (50:01)

Yeah, effectively.

B (50:02)

So then how, how are you envisaging the channel set up and what's that, what does that look like in practice?

A (50:11)

From user experience. From user experience point of view, you just, it works in the same way. You scan the link, you join the channel, you start receiving messages. The difference is that if you have right to send messages to, to the channel, then instead of sending it to whatever number of subscribers, 1,10,000, 50,000 subscribers, you send it only to chat relays and they do rebroadcast the server. It is not exactly the server. It is again it's some sort of a message. It uses client side technology because you're not connecting to this chat relay over the Internet effectively. The chat relay is a messaging client that cosplays role plays as a server, right. That is a router. Right. So it receives your message as a Simplex client. Right. And it's a special kind of client because you're never connecting to it directly. You don't know its IP address, you only have its Simplex address. Forwards your messages through Simplex Network, you connect to it via Simplex Network and it forwards the messages to Simple X network. So unlike NOSTR relays, you never build direct Internet connection to this relay.

B (51:17)

Okay, I, I mean to help me understand, maybe it's more helpful because if I don't understand it then it's less likely other people understand it. Let's say, I don't know, some politician wants, has a hundred thousand person channel, right? Wants to broadcast to his audience a hundred thousand people big. What does that look like? Is he running his own chat server and is who's running the chat relays and how does that all fit together?

A (51:47)

It's not different from who runs Simple X network routers. There will be some chat relays that Run by third parties pre installed in the app, he can run his own and each channel can have multiple. Our idea is that you want more than one chat relay in each channel for redundancy, for censorship, resistance, for mitigating any trust issues. So the way we designed the protocol and Lori implements it is that some critical messages are assigned by senders, so they cannot be faked. Most messages are not signed, but they are kind of delivered redundantly and recipient clients can see if some relays decides to invent messages or change messages or. So with like that's in case they're not end to end encrypted, Right. We're talking about public channels at this point.

B (52:31)

The big thing with public channels is not, is not necessarily encryption of the content, it's verifiability of the content that it hasn't been changed in transit and privacy of the participants. Correct?

A (52:47)

Correct, yes. And end to end encryption between this relay and the participant helps privacy. Right? Because there is end to end encryption between relay and participant. All the traffic information is not uniform. So transport network cannot observe the content, it cannot correlate the content, it cannot understand which groups you are receiving content from. For the same reason it's end to end encrypted. So end to end encryption, this broadcast and relay and the members helps privacy of the members. Right, because without end to end encryption, transparent network could see content. Right. And if transport network could see content, they know what you're reading. Right. So the sentient encryption is very important to provide and then the members are known. Exactly, yeah. So and with end to end encryption, transport network can see nothing and chat relays don't see your IP address. So they kind of protect you from each other and then from the.

B (53:43)

Why aren't all you mentioned so the broadcaster, let's call him the broadcaster in this, in this scenario, the guy who owns the channel that's sending out the messages to people. You said every message isn't signed. Why isn't every message signed? Is it A, is it A, is an efficiency thing or.

A (54:02)

No, There is no cost on signing messages, but it's, it's always a double edged sword. Right? So like one, one of the qualities in communication is deniab, right? So the double RH protocol has this quality called repudiation, which means that it's not possible to prove to a third party that you actually ever sent this message because the message is, is encrypted by the key that the recipient also possesses. The second you start signing the message, you're effectively putting your signature on the message saying, I actually said that you lose the deniability because yeah, it's not just, it's not just verifiable, it's also verifiable is a good thing. But the flip side of this coin, it's non repeatable. So you can no longer say, I have no idea where this message comes from, I never sent it.

B (54:51)

Like yeah, we see that issue with a separate rabbit hole that I've dove down in the past, which is the idea of, of of more modern voting techniques that would involve a signed receipt. And that issue there is you could have an employer or a husband or a government come to you and be able to with no doubt whatsoever know how you voted and then pressure you accordingly.

A (55:20)

Exactly right.

B (55:21)

Because on the surface it seems like such a great idea. It's like, oh, I should have a verifiable receipt so I can make sure they're not faking the votes. But then all of a sudden you realize why votes are supposed to be private.

A (55:31)

In democracy it exactly right. We effectively saying, okay, so some like for example, if the command you're sending to chat relay is to remove a member, it should be signed, right? Because the consequences of relay removing a member are irreversible. Or for example, you say I want to delete a channel, right? This action requires your signature because it's irreversible and it's destructive. Right? So everything irreversible and destructive, we add signature by default as a requirement and the receiving clients will simply refuse to process the message if it's not properly signed and your key is cryptographically bound to the channel link. So this is like we build this whole kind of cryptographic trust chain with the channel owner that when the member, when the subscriber just joins your channel, they already get the key from the link, it cannot be faked. So effectively they know your credentials for this channel from the get go, from the journey and they have that locally. Yeah, exactly. Yeah. But for messages we want to make it an opt in. If you really want to sign important messages, then maybe we would provide it as an option or as a feature. But I believe it's wrong to make it a default because think about that.

B (56:47)

And so the UX would display this is a signed message, for example.

A (56:51)

Yeah, exactly right. Yeah, exactly right. So imagine this like you already have five relays in a group, right? These five relays are operated by different entities, right? If one of them decides to substitute the message, the recipient client will see it and say, oh, what's going on? Here. Right. So there is some kind of trust

B (57:08)

one thing and one said a different.

A (57:10)

Exactly. So and I think it's actually better than signature because that gives them similar degree of trust. Right. The probability of 4 lace colluding if they are run by different parties. Right. Is low. Right. And especially if the politician himself runs the relay. Right. So then, then what's the chances of it being replaced? Right. But at the same time there cannot be used, as you said, as a signed receipt, which kind of, which can be used as a proof of, of doing that. Right. So like it's,

B (57:40)

that kind of makes sense to me.

A (57:41)

It's, it's all.

B (57:43)

Yeah, yeah. It still solves. The main underlying problem, which I think is going to become a bigger concern is as digital communications become the main way people digest information, there are serious real world consequences on what influential people say. And we've seen this. Trump sends out a true social post and military is moved and markets react. And meanwhile, there's zero way for me to know that Trump actually sent the true social post. Right. There's a bunch of men in the middle that can, can fake that.

A (58:15)

Yes.

B (58:16)

And we haven't seen a large scale repercussion yet of that type of attack. But I assume it's going to happen sooner rather than later. And so it's important that there's at least some level of verifiability or trust here. And I see how you're kind of trying to, you know, there's trade offs on both sides. Yes.

A (58:36)

You know, it's, there is a value in being able to sign important messages 100%. But I believe it's wrong to make it default and rather than opt in because like, okay, so we are like, imagine the situation. Right? You talk to me and we record this conversation. People can listen and obviously nobody of us can deny that this conversation happens. Right?

B (58:57)

Right.

A (58:57)

Imagine a different situation. We meet in a cafe, we have a private conversation. We really don't want this conversation to be public. Right. Whoever knows what we may be discussing. Right. It doesn't necessarily. We're conspiring. We can be just having a private conversation about our lives. Right. And if anyone later quotes that he said that it's unprovable. They have plausible deniability. Now imagine if it happens in encrypted messenger. If you use signal, you also have plausible deniability because, or simple X because messages, even though are end to end encrypted, they are repeatable. So there is no way to prove that you actually sent this message. And we haven't seen what I hear. The criticism I hear from technologists is that nobody has ever used this concept in courts, it has no legal standing, and so on and so on. Right. But reality is, Signal is the first widely used messenger that pioneered repudiation as a cryptographic quality in message sending. And it only happened like 10 years ago. Right. And before anything becomes understood by legal systems, we usually observe, like many, many of decades of not understanding what it is and how it can be used and what legal consequences of this is. So, yes, I don't know any precedents of this concept being used, but it doesn't mean it's not valuable potentially. So we like to stick with repudiation as a cryptographic quality of the protocol.

B (60:24)

Yeah. I mean, it's the difference between, like, building the technical foundations versus real world repercussions, and the real world repercussions always happen later. I mean, this is the first administration that I know of where we've seen official business happen on Signal. And there was that leak of that group chat. Right. And I'm sure a bunch of those group members are grateful that at least they can technically say that they didn't send a message in there. Whether anyone believes that they didn't send the message is a different thing. Because you kind of have to modify some things in Signal to do that.

A (61:00)

Yes.

B (61:01)

I mean, and to your earlier point about different types of conversations, I mean, this is a perfect example, Right. Because we had a conversation on Simple X that was off the record, and then this one I will be hashing and signing with my noster key. Because as someone who has spent a lot of time broadcasting my thoughts and having candid conversations like this on the podcast, it does frighten me that we could have AI deepfakes and basically me saying anything without no verifiability. So I really take that verifiability piece very seriously when it comes to these types of conversations. Like, I want there to be for this conversation, I want there to be a historical record of truth that if some AI in five years makes us say whatever it wants us to make us say, you can go back and see that hash signed version of the MP3 and know that it hasn't been changed. And that's what was originally said, right?

A (61:56)

Yes.

B (61:57)

Okay. This is all fascinating to me. I'm really enjoying this conversation. The. The big one that will come up next is which, I mean, I see all the time in distributed systems is, okay, so the system relies on people running servers and relays and whatnot. Ideally, the system works Best when there's many, many operators doing that. And this is something that Tor, for instance, I think on a widespread scale has had a lot of issues with, right. Having more independent operators running these things. Bitcoin, we've, it's a, it's a, it's a major contention point of Bitcoin. Making sure that Bitcoin nodes are easy and accessible to run so people can use it without relying on a trusted third party. We see it in Noster with relays. So how are you thinking about this like fundamental problem, right, which is you need a. As many people running servers as you need more. The better, the more, the better servers. And so how do you see that scaling?

A (63:09)

Right now we see lots of communities running their own routers in Simplex Network. I think there are some Bitcoin communities, I think there are some Monero communities, there are some discussion groups that run their own servers. They advertise it on their websites. We cannot know exact number, but I think conservatively there are over thousand routers in Simplex Network at this point. And that's fine. And it works. And people get their own sovereignty and autonomy and independence of anything that we may be doing or anybody else can be doing, which is great. The downside of this model is that your router, because it has fixed endpoint address, right? Like the whole point of Simplex network is protect your endpoint address, right? But if you run a router, this router becomes effectively your address, right? So like if, if, if it, if it's a, if it is run on public network, then obviously anybody knows the IP address, they somehow can link it to your identity. And maybe that's not what everybody wants. If you run it on Tor, then it's potentially not very usable, even though we build Internet to Tor routes and capabilities. So for example, if you send messages to Tor router, it will be delivered even if you don't use Tor, because Simplex routers would connect, they can connect to Tor routers, right? So even, even if the router is only on Tor network, then Simplex router that has Internet address will be able to forward message Tor network. That, that's how, that's why network remains interconnected, right? So you don't have to use Tor to deliver messages to Tor on the routers. And it's all great. But I think long term this is not really scaling because I don't know, you've probably seen Moxie Martin Martinspike said once that people don't want to run their own infrastructure.

B (64:57)

Yeah, the founder signal yes, yes.

A (65:00)

So my view was always, if we want privacy to be a norm, then we have to be building technology that everybody can use. Right. People who don't want to run their own servers, people who don't want to think, who want to use just default software out of the box and get this privacy. And that's the only way it can be normalized. Right. And I think it kind of resonates with what Cypherpunk manifesto also was writing later. Right. So for just writing code is not enough. It was his later letter, not the manifesto, that we have to have acceptance in the society. We have to have wide usage of those technologies. We effectively see adoption as a privacy feature. So this whole idea is that in order to be autonomous, you have to run the server. It is not scaling to the future. So that's why we want to build a network when hundreds of commercially incentivized operators can run routers and be making more money from doing that from the network than they're spending money running on this infrastructure. Bitcoin obviously has inbuilt monetization solution. Right. You run the node, it potentially can mine Bitcoin and it kind of at least covers the cost of operation.

B (66:22)

Well, we kind of lost that, to be honest. I mean, yes, most nodes are not mining nodes now.

A (66:27)

Yes, I understand that. Yeah. But at least you get an indirect

B (66:30)

benefit that you can use it. It allows you to use the network without trust, which is kind of what we're holding onto at this point. And then also if you hold the money, the money tends to increase with purchasing power. So we have that going for us.

A (66:44)

I'm not quite sure. I've seen some talk a couple years ago at a conference when somebody was talking running bitcoin miner at home. And his idea was that, okay, we can't make profit from running the miner, but we can convert electricity costs to non kyc bitcoin and that's a great thing. And let's do that. Right. So it's absolutely.

B (67:03)

Yeah, we do have that aspect going well for us. And there actually is a company called Future Bit that like puts the node and the miner together in one convenient package that you can run at home. But a lot of those miners, just to be clear here, and it's, you know, it's kind of a tangent, it doesn't really matter that much for our conversation. A lot of those miners are, they have the heater in their home, but then they're connecting to someone else's node. Right. So it's not their node. They're not running the actual node infrastructure, more are. Which is awesome to see, but yeah, fair enough.

A (67:34)

So for so for Simplex Network, we see the imperative to create a commercial model when anybody who wants to provide infrastructure can make more money from providing this infrastructure than running this infrastructure costs.

B (67:48)

A financial incentive.

A (67:50)

Yes, a hundred percent. And we don't want to create any blockchains to do it. We don't want to do any mining operation, we don't want to create any. But we still need a solution and we've been discussing it with the community for quite some time. So the idea is that to answer how servers are paid, we have to answer first. The question is what in the network itself is paid, right? When we were just starting developing this, we were thinking, okay, maybe some premium features can do that, maybe some something else can do that, right? But then we've seen what happens with Telegram Premium. We keep talking about Telegram, right? To me, Telegram. To me, Telegram Premium is a proof that premium model for messaging application is a dead end. Because yes, you may be generating revenues and yes, you may be developing the nice features, but reality, what happens is you're fragmenting your network, right? You very quickly as a provider of this application, realize that in order to make profit, you have to make your application unusable.

B (68:48)

Yeah, the best features need to be behind the paywall, basically.

A (68:51)

Pretty much all of them. There are already features when I can't message people until I have or I can't make call to these people and it's just like. Not because they choose to, but it's just like, it's just fun, right? And to me that's kind of very much a dead end for communication network. Imagine like a web browser, right? What we built, we take lots of inspiration from the web. We say often that what we build is a missing part of the web, the messaging part, let's say next web, right? Because web has never created messaging solution as part of it. So if you look at the web, how web is monetized, users don't pay for the browsers, right? At all. At all. Users don't pay for using the web at all. People may say, oh yes, we pay ISPs, but it's a different story. ISP is not the web, right? It's simply a transport network that connects you to the website. But the web itself, like all the DNS systems, all the infrastructure that allows web to function, it's free, right? So who pays for all that? The answer is very simple. Websites pay people who want to host the websites they pay. And because every quantum distribution network has this distribution, when 5% of websites generate 90% of traffic. Right. What it actually means is that it's enough to charge this 5% of websites and everybody else can be free. So you don't need to pay to host a small website today. Right. You just go, you create account, you can pay either a $1 a month or nothing. Or.

B (70:24)

Right. It's subsidized by the big guys.

A (70:26)

Exactly, yeah. So the whole web is subsidized by the big websites. So 5% of websites create all the carry or maybe 20% of the websites carry all the costs of the web. And that's why we see channels as so important, because we see channel on Simplex network as equivalent of the website. And we believe as this part of the network grows the traffic distribution, the cost distribution will be similar. So 10% of large channels will generate 90% of the traffic. And that's who they should, who should be paying. And they will be paying. Right. Because if you say I'm a politician, I want hundred thousand people audience. Right?

B (71:05)

Yeah.

A (71:06)

If your choice is to be on the platform, that can shut you down. Because the current administration doesn't like what you say. Right. We've just seen it happening with Trump before. Right. So before Twitter acquisition, before sitting president

B (71:21)

of the United States gets banned from Twitter and Facebook, which is ridiculous.

A (71:25)

Right. So and one of the he can pay, right. And anybody who has a 50,000.

B (71:31)

Yeah, I mean he ended up buying and building his own social media network.

A (71:35)

Exactly, yeah. So what we see is a much cheaper solution. So if you want a channel that's sovereign, that you actually own, you have to pay for it, you have to cover infrastructure costs, you have to cover discovery costs, you have to cover some costs. And that's the business model that we see for the whole Simple X network. So messaging remains free forever, just as an add on service effectively. And small channels and communities can exist for free, but large channels and communities carry the whole cost. And they just need to find a solution that allows to transfer value from those channel owners to the infrastructure owners in a way that kind of preserves privacy and security of all participants within what's possible. So that's our view. So our view is not. Our view for the network is not that it's enthusiast run network, but it's a professionally run network, but it's run by so many independent facility and infrastructure providers that trust is minimal because it's distributed. Right. If each conversation uses four different companies. Right, right. And those companies are rotated on a weekly basis, then your dependence on this particular company is extremely low. They get profits from doing that, but they have no control over your conversation.

B (72:51)

I love that. I mean, look, I love from. I wear two different hats. I wear my charity hat with open sats and I wear my for profit hat with 1031, where we invest in for profit businesses that are often built on top of open source stacks. And so I see both, both, both worlds in the greater open source movement. The foundation led, charity led, and the, you know, and then the opposite side, which is a for profit led. And oftentimes you see foundations get spun up and run donationware. I mean, we've seen that with Signal is probably the best example and it's probably the easier path for these type of things in the short term. I think long term they scale much worse. They're not sustainable. You have to go out and constantly seek donations and the incentives aren't necessarily aligned that well. I think one of the issues you start to see is longer term, it's like, okay, the employees or the stakeholders of the foundation don't necessarily need to see the thing grow significantly. And the reality is in is the truth is in the reality, which is Signal is probably one of the most successful nonprofit privacy freedom focused projects and it's found massive success, but it's at about a hundred million users, maybe less. And then you have things like WhatsApp that are in, you know, 3 billion plus, you have Telegram, that's 2 billion plus. And those are for profit ventures. And I don't think it's a coincidence that those for profit ventures tend to have significantly bigger user bases. I think it's an incentive alignment thing. So I do, I have a lot of respect that you've tried. You're trying to go this for profit, ethical, for profit, sustainable approach. And I kind of want to dive a little bit deeper in here.

A (74:34)

Look, I think, I think the challenge is that I can go philosophical here. Frankly. I think it all comes from people seeing most choices as binary.

B (74:46)

Right?

A (74:48)

So I have heard this in my life million times. You have to pick a lane, right? And I refused to pick a lane, right? When I was building my, you know, I was building like, I will go again to this library that nobody knows about. But that's a good example because when I was starting this library, There was like 12 different competing libraries and they all were either super fast and really badly compliant with the specifications or very, very slow and somewhat better compliant with specifications. So I said, all right, how about, how about I just build One library that is fastest and also best in compliance with the specifications. And everybody was laughing at me and said, also XACD comic, right? There are 14 bad frameworks, let's make one more framework.

B (75:32)

Here's the 15th.

A (75:33)

Now we have 15 bad frameworks. I was sent this comic by 10 different people in my life. But reality, what I learned from this kind of retrospectively again. So if you refuse to compromise on important trade off because trade off is artificial. Right. The choice between fast and standard compliant wasn't a real choice. It was just easy path. Right. It's just harder to build something that is both fast and standard compliant, but it's not impossible. So I built a library that came to be the only library that people use today for data validation in JavaScript world because the choice was eliminated. And again same between like private messenger versus convenient messenger. Right. So people have been trying to pigeonhole what they're building into. Like some people say, oh, you're building a private messenger. You shouldn't worry about convenience really. You should add more privacy features. Right. That's half of our user base would says and some other half of the user base says, you're focusing on privacy too much. You should compromise on privacy and it's not convenient enough. Yeah. And instead like for example the fact how you discover people some of the hurdles or for example that we still don't have multi device in the messenger, say whatever compromise on privacy build multi device. Everybody wants multi device. I don't know. I think my brain is wired against making such compromises. And we instead find proper solution that deliver both without compromise and it's obviously slower. The downside is like what you compromise on is time to working products. That's what have to go. Right. But I think reality is by taking this right.

B (77:06)

I mean, yeah, signal's the perfect example here. Right. Because the easy path was saying, okay, let's just use phone numbers as discovery. That's what WhatsApp does, that's what Telegram does. We can do that, my grandmother can use it. And then you're stuck. You took the easy path and then you're stuck with that building block.

A (77:24)

Exactly. Yes. It's not something that you can revise later. It becomes a foundation of your architecture. It's used everywhere, it's pervasive, it's. It's not removable. So I think what we're trying to build is a communication protocol and product and transport network that's used by everybody. And yeah, it may take decades to get there, but I still have time. So. And Talking about private, like for profit versus nonprofit. Going back to your question. Right. I also see it as a false trade off. Right. I was when, when we took venture capital money, we took it like without any control provisions. It's a proper Y Combinator safe agreement. There are no board seats, no control. Right. I have to chase my investors for advice. And when people say, oh, they will have influence to you on usa, I would like to have more influence if I can. Right. This is. Or some advice because they're very busy people. Right. But reality is we run our business how we want and they just trust. Because, you know, I think venture capital has changed dramatically after some major successes. When most venture capitalists arrive to conclusion that they have to let founders do things they disagree with because that's the only way founders face.

B (78:30)

Facebook was a big one. I mean, obviously it's kind of a weird example to use here because they turned into one of the most evil companies. But Facebook early days was we trust. You know, the investors were like, we trust Mark. Mark is the leader of the ship. We're not going to take any control. But before that, historically it was like VCs would come in and they would just take full control of a company and push the founder out.

A (78:53)

Yeah. Apple would be a classic example. Right. And this pushing the founder out pushed the Apple to the brink of bankruptcy. So they had to bring the founder back. Right. So yeah. So we see the world has changed. Investment doesn't mean control. And yet we've been like vilified by everybody that we did it. Right. So I had to write a blog post, right.

B (79:10)

For profit capital.

A (79:12)

Yeah. I had to write a blog post about why privacy becoming a norm requires venture funding. Because to me, privacy becoming a norm requires building a mass market, widely adopted products. The problem with this premise is that it is the costs are exponential. It's like, like getting like 10x more adoption. It's not necessarily like. You see what I mean? Right. So you simply cannot build a mass market, widely adopted product on a grassroot movement. And that's what Signal observes. Right. Foundation model doesn't scale. The nation model doesn't scale. So either you build at some point the model that allows it to be a business that generates profit. Right. And again, when people say, oh, you're a for profit company, it's a bad thing. My response was always like, what is profit? Right. It's either it's independence. Right. That's what I think. Bitcoin community, privacy community believes in independence, right. In sovereignty and ability to make their own choices. But nothing of this is impossible if you are existing on handouts, right? Because you are dependent on whoever gives you handouts, right? Children are dependent on parent until they start earning their own money, right? People who get whatever Social Security benefits, they are dependent on government to tell them what to do. And it's not a good thing. So any organization that wants to be independent has to make profit, otherwise it becomes dependent on whoever gives its money. And that's another dark side of the kind of for profit model nonprofit model. Because not only you can scale it really well, you become dependent on your donors. And those donors may have not necessarily like good motives. Right. So we've seen nonprofits who have been like, you've seen this chat control legislation, right? The biggest lobby effort for chat controller legislation was coming from nonprofits funded by big tech. So talking about nonprofit being a good thing. So I honestly think that morality and integrity of what happens doesn't depend on the organization form. I think it depends on people behind this organization in the first place. Right. I've seen companies doing moral things and we've seen nonprofits doing immoral things. And I think, yeah, so what we're doing right now, so we kind of understand we're building a network that nobody should own, we don't want to own. Right. We want a general purpose transport network that is run by community, operated by community, which means that the model, when we control the protocol, the model, we control all the licensing on the software is not sustainable long term. Right. So what we're doing right now, we are, we already announced to the community that we will be transitioning the governance. We are transitioning the governance to consortium model, which is similar to how the web was governed until recently. It's interesting, by the way, I didn't know about that. I only learned when it was written. So World Wide Web was governed by consortium, not an entity. Like it's effectively an agreement between four different entities in different countries worldwide. Web was garuntary consortium from Netscape shutdown In I think 2004 and until 2023 when WorldW3C became a US nonprofit, a single entity, which is fun, which means the World Wide Web that we all believe is decentralized now have a centralized governance model. Even though it's by nonprofit, it's still centralized. Right. So what we did, we worked with one exceptional open source lawyer, Heather Micker. She has authored multiple open source licenses such as Mozilla License Elastic License. She participated in some exciting work. She helped us draft this agreement for consortium for Simplex Network. And we are in a process of setting up the entity that will be in a consortium agreement with Simplex, the company. And then we'll be setting up additional nonprofits in different jurisdictions so these multiple entities will be able to run Network together and this way avoid jurisdictional pressures or risks and avoid any kind of corruption from any centralized governance models.

B (83:13)

Like corporate captures whatnot.

A (83:15)

Exactly, yeah. Because we've seen corporate captures happen in nonprofits a lot. Right? The whole Linux. Like, look at this. You're probably observing this noise about California law of. Yep, this is insane.

B (83:29)

Kyc to Flash Linux.

A (83:31)

This is insane. I made a tweet yesterday. It resonates with lots of people. It's effectively they tell you you no longer own your computer. Right. So we're going to break and enter into your computer and demand your. It's a violation of like multiple constitutional amendments, like certainly first constitutional, fourth and fifth and God knows what else is violated. And they say it's okay. What I find completely ridiculous is that all those open source foundations developed in Linux software are just quiet. They don't say anything. Right? They don't. The only, the only open source, the only privacy foundation is eff. EFF is campaigning against this law. Linux foundation says nothing. Right. All these kind of foundations developing Linux software say nothing. They already commit code that implements this age control into open source code, which is just ridiculous.

B (84:20)

Why do you think that is?

A (84:21)

Because they were captured, I think. Right, because we've seen a lot of decisions in those foundations that don't necessarily. They have been pressuring creators of software to leave. They have been pressuring, so that's not good enough.

B (84:35)

So they're reliant on their donors to pay their rent, basically.

A (84:39)

I don't know, Matt, I cannot say why it happens, but to me it was always like always the. I don't want to go into there,

B (84:47)

but, but the reason I bring it up, the reason I bring it up is because I'm neck deep in this with open sats, you know, OpenSats, we saw a concern of very centralized funding options for open source developers building nonprofit stuff in the Bitcoin ecosystem. And to be clear here, there's a bunch of foundational open source stuff that can't be monetized. It just. It cannot be monetized. It would, it would ruin the value prop for something like Bitcoin protocol software to be monetized directly. And so we built OpenSats in a way to resist that. And I think one of the biggest things is we're a volunteer board. We're a nine person board that's all volunteers. We make money doing other things. And it's because of that concern, you know the, the concern that you get captured by your donors because you're making $500,000. Some of these nonprofit boards, it's and how much money they're making and if that donor, if that donor base disappears, then they lose that. If my donor base disappears directly financially, there's zero impact to me. Right. And I think that's a key piece, but it doesn't completely solve it. Obviously if the donors disappear, open stats is gone. And so then I, I do agree to your point that it does come down to the people in a lot of ways. Right. It's like I would rather open stats be gone than ever take, take direction from a donor.

A (86:15)

Exactly. Because you, because you are independent, because you personally making profit in your life and you wouldn't get other people around your life. That comes to who should be on the board, which is also a very important question. Right. We still didn't form the board, but we are reaching out to various people who we believe can create value for governance and also it would be helpful to them as well. But I think it's still important given that jurisdictional law changes quite rapidly sometimes I think it's important to have multiple layers of decentralization of governance decision. So my initial thinking was that we should have shared ownership of ip, right? But intellectual property, the legal advice from, from, from our lawyer was that it's not possible really because there is no such thing. Right. So shared ownership of intellectual property means that any owner can dispose of it. Not just some consensus is needed. So what is going to happen is that the company will be remain the owner of ap, but it will be licensed to all consortium members irreversibly. There is a specific close on open source licensing when there is a lien attached. So even if the company stops existing or sold license still survives this. So effectively we will transfer licensing to multiple consortium members in a way that we can't revoke it. And then bit by bit we want to transfer governance over the key protocol in the same way way again like Netscape has always been an inspiration to me as a company. Right. Netscape built web as we know it, Right. Because Netscape pick up the protocol when it was embryonic, right? Nobody like you know who knew about the web in 1985, right? Nobody knew about web, but they picked it up, they built a Browser, they added JavaScript, they added cookies, they added SSL, they added like people think cookie is A bad thing. But Cookie is a foundational piece that allows you Facebook know to you is you. Right. It's verifiability. Right? So without cookies, Facebook doesn't know who you are or Twitter or whatever. So they created web as we know. And then they shut down in 2004, W3C took over abruptly. And what happened is that all the innovations stalled completely. Right. Took them like seven years to get CSS to next version. Right. The industry was so frustrated with W3C gardener, so they had to hold their own working group, if you remember this. What wg. So and they had to take matters on their own hand and it was like super frustrating for everybody. Right? And that's exactly what. And that's what unfortunately we see, I think with many decentralized protocol because they want to be decentralized. Right? But they don't understand that from the point of early enthusiasts using this protocol to the point everybody else can use this protocol, it's not just time and adoption, it's radical changes in the protocol that's required. And these radical changes require speed, commercial incentive, funding, centralized decision making. So you simply cannot get a protocol to mass adoption without running things as a venture hazard company would run things. That's what Netscape did. Right? Netscape was doing Netscape browser at the time. There were like 30 other competent browsers also trying to do browsers. Right. With venture funding, it didn't occur to Netscape to ask other browsers what they think about protocol changes. They honestly didn't care. Right. If they did, they wouldn't have the web. So that's how I see the whole kind of decentralized governance. There are some stable parts of the network and changing them should require consortium vote. Right. But there is some evolving part of the network that's kind of on the boundary, require adoption, require radical changes. And they're not ready for decentralized governance yet.

B (89:53)

You need to be able to move fast and adopt.

A (89:56)

Exactly. Yeah. And that's what we lost with xmpp. Right? That's what we lost with Matrix. That's what we lost to a large degree with Nostr, for example. Nostr has idea of channels, but I think they are not supported in iOS app even today. Right. I may be wrong, maybe it was edited. But the problem is if you have decentralized protocol governance, you lose ability to innovate fast.

B (90:20)

Well, the nice thing about NOSTR is you don't need consensus. So if certain actors are breaking things, you know there's no global state of Nostr. Right. That's one of the issues we have with Bitcoin, which fortunately, you know, I think is more of a feature than a bug for something that needs to be like this decentralized asset, like this global base of a global financial system, because you don't want it to change that much. But there is a global state. So as a result you need consensus from like an overwhelming majority of peers with Nostr, like if one actor is breaking something, everyone else can ignore it if they want to, and then if it actually is working, then they can accept it in the future or not. There's no global state.

A (91:02)

Don't get me wrong, Matt. I didn't come to criticize Nostr. The point I'm trying to deliver is

B (91:07)

I don't think you are.

A (91:09)

I think the Noster community will benefit a lot if the condition of funding for 1Up to develop a feature will be that all ops develop this feature because then effectively some degree of centralization in protocol governance. Because if the feature is added only to one app, it means nobody can use it. Right?

B (91:28)

Right.

A (91:29)

I'm not going to use Channels on Nostr if half of the users can't use channels. Right. I will just use the default account. And that's what happens. That's what happened with xmpp, that's what happens with Matrix, and that's what happened. I think the presence of OpenSat and some degree of centralization and OpenSat that could take a role beyond just funding and really drive innovation much faster. If, let's say any feature should be universally supported by all apps to be funded in any of the apps, I think that may help Noster because we really like. I think competition is a great thing. Right. So for example, in our channels, people ask, why do we allow people to. We want everybody to succeed, frankly, because we're not competing against each other. Right. We're competing against Telegram and WhatsApp and. And we share the same enemy. I think Simplex Network will be better off. If Noster is better off and Mastodon is better off and Matrix is better off, everybody is better off because we all together. If you think about it, it's crazy. All privacy technology together are used by maybe like what, 2% of people in the world?

B (92:33)

Nobody.

A (92:34)

Yeah, it's like it's a negligible amount. You know, I keep saying to our team, when they kind of start suddenly think that they essentially, look, we build software nobody uses and nobody knows about and this is super important. Nobody. Have you watched the movie? Right?

B (92:50)

Yeah.

A (92:51)

These are the most important people in the world. No question about it. But on a balance of things, we really need like to get to 10% adoption together, not to 2% if we really want to. Yeah. So that's what we want, that's what we're trying to achieve.

B (93:05)

That's why I always use like signal as an example because they once again, not perfect, but very pragmatic trade off balance that they went with. They, they've had. It's, it's funny, right, because you can look at it from both perspectives. You can be like, oh, they're a massive success for a privacy project because it's a hundred million people. And you can look at it the opposite side, that's nobody, right?

A (93:26)

Yeah, it's 2%. It's still 2%, right? 100 million people is 2% if I can count 10 years.

B (93:32)

Evgeny, I want to dive in just before we wrap here. I think it's important that like high level, the, the monetization makes sense to me in practice. Everything's harder to execute on in practice. So I want to dive a little bit more into the details because there was some controversy around it about how you're thinking about implementing it. And the big one is, okay, so the main operators that are doing, you know, 90% of the traffic, these big channels are going to be paying for things you have, I mean you got, you basically got flack, you know, you're, you're doing well when you get flack from everyone that has all different conflicting interests and everyone is mad at you. But the two big ones that I noticed was the Bitcoin and Monero communities respectively. The Bitcoin community being saying, why aren't we using Bitcoin for this? And the Monero community being like, why aren't we using Monero for this? This? So my question to you is rather simple. Why aren't you using Bitcoin for this? And what's the alternative? Why is that being chosen?

A (94:39)

Okay, so one thing at a time. So to have network pay, to have network function, we don't need to just pay for servers, right? We need to have mechanism how governance layer can be paid, how software developers can be paid and how channels can make profit. And that requires some mechanism of revenue sharing and distribution between those parties. We cannot tell channel owners say, you have to pay this and this and this, right? So we have to create some codified approach for revenue distribution. And not just that. So we also need to solve problem of server discoverability, right? So how will people learn where the service exists, how they find them out, right? So okay, they want to use paid service, how they find it, Right. So. Or they want to have channel names. Because again, if you're talking about usability, you need to have a name for the channel. Right?

B (95:35)

Right.

A (95:36)

You cannot have gibberish letters and numbers. Yeah, yeah, yeah. You cannot have. So Noster keys are great. Simple X addresses are all great. They're 100 characters of gibberish. Normal people will never ever use it. They want to type music and go to the channel with the music, or they want to type sport and go to the channel with the sport.

B (95:53)

It's the same reason we don't go to direct IP address, we type it in a.

A (95:56)

Exactly. We type domain names. Right. So how do we do it? So we need some mechanism to agree on what this address means. Because if you simply give this address to a server and say, okay, I will tell you music, you will tell me the address. The problem with that is the server can give you any address. They can execute manual attack on your connection. Right. So you need some way to get trust to the information you're getting. And how Internet solved this problem and worldwide web solved this problem. They created like hierarchy of trust, right. Certificate authorities and domain name systems. When your trust is built ultimately because you have an authority, but that's antithetical to both Bitcoin, Monero and to us. Because the second there is an authority, this authority will be corrupted. Right. And we've already seen attacks on certificates via major certificate authorities. Yeah, it's complete mess. Right. So we cannot build a system based on trust or on authority. We have to build a system that's properly decentralized. When any information you get about the network is trusted without having authority that you trust. And the solution exists, it's called blockchains. Right. But I think the way I see blockchain, and that was the root cause of this misunderstanding and the way many people see blockchain is very different because people see blockchain as a way to transfer value between participants, as a ledger that records transactions. But that's just one use case like, since there are lots of technology has evolved when blockchain can act as a global distributed computer that can perform arbitrary computations and arrive to consensus about things, not just transactions. Any consensus can execute arbitrary logic in a way that it's trusted without having a single party that you need to trust. That's what's called smart contracts do, because people think contract is some sort of agreement that you sign, or it's some sort of an asset, or it's not it's just a code, right? So when you go to the server, you run some code that gives you some result. You have to trust the server. If you go to smart contract enabled blockchain, then you can run computation and get the result and then you trust. And this trust is not based on a particular node of this blockchain. It's based on the whole decentralized blockchain.

B (98:17)

The best example of that at scale in my opinion right now is polymarket.

A (98:23)

Potentially, yes. I'm not that familiar with that. I know.

B (98:26)

Well, I mean they have a similar. I mean they have a similar problem, right. Their problem is if, you know, they can't have a centralized entity taking custody of funds and handling arbitrary code.

A (98:38)

Yes, exactly.

B (98:39)

Right. Settling of the markets. Right. If a missile strike hits or not, like it can't be a single company doing it.

A (98:45)

That correct. So when we say we need to. So several things should happen for Simplex Network for it to be usable and sustainable. Right. We need to have a registry of servers that can receive money and trust this registry. Right. We need to have a registry of names so we can discover channels and we also have design for private names when you can discuss people without anybody knowing their addresses. We have designed for that already. And we also have to have a way to transfer value as also. But not just transfer value, but also distribute the revenues in somewhat agreed way. So depends on.

B (99:22)

It's like it's programmatic value transfer. Right. It's like an auto split that's going to multiple values.

A (99:27)

Exactly. Yeah, exactly. Right. So because otherwise we, yeah, transferring value is a simple problem. And yes, Bitcoin is the best at solving this problem and the first solving this problem. And if transferring the value would be the only problem that we needed to use, then Bitcoin is a viable solution. And likewise Monero is a viable solution. Right. But that's not the problem that we need to solve. We need to have a distributed computer that we can trust that will solve all the problems that require a network wide state. Because today Simplex network has no network wide state. You said network wide. Right. So there are no registrar servers, there is no list of participants. It's a global state. Exactly, it's fragmented. And when people say, oh, we have to bring the whole messaging on the blockchain, that doesn't work because messaging has to be fragmented, communities have to be fragmented network. But if you want to have a global namespace that is recognized by all clients, then you suddenly want a network wide state. Right? If you want to have a server registry to which you can pay money. You want a network wide state and if you want an agreement with those servers that you can trust and everybody is paid who is doing the work for the network, you need some programmatic way to split revenues and distribute money that requires smart contracts. So, so our whole idea is behind that, to program all this logic so effectively if anybody on the blockchain and have server operators and network users interface with smart contracts so that payments can be transferred from the channel owners to the servers with whatever revenue sharing agreements that can be put in place as code. So specifically we're going to build a proof of concept quite soon on some blockchains so people can and have a feel of how it's going to work. But imagine your operator, you're going to smart contract via some service DAPP hosted on IPFS for example. And you say I want to be an operator. You will be asked to give your details. You will be asked to put our server addresses and whatnot. You'll be asked to sign a deed. So I believe that technical guarantees have to be supplemented by contractual guarantees. So let's say if you want to run a server on Simplex Network, you have to guarantee the users that you're not going to sell the date, that you're not going to collude, that you're not going to. So there have to be legal remedies if you do. I think that's a big missing bit in networks like Tor because they ask for the only thing. Maybe because they're technologists, maybe they just don't think about it like this. But I think if I am using the server on the network, I want not just technical guarantees, I also want contractual guarantees as well. And we want blockchain to deliver it all. So participation network would require providing contractual guarantee in exchange for making the money. Many which they think is reasonable. So that requires programming, that requires writing code, that requires deploying code in a way that it's executed not on a particular computer, but on a distributed network of computers. And that kind of. Yeah, and that kind of. There is not a single. There are choices, right? There are multiple networks that can do it. Think it would benefit Bitcoin a lot to evolve into this direction, but it's not there yet. It, I think Bitcoin, I mean why

B (102:33)

does bitcoin have to do all the things I, I'm, I'm in the camp that like if you use. I mean because the problem is adding that functionality reduces the robustness of whatever blockchain it has that functionality that's always been the, the trade off from Bitcoin protocol point of view.

A (102:54)

Correct.

B (102:55)

So like if you use like for instance, and I've gotten some shit for this and this is why I use Polymarket as an example. Like Polymarket runs on I think like an Ethereum layer 2 called Polygon. Right. From a user point of view, I just need to be able to deposit Bitcoin.

A (103:15)

Yes.

B (103:16)

Like if it runs on a different tech stack, that's in a lot of ways a benefit that's in a lot of ways a benefit to Bitcoin holders because it's not burdening Bitcoin with that tech stack. You just need to be able to

A (103:29)

send bitcoin to it 100% and that's actually a solved problem. Right. The whole idea of foreign assets have been executed in a trustless way by other blockchains. For example, I think Polkadot did it, Starknet did it. There are some other blockchains that did it that you can hold asset on a Bitcoin blockchain, but in a way that you operate on this asset on another blockchain. So it's kind of, it's almost definitely not trustless.

B (103:54)

But.

A (103:54)

No, no, there are trustless solutions as well.

B (103:57)

I question, I question if that's the case. There's a lot of hype around it. Look, I think it's important that you minimize the trust as much as possible. For that cross chain situation. There are atomic swaps that can handle it. Bolts just released an atomic swap that moves you from for instance, Bitcoin to Tron Tether and in between there's no custody. But trust is a hard thing.

A (104:23)

I agree that it's hard to do a completely non trustless way, but they think they're doing something reasonable with that. But that's not the point.

B (104:30)

But we get derailed. Yes, exactly.

A (104:33)

I think what we want to do is to just have ability to transact with any currency on the entry. Bitcoin, of course as well, but ultimately to have a mechanism of revenue sharing between participants that enable. Like you're using the web browser. Right. You're not paying to the web browser. It doesn't mean that the browsers are not paid. Right. Ultimately, web browsers find a way to make revenue. So we believe that companies developing client software for networks should earn revenue from the network for doing that. Right. And it's not just our company. Any company that develops software should earn money proportional to the usage that they are able to generate for the network.

B (105:13)

Yeah, I mean the web browser is an interesting Example. Right. Because. Because it wasn't built in a programmatic way of revenue sharing and stuff. Stuff. They have to find revenue streams that are very convoluted and oftentimes have warring incentives. The best example being Chrome, which Google figured out was the way you monetize it is with search and mining data of people.

A (105:35)

Exactly.

B (105:36)

While like Internet Explorer was monetized basically through Windows and Windows lock in. And Safari is Apple's ecosystem. And as a result we just don't have many different web browsers browsers we can use.

A (105:48)

Right, exactly, exactly. So it's stifles competition because there is no mechanism to get revenue for making a browser from the network that requires browser to access. Right. So. And also all sort of perverse incentives. Right. When privacy gets compromised, when security gets compromised, when users data is being sold. And that's just corrupt model. And the only proper solution is to just build in this revenue sharing model in the network. So browser developer, whatever, software developers get some share of the revenue proportionally to the value they create to the network. And likewise governance of the network. Right. When we say we are establishing consortium governance carries legal costs. Right. It carries documentation costs that maybe not cost a lot of money. It may be whatever, a hundred thousand dollars a year, $10,000, it doesn't matter. It's still money that somebody has to pay ultimately. Right. And until some point it's okay to sustain on donations. Right. But beyond some point it may be hard to sustain on donations and it may require explicit revenue sharing agreement with the network. So I really see it's important to have foundation that would allow it. I think it's fundamentally the vision of Tim Berners Lee around the web. Right. That's why we say that what we're building is potentially the next step. Because he was talking about micropayments powering the websites and generally web ecosystem from day one it was way ahead of blockchains or cryptocurrencies or even understanding what these micropayments means. But I think like he was talking about the future for which we today have technology.

B (107:23)

Fair enough.

A (107:24)

So yeah, so that's why we didn't make a final decision. We still iterate on which is the blockchain. What smart contracts. But fundamentally we are looking for solution with smart contracts.

B (107:37)

I'm trying to be mindful of time because this is supposed to be. This was supposed to be a tight hour and I know time is scarce. No, don't apologize. I was apologizing to you. But this conversation has been so fascinating that we're Almost at two hours. But I, I still, I mean, I still want to just go a little bit deeper on this before we wrap. If you, you have a little bit more time.

A (107:57)

I have all the time you have.

B (107:59)

Okay, great. I. What thought have you give. I mean, the big concern, right, I would say is we haven't seen. So basically there's two pieces here, right? And I think the first is the reason the community's gut reaction was outrage is because most of the time when a proprietary token scheme or credit scheme gets presented is very scammy. I don't think it inherently needs to be scammy. I just think that 99% of the time it is scammy and there aren't many examples of it not being so. People default to that. I understand why you would choose this path and I don't think it's necessarily unethical or anything.

A (108:49)

It's not even that, Matt. We're not going to do any tokens or emission for that. We see a smart contract as a holder of the existing value. We're not going to create any digital asset class. All we want is a scheme that allows people to deposit some existing assets. There's no final decision of what the asset is.

B (109:10)

But it can be multiple different assets, right?

A (109:11)

I mean, exactly. They deposit it and smart contract simply holds it. We're not interested in emitting digital assets at all and we're not planning to issue any tokens. What we want is a autonomous smart contract on the chain. When you deposit existing assets that we didn't create and then you assign it to a community using zero knowledge proof, which already decouples your purchase from assignment. And then once community has assigned credits, credit is existing assets. It's not our token, it's not something we created. Then they can redeem it to the server. And then when the revenue gets distributed, what we achieve with this scheme is that privacy is preserved because it's effectively you're pre. It's like, think about it like prepaid telephone cards, right? You go into the store, you pay cash and you get the card and then you use the card to pay for your phone. Or you may give it to your friend and your friend will pay for his phone, right? Or for her phone. So that's fundamentally what we want to develop, prepaid scheme allowing you to use existing digital assets on a blockchain to prepay server capacity and do it in a way that preserves your privacy because fundamentally programmatically split it between and programmatically split revenue, right? So we have no interest in issuing tokens, we have no interest in creating any digital asset class us, we have interest in creating a mechanism that allows people to transact in a way that protects their privacy. Because you cannot really like yes, people go through all the hoops to have privacy. They have to think about how they connect to blockchain nodes, how they do this, how they do that. So privacy is possible with blockchain, but it's not possible for mass market users? Realistically, yeah, it's quite difficult.

B (110:53)

It's been a major focus.

A (110:55)

Exactly. So what we want to develop is a layer that is built on top of blockchain, uses existing blockchain primitives, existing blockchain assets, and that allows people to pay for infrastructure in the same way they would pay for telephone. Buying telephone prepaid card we didn't like. If I tell you that we are doing a prepaid telephone card, that doesn't mean we are printing cash. We're not printing cash, we're just doing pre paid cell phone card. So we don't want to do any token that would hold value. We simply do.

B (111:23)

Interesting analogy.

A (111:25)

Effectively a treasury which will hold some other tokens that already exist. We didn't know. It may be usdc, it may be some other token, it may be something that people recognize as a value and use it as a transient value store to pay for the servers.

B (111:43)

That brings me to my second piece, which is, I would just say as someone who is pretty excited about what you're building and understands the need for it, and I don't want you to make any bad decisions that you regret later is, you know, the way Bitcoin is designed. And the trade offs Bitcoin has made make it very resistant to centralized capture, both on the protocol level and then also the token itself is a native asset. Right. When you're thinking about how you're going to actually execute on this and build it out, I think it would. And I'm sure you're already thinking about it. There's two pieces, right? First of all, the protocol you decide to build on is going to have varying levels of centralization, right. So Tron for instance, is an example I constantly use. Tron has $10 billion worth of tether on it, but at the end of the day it's just Justin Sun. It has full control. Now regulators perceive it as federated control and he doesn't have full control. And maybe that's enough for him in his use case or whatever. But when it comes to something as important as Simple X, I could easily see censorship happen. On, on that chain. Chain. Now you could. Now there's varying levels of this throughout the ecosystem, right? With I would say Bitcoin being the by far the most secure but not programmatical for your use case or whatever. And then things like Tron being incredibly centralized, but a lot of people are using them as a result. And then the second piece is the actual assets itself. Right? USDC is controlled by a centralized group of regulated institutions. Right. It gets frozen all the time. So does tether. Right. So you got to think through these. Because, because ultimately, I mean, I could imagine a world where you build this all out and then if that layer gets broken, everything starts to break around it. Right. Like people. It hurts the robustness of the protocol itself. So these are things like, I'm sure, are you thinking about this? Or I assume you are 100%.

A (113:44)

Yes. Matt. You know, one of the reasons why we announce our strategy and technology direction long before we have answers is exactly that. Because we usually iterate ideas internally and then when we think, okay, we don't know how to make it better at this point to announce, it sometimes happens like months or even more than a year before we actually start building. We didn't start building it yet. We only arrived recently to a cryptographic design that, that, that hits all the goals. Right. We didn't even, we only recently were running the review of all the blockchains that can be used for that. And Tron is disqualified. Right. Same as many other centralized blockchains. We absolutely don't consider high degree of centralization. I understand the downside of. So choice between USDC or Tether and other tokens is effectively volatility versus centralization. So it's a hard, it's very, it's a very hard choice.

B (114:42)

Right.

A (114:43)

So, and for many. So I would say in the same way, I like reject false trade offs and false binaries. Right. Some choices are just not real. Right. You just invent them and you say you cannot have both. In many cases you can have both. But sometimes there are some genuine trade offs and they're really hard to take. And with this kind of specific technology, there are a lot of hard trade offs. That's true. What I think is important though, we're still in enthusiast territory. I think it would be correct to see what we are building right now as a prototype. Right. In the same way as Simplex V1 was a prototype. And if you compare Simplex design on the day of launch with Simplex network design today, it's almost like two different products. Right. We have completely different layer of security. We have completely different. And we have managed to evolve it all kind of with backwards compatibility. So people were effectively using a different network without changing the client, without having been disrupted, et cetera, et cetera. So I think we can do the same with payments. So whatever we build in the first instance is likely to be a prototype we learn on. And that will evolve dramatically as it gets adopted, as it gets tested. Because I think the biggest test for the product is not technology, it's market. Right. We kind of hypothesize that channels will pay for servers, servers will want to participate. We hypothesized a lot about the market. And you know it better than anybody else. You're a vc. Right. Products don't fail because technology fails. Products fails because nobody cares.

B (116:14)

Yep.

A (116:15)

Nobody cares to use them, nobody cares to build them. And I think at this point it's much more important to prove that our hypothesis about the world that people will pay, that service will want to sell are correct. Right. That there is actually a market. I think to prove this is much more important than to avoid, like, centralized. You also what I mean, right? So, like, it's much more important. And once we see, okay, yes, there is a market, it can grow. We'll just rebuild the technology in a way to avoid the capture. You can see it's in the same way as if it builds a simplex network. People are telling me from day one, you should create a foundation. It should run a protocol evolution. But my response was, look, we don't know if anybody needs it. Number one, we don't know what people need. It's not just. We don't know, even if you know that people need something, it's almost like, you know, like your trade has an expression, product market fit. Right. We've been running product market fit experiments for four years, and now we kind of have understanding of what people need in terms of messaging. Right. What people need in terms of payment for infrastructure capacity. We're just in the beginning of running this experiment. Right. We hypothesized, we learned, we talked to people, we believe just putting the cart

B (117:24)

before the horse otherwise.

A (117:26)

Exactly. Yes. So I think it's important for community not to overvalue technology choices. Of course we'll make the best job. Of course we'll do decent technology choice. Of course we'll avoid, obviously bad. Like Tron is obvious bad choice. Right. There is no way. There is no road in which we use Tron or Base or something else centralized. So it's literally not even on the table. Right. But within reasonable choices. I think I wouldn't over index the importance of doing it right on the first try, but rather doing something that's kind of. We're trying to do a good job. I think they're trying to do a good job with version one. But that's directionally correct.

B (118:01)

And learn from it.

A (118:02)

Exactly. I think that's how we've been evolving the product from day one. Right. We built something and then it was pulled by users into some direction and we pushed in some other. It was kind of a combined effort. And I think that's why people use it. Because we tell people really what we do, we listen what they say, we learn, we do something that they think is. We're building it for people. I'm too old to do it to be rich. Right. I personally. No, come on. It's just like you're not doing what you're doing to be rich. Right. If you wanted to be rich, you would be doing different things.

B (118:33)

I think I agree with that. That is correct.

A (118:36)

Yeah. There are simple ways today to get rich. Right. We really. I think what kind of is common between us is that you kind of dislike the place where this world arrived. Right. And you do what you can in your place with your resources, with your abilities to make this world a little bit better. I think that's why we're building communication technology. Because I. I care about communications. Right. I experimented with page, you know, pagers. Like I had some was deven with those things. So, like I really care about people being able to connect to other people. There is nothing more important. And me seeing like the whole world is converted into some kind of surveillance Panopticon when you can't really talk to anybody anymore. That's just not right.

B (119:22)

Yeah. Someone has to do something.

A (119:24)

Exactly. I was saying that something has to do something for the last 12 years, 15 years now. Right. So like four years ago I said,

B (119:30)

no, less than who?

A (119:32)

Yeah, four years ago I said, all right, nobody does anything. I have to do something. Right. Yeah.

B (119:37)

That's what compels me to. Look, I think you're thinking about it the right way. I think it's the right perspective. Obviously you have my contact now, so if I can be helpful as you try and figure things out, don't hesitate to reach out.

A (119:47)

Thank you so much.

B (119:48)

But yeah, I think it's the right perspective. I think it's, I mean, just really well said across the board. This was a great, really great conversation. I enjoyed it. Maybe we'll do a follow up in the future, like in a year or something. I don't want to take too much of your time, but I think it'd be cool to have, you know, kind of like a timeline as we, as you build all this out. It'd be fun.

A (120:12)

That would be fantastic. Yeah, so we. Yeah, so that would be fantastic. Okay. We are trying to make it work.

B (120:20)

Yeah. We're past the two hour mark now. This was an epic, epic conversation. Do you have any final thoughts for the audience before we wrap? How that can be helpful? I'm gonna obviously link to all the important links in the show notes.

A (120:33)

We didn't do a formal announcement yet. And what we're playing this year is effectively transfer and give people more ownership of simplex across multiple dimensions. So this consortium governance is one thing. Another big thing we are playing for this year is crowdfunding. It's not formally launched yet. We kind of in testing the water phase. So we're not accepting any money. We are not doing that. But we will be doing it this year. We've been criticized a lot by our users for taking private investors money. And we think it's like, I think our users have to own a piece in this network and have a say in where this network evolves. And not only via nonsense profit governance, but also via having shares in a company that builds this network. So we are creating this opportunity right now. It'll probably launch in like three months or so, but there will be announcements soon in the blog post on Twitter. So yeah, that's a big thing. So I really wish to see community supporting and benefiting from what we're building because we're not trying to be just nonprofit entity. We believe that like if, if what we're building is the next web and we're the company building the next web, then it may be really large business and our early investors can benefit a lot from participates in that. And I really want to see community members in their numbers.

B (121:53)

And I don't know if you're comfortable with sharing how that's going to be set up or like was that just a traditional equity sale or.

A (122:00)

Yes. We don't believe in tokens. We will sell company equity. It will be some sort of modified safe agreement. We can, we can't use YC Safe as is for crowdfunding. It's not, it's not decided. It's premature. It's currently what we're working with, with lawyers. But fundamentally, yes, it will be the community who that participate will own company equity.

B (122:21)

Awesome. Got it.

A (122:22)

Well, that's our big news for this year.

B (122:25)

Keep an eye out for that.

A (122:27)

Yeah, and I have to say what my lawyers keep saying, maybe have to say a disclaimer that this is not an investment offer and we cannot accept any money at this stage. This is just us testing the interest.

B (122:40)

I think that was good legal advice that you received. I'm glad you said it. Sir. It was a pleasure. Thank you for joining us.

A (122:49)

It's a privilege, Matt. It's a privilege, Matt. I really appreciate you doing that with me. Thank you so much.

B (122:55)

Thank you. Freaks. Thank you for joining us. I hope you found the show helpful or fascinating. I enjoyed it as always. Share with friends and family. Search cilladespatch in your favorite podcast app. All relevant links@silladispatch.com Love you all. Stay humble. Stack sets Peace.