XMTP Overview

Umul's messaging is not homegrown; it sits on top of the XMTP protocol. This chapter explains what that protocol is and why it has the shape it does. For which parts Umul actually uses, see How Umul Uses XMTP.

In one line: XMTP (Extensible Message Transport Protocol) is a wallet-identity-based end-to-end encrypted messaging protocol, plus a shared node network that carries those messages.

The email analogy

A Gmail user can write to a Naver Mail user not because the two companies struck a deal, but because both follow the same protocol (SMTP). XMTP is aiming for that role in the messaging world.

Two things differ from email. Accounts start from a wallet rather than an email address, and end-to-end encryption is the default, so even the service operator cannot read the contents.

The terms, as a house

Protocol vocabulary doesn't stick at first. Read it as a house and the relationships become visible.

Analogy	Protocol term	Meaning
You, the person = the house	Inbox	Where messages arrive. One per person
Family members holding keys = devices	installation	Phone, laptop, each separately. The actual encrypt/decrypt agent
A conversation = a shared vault	MLS group	Members share a passphrase only they know
The post office = a node	xmtpd	Carries envelopes and keeps copies
The registry office = the blockchain	—	Officially records only "whose house" and "who is in the vault"

The part that matters is that several family members hold keys. There is one house (Inbox), but the phone and the laptop each hold a different key, and a new member who has never opened the vault cannot hear what was said before. That is what leads to the recovery limits in Message History.

Three layers

The protocol splits into three layers, and the rest of this chapter follows that split.

Layer	Question it answers	Document
Identity	Who is sending and who is receiving	Identity
Encryption	How the contents are hidden	Encryption and Delivery
Delivery	How a message arrives	Encryption and Delivery

flowchart LR
  subgraph apps["Apps (Umul, Base App, Convos, ...)"]
    a1["App A client"]
    a2["App B client"]
  end
  subgraph proto["XMTP protocol"]
    id["Identity<br/>who sends and receives"]
    enc["Encryption<br/>contents hidden by MLS"]
    del["Delivery<br/>arrival via topic subscription"]
  end
  subgraph net["Shared node network"]
    n1["Node 1"]
    n2["Node 2"]
    n3["Node 3 ..."]
    n1 <-->|"replicate copies"| n2
    n2 <-->|"replicate copies"| n3
  end
  a1 --> id
  a2 --> id
  id --> enc
  enc --> del
  del -->|"connect to any node"| n1

The key point is that the network is several nodes, not one box. Nodes run by different operators each replicate a full copy of the ciphertext, so a client can attach to any node and messages survive a node going down.

Messages cross app boundaries

They do — with the caveat "among apps that adopted XMTP."

The principle is where the data lives. In a conventional messenger the account and the conversations sit on one company's servers, which is why a KakaoTalk account cannot message a LINE friend. In XMTP the account (Inbox) and the encrypted messages live on the shared network rather than in a particular app, and the app is a window onto that inbox. With the same Inbox you can pick up in app B a conversation you started in app A.

Reading this as "any messaging service at all" is wrong, though. Five conditions have to hold.

Condition	Detail
XMTP adoption	No interop with WhatsApp, Telegram, or KakaoTalk. Same as email not reaching a fax machine, which doesn't speak SMTP
Same network environment	dev / production / local are entirely separate and incompatible. Across environments neither identity nor messages carry over
Same protocol generation	v2 conversations were not migrated to v3. Across generations the link breaks
Content type support	The message arrives, but if the receiving app doesn't know the type it shows only the fallback text
Consent state	Messages from unknown senders arrive but may be routed to a request inbox (consent)

Umul uses the dev environment. So it does not currently interoperate with XMTP apps on production. That is a choice rather than a constraint, and it is covered in How Umul Uses XMTP.

A short history

The early versions (v1/v2), started in 2021, used a homegrown encryption scheme. From June 2024 the project moved to v3, based on the IETF standard MLS, and v2 was retired to read-only on 2025-06-23 (XIP-53). Since December 2025 the company-operated central network has been migrating to a decentralized node network.

That is one generational change in four years, and building an app on XMTP means accepting the operational cost of following such changes. It is noted again under Limits.