ENS Messaging Provider (MP) record for web3 messaging

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:

3 Likes

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 DAO Calendar

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

1 Like

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?

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.)