[DRAFT] XMTP Litepaper

Author’s Note

This is an early draft of the XMTP Litepaper. A number of things are still in the works, some things missing outright, and some of what is in here is subject to change. We will keep this published here in Discourse for now, and at a later date will be moving it to a public Github repository.

Please highlight and quote areas where you’d like to see more clarity, or are curious about something. We’re encouraging replies to this thread for now so that we might improve the paper before its public release.

For now, thank you and enjoy!
@mg XMTP Labs Co-founder

XMTP Litepaper


The web3 communication network, enabling messaging between wallets.


Version: 0.2.1
Authors: Matt Galligan, Shane Mac
Last updated: 9 February 2022


Table of Contents


TODOs

  • Things to add
    • [ ] Supporting imagery
  • 1 Abstract
    • [ ] Improve first sentence
    • [ ] Adjust language of message history phrasing
  • 3 Motivation
    • [ ] Update language around DNS to being about blockchains being largely closed systems
    • [ ] [Something about universal inbox if needed]
  • 4 Concepts
    • 4.2 Message Extensibility
      • [ ] Add something about introducing some standards to start
        • [ ] Perhaps include some code examples
    • 4.3 Clients
      • [ ] Modular message design
      • [ ] Write up a paragraph on non-standard clients and use cases
      • [ ] Paragraph on the benefits of joining the network vs. creating a standalone app using a centralized database
    • 4.4 Unified Inbox
      • [ ] More about siloed & fragmented apps
    • 4.5 Economic Spam Control
      • [ ] Make sure to add citation
    • 4.6 Connections
      • [ ] Could include some specifics on how connections work (e.g. could they be used to DOS the network?)
  • 5 Architecture Overview
    • [ ] Add graphics
  • 6 Additional Remarks
    • [ ] Addressing cold-start problem and minting L1 NFTs as notifications to wallets not yet on XMTP
    • [ ] Describe plans for progressive node decentralization
  • 7 Future work
    • [ ] Long-term Message Storage
    • [ ] Progressive Security
  • 8 Conclusion
  • More
    • [ ] Include more specifics around some use cases?
      • [ ] Impersonation?

1 Abstract

Typical blockchains are purpose-built for the transfer of value in the form of crypto tokens and non-fungible tokens. In the course of one’s activities within these blockchains, participants may desire to communicate with each other. However, despite having clear identifiers in the form of addresses among those participants, current blockchain networks are not designed for nor optimized to handle typical communication. As blockchain activity grows, so too will the communications needs of its participants.

In this paper we propose a decentralized communication network that enables wallet-to-wallet messaging between users of blockchain networks (such as Ethereum, Bitcoin, Solana, and more). Blockchain users register with the XMTP network using their preferred wallet, and can use any XMTP client to view, send, and receive messages. Messages may also be sent to addresses that have not yet r
egistered with the network, which will be held for them until registration. All of a user’s message history can be available to them within any client connecting to the network, establishing a unified inbox that any website or application can present.

To control unsolicited messages and manage network bandwidth we’re introducing an economic control termed postage. Postage fees are required to send messages given certain conditions, including, but not limited to, the relationship between senders and recipients, sender reputation and history in the network, and the volume of messages sent or intending to be sent in a given period of time.

2 Introduction

2.1 Overview

XMTP is both a messaging protocol and a decentralized communication network that enables messaging between wallets, smart contracts, and other blockchain network participants. It establishes an inbox for existing blockchain network addresses. Users send and receive messages through clients, authenticating with the network by way of a wallet signature. Rather than each client maintaining its own inbox, messages are stored in a unified inbox, enabling portability for one’s communications. Spam within the network is mitigated through postage fees, which can also be bypassed through opt-in connections made between users.

2.2 Naming conventions

The name XMTP stands for Extensible Message Transport Protocol, and is inspired by its communication protocol forebears in the Simple Mail Transfer Protocol (SMTP) and the Extensible Message and Presence Protocol (XMPP). XMTP refers to the communication protocol itself, as well as the decentralized network on which the protocol operates. The latter may be more specifically referred to as the “XMTP Network.”

3 Motivation

For decades email has and continues to serve us well as a means of communication that’s permissionless and decentralized. While countless other forms of digital communication have emerged over time, email’s universality and open nature have likely aided in its survival and hardiness as a network. Adopting SMTP as a standard has meant we can run our own mail servers, build our own mail clients, and participate in its vast network without requiring anyone’s authorization to do so.

While email remains a tremendous example of a decentralized communication network, it is unfortunately cut off from the world of web3 and blockchains. Core to email’s function is its use of DNS, which does not play a role in blockchain networks, leaving it wholly incompatible.

This incompatibility was laid bare in a conversation with Robert Leshner, a co-founder of Compound, one of the first DeFi lending protocols. In it he shared his disdain that despite knowing every address that had interacted with the protocol, it was unable to communicate with any of its participants reliably—even in circumstances as dire as an impending liquidation. Email addresses provide both a means of identification and communication, but blockchain addresses unfortunately lack the latter.

Hearing such a clear and unfulfilled use case led to the discovery of many others: connecting NFT creators with their collectors^1, contacting individuals who might have unclaimed assets waiting for them^2, impersonation of individuals and projects leading to theft^3, and more.

For communication to be brought into this thriving new ecosystem we must carve out a new path—one that’s inspired by the past, but purpose-built for its novel and unique qualities. Like email before, its foundation must be built on universality—a network open to any participant using any client, sending any type of message to any form of recipient, regardless of where or how they might be reading it. It needs to be easy to understand and use. And with the future in mind, it must also be secure, and free from the control of any one party—whether benevolent, malicious, or apathetic.

As the web evolves, so too will the methods and means by which we communicate. Email has served us dutifully since the dawn of the internet, and as we embark on this new journey that blockchains have opened the door to, it’s time to bring its essence along. It’s time for us to build XMTP.

4 Concepts

XMTP is a collection of technologies and concepts that when put together enable a decentralized communication network. These concepts include:

4.1 Wallet-to-Wallet Messaging

Blockchains typically use a long hexadecimal string as an address that serves as a location where tokens can be sent, or to identify where a smart contract is deployed. Such an identifier may look like 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045, in the case of the Ethereum network. Additionally, there are name services that seek to simplify a blockchain address to a simple string. An example would be the Ethereum Name Service, or ENS, with an address like maaria.eth.

These identifiers are analogous to email addresses or phone numbers, but the networks they derive from are not optimized and sometimes are incapable of secure communication between them.

XMTP solves this by establishing a decentralized communication network where sending messages requires cryptographic proof that a user owns a given wallet. To send a message, a user must use a client connected to the XMTP network. The sender inputs the address of their intended recipient into the client, and once a message is sent, authentication by the bearer of that recipient address would enable the receipt of the message.

Blockchain network addresses supported by XMTP would be limited only by a client’s ability to authenticate and prove ownership of an address. Further, as the XMTP network and its stored messages exist outside of other blockchain networks, it would be possible to send messages between addresses on different networks.

When attempting to send a message, the sending client will first check with the network to see if its receiving address has been established on the XMTP network (i.e. the recipient has used XMTP before). In the event that the recipient has not used the XMTP network before, it would still be possible for the sender to send a message and have it retained by XMTP to be received later. In this way it is possible that new network participants may already have messages waiting for them as they join.

4.2 Message Extensibility

Over the last few decades many text-based methods of communication have emerged: email, SMS, instant messaging, app-based chat, push notifications, etc. Each method had its own rules, format, protocol, network, and more. As blockchain networks generally lack many of these features, it would be meaningful for XMTP to support the aforementioned use cases.

As a network, XMTP will not require a specific message format and will enable content encryption. Clients will ultimately be responsible for properly rendering message content once decrypted, so it will be in the interest of the community to adopt standards for message formatting. Given that XMTP is an open network that any compatible client could connect to, each of which makes their own rendering choices, it would be advisable for specialized message formats to gracefully degrade to minimally formatted text.

Developers will be free to explore specialized message formats that specific clients would be capable of rendering. For example, it would be possible to include JSON data within an encrypted message, enabling compatible clients to render a richer message experience. Some possibilities include referencing images and other rich media, buttons, and methods of executing actions such as smart contracts. Lastly, while this paper focuses above on examples of people messaging with each other, it’s reasonable to assume that software could send messages within this network, communicating with people or other software.

In the future we will explore additional parameters for messages that might affect receiving latency, message expiration, and other features that relate to deliverability vs. content and context.

4.3 Clients

Clients are software applications that interface with nodes participating in the XMTP network and provide key functionality to users. They authenticate with the network by way of signatures provided by wallets, and enable the sending and retrieving of messages intended for its corresponding address. Clients may be written to take on many different forms and should not be creatively limited by anything other than the need to provide valid commands to XMTP nodes.

Some examples of possible XMTP clients may be an email-like application (e.g. Gmail, Superhuman), an oracle that is connected to an on-chain smart contract, messaging app (e.g. Telegram, Signal), group chat app (e.g. Discord, Slack), support widget integrated into a website (e.g. Intercom, Zendesk), a Marketing Platform (e.g. Mailchimp, Campaign Monitor), etc. Factors such as network latency, message size, and metadata, may make some experiences more viable than others until those factors are accounted for, implemented, or improved.

4.4 Unified Inbox

Messaging is a common feature available in applications and websites today, but communication within those experiences is typically reserved only among other participants of those apps or websites. Adding a messaging experience to an application typically means that the user’s inbox is restricted to that application alone.

XMTP addresses this by allowing clients to present a user’s message history in its entirety, as retrieved from the network. This ensures that under typical circumstances when a user interacts with any given client application, their message history would be available to them, with some considerations given to message encryption and off-network storage.

Filtering may also be applied such that a client only displays a subset of messages to its users. However, messages sent within that filtered environment would still be available in other, less restrictive clients. For example, to keep its experience more streamlined, an NFT marketplace may choose to embed a client that enables messaging between its users, and filters messages sent from other clients.

4.5 Economic Spam Control & Postage

According to [INSERT REPORT HERE] approximately 85% of all email sent today is spam. Even Bitcoin’s proof-of-work consensus mechanism can be traced back to Hashcash^4, which was a PoW-based system aimed at reducing email spam. We see unwanted and unsolicited messages in our email, SMS, Discord servers, and countless other places.

Blockchain networks differ from mediums like email and SMS in that the addresses for participants are all publicly visible, making it trivial to identify potential spam targets. Given that public blockchains enable any party to view historical transactions of a given address, it’s reasonable to assume this information could be used to identify and message accounts of high value. Without a means to effectively throttle or otherwise deter unsolicited messages this could result in an unmanageable volume of spam for participants in the XMTP network. This is where the concept of postage comes in.

Postage is the fee paid by a sender to send a message within the XMTP network. Postage fees exist to create an economic disincentive to send unsolicited messages. Note: Not all messages sent with XMTP will require postage to be paid, which is covered in the next section Connections.

Variation in the postage rate, based on a number of potential factors, may enable the network to penalize accounts attempting to send mass quantities of unsolicited messages, while making it inexpensive for other senders that may fulfill a particular criteria. One example would be an NFT creator wanting to send messages to collectors, and requiring a lower fee because there is an established relationship between the parties, provable by previous blockchain transactions.

While the precise method for calculating postage fees is still being researched and under experimentation, we present a number of the potential factors that may go into it:

  • The relationship between senders and recipients
  • Sender reputation and history in the network
  • Volume of messages sent or intending to be sent in a given period of time
  • Custom postage fees set by the recipient that are different than the network-defined base fee

Though spam is a term used to describe unwanted solicitations, the concept of postage may also allow for unsolicited but otherwise desirable messages to be sent by benevolent parties. It introduces the opportunity for the inclusion of rewards given to message recipients in exchange for their reading.

As a network, XMTP’s primary purpose is in messaging, but the presence of postage fees has the potential of adding complexity to the core protocol. Rather than transactions for payment of these fees happening directly within the XMTP network, the collection of postage will occur on other L1 and L2 blockchains via smart contracts. Then, to send a message within XMTP a “Proof of Postage” will be associated with the message, permitting it to be submitted to the network.

Generating a Proof of Postage will happen at the client-level, with XMTP nodes verifying those proofs to allow messages to be sent.

Beyond direct payment, we are exploring alternate qualifications for generating a Proof of Postage. One such alternative would be to utilize token staking. This approach could result in a simpler user experience, economic benefits to stakers, and reduced volatility for XMTP’s native token. Additionally, it may aid in controlling spam as bad actors within the XMTP network may be subject to their stake being at least partially slashed as a direct consequence of their negative actions.

4.6 Connections

In many scenarios where parties want to communicate with each other, the participants already know each other or have some level of trust established, which may obviate the need for postage-based spam control. Furthermore, as most mediums enable parties to communicate with no cost to them, requiring fees for all messages would create a barrier to usage and adoption. It’s therefore desirable to provide an additional means to communicate within XMTP that wouldn’t be subject to the same requirements as unsolicited messages.

Establishing a connection within XMTP is an opt-in process for all parties involved. This is handled by a “Connection Request.” These requests would exist for multiple use cases including but not limited to one-to-one messaging, establishing a push notification subscription, establishing multi-party channels (in the future), and more. Requests may also set up a new encryption scheme for messages sent within the connection.

Connection Requests may take different forms, or be executed in a variety of ways. Here we’ll propose a few possibilities, but there may be other viable options:

  • A message sent from the requesting party to the receiving party with the request instructions “attached”
    • This type of message may be interpreted by a client and given an alternative UX, e.g. a notification feed or modal request
  • A receiving party sharing a pre-constructed code that would establish a connection

For the duration of a connection, messages sent would not incur the standard postage rate. Messages sent via connections may also have a privileged position within a client’s front-end.

Note: There is more research to be conducted around the method of payment to store such messages, but some possibilities include network activity subsidizing this type of communication, or enabling sponsorship of connections—for example by a DAO.

4.7 Progressive Security

[NEED TO ADD CLARITY ON THIS]

To add points on:

  • Standard encryption process for network participants
  • Encryption of connections
  • Encryption of messages to non-network participants
  • Not requiring encryption
  • Exploration of future encryption, such as double ratchet

5. Architecture Overview

[ADD DETAIL ON ARCHITECTURE]

  • Application Layer
    • Clients
    • Wallets
    • Message encryption
  • Routing/Network Layer
    • libp2p
    • Transient storage
  • Storage Layer
    • Local storage
    • Web-based storage providers
    • Decentralized storage
  • Postage Layer
    • Smart contracts
    • Proof postage
    • Node incentives

6. Additional Remarks

Need to add

7. Future Work

This paper seeks to establish a broad understanding of the motivations and goals in building XMTP, and while thorough, is not intended to be comprehensive. There are some subjects that will be addressed and written about at a later date that are worthwhile to notate. These subjects include:

  • $XMTP tokenomics
  • Node operation & incentivization
  • Long-term message storage
  • Message deletion
  • Process for supporting additional networks
  • Encryption improvements for messages intended for network non-participants

8. Conclusion

[TO COME]

Footnotes

8 Likes