Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#19 Decentralized Messaging with dm3 cofounder Steffen Kux
48 Plays8 months ago
Steffen Cox is the co-founder of the DM3 Protocol, a network designed to act as a the glue for all messaging apps. Before dm3, Steffen built slock.it alongside former core Ethereum dev Christoph Jentzsch.
The Core Functionality of dm3
dm3 was envisioned as a tool leveraging blockchain registry for ENS to create a decentralized registry for public keys and communication details. This registry would ensure that any message sent is encrypted and verifiable, countering the pitfalls of traditional email systems which often remain unencrypted or are siloed within specific platforms.
The long term vision is to create a unified application for all messaging, whether it's email, WhatsApp, Telegram etc.
Security and accessibility
One of the key aspects that Steffen highlighted was the need for security and privacy in communications, something the current email systems lack comprehensively. With DM3, the aim is to use blockchain technology for its inherent security features, allowing users to have encrypted and verifiable communications effortlessly.
Even with encrypted services like WhatsApp, communication is confined within the platform. dm3’s vision extends beyond these limitations by facilitating a system where communication protocols from various networks can interlink seamlessly through dm3’s decentralized messaging framework.
DM3 proposes a unique approach to tackle the scalability and efficiency issues prevalent in traditional and current blockchain-based messaging systems. By employing a relay network of decentralized nodes, dm3 ensures that messages are not just secure and private but also efficiently managed without overloading the network, addressing significant scalability concerns seen in other peer-to-peer messaging systems.
Future Plans and Community Involvement
Looking ahead, Steffen is excited about the evolution of dm3, emphasizing the protocol’s shift towards becoming a community-driven project. The upcoming features include enhancing the system's interoperability layer and expanding its functionality with new updates that promise to make the protocol more robust and versatile.
This podcast is fueled by Aesir, an Algorithmic cryptocurrency Trading Platform that I helped develop over the last 2 years that offers a unique set of features.
Recommended
Transcript
Introduction to Unified Communications
00:00:00
Speaker
all communications I want to manage or I want to store, I will link to my inbox. And as long as this solution is theme-free compatible, this will work. That's seriously cool. I don't think I've seen that before.
Introduction to Proof of Talk Podcast
00:00:24
Speaker
Hello and welcome to Proof of Talk, the cryptocurrency podcast where we invite leaders and builders into the space to come on and talk about their experience in the industry, as well as the projects and products that they've been building. My name is Andre and I've been in the cryptocurrency space since 2017. I've also helped co-found algorithmic crypto trading platform ACIR that enables users to quickly and easily automate their trades while managing the risk.
Guest Introduction: Stephen Cox
00:00:47
Speaker
I'm here today with Stephen Cox, who is the co-founder of a Web3 communications protocol called the DM3.
00:00:54
Speaker
Nice to meet you, Steven. How are you doing? Yeah, nice to meet you too. It's nice to be on your show.
00:01:00
Speaker
Thank you, my pleasure. Look, I think it's so good to kind of have more of this kind of activity on Web3 to have protocols or systems that enable decentralized communication in an open way.
Emerging Technologies in Decentralized Communication
00:01:16
Speaker
And I'm fascinated by that kind of technology. I've been looking at Farcaster for the last few weeks and it's so cool to understand how it all works. And that's why I'm also really, really excited to talk about DM3.
00:01:28
Speaker
and everything that you guys have been building, you know, and everything in between. But I just wanted to start by saying that this is the second week where we're seeing crazy crypto activity. I'm not sure if you're following the prices very much. I tend not to get too into the details about that, but we've broken all time high. Bitcoin 70K, then we're back down at 65K. It's been a crazy week. Yes, it is.
00:01:57
Speaker
But not only the prices, so I'm not looking too much on the prices. But also when we look on the technology which is presented in the last month, there are really exciting times now and a lot of interesting applications are being presented now. Oh yeah, so many of them. And it's fantastic to see. Let me just ask you, how did you first get into crypto and Web3?
Stephen Cox's Journey in Crypto
00:02:24
Speaker
Like where do you come from? What's your experience like?
00:02:27
Speaker
Yes, I'm in the space almost since 2017. So I joined the company of a friend of mine, Christoph Jensch, who was one of the early persons working on Ethereum. And then later here, you build it, the company's locked it, which was focused on IoT and blockchain. The DAO was something which was developed by
00:02:57
Speaker
by Slogit. I've had him on the podcast just a few episodes ago, actually. He was really good to talk to him about Ethereum, the good old days and everything. Exactly. He's a good friend of mine for a long time. We worked together in a lot of other projects not connected to blockchain. Then when there was the chance to join, I joined Slogit and we did a lot of interesting work in these early years.
00:03:24
Speaker
especially to build blockchain applications connected to real world assets to real world applications. Right. That's great. So basically you got, you got in around 2017 just before or just after the first like big bull run, so to speak. Exactly. Yeah.
00:03:47
Speaker
Yeah, that's the same time I got really into it as well. There was a time that I was just looking at Bitcoin and looking into mine Bitcoin. I think back it was 2014 or 2015, and I was just putting on paper the profitability of like, okay, what if I just buy some Antminers and move to Iceland for cheap electricity? Is that going to be profitable?
00:04:09
Speaker
And then I realized that is not profitable. I mined some with my GPU. I lost my wallet and then I forgot all about it up until 2017. Yeah. That's interesting story. Well, it happens. There's so many people that seems to have just lost their first wallet or first crypto wallet. A lot of people just seem to, you know,
DM3's Mission in Web3 Communication
00:04:30
Speaker
lost or misplaced that. Yeah.
00:04:32
Speaker
Yeah, I wonder why. So tell me a little bit about DM3, like what is the main problem that you guys are trying to solve with the DM3 protocol? Yeah, maybe I can start with a little bit storytelling to tell you how we came to the point that we have to develop DM3.
00:04:52
Speaker
So when we started our venture studio corpus, which is a venture studio focused on developing web3 applications. And then if they are successful to build own companies out of this. So we came to the point that we need some ENS names and some of these names were available, some not. And. Okay.
00:05:17
Speaker
When we looked at these names we needed, but which were not available right now, so we discovered these were unused names.
00:05:28
Speaker
On OMC, they were offered for some price, but we were not able to connect to the owner. We tried to connect to them, to negotiate and to talk with them, but it was almost impossible. Sorry, why did you need the ENS names for in the first place?
00:05:48
Speaker
Yeah, we needed it for some projects so that we have some projects where we use ENS also as an address for the users. So that's why we need it fitting in as names for this. Got it. And by discovering these problems, we said, okay, we are on the web3 space. We have private and public keys.
00:06:15
Speaker
We have everything which we need to have encrypted communication directly. Why not build a tool which uses a registry on the blockchain and uses the keys to encrypt the messages. And this was the birth of the project in the beginning. It was called in S-Mirror, but then we switched it to a database.
00:06:41
Speaker
So, and what was the idea? The idea was, yeah, let's build a system which can use the existing keys or derived keys from this existing keys to build a secure communication.
Building a Decentralized Communication Registry
00:06:57
Speaker
And a second problem which we can easily solve in Web3 is that we can have a registry which is available for all. When we look to the email communication, which is the oldest communication form on the internet, actually this was the first killer application of the internet at all.
00:07:18
Speaker
So over the years, it is common that we have unencrypted emails. Even now, most of the emails which are sent are not encrypted. And I don't know if you tried some time to encrypt emails. I did. So I installed all the BGP stuff. It worked well. And I tried to get in encrypted communication with others. It didn't work.
00:07:46
Speaker
I never ever received a single encrypted email back, even if I published my keys. Yeah, and what is the problem in the PGP email world? We don't have a central registry for this communication information. There are some solutions, and in these closed ecosystems, like ProtonMail, we have encrypted emails. But this only works in this ecosystem.
00:08:15
Speaker
Right. It's the same thing with communication tools, right? Like WhatsApp has encryption, but it only works on WhatsApp, right? This is the second problem. I will come to this problem soon. But first, we decided to have a central but decentralized registry for communication information.
00:08:35
Speaker
And blockchain actually is exactly what you need for this. So we decided to use ENS as the way to build this registry. That means every ENS name can have a special text record, which contains your communication profile, which means the information about
Decentralized Relay Network for Messaging
00:08:54
Speaker
your public keys for encryption and signatures, and also the information how to deliver the messages.
00:09:01
Speaker
That's it. With this information, we have a general trustless and permissionless registry for this information. And now we come to the second topic. Now you said that we have all these two messaging solutions and every one of us is using these tools.
00:09:21
Speaker
When we look at our smartphones, I don't know how your phone looks, but mine has a lot of different applications. I have quite a few. I've got two screens of apps and folders, multiple folders. That's my crypto folder. This is exactly the same way mine folder looks. We have these messaging tools now.
00:09:48
Speaker
Now, most of them are end-to-end encrypted, but they are siloed. They are closed ecosystems. And if I want to communicate with you, we have first to agree to a special ecosystem. Otherwise, we are not able to communicate.
00:10:06
Speaker
So when we built the DMS3 proof of concept, we built a small messenger with using this registry. We decided to have a not connected network of decentralized nodes to deliver the messages. I can explain it in detail a little bit later. So then we presented this tool to the community. So this is the way how we work in the Cobus Venture Studio.
00:10:36
Speaker
We build prototypes in some months, three to six months maximum. And then we present it to the community and see what the community thinks about it. And if we see the potential, then we continue. And if we don't see and don't find enough feedback, then we go to the next projects. Right. And then we did this for DM3. We received a lot of positive feedback.
00:11:07
Speaker
Of course, some of them liked our concept messenger, which was nice, was a simple messenger. But the biggest feedback we received was what we really need in the web3 space, in the web3 messaging space, is interoperability.
Interoperability in Web3 Messaging
00:11:25
Speaker
So in the web2 world, we don't have it now. And when we look in the web3 world, in the web3 messaging world, exactly the same issue. So we have a lot of interesting solutions coming to the world last year and the year before.
00:11:44
Speaker
but they have the same issue like the Web2 world. Most of them are siloed. They are closed ecosystems. And the feedback from the community was, let's build something that we can connect all these solutions.
00:12:03
Speaker
So at this point, we did a change in the main focus of the DMS3 project. Of course, we have this messenger, and we keep it as reference implementation. But from this time on, this was not our main focus. Our focus was to work on this interoperability layer, to build an interoperable messaging
00:12:27
Speaker
the core protocol which can be used as messaging layer and which can also be used as an interoperability layer between other messaging protocols. So what we are working on now, so team 3 is a community protocol, is a community project
00:12:46
Speaker
And we want to build this layer 0 and layer 1 messaging solution on top of theme3. Layer 0, because it should be able to connect easily other existing solutions, like other protocols, other services, and as layer 1, that we can build messaging application also directly on top of the theme3 network.
00:13:12
Speaker
Right. Well, you've said something that I wanted to stop for a moment. You've said that even Web3 communications protocols are siloed. What do you mean by that? Do you mean they're siloed as in they're using certain chains, so there's no cross-chain communication between these messaging services? Okay. Maybe we have to take a look into how Web3 messaging solutions are implemented.
00:13:36
Speaker
Yeah. So we have some different approaches which are commonly used in messaging solutions. So all the Web 3 and the Web 2 messengers, they follow almost the same approach. They have a centralized service. And with the centralized service, they build a messaging solution. That means if I send a message to you, I send it using this centralized service.
00:14:03
Speaker
This is a good approach, but you still always have decentralized almighty coordinator in between. This solution cannot be censorship resistant because decentralized partners can always censor.
00:14:22
Speaker
Also, from the privacy perspective, even if the solution is end-to-end encrypted, which means that the messages are encrypted, but their meta data are not. Now, if I have a centralized service, then I can always track who is sending a message to whom.
00:14:43
Speaker
You can't see the contents of the message, but you can see the – Yeah. Exactly. And yeah, at some of these big messengers, even if they say that they are end-to-end encrypted,
00:14:58
Speaker
it's hard to prove because they are closed source systems. So if I have a system where it is possible to restore my account and restore all the old messages when I have a new phone, I should be very
00:15:17
Speaker
very interested if this is really end-to-end encrypted, because if it's restorable, somehow the keys must be available. And also, we don't know in closed systems if there are some backdoors or not.
00:15:37
Speaker
So in the Web3 space, we have a lot of solutions which are, let's say, Web2.5 solutions. That means they are using Web3 technologies, but they are also using a centralized service for the coordination of the messages.
00:15:55
Speaker
So this is one group of the WebSphere-based messaging solutions. And then we have another category of messaging solutions, which is built like the first approach from Ethereum. When Ethereum was created, we have this peer-to-peer network for the blockchain. And also there was proposed a peer-to-peer network for messaging, which was Whisper.
00:16:23
Speaker
and the peer-to-peer network for storing information, which was swarm. And so the Whisper-like systems, they are using a broadcast network or a peer-to-peer network to transmit the messages. That means if I want to send a message to you, I simply connect to one of the nodes of this network,
00:16:46
Speaker
I encrypt it so that only you can read it, and then I send it to one of the nodes. Then this message is published in the network, it's distributed, and on whatever node you are connected to, you can get this message and read it because you are the only one who can decrypt the message. But it's distributed in the network. This is a great approach, especially when we look at the privacy aspect.
00:17:15
Speaker
So I cannot track who is sending a message to whom. Because you are sending a message to the network and someone is taking a message from the network. I have no connection to see that it is from you or who is the recipient you have the message addressed to.
00:17:39
Speaker
So it wouldn't, excuse me, it wouldn't be like a normal transaction on the blockchain. You wouldn't see like this wallet sent something to this other
Scaling Challenges in Decentralized Messaging
00:17:49
Speaker
wallet. This has nothing to do with blockchain. This is simply a communication network. It's like the network of nodes we have in the blockchain where all the transactions are communicated, but for messages. So this works very well.
00:18:05
Speaker
But when we think about modern or the most famous messaging solutions, they are sending hundreds of millions of messages per day with attachments, with multimeter attached to it, and so on. And now think that you have to
00:18:25
Speaker
to publish this in a peer-to-peer network. This is quite problematic. These networks work very well if you have not too much messages sent, but if they grow, they might get in trouble because of scalability issues. Of course, you can do sharding and all these things also in these kinds of networks, but we know from blockchain networks that sharding is not an easy task.
00:18:55
Speaker
Especially not if you have a network which should transfer messages or publish messages in millions and billions all the time. Well, you probably need some sort of decentralized storage for the multimedia. You can't store them on the chain itself, I guess. Even if you store it in multimedia, only small messages. Now, if you send millions and hundreds of millions of messages in such a way, it is quite challenging.
00:19:25
Speaker
Of course. So we chose another way of decentralized network to distribute a message.
DM3's Message Relay Network Solution
00:19:35
Speaker
So we call it a message relay network. This is also a network of not connected decentralized nodes, but these nodes are not connected to each other.
00:19:47
Speaker
These nodes are available as relays for messages and the receiver decides which nodes he is connected to. So that means in your communication profile you publish what are the keys for encryption and signatures and you publish which
00:20:07
Speaker
of these relay nodes you are connected to. And when I want to send a message to you, I simply read your profile, find the encryption data, and I find what nodes I can send the message to. And with this, we have a very easy scalable network of decentralized nodes. But because the nodes are not distributing the messages, we don't have this problem that we
00:20:36
Speaker
get in trouble if we have more and more messages. The network scales very easily because if I need more capacity, I can simply have more nodes in the network and it works well. Right. So, and the other point is this type of message really network is a very lean approach. This means it needs only a
00:21:03
Speaker
very lean infrastructure to start with this project. Now, I don't need a peer-to-peer network which distributes the messages. And if I connect a client to this network, it doesn't need to be part of this network. It doesn't need to run a node of this network. It simply makes a connection to one of these nodes and sends the message.
00:21:26
Speaker
And when it came that we changed our main focus to become an interoperability protocol for messaging, instead a protocol which should replace all the others.
00:21:41
Speaker
this message relay network is very well suited to be such an interoperability layer. Because such a relay node can also be a gateway to another solution. It could be a gateway to a centralized solution. That means if I want to send a message to
00:22:01
Speaker
a recipient who is in a centralized solution, then I send the tn3 message simply to this delivery service or message, really a node.
00:22:14
Speaker
which is connected to the centralized network. And then this really node can inject the message into this other network. Very easy. Or if I want to be connected, which does appear-to-peer network, it's easy. Then some of these relay nodes are also nodes of this peer-to-peer network. And if I send a DM3 message to the relay, which is the gateway to the other network, then it injects the message in the other network.
00:22:44
Speaker
And with this, we can very easily build an interoperability layer because these gateways are very lean and easy to implement. And with this, we want to build this connected ecosystem, not by replacing all the other protocols and all the other nice solutions, but by connecting them and helping them to become part of the DMC network.
00:23:12
Speaker
I think that's exactly what kind of the entire ecosystem needs at the moment is more interconnectivity tools. And the more interconnectivity we achieve, the better off the entire ecosystem is. You've said something that I wanted to unpack for a moment. You've said that these communication relayers, they can potentially also connect to even centralized applications. How does that work? I think that's a really interesting use case there.
00:23:40
Speaker
Yeah, so let's say we have a centralized messaging solution with our own ecosystem, then these ecosystem can run one or a number of freely nodes which are connected to this network. And when I, from any other DM3-compatible
00:23:59
Speaker
solution, send a message to one of these persons inside this centralized system, I send it to one of the relays which is connected to the centralized system. And then the message is taken, received from this relay node, but instead of being cached until it is delivered, it injects the message in this other network. Right, so the other network could be WhatsApp, for instance.
00:24:27
Speaker
Could be, yes. And when I talked about this registry, this is exactly the crucial part of the whole system. If I want to send a message to the centralized receiver, or the receiver in the centralized system, I need to know the communication data from this recipient. So I said, we are using ENS for this.
ENS Registry Complexity and Solutions
00:24:55
Speaker
And let me give a little bit more insight how this ENS registry indeed works as a general registry for all different solutions. Please. Of course, if you want to store your profile on your own ENS name, you can do this. So I have my own ENS name.
00:25:19
Speaker
I published my communication, my DL3 profile directly on this name. To be honest, this is something for very special people. Let's put it this way. How come?
00:25:36
Speaker
this transaction to store this profile on ENS on layer one on Ethereum might be a very expensive task. Right. So I paid, so one time there was a bad time and I urgently needed to change my profile and I paid something like $35 to store my profile.
00:26:00
Speaker
A steep. You talked about a potential new bull run. The blockchain might be used much more than it is used now and the gas prices spike up again.
00:26:16
Speaker
And then this will be a very, very expensive task. And nobody will do this, to be honest. Yeah. Well, that's one of the limitations you sometimes have with layer one. Whenever there's a lot of activity on layer one, gas fees just go mental. That's what it is. Exactly. But if this would be the solution, it will definitely not work.
00:26:39
Speaker
But we did it in other way. So with ENS, there are some solutions to link outer sources to ENS.
00:26:51
Speaker
So we are using the cross-chain interoperability protocol CCIP from Chainlink, which means you can have a value which is verifiable on chain, but it is stored on another device or not a device, on another source. Now this could be a layer 2.
00:27:11
Speaker
This could be a central cloud service. This could be a cross-chain, any other blockchain, whatever source it might be. It works like this. So if I ask for this value, I can simply ask the smart contract for this value. If this value is not stored on-chain, I will receive the information. The information is not here.
00:27:34
Speaker
But the information can be fetched from displays. I get information how to fetch the information. And I also get information what proofs are needed to verify the information. So then I can ask this other source. Let's say it is stored on a layer 2, like Optimism or Arbitrum or any other layer 2 solution. I get information from this layer 2.
00:28:02
Speaker
And I get also the proof, which is needed to verify the information. And with these two informations I go back to layer 1.
00:28:11
Speaker
and call another function in the smart contract where I deliver the data and the proof. And then the smart contract can give me the information, yes, this is validator or not, this is not validator. And with this, it is very easy to include other sources. If I have decentralized cloud messaging service,
00:28:35
Speaker
which is managing the registry of the users in a cloud service, they can add it as a subdomain from ENS by using this CCIP resolver technology. If the solution is living on the other blockchain, they can be integrated and link it to another subdomain of ENS.
00:28:58
Speaker
If they are layer 2, they can be linked in exactly the same way. And with this, we have this single source, which is ENS, as the general central registry, but the data sources can be distributed.
00:29:15
Speaker
So, and of course nobody or most of the people will not store this communication information on layer one. They will store it on layer two or somewhere else. And other solutions, they can store it wherever they want and then link it to an S. And with this, we have this channel registry.
00:29:37
Speaker
which is accessible by everyone, which is permissionless and trustless. And so it can be used as this general communication profile registry, which makes it possible that different ecosystems can share the access data or the communication data in this registry.
00:29:59
Speaker
That's fascinating. So when you say a registry, a centralized registry, do you mean the actual encrypted messages that you just leave there? No, not the messages, the information, how to send messages. In this registry, I find, for instance, the public here, which is needed to build the encryption that I have this end-to-end encryption from my client to the receiver's client.
00:30:29
Speaker
I also have the public here for signatures. Why I need us? Especially in email, we see it very often that I receive an email which says it comes from, let's say you, but you have never sent it. Someone hijacked your email name and you can't do anything against it. I receive it and it looks like as it comes from you, but it is not.
00:30:59
Speaker
Yeah. So and in Web3, we have this technology to prevent this from happening. So we can have signed all information. So that is very easy for me to prove that it comes from you and only from you. That's why we have also the signature key. And we have in this profile also the addresses of the delivery services of these message relay nodes I'm connected to.
00:31:28
Speaker
And that's it. This is the whole communication profile. And with this profile, I can establish a secure communication always to anybody who published this information. I know how to deliver the message. I know how to encrypt the messages. And when I signed a message, the other one can read my profile and find the signature key to verify that it is really send it by me.
00:31:58
Speaker
Right. And when it comes to storing the message, we decided that the core protocol is not responsible for storing the messages. So the core protocol, the core DM3 protocol, which is the DM3 message transport protocol is only responsible for transferring or sending messages from A to B.
00:32:24
Speaker
That means in this protocol, we define how this message is structured, how it is encrypted, and how these delivery services, which are these message relay nodes, are working. And that's it. And when a receiver reads the message from this delivery service or from this message relay, they are deleted from this node.
00:32:47
Speaker
That means in the network, only unread messages are cached. As soon as they are delivered, they are removed from the network. That's why the network never grows because no messages are stored for a long time. The client is responsible to store the messages.
00:33:11
Speaker
The client can store it locally. It can store it on a decentralized message, like IBFS-based storages, Web3 storage, or something like this, Filecoin, or other solutions. Or it can store it also on a central cloud service. It can store it as a file in my cloud drive.
00:33:35
Speaker
Whatever, the protocol doesn't restrict the client how to do it. And the user should decide what he needs. Maybe he said, okay, I read maximum privacy. I don't want to
00:33:52
Speaker
give the control over this data to anybody. I don't want to share it on a cloud service, but I also don't want to share it on a Web3 storage. So Web3 storage is great, but if I store encrypted data in a Web3 storage, like IPFS for instance,
00:34:11
Speaker
IPFS is not a storage, it's only a directory service, but somehow it is stored. But when I publish data on IPFS,
00:34:25
Speaker
I cannot get it back. Now I cannot delete it. Now if someone else already stored it on his node and keeps it there, it is there and it is addressable by the hash. Yeah, on IPFS though you could, if you don't pin a file, it just gets picked up by the next garbage collector run. And that's I think once every 24 hours or something like that. But I don't know if it is picked.
00:34:55
Speaker
And I don't know if it is stored somewhere. And for instance, if I would collect your encrypted messages you store in such a web3 storage and some
00:35:10
Speaker
time in the future, the encryption is not secure anymore. This is public information. So that's why you always have to think about what is the best way to store my messages.
Flexible Data Management in DM3
00:35:22
Speaker
And from the protocol level, from VM3, we don't say this is the best solution or this is the best solution. We say a client has to decide and the user has to decide what is the best solution to store my messages.
00:35:36
Speaker
And that's why the base or the core protocol is not talking about storage, it's just talking about transmission.
00:35:46
Speaker
The DS3 protocol is a very modular protocol. Now we have this message transport protocol, which is the core protocol, but then we have a lot of different protocol extensions. Now there are protocol extensions for more privacy. We have them for group chats. We have it for spam protection and a lot of different attachments
00:36:14
Speaker
There are extensions we have so that the solutions which are using the protocol can decide what part of the protocol they want to use and maybe they are using other parts from their own stack.
00:36:29
Speaker
Are you familiar with the IBC protocol? It's the Inter-Blockchain Connectivity Protocol that the Cosmos, what that Interchain are working with Cosmos have built. And that's supposed to help communication between blockchains.
00:36:46
Speaker
And I just noticed some interesting similarities there so that protocol is just concerned with transporting messages from one blockchain to another but the way it works is it requires something called a light client. And a light client is a very light version of let's say blockchain A on blockchain B so that each chain is
00:37:08
Speaker
is aware of each other's state. So that's how they can verify that the transaction is real and that piece of data has happened. So you could transmit messages, you could transmit tokens or anything else in between, but that is more of an inter-blockchain protocol rather than a communications protocol. Right. From the wording, yet for both
00:37:30
Speaker
things we use the term messaging, but it is completely different. Now we are talking about peer to peer messaging with messages between people. And it's a complete different game when we talk about messages between blockchains. Because this is a machine to machine messaging and we are talking about human messages.
00:37:58
Speaker
Yeah, no, yeah, of course. So that's actually a good distinction to make because you have a protocol that technically you said it's very modular and people could use it for different things. Do you see or are you building the infrastructure so that other applications may be built on top of this?
00:38:21
Speaker
So as themes-free organization, we build themes-free as an open source and a public good project. So that means all the sources, all the information, all the specifications are open source and can be used and adapted and extended by everyone. So I think it's very important to know. So it's not a closed system. It's completely open.
00:38:46
Speaker
And we also try to communicate with the community very well to see what is really needed and what helps and what is needed in applications. So that means, yes, we provide the stack of functions of specifications and also of libraries so that it can be used.
00:39:08
Speaker
So if you, for instance, have an own messaging solution already up and running, you might be interested to have the specification how to become the entry compatible.
00:39:23
Speaker
And maybe you are interested to use some of our code to be a little bit quick enough. For instance, if you want to build your own delivery service, which is this message relay node, then of course you can use our reference implementation and build on top of it.
00:39:43
Speaker
So if you only want to run a standardized delivery service node, then you can use our package out of the box. But if you want to use it to connect it to your solution, then you can use the code and extend it.
00:40:00
Speaker
What we also are providing is we have a set of components you can use if you need messaging inside your application. Now, messaging is not only used in messaging solutions, which is, of course, a special and interesting approach. And a lot of applications do it like this. But when we look, for instance, in social media applications, in wallets, in games,
00:40:29
Speaker
A lot of different applications, we see that you need messaging also inside these apps.
Integration with Various Applications
00:40:37
Speaker
For instance, you have a multi-sig wallet and you want to include that the key owners can have a close and secure communication with each other.
00:40:50
Speaker
You would include a messenger inside your wallet, which is focused on a special purpose. Or if you have a website where you have to present some of your specialists and you want the community to be able to communicate with these,
00:41:10
Speaker
Of course, you can publish your email, but you also now can just include a messaging window so that everyone who comes to the site directly can send a message, a secure message encrypted and decentralized to this person, to this specialist.
00:41:30
Speaker
Or you have a game where the players want to communicate during the game with each other. You need a messaging solution to be included in your application. And for most of these applications, actually this messaging part
00:41:47
Speaker
is only a very small side project. Now they want to focus on a very specialized messaging solution there. They just want it to work. So N15.3 it's quite as easy as writing one or two lines of code. Now you just include this component, you configure it, you
00:42:13
Speaker
and your application has secure messaging. Of course, then you should also provide some infrastructure, some message-related nodes so that it becomes more and more decentralized. Of course, you could also use our provided nodes, but this is not the intention. We want others also to run these nodes so that the network becomes more and more decentralized. Yeah, and with this,
00:42:42
Speaker
you have your CQ messaging included, just some lines of code. And this is actually something what a lot of applications are doing right now. We have a lot of requests that they want to build it like this and use it as the internal messaging solution for their depth so that they can have these functions with low effort.
00:43:10
Speaker
And something what we can provide with DM3 is also very special in this space. For instance, we have also a lot of Web2 based embedded components for messaging as well. There's a lot of websites have support chat included right now.
00:43:31
Speaker
If you use it, I use it sometimes. And if they are not very quick in responding, then I leave this page and maybe I will never come back. And even if I receive an answer, I will never see it.
00:43:47
Speaker
I do that sometimes. I do that. They reply to me after a while and then I come back in 15 minutes and the message is closed already. The chat's closed. And this is how it works. And often these embedded messaging solutions are also not encrypted or very simple.
00:44:05
Speaker
So with Team3 we have it encrypted and we have a very interesting approach because this network is right now fully decentralized. I can also have different
00:44:19
Speaker
different accounts which can be linked. Now I would go to this website, I would sign in just with a signature from my wallet, but I must not connect it to my standard or my default messaging
00:44:36
Speaker
I just go to the site, log in and so I have a secure communication. But if I see that this is a value-able communication, I just can link it to my inbox. This is just one click or just one
00:44:55
Speaker
information which must be sent and then we can link these accounts together so that I have it in my inbox where I can manage it very well. And here I don't need to use the DM3 app for this.
00:45:13
Speaker
every DM3 compatible application can be addressed. So I decide what message I'm using. And when I go to a website and see, okay, this is an interesting communication, I want to store it or I want to connect it to my inbox, I just connect it to my inbox. And then it is connected. And whatever message I use, I have this connection.
00:45:39
Speaker
And this is possible because Team3 is an interoperable protocol and it's very easy to add these linked profile extension to my solution.
00:45:54
Speaker
That's very cool. So effectively, you would be able to talk to people or organizations through different communications.
Unified Inbox Vision
00:46:02
Speaker
Like you said, you could have a website, you could have someone's group on some other communication network, you could have even things like email, and then you could see all of those in one centralized, your own personal inbox.
00:46:21
Speaker
Exactly. That's very cool. So I have my inbox and all communications I want to manage or I want to store, I will link to my inbox. And as long as this solution is theme-free compatible, this will work. That's seriously cool. I don't think I've seen that before. No.
00:46:45
Speaker
This is something we defined in the last months. So this feature will be released in the next months. It's not yet available, but it will be. So that means if you use our DM3 component right now and embed it in your application right now, it's not linkable.
00:47:10
Speaker
But as soon as we release this function, it's automatically linkable. You don't need to change your application, it's just an update of the core library and then it will be impossible.
00:47:26
Speaker
That's seriously cool. I do hope that a lot of companies are going to be adopting this because there are a lot of communication threads that someone manages. You have your WhatsApp and your Telegram and your Discord and your email and whatever live chats you happen to have with support and other websites. It'll be fantastic to see a portfolio like your own inbox of all of that stuff. I'm definitely interested in that.
00:47:51
Speaker
Yeah, and when you talk about these big messaging solutions, at least in Europe, right now we have some regulation which is at least at the first site looks interesting. There will be enforcement that these big messaging solutions will open their interfaces in the future.
00:48:15
Speaker
So that it might become interval. And what we see right now is that some of these already said that they will open an API or they will publish an API so that others can then connect to these solutions. So this will happen. I think all the big ones will do this.
00:48:41
Speaker
But actually I don't believe that this will serve the interoperability problem. So if WhatsApp is publishing such an API, that means if my messenger should become compatible, it must also implement this API. And when it wants to be compatible to messenger XYZ, it must implement maybe some more of these APIs.
00:49:09
Speaker
Yeah, for sure. Small messages will do this, but I doubt this that a big messages will start to build these interfaces to all the others, especially to small ones.
00:49:24
Speaker
I think what you're going to see is you're going to see aggregators. You're going, first of all, you're going to see library wrappers that just have a collection of functions that offer API for, okay, this is how you fetch WhatsApp. This is how you fetch Telegram. This is how you fetch signal messages.
00:49:42
Speaker
And then you're going to have companies that aggregate that using those wrapper libraries. So you're going to have like little apps that kind of aggregate all of your messages, you know, maybe web through, maybe some Web3 stuff. But I think that's, if they open, if those companies open their messages, as you suggest, then I think that would be the next kind of hot new thing on the market. But it's much easier actually. Just use Team3 because with Team3,
00:50:12
Speaker
we can build data and we will build bridges to all these interfaces and then the only thing you need to be compatible with all of these APIs is just to be DN3 compatible.
00:50:25
Speaker
then you can send a message to any other solution which has such an DNS-free connector. The small solution, my messenger, must not implement all these APIs. It simply needs to be DL3 compatible and then it is automatically compatible to all these interfaces.
00:50:48
Speaker
That makes sense. You're just abstracting away from the complexity of the APIs. Exactly. And from the Web3 world, we have learned that diversity is something good. When we look for the clients of blockchain, it's good to have not only one implementation, it's good to have a diversity. And I think the same is valid for messaging.
00:51:15
Speaker
So right now in the Web2 approach, it is the winner takes it all. There is a competition and the big ones, they try to be the most mostly used messengers. They don't care about it or probably it's not the goal of those messengers. But when we look especially in the Web3 space and see
00:51:41
Speaker
messages, we see that they are focusing on small and special ecosystems. Now, for instance, you can have a messenger which is focused especially on the NFT community and has special functions to deal with MFTs and maybe to integrate it to have token gated access to messaging groups using NFTs and all these things, which is very great for these communities.
00:52:08
Speaker
But if I don't have interest in NFT, this messenger is not the best choice for me. But I want to be in contact with people who are using this messenger. And that's why diversity is quite good. And as long as we have this interoperability layer so that the end user can decide which messenger fits best to his needs,
00:52:32
Speaker
And then not understanding what message is the choice of the recipient, he can send a message.
00:52:42
Speaker
Yeah, no, for sure. And I mean, before Web2, most of us relied on sending messages via SMS, right? That was the standard. Apart from email, you had the standard like you could just send messages provided you have a phone number, work your phone number, could you send a message to everyone? And then once Web2 really picked up and multimedia picked up, people realized that they really can't send videos and images and all this other media and hyperlinks through SMS. And that's when it all kind of became a bit centralized.
00:53:12
Speaker
My question is, can you build mobile apps using the DMT protocol? Yes, of course. The protocol is a very, very lean protocol. What you need is you need a connection to get the registry information. Of course, you don't need to run your own node.
00:53:35
Speaker
use RPC services or nice decentralized RPC services. And we have a lot of interesting solutions right now. You can use a secured RPC connection, whatever your application wants to use. So with this, you get all the information you need from the registry. And sending a message is simply a connection to another server and send a package of data. That's it.
00:54:05
Speaker
Of course, I mentioned this earlier, so we have also protocol extensions which make it a little bit more complicated. For instance, for more privacy, the DM3 core approach is not fully private. If you monitor some of these nodes, you can also track the communication
00:54:30
Speaker
for those who are sending and receiving messages. But yeah, we also have a tour-like network between these nodes so that we can have an additional privacy layer. You must know, privacy you never get for free. Never.
00:54:52
Speaker
So you must have a special infrastructure for it. And that's why not every communication you send might need the same level of privacy. If I messaged with my son what he wants to eat for lunch today, it might be enough if this message is encrypted.
00:55:17
Speaker
If I am a journalist in a country where I have to be careful what I'm saying and whom I'm communicating with, it might be much more important for me to have a very private and real private communication. And that's why DiEM III supports different levels of privacy as well.
00:55:45
Speaker
And I can decide what level of privacy I need for my messages. That's good. Of course, if I want to use this.
00:55:56
Speaker
tool-like network, it might be cost some fees for me. I might have to pay something so that I can use it. But yeah, as I said, privacy is never for free. And so the user must be able to decide what level of privacy he needs.
00:56:19
Speaker
Right. I was actually going to ask about the pricing. Obviously, is there a pricing associated to using the protocol or how does the network sustain itself or how does the nodes get rewarded? Yes. The protocol itself, we are building as a public good. Then we decided in the very early beginning of the industry that this must be a public project.
DM3: An Open-Source Public Good
00:56:43
Speaker
because you cannot establish such an ecosystem protocol and try to license the core protocol libraries also. This will not work. It also must not be controlled by a centralized company because a decentralized protocol controlled by centralized companies is also not the best approach.
00:57:06
Speaker
And that's why we decided in the very beginning that DiEM3 must become, has to be published as open source and is a public good. And that's why it's free, accessible to everyone. We are not making money with this protocol. There are some services on top of it, like operating a delivery service node.
00:57:35
Speaker
you might take money for this. If you are offering privacy features, you might take money for this. There are some things inside the network which can be used to monetize the service. This could be done by others as well.
00:57:56
Speaker
Yeah, but this is nothing which is connected to the core protocol, is free and can be used by everyone. Got it. That makes sense. So I was just going to ask, what is your guys plan for 2024, 2025 in terms of maybe new releases or areas you're looking to expand?
Future Plans for DM3
00:58:19
Speaker
Yes, so we released last year the first version of the specification. And during the last year, we also released the reference implementation. Then we did a complete newer implementation of this user interface components, which can be embedded in application. This we released beginning of this year, so that now you can use these components and embed it into your applications.
00:58:49
Speaker
So right now we are working a lot on the cross-chain functionality. So we did not talk a lot about this only when we talked about a registry.
00:58:59
Speaker
So as the registry could be on different sources, different chains, different naming services, different identity services, we invested a lot of effort into this crossover technology so that we can easily attach other sources to ENS.
00:59:21
Speaker
So, and with this, there are other projects which are using already this technology and we are connecting other ecosystems to this network so that they can use the DL3 protocol natively in their network. For instance, Moses did this for the Moses network and the new coming Moses name servers, which will be released in the next weeks or months.
00:59:46
Speaker
And then when they release it, it is already natively supported by DMsray. And we are doing this for layer tools like Optimism and also other layer tools so that they can use it natively in their ecosystem. So this was, we did a lot of work to this so that it can be used in all these ecosystems very easily.
01:00:12
Speaker
So in the next months, we also work on a lot of protocol extensions like group chat, like his privacy extensions. Also, we are working on a special form of spam protection, but we know from most of our communication channels that spam is a real problem. Right. We can solve this.
01:00:37
Speaker
easily is maybe the wrong word for this, but we can solve it. So with DiEM3, we have several levels of spam protection. So the first levels are that we can see what addresses are sending messages. And we can request from these addresses, which are the wallet addresses of the owners of the communication,
01:01:02
Speaker
That they have used addresses not that they have done some transactions before they are able to send messages we can request that they hold some tokens or some nfts or some ease or whatever we in with this we can make it already very very,
01:01:21
Speaker
difficult and expensive for spammers. But then in mid of this year, we will build another layer of spam protection, which is based on the DM3 token. There will be a DM3 token for the governance and also the standardization process and also for especially the spam protection. With this DM3 token, we can attach tokens to messages.
01:01:50
Speaker
Oh, wow. It means if I want to send a message to you and you are spent at this time, then you say, okay, I only really receive messages if an amount of tokens are attached to this message. So then you say maybe I want to have.
01:02:07
Speaker
100 of these spam points attached to my message with the worth of let's say 10 euro. And if I send a spam message to you, you say you market a spam and in this moment these tokens are burned.
01:02:25
Speaker
So if you read this message and everything is fine, the tokens are returned to the sender. So that means if I send a message to you and you request that I attach or I deposit some tokens to it for spam protection, nothing happens if it's not spam. I will receive it back, everything is fine.
01:02:46
Speaker
But if you market a spam, it is ruined. And so with this, we can make it insane, expensive for spammers to send messages. That's a very cool idea. I like the fact that the tokens return to you once the message has been approved and it doesn't cost you, say, 10 euros to send a message every time. Exactly. If it would cost you, it will not work. People will not pay for sending messages.
01:03:15
Speaker
But if I say, okay, I have a budget of let's say 10 or 20 Euro, which I can use for spam protection, then I will never feel that there are tokens attached to the messages. I will work and we will message with each other and everything is fine. Except I start spamming and then you will burn my tokens. And then most probably I will not send messages to you anymore.
01:03:44
Speaker
But this is exactly what the intention is. And in the same way, we also can do advertisement messages. The same way, we can attach tokens to the message. And if you read the message, you will receive the tokens. And with this, we can make peer-to-peer marketing. It's exactly the same technology which we are using for the spam protection.
01:04:11
Speaker
In this case, the big companies, they will not be paid for us for getting a click. So I simply send messages to others. And if you say I will accept marketing messages, then you will get paid if you read it.
01:04:30
Speaker
That's pretty cool. As I said, for this, we need our token because it's not easy to do this with ease. If I would use ease for this, I would die on transaction costs. Even if I do it on a normal layer 2, it might be too expensive for such a network. That's why we will have our token, we will have a special roll-up for this so that it
01:05:00
Speaker
maybe a layer 3 roll up so that it is really cheap to send these tokens from message to message. But with this we can provide a really nice way to protect people from spam. So we don't need any longer to scan for
01:05:24
Speaker
for information in email and your guess if it is or if it is not a spam message with the DM3 approach, spammers will very quickly stop sending spam because they will discover it is too expensive.
01:05:43
Speaker
It's definitely a cool idea and I'd love to see it live to kind of see how people react to it and what kind of, you know, responses it gets. I think it's a great innovation to kind of combat spam. It's definitely like great, great work on that front. Do you, do you have anything else that you maybe like to add or anything to, maybe you want to mention the social media or the website or anything that people can go and kind of take a look at?
01:06:09
Speaker
Of course, you can visit our website, dm3.network. You get a lot of information there. Also, you have access to our GitHub repository. You find all the links on our website. You find us on X, on Forecaster, on every interesting social media as well. Mostly it's dm3 protocol. Yeah, and something we want really to emphasize is
01:06:38
Speaker
You are invited to participate. We don't want to be alone in the D&3 network. We don't want to build it alone. We just want to connect the community. And that's why there is an invite that everyone who wants to use it, just use it. Give us your feedback.
01:06:58
Speaker
give us the information what you need, what you are missing, what you need in a different way. We are very open to discuss this. Also, you are invited to be involved in the protocol discussions. Later on, our nonprofit organization will become a DAO so that we can make more and more decisions completely in the crowd and the community so that everyone who wants to grow this project can participate.
01:07:28
Speaker
Now, we are doing also a social experiment. Now, we try to establish a standard with three technologies. And let's see. And we are very confident that it works because it helps all the protocols, all the solutions which participate. We don't want to replace, we want to connect.
01:07:55
Speaker
Well, that sounds amazing. Thanks a lot, Stefan. It is, like I said, I think it's a tool that has amazing potential and I want to see some live applications of it. And you and your team are more than welcome to come onto the podcast, maybe, you know, six months, maybe one year from now, again, and kind of just do a quick pulse check, see where you guys are at, see what applications were built with it. I'd very much love to see that. Yeah, we absolutely will do this.
01:08:22
Speaker
Awesome. Well, thanks a lot for the conversation. I've learned a lot and it was genuinely a pleasure. And yeah, I guess we'll speak sometime in the future. Thank you. Thanks for having me. It was a great time. Thank you. Cheers. Thanks, everyone. Bye.