Transcript
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.
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. I'm here today with Stephen Cox, who is the co -founder of a Web3 communications protocol called the DM3.
Speaker: Nice to meet you, Steven. How are you doing? Yeah, nice to meet you too. It's nice to be on your show.
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. 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.
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.
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? Like where do you come from? What's your experience like?
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
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.
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.
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?
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, lost or misplaced that. Yeah.
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.
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.
Speaker: When we looked at these names we needed, but which were not available right now, so we discovered these were unused names.
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?
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.
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.
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.
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.
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.
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.
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.
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 your public keys for encryption and signatures, and also the information how to deliver the messages.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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.
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.
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.
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.
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,
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
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.
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.
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.
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,
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.
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.
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 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.
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
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.
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.
Speaker: Of course. So we chose another way of decentralized network to distribute a message. 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.
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
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
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
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.
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.
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
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.
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.
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.
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.
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
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.
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.
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.
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?
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.
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.
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.
Speaker: But we did it in other way. So with ENS, there are some solutions to link outer sources to ENS.
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.
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.
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.
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.
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,
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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,
Speaker: IPFS is not a storage, it's only a directory service, but somehow it is stored. But when I publish data on IPFS,
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.
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
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. 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.
Speaker: And that's why the base or the core protocol is not talking about storage, it's just talking about transmission.
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
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.
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.
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
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
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.
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?
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.
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.
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.
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.
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.
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,
Speaker: A lot of different applications, we see that you need messaging also inside these apps. 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.
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,
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.
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
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
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,
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.
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.
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.
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.
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
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
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
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.
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.
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.
Speaker: That's very cool. So effectively, you would be able to talk to people or organizations through different communications. 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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,
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.
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.
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.
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
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.
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,
Speaker: And then not understanding what message is the choice of the recipient, he can send a message.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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,
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,
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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?
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
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.
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.
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.
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.
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.
