The dm3 Protocol — Web3 Messaging — Decentralized and Scalable by Design
Abstract
Designed to address the complexities of the web3 messaging ecosystem, the dm3 protocol pioneers technological innovation by merging layer-0 and layer-1 approaches to set new standards for interoperability and scalability. By rigorously analyzing existing architectures — from centralized services to broadcast networks to blockchain-based and message relay networks — the protocol identifies and addresses the fundamental challenges of security, privacy, censorship resistance, and scalability.
At its core, the adoption of a Message Relay Network architecture represents a strategic move toward a decentralized, secure, and scalable messaging infrastructure.
The dm3 protocol enables direct integration with a wide range of existing messaging services, networks, and applications, fostering a cohesive ecosystem without compromising security or privacy. Its modular and flexible architecture is designed to support scalable expansion to meet the increasing throughput demands of Web3 communications and beyond. As the foundation for enhanced connectivity and interoperability within the messaging space, the dm3 protocol is set to redefine the landscape and embody a critical advancement toward a more interconnected digital future.
The previous article emphasized the importance of interoperability for sustainable web3 messaging solutions. The dm3 protocol is a combined layer-0 and layer-1 messaging protocol that can be seamlessly integrated with other messaging protocols, services, networks, and applications without compromising security and privacy, and can be used as a core protocol for new messaging solutions as well.
This paper discusses the critical importance of decentralization and how to achieve the necessary scaling to handle the number of messages that today’s messengers can deliver. It also covers the requirements for building an interoperability protocol.
Messaging architectures
There are many different possible architectures for implementing a messenger service. While many of the existing and currently successful messenger services are usually operated as central cloud services, there are other interesting approaches, particularly in the web3 landscape. Each of these approaches has its strengths and weaknesses, and in the following, some of these approaches are compared and evaluated regarding properties essential for secure, private, and self-sovereign communication.
Centralized Service
Centralized messaging services are commonly built based on a client-server architecture, a model in which client devices communicate with a central server over the Internet. The central server acts as the central access point for all communications and is responsible for processing, storing, and routing messages between clients.
When a user sends a message using a centralized messaging service, the client device sends the message to the central server. The server receives the message and performs various tasks, including:
- Authentication and Verification: Since user accounts are managed by the service, the server first verifies the identity of the user who sent the message to ensure that they have the necessary permissions to use the service. Typically, this is done by checking the user’s credentials or session information.
- Message Routing: Once the user’s identity has been verified, the server uses its messaging protocol to determine where the message needs to be sent. The server keeps track of all connected clients and their status, so it knows which clients are currently online and available to receive messages.
- Message Storage: The server stores the message in a database or message queue until it can be delivered to the intended recipient. Depending on the solution, messages may be persisted on the server or only be cached until they are delivered to the recipient.
- Message Delivery: When the recipient’s device comes online, it connects to the server to check for new messages. If there are new messages, the server sends them to the recipient’s device.
- Acknowledgment and Confirmation: The server can also send an acknowledgment or confirmation message back to the sender to indicate that the message was successfully delivered. Also, instant information like “user is writing…” can be transmitted.
However, often other applications (e.g. social media applications) also have integrated messenger functionality, which is integrated into their applications. These messaging functions are often realized as centralized services as well.
One of the main advantages of centralized messenger services is convenience — that they can provide a consistent and reliable user experience across multiple devices and platforms. Users can access their messages from anywhere, and they don’t have to worry about managing message delivery or synchronization.
Centralized messenger services do have by design some limitations, including concerns about
- Security: End-to-end encryption is nowadays a common standard for most of these services used in the Western world although various messengers may offer the option to disable this without the user’s consent. Other messengers have known backdoors for monitoring communications by public authorities or similar. It is not uncommon for political decision-makers and law enforcement agencies to demand that encryption be softened accordingly. In some regions of the world, solutions with secure encryption are even prohibited. Many applications use embedded messaging (community internal communication, support, …). Even today, these messaging solutions are not securely encrypted.
- Privacy: Even with fully end-to-end encrypted communication, the connection data (i.e., who sent something to whom and when) and the chronological flow of the communication can be traced by the solution provider and thus evaluated if necessary.
- Censorship: Since the entire service is operated by a company or organization, including the management of users and their identity data, the latter can restrict the user at any time (e.g., not deliver messages) or even lock the user out of the service entirely. In particular, if the operator can be forced to do so due to legal requirements or other obligations, censorship cannot be prevented.
- Single-Point-of-Failure: With centralized services, there is always a risk that if the central server or another centrally used resource fails or is not accessible, the entire service will fail. This is often counteracted by redundant components and high-availability solutions.
If the number of users of the service increases, the service provider must ensure that the required bandwidth and storage capacity is available by expanding the resources accordingly. Some well-known services have hundreds of millions of users, the market leader even has over 2 billion with a volume of over 100 billion messages per day. Through linked server clusters and with suitable load balancing, the service can meet these requirements.
Broadcast Networks
In the web3, decentralized and distributed networks are the common standard. Blockchain networks such as the Bitcoin blockchain or Ethereum consist of many independent nodes that are connected to other nodes in a distributed network and exchange data (e.g., transactions). Each node has equal rights. The failure of individual nodes does not significantly affect the network, as all data is kept redundant. A user can connect to any node and thus interact with the network without additional permissions needed.
As part of the Ethereum ecosystem, Whisper was designed as a secure and private peer-to-peer messaging protocol. The core concept is that messages are passed encrypted to nodes of the network and then distributed in this network. The receiver and any other user can fetch the messages from any node in the network but only the designated receiver can decrypt it.
Now, many other protocols like Waku, xmtp, and others are using similar approaches.
As there is no centralized service involved, all tasks are performed in the network, including:
- Authentication and Verification: Since these networks are permissionless, often there is no authentication needed to connect to the network and to deliver messages or read information from the network. As only the real receiver can read the content, no additional verification is needed. For performance and additional security reasons, these networks can also restrict who is allowed to connect to the nodes.
- Message Routing: Messages that are published to any node in the network are distributed to all nodes of the network. There is no receiver information needed as the receiver can fetch potential messages from any node of the network.
- Message Storage: Messages are published in the network and stored on the nodes. If a client needs information, it connects to the network and fetches potential messages. As it is not known by the node if a message is delivered or not, it needs to store it directly or at least need to be able to get this information from other nodes of the network. Nevertheless, redundancy is needed to have no single points of failure.
- Message Delivery: Clients connect to the network to fetch potentially relevant messages. As all messages in the network are encrypted without any information about who the receiver is, it is the responsibility of the client to get and evaluate the messages.
- Acknowledgment and Confirmation: This information is also what the client needs to extract from the information in the network.
Messaging protocols and applications based on broadcast networks have some advantages.
- Decentralization: As they are built on distributed networks, they are decentralized without a single point of failure.
- Privacy: Also, as there are no direct transmission paths, that can be tracked, high privacy is given by design. Users can access their messages from anywhere by connecting to one of the nodes.
- Censorship Resistance: Like blockchain networks, these distributed messaging networks are censorship-resistant by design, as long as no entity or group is controlling all nodes.
Messaging protocols based on broadcast networks do have by design some limitations as well, including concerns about
- Scalability: As these distributed networks share all messages redundantly, scaling is not possible by adding additional nodes to the network (same as it is for blockchain networks). Technologies like Sharding are envisioned as possible solutions but are not yet available in production.
- Resource hungry: As nodes of this network must handle all messages (maybe also including attachments and multimedia content), these nodes must be powerful enough with high bandwidth connections to handle this data. Without a good strategy how to handle old data efficiently, these nodes must grow very strong. Operating such a node will be challenging even if this would be permissionless.
- Real Decentralization: Because of the challenges mentioned above, the number of running nodes can be restricted which can result in networks with only a few nodes operated by a few players. This might also influence the censorship resistance.
Blockchain (On-Chain Messaging)
Instead of using a separate network, special solutions are built on top of a blockchain directly. Sending messages is done by sending a transaction. As this is in most cases not feasible to do so on the Bitcoin or Ethereum blockchain, special application chains (like a layer-2 or layer-3 chain, a Polkadot Parachain, or similar) can be used.
This approach focuses on special use cases. Messages once sent, can’t be manipulated, or revoked. This communication often is less focused on privacy than on transparency. Instead of storing the message information on-chain (which will be in most cases too ineffective or expensive), it can be stored in a decentralized storage and only the hash is stored on-chain.
Most tasks are handled differently:
- Authentication and Verification: If permissionless and public networks are used, there is no authentication needed to connect to the network and to deliver messages or read information from the network. Encrypted messages can only be read by the owner of the accompanying keys.
- Message Routing: Messages are published by sending a transaction. As soon as this transaction is added to the blockchain and if needed data is stored in decentralized storage, the receiver can access it from any node.
- Message Storage: Messages are stored in the network (in a few special cases on-chain or in decentralized storage).
- Message Delivery: Clients connect to the network to fetch potentially relevant messages.
- Acknowledgment and Confirmation: As a message is delivered with a transaction, by monitoring these transactions it can be evaluated if a message was transmitted.
Blockchain-based messaging protocols have some advantages, which come from using a blockchain:
- Decentralization: As they are built on a distributed blockchain network, they are decentralized without any single point of failure.
- Transparency: Each transaction is reproducible in the blockchain. So are the messages, too. While the content is encrypted, the metadata information (from and to addresses and time) is transparent.
- Manipulation safe: Once a message is sent, it can’t be altered anymore. Also, it can’t be deleted.
- Censorship-free: If it is based on a public and permissionless blockchain, no censorship is possible.
While these on-chain messaging protocols are mainly focused on special use cases, some characteristics must be considered critically for certain applications.
- Privacy: As the messages sent are anchored in the blockchain by transaction, this information is generally not confidential (even if the content is encrypted and therefore not publicly readable). If the encrypted messages are stored on-chain or in public decentralized storage, the content is only secure as long as the encryption has not been broken. However, since the encrypted data is irrevocably publicly available, there is no guarantee that the encryption will remain secure in the future, meaning that this data is potentially public. Confidential data should therefore not be stored on-chain or in public decentralized storage.
- Performance: The performance depends on the underlying blockchain. As a transaction must be executed, this is also a decisive limitation for performance, even if the chain is particularly fast. Even more critical is when more messages need to be sent than transactions can fit in the next block.
- Scalability: If a blockchain is the base layer for the messages sent, the blockchain is also the limiting factor. If more messages are to be sent than the blockchain can process, the scaling of the messaging application depends on the scalability of the blockchain.
Message Relay Networks
In contrast to broadcast networks or blockchain-based approaches, peer-to-peer relayer networks are made up of nodes that do not communicate directly with each other. Messages that are sent to a relay node are therefore not forwarded to the other nodes in the network but are only temporarily stored by this node until they are picked up by the authorized recipient.
The choice of nodes to which recipients wish to have their messages sent is defined exclusively by the recipients themselves. Since recipients can use several relays of their own choice in the network, sufficient decentralization is ensured. In addition, everyone can operate their nodes to be completely self-sovereign.
As there is no centralized service involved, all tasks are performed in the network, including:
- Authentication and Verification: Relay nodes can be permissionless or may require authentication. Users can run their nodes or connect to existing services. Which nodes are used is defined by the users themselves. Nodes can store any message or only messages of authenticated users.
- Message Routing: Messages are sent directly to relay nodes designated in the user’s profile. No routing to other nodes is needed.
- Message Storage: Relay nodes only temporarily store messages until the receiver retrieves them. After successful delivery, these messages are deleted. The storage of the conversations is the responsibility of the clients.
- Message Delivery: Clients connect to the designated relay nodes to fetch messages addressed to the receiver. As all messages in the network (and stored on the relay nodes) are end-to-end encrypted, only the receiver can read the content.
- Acknowledgment and Confirmation: The relay nodes can send notifications to the recipient if they have messages ready for him. Confirmations are additional service messages sent the same way to relay nodes of the original sender of the message.
Messaging protocols, based on message relays, have some advantages:
- Decentralization: The network is sufficiently decentralized as users can connect to several relay nodes of their own choice and everyone is allowed to run their nodes.
- Censorship-free: There is no central instance that can censor messages. If a relay node refuses to accept a message, the sender can always use another node.
- Scalability: Since the network consists of independent nodes that do not (have to) communicate with each other and do not hold redundant data, the capacity can be increased simply by adding more nodes.
- Lean Core Protocol and simple infrastructure: The core protocol can be realized as a very lean protocol. Also, the core infrastructure is very simple and can be built step by step.
- Interoperability: Relay-based messaging infrastructures are well suited to establish interoperability with other networks and services. Contrary to centralized services no trust to a central instance is needed. Special relay nodes can act as a gateway to other services. Also, these gateway nodes must not provide other functions as it would be necessary if those nodes were part of a broadcast network.
The dm3 network
The dm3 protocol provides a messaging infrastructure based on a message relay network. The relay nodes (called delivery service nodes) form a network of independent message relays. All dm3 users decide which nodes they want to be connected to, including running one or even more self-hosted delivery service nodes. Publishing to which delivery services the user is connected to, allows the sender to determine where to deliver a message.
Delivery service nodes can also act as gateways to other messaging services, protocols, or networks. These gateway nodes are on the dm3 side like any other delivery service but are also connected to the other solution. So, these nodes can receive based on the dm3 protocol and inject it into the other service or network and vice versa. With this approach, the dm3 protocol provides a standardized way to connect messaging solutions to build a connected messaging ecosystem without compromising the privacy and security of existing solutions.
Decentralization
To build a connected messaging ecosystem that links big and small players, decentralization is essential. It is neither possible nor desirable for a centralized messaging service to act as an authority for interoperability. Others would have to submit to its dictates or at least trust it. This could even reinforce monopolization, as it would give this player additional power.
The path currently being taken by some services due to regulatory requirements to open up their ecosystem to the outside world through APIs is also not a practicable way to meaningfully build an interoperable messaging ecosystem, as this puts large solutions in an unjustifiably better position than small ones, which would then have to implement a large number of different APIs and would themselves have little chance of the market leaders also addressing their API.
With a decentralized interoperability protocol, all players are on an equal footing, so interoperability can be implemented by each solution connecting to the ecosystem and leaving it up to its users to decide how they would like to communicate.
However, a decentralized messaging core protocol that is intended to serve as the foundation for a connected messaging ecosystem must already be able to meet the throughput requirements that are necessary to integrate existing solutions, in addition to security and privacy, in terms of its architecture and infrastructure.
Scalability
Scalability plays an — if not the decisive role. While niche solutions (as many web3-based solutions currently are) can cope very well with the fact that they cannot currently be scaled to the extent that the market-dominating solutions would require, the situation is different for an interoperability protocol. If this were to break or collapse if successful, it would not only not be suitable but would actually harm the aim of a connected messaging ecosystem.
The dm3 approach is by design scalable right from the start. The network of independent delivery service nodes (message relays) can be expanded without restriction depending on requirements. If more solutions are integrated (be it new clients that are based directly on dm3 as the core protocol or existing solutions that are linked via a gateway) and the existing resources (nodes) are not sufficient to handle the traffic, the dm3 network can be extended accordingly with additional nodes so that the required capacities are available.
Conclusion
There are various approaches to realizing good messaging solutions. While the currently most popular messengers are implemented as centralized services with closed ecosystems that are currently unable to exchange messages and some even have potential privacy limitations, there are several new solutions, particularly in the web3 environment, that promote decentralized solutions based on web3 technology.
To achieve interoperability and thus come closer to the goal of a connected messaging ecosystem, a decentralized core protocol is needed that is scalable in addition to the properties of security, good encryption, and privacy.
The dm3 protocol is a lean messaging interoperability protocol that is structured as a message relay network. It is built as a decentralized and scalable architecture and can be used as a core messaging protocol for new solutions as well as efficiently integrating existing services and messaging networks without compromising security or privacy.
The dm3 protocol is a public good and can be freely used as a messaging core protocol or integrated into existing protocols, services, or applications.
The mission of dm3 is not to replace but to connect!
Learn more about the dm3 protocol and connect with us on Twitter, Farcaster, or LinkedIn, and join our community on Common Ground or Telegram to stay updated on the latest developments. If you’re interested in integrating dm3 into your messaging application, don’t hesitate to schedule a call with us!
