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:
- 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
- Enable interoperability at the messaging provider-level
- Make a specific recommendation around message encryption standards
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:
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?
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.
With an ENS MP record we need to:
- Declare one or more messaging providers (key)
- Declare a destination that would be used for messaging (value)
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/22.214.171.124/- Server IP address
/udp/1234/- UDP port
/p2p/CGcwj4riJfhBpQxzs6qaEuRNidgwgyW8xXRrn/- a libp2p
/dm3/0x2b…45ef/- Address for a dm3 profile
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.
The flow would be like this:
amal.ethwants to message
bola.ethand 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
bola.eth's Ethereum address or XMTP public key would appear in the
mp.xmtpvalue, 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.
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 (
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:
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.
- 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?
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!