XMTP Litepaper

Repo for internal tracking of Litepaper before publishing to public.

The web3 communication network, enabling messaging between wallets.

Version: 0.2.2 Authors: Matt Galligan, Shane Mac
Last updated: 15 February 2022

TODOs​

• Things to add
  • Supporting imagery
• 4 Concepts
  • 4.2 Message Extensibility
    • Add 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 Decentralized 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​

Imagine a market where the total capitalization is in the trillions, daily volumes regularly cross $100B, where every transaction and every participant is clearly identifiable with a public address. Now imagine that despite having those identifiers and a wealth of more information, there is no universal way to communicate with and among participants in that market as identified by those addresses.

This is the current state of the blockchain and cryptocurrency ecosystem—where distributed ledger technologies enable the trustless transfer of value in the form of fungible and non-fungible tokens, but are not designed for nor optimized to handle the scale or volumes of typical communication.

There are countless examples where communication is desired and oftentimes necessary in this space. Whether it's market actors proposing a trade, NFT creators contacting their collectors, or notifying DeFi loan holders of impending liquidation, nearly every use case in this space is benefitted by having the ability to communicate directly between wallets. As adoption and utility of the blockchain ecosystem grows, usability will be a key factor, and direct communication a requirement.

In this paper we propose a decentralized communication network that enables generalized wallet-to-wallet messaging that will exist alongside and support existing blockchain networks (such as Ethereum, Bitcoin, Solana, and more) to enable greater adoption and usability of this technology.

Blockchain users register with the XMTP network using their preferred wallet, and can use any XMTP-compatible client to view, send, and receive messages. Messages may also be sent to addresses that have not yet registered with the network, which will be held for them until registration. All of a user’s communications can be available to them within any client connecting to the network, establishing a decentralized inbox that any website or application can present.

To control unsolicited messages and manage network bandwidth we’re introducing an economic control termed postage. If a sender wishes to message a wallet that has not opted into communicating with them, their interaction may be subject to postage fees, or staking tokens. Fee and staking amounts will vary dynamically depending on different factors that can be underwritten through public blockchain information, including, but not limited to, the relationship between senders and recipients, reputation and historical behavior, and messaging volumes.

2 Introduction​

2.1 Overview​

XMTP is a messaging protocol and decentralized communication network built for blockchain networks. Its extensible design enables a diverse set of use cases such as wallet-to-wallet messaging, push notifications, group chat, and even cross-chain communication between smart contracts.

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 represented by a decentralized 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.

Email remains a tremendous example of a decentralized communication network. However, email, along with secure messaging apps and platforms, push notifications, and other current forms of digital communication are wholly incompatible with web3. This is because blockchains are closed systems that can't natively execute network calls outside of their own ledger.

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 delivery mechanism, 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¹, contacting individuals who might have unclaimed assets waiting for them², impersonation of individuals and projects leading to theft³, 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:

• Wallet-to-Wallet Messaging
• Message Extensibility
• Clients
• Decentralized Inbox
• Economic Spam Control & Postage
• Connections
• Progressive Security

4.1 Wallet-to-Wallet Messaging​

Blockchains typically use a long hexadecimal string that serves as a public address 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 adds the address of their intended recipient to the message, and once sent, the recipient must produce a signature indicating their ownership over that address to receive and read 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 check with XMTP to retrieve the public key for their intended recipients, and establish a key exchange for secure messaging. In the event that the recipient has not used XMTP before, it would still be possible for the sender to submit a message where it will be secured and retained by the network to be retrieved later.

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 usability to support formatting standards. A basic message format will be available to establish broad compatibility among clients. Over time the community may propose and adopt standards for message formats, either informally or through a governance process. 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 Decentralized 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 external parties.

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⁴, 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.

Processing postage fees has the potential of adding complexity to the core protocol. Rather than processing directly within the XMTP network, postage will be paid for using the native XMTP token deployed on L1 and L2 blockchains via smart contracts. The XMTP protocol itself will be the oracle for determining the postage required, and other blockchains will be processing service providers. Then, to send a message within XMTP a “Proof of Postage” will be associated with the message, permitting it to be written 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 & Consensus 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​