ENS Messaging Provider (MP) record for web3 messaging

🧑‍💻 ENS Development Standards
1

The topic of web3 messaging (wallet-to-wallet chat, notifications, etc.) seems to be heating up considerably in recent months, even here within the ENS forum. And for some background, as a co-founder of the team building a secure web3 messaging protocol called XMTP, I’m also highly interested (and have an obvious stake) in seeing web3 messaging succeed.

A few weeks back forum member @hai-ko.eth posted a topic, introducing his concept for how ENS could introduce web3 messaging by supporting their proposed standard, dubbed DM3. I highly recommend reading that post as context for this proposal.

The idea presented in the aforementioned post was certainly interesting, and it led me to wonder about how ENS could adopt a standard for a more neutral and service-agnostic approach for web3 messaging, as opposed to picking a specific implementation or protocol. In the 8/29 Weekly Ecosystem Meeting, it appears as though the community was leaning towards that preference as well.

So much of what ENS is in both stated goals and in practice closely resembles its predecessor in DNS—itself a decentralized, neutral naming system. That led me to research the prior art in DNS, and see if there’s an approach that both satisfies the very real user need of pointing towards a preferred web3 messaging provider, while not looking for ENS to consider any one protocol.

The DNS MX record seemed like a natural blueprint for this functionality, with some web3-specific updates of course.

What follows is an idea for a possible standard that the ENS community could adopt, to better support the burgeoning desire for web3 messaging:

Design requirements

Goals

  • Give ENS domain controllers the ability to set their preferred messaging providers
  • Note: I’m using “provider” in a generic sense, in that it could be inclusive of messaging protocols (e.g. XMTP, dm3, WalletConnect) and some centralized services (e.g. Blockscan Chat).
  • Allow for multiple messaging provider records to be set
  • Be implementable today using text records, with a path towards becoming a first-class record type via improvement proposal
  • Be flexible enough to account for the differences in how each messaging provider might function
  • e.g. dm3 uses public keys for PGP-like message encryption which can be updated via a transaction, and XMTP uses a Signal-like encryption algorithm where keys may change more frequently

Non-goals

  • Enable interoperability at the messaging provider-level
  • Make a specific recommendation around message encryption standards

DNS MX records as prior art

DNS has the MX record (mail exchange), which gives discretion to the domain controller around the mail server(s) responsible for handling messages on behalf of the domain name. For example:

Type Host Priority Host
MX @ 10 mail.protonmail.ch
MX @ 20 mailsec.protonmail.ch

In the above example, the domain controller is requesting mail to be sent to mail.protonmail.ch first, with mailsec.protonmail.ch as a backup.

With DNS MX as our inspiration, what would a web3 ENS-based equivalent look like?

Idea: ENS Messaging Provider record (MP)

DNS MX doesn’t exactly map 1:1 with how some of the early web3 messaging providers work. In consideration of that, we need to identify the parts that may be valuable to carry over and find a new format that adheres to how ENS already works.

For the purpose of this exercise, I’m dubbing this the ENS Messaging Provider record or MP record for short.

MP as a text record

With an ENS MP record we need to:

  1. Declare one or more messaging providers (key)
  2. Declare a destination that would be used for messaging (value)
key value
mp.xmtp /dns4/xmtp.network/xmtp/‌0x2b0d29ffa81fa6bf35d31db7c3bc11a5913b45ef/
mp.dm3 /ip4/76.76.21.21/udp/1234/p2p/CGcwj4riJfhBpQxzs6qaEuRNidgwgyW8xXRrn/dm3/0x2b0d29ffa81fa6bf35d31db7c3bc11a5913b45ef

In the first above example mp comes first to indicate the record type, followed by the messaging provider, which in this case is xmtp. Next is a libp2p-style multiaddress which allows for additional information and granularity in defining the destination.

A multiaddress is a composable string of addressing information, which allows the layering of protocols and destinations. So in the above example, it’s telling the reader that the protocol is xmtp and the destination is one of my wallets 0x2b…45ef. They can also be layered to add additional protocols, as in the second example.

In the case of the dm3 record it might read as:

  • /ip4/76.76.21.21/ - Server IP address
  • /udp/1234/ - UDP port
  • /p2p/CGcwj4riJfhBpQxzs6qaEuRNidgwgyW8xXRrn/ - a libp2p PeerId
  • /dm3/0x2b…45ef/ - Address for a dm3 profile

Using a multiaddr would provide a universal and human-readable method path to direct a sender’s messaging app to the correct destination—down to a specific server, PeerId, or another concept. It could also encode protocol-specific information, such as a different addressing scheme. An example might be a messaging provider that supports multiple public keys for a recipient, perhaps dedicated to specific message types or different device destinations.

MP record in use

The flow would be like this:

  • amal.eth wants to message bola.eth and enters their address in their preferred messaging app
  • Amal’s app looks up bola.eth's ENS record to look for their MP records
  • Amal’s app looks for a messaging provider that it supports, and finds mp.xmtp
  • bola.eth's Ethereum address or XMTP public key would appear in the mp.xmtp value, providing everything necessary for Amal’s app to message them

IMO that’s all it really needs to be! Just a way to register that the domain controller has one or multiple messaging providers, and how to reach them there.

Priority considerations

MX records have a priority value, which tells the sending mail server which receiving mail server to send to first, typically the priority 10 record. At higher values (20, 30, etc.) these servers are treated as fallbacks should the lower values not work.

These records are set by the domain controller directly within the website of their DNS provider.

Since ENS MP is permissionless and only requires a transaction to update a record, a change to the MP records can be initiated from anywhere. From there, the domain controller does need to accept the change, but it’s conceivable that the controller may not fully know about or understand the changes that are taking place.

For example, during the addition of an MP record to an ENS domain, the user may be presented with the proposed change, displayed within an application. But let’s say that the user already has 1-2 other MP records configured. If MP priority could be set by any record update transaction, then it’s possible that the app could intentionally (or perhaps unintentionally) manipulate the existing priority values to favor the application initiating the change—which isn’t ideal.

One possible solution, which still doesn’t totally solve the above case, would be to create a new mp text record, which would point to the preferred messaging provider. This mp record would only contain a top-level string. Its subsequent value could be set to the text record that contains the controller’s preferred provider. Such a set of records may look like this:

key value
mp mp.xmtp
mp.xmtp /dns4/xmtp.network/xmtp/‌0x2b0d29ffa81fa6bf35d31db7c3bc11a5913b45ef/
mp.dm3 /ip4/76.76.21.21/udp/1234/p2p/CGcwj4riJfhBpQxzs6qaEuRNidgwgyW8xXRrn/dm3/0x2b0d29ffa81fa6bf35d31db7c3bc11a5913b45ef

Intentionally flexible

The MP record, with its open-ended mp.provider key, and multiaddress value format, is very flexible in how it could be used by messaging providers and the applications that interface with them.

There may be some value in finding a way to extend MP to include such things as an encryption scheme, so that an application looking up a record has fewer hoops to jump through, and may rely solely on the text record to know what to do.

Some questions

  • What would the UX for a sending user be when the destination address has multiple MP records set?
  • Beyond using the MP record concept, would there be a common schema that messaging providers could adopt for some basic interoperability?
    • DM3 seems to pave the way for a PGP-style approach
    • What about content encoding and formatting?

Next steps

Honestly, just getting some feedback here would be awesome. The design spec as stated above requires nothing to change about ENS, but community adoption would be necessary to see the MP record becoming at all a useful standard.

If you’ve got any thoughts, ideas, concerns, or questions, please leave a response!

Thanks :slight_smile:

6 Likes
2

It would be neat for the sending user to be presented with a pop-up to choose which MP record to use for routing the message. The UI could be simplified so if a dm3 MP record is detected, maybe it just has a dm3 logo with a radio button choice kinda thing. Maybe an expansion div for the sending user to see the whole MP record they are choosing. Maybe also the opportunity to input a custom one? Not sure if there’d be a use case.

Very cool idea and project so far!

I don’t think you joined an Ecosystem call yet, but here is the public calendar with meeting link for that: ENS Calendar

Seems like an interesting concept. Maybe there is time for a presentation on this if that’s something you wanted to do.

2 Likes
3

The comparison to email is instructive; although people can use any email server they want, they all speak the same protocol. Can’t we focus on developing an interoperable protocol all clients can speak, rather than pre-conceding the point that there will be multiple incompatible protocols and clients will have to negotiate which ones they share?

4

Sorry that it took so long for my reply (I needed to get access to the forum first :slight_smile: ).

Let me answer from the dm3 perspective. First of all, it is a good step to publish the connection information in an ENS record. Here we are on the same page.

The MP record, as you described above, would only help to see, what is the preferred communication protocol of this user, but it would not help to NOT build silos as it is in messaging in web2 nowadays. This would mean: you can easily find what protocol the receiver prefers, but an app would not be able to send or receive a message less it supports this protocol, too.

We think we need to go one step further - which means, we should define a base standard that can connect different applications and even protocols.

Our proposal was/is to build such a connection between protocols and apps based on the dm3 Message Transfer Protocol (in short dm3 MTP). This makes it possible to communicate across apps and protocols, as long as each implements the 3 things:

  • adds information to the Registry (ENS record). Subdomains (like username.nameofservice.eth). To bundle the registry for ecosystems are possible, where data is hosted in Layer-1, or in Layer-2, or similar using CCIP.

  • implementing a Delivery Service to receive messages in “dm3 format”, where the receiver can pick the message or the message is distributed in another service/protocol, …

  • implement the ability to build a dm3 compatible message and send it to the delivery service of the receiver (listed in registry = ENS record)

Pros from the user perspective: The user can decide which app/messenger he/she wants to use, and they can send and receive messages from any sender, as long, as the users’ app supports the dm3 MTP. The user also can find contact information on how to connect to others in the general registry (ENS) and can send messages (to the receiver’s delivery service).

From the app/protocol perspective: To implement/support the dm3 MTP only the dm3 message format needs to be supported, the contact information can be read from the ENS record and one (or several) delivery service(s) need to be implemented and operated.

This week, we will release the first version of the specification for the dm3 MTP - which is meant as a base for further discussions. Nothing is in stone for now - we seek for feedback and open discussion to define together as a community a lean base standard to make messaging in web3 interoperable from the very beginning (that it needs to be encrypted and sufficient decentralized is self-evident and does not need to be emphasized.)

5

Yeah that’s a really great point. All mail servers speak some flavor of SMTP, so the comparison definitely ends there.

Currently, all of the web3 messaging providers have been implemented quite differently from each other—how messages are stored, encrypted, encoded, what payloads they allow, and a bunch more factors.

I would argue it’s good to have this kind of exploration in the early days, and perhaps there may be ways to maintain some of these unique properties while still accounting for some common denominator.

That’s ultimately where the MP idea came from—currently the lowest common denominator between each offering is that there’s some sort of account identifier, and a place where the messages are delivered. All of the rest of the details may be unique to the service, but it’s a starting point to evolve from. Perhaps it’s not enough, but such is the value of exploration and feedback!

Interoperability would be ideal for many reasons, and for all of the same reasons where email is still so dang dominant and valuable, and we are otherwise left to fumble through varying competing messaging apps like Telegram, Signal, iMessage, etc.

So my biggest question in this topic is how do we get this right from the onset, and not fall into a situation like we’re seeing play out in the EU with the Digital Markets Act. The core issue here is that each messaging service developed its own standards and unique features, and will now be compelled to be made compatible with all others. The crux of why this is tough is in encryption—and the varying solutions each service provider have for it.

My mind has been focused a lot on encryption, as I believe it’s root by which safe and secure communications can take place. Taking it a step further is in how the messages are transported as well—and how to protect from observers mapping senders and recipients and their communications easily.

In the EU, it’s not yet known how these services will work to be compatible with each other without somehow compromising to the lowest common denominator. In exploring this interoperability for secure web3 messaging, we would definitely want to set a high bar for security and privacy.

First, thanks for chiming in @stkux.eth! Welcome to the forum (I’m new here too).

And you’re right in the scope of the proposal. In this case that wasn’t necessarily the stated goal. It was just that we can take our time in getting an interoperable protocol working, while still being able to explore and implement some early support for the various messaging protocols (some of which have the express intent of being anti-silo and permissionless).

Factors for interoperable web3 messaging

To be clear: I’m enthusiastic and optimistic about the exploration of interop. I’m certainly of the belief that finding a way towards a base-level amount of interoperability between web3 messaging protocols would be valuable, and likely beneficial to users. Very happy to explore the topic and see what’s possible.

So what are the considerations for interoperability then? As I see them:

A common registry for identification

Thankfully we have ENS!

Adversarial risks

In opening up to cross-protocol messages, what approaches might we take against sybil-enabled DDoS attacks? If inbound messages are to be accepted and escrowed by a recipient’s designated delivery service, what kinds of methods can be taken to prevent mass spam attacks?

Message format, payload, and encoding

What constitutes a message? Plain text, and only text is one option, but then is it UTF-8 encoded? Base64? There is so much variability here that must be accounted for. And in messaging today we have so much expressiveness possible in our communications—with reactions, rich media, attachments, etc. How do we account for all of that?

In that case, this is an area we’ve explored with XMTP and developed an extensible content format that allows developers to create their own message formats and payloads, with a default fallback to help with downstream compatibility. We’d certainly be happy to contribute our learnings and experience around this.

Message encryption / key exchanges

Probably the area that needs the most attention when it comes to interop. How a user of one protocol can securely message the user of another protocol, and ensure its readability, will be dependent on specific key exchange and encryption implementations. Ethereum key-based encryption is not yet a standard, so how we handle key generation is also an important factor.

Further, some protocols may favor an approach that is more involved, so perhaps we might we find some base level of compatibility for “basic” messages to be sent.

Other subjects

In developing a standard do we care about participant privacy or observability? What about deniability? How about using the same keys for group messaging? In addition to features and discussion of standards, it’d also be great to work through and enumerate the trade-offs that might be present in an interoperability protocol.

How to proceed?

Well first, the proposals mentioned above (ENS MP, dm3) aren’t at odds with each other. We could move forward with simple, and early primitives such as MP, long before a more coordinated and complex interoperability between protocols is achieved. Beyond that, to take a step further maybe there is a forum by which some of these discussions could be opened and the various problems and paths explored.

I’m personally open to contribute and discuss either!

6

I think, precisely this is the topic. Storage might not be the issue as this depends on the application but not the communication protocol. Encryption indeed is an issue as different algorithms or different architectures/workflows might be implemented. Here it seems to be important to see if we can find a common ground.

From the user’s view, this is essential, and actually also if we want that web3-based communication gets relevance, it doesn’t make sense to have a lot of different (even if technically brilliant) solutions. We need to go to the next step.

Today we released version 0.1 of the specification of the dm3 message transfer protocol. As mentioned before, this should be a proposal for further discussion. We are keen to get feedback and to discuss ideas, on how this could be a base for interoperability between different solutions.

As I can’t add a pdf here in the forum, I will build a web-based version to share here.

I’m personally also open to contributing and discussing possible approaches.