With Heiko’s post dm3-decentralized-messaging-for-web3 from August 22, we started the discussion on web3 messaging and interoperability of web3 messaging protocols, services, and applications in the community.
- The first iteration of the dm3-specification draft was published and we received a lot of feedback.
- Discussions with a lot of different teams have been held to evaluate requirements and standardized approaches that will enable the web3 world to do much better than the web2 world - being interoperable and giving the decision which app to use and how to manage personal communication data to the user - without building new separated data silos.
- We incorporated the feedback.
Now the new version (0.3) of the dm3 message transport protocol is published. Thanks to all for contributing to it with their feedback.
The current specification draft can be found at https://dm3.readthedocs.io/en/doc-latest/specification/message-transport/mtp.html.
The following major changes have been included:
HASH: we replaced all Keccak hashes with SHA256 hashes
As SHA-256 is more common (Keccak is more Ethereum-focused), it might be easier for non-Ethereum-based applications to adopt it.
MESSAGE TYPES: There is a variety of types possible that might or might not be supported by a messenger. We set most of the types optional, which means dm3 compatible apps can decide whether to support it or not. The user’s settings (readable from mutableProfileExtensionUrl) can now return a list of not supported message types. A sending client needs to check the receiver’s settings and must not send a message type not supported by the receiver.
Another service message type needed to be added (RESEND_REQUEST). With this service message and a hash referencing the message, the sender can ask to resend a historical or lost message.
- MESSAGE ENCODING: The encoding of the message text must be plain text (UTF-8), optionally flavored with Markdown highlightings. If other application-specific encodings are to be used, they are provided as an attachment. The plain text representation must be available, too. A client able to interpret the encoded attachment may show this instead of the message text.
DELIVERY SERVICE PROPERTIES: The delivery service got an additional API function: dm3_getDeliveryServiceProperties. It returns a list of properties relevant to the delivery service.
messageTTL: This is an optional parameter. It defines the minimum time an undelivered message will be stored by the delivery service. This parameter might be important for a delivery service to manage resources (otherwise, a delivery service will store all messages until they are picked up.) With this property set, the delivery service can purge its storage, if necessary, in a coordinated way.
sizeLimit: The delivery service can define the maximum size of a received message to be accepted. As a delivery service can be a gateway to another protocol or app, it might be important to have a harder restriction
- DELIVERY SERVICE DESCRIPTION: added an appendix to explain delivery service models in detail. In particular, delivery services can act as a gateway to other services/protocols to receive a dm3 message and include it in the ecosystem.
We are again asking for feedback and trying to have in-detail discussions with you. We especially want to open a community discussion on possible integration scenarios of dm3 in applications, protocols, or services. The goal is to have a variety of messaging applications in the web3 space but those solutions are able to interop.
Also, in the next iteration, we want to discuss in more detail the general registry based on ENS, as this is one of the crucial parts of interoperability between different applications and protocols → a standardized way to get information from the receiver (like public keys and how to deliver messages). Using ENS for this registry is a no-brainer. By using CCIP (Cross Chain Interoperability Protocol, based on EIP3668) the integration of Layer-2 registries, registries on sidechains or other chains, and even centralized services is possible as well.
The result of the next iteration should be a proposal of a basic protocol that fits well for a big variety of protocols, services, and dApps as a way to accomplish interoperability without giving up on security or features relevant to that ecosystem.