---
# System prepended metadata

title: Untitled

---

## Acceptable solutions
- E2EE defined broadly as: only the sender and recipient can read the contents of the message. 
- Totally public: Everyone can read the contents of the message, and we build a UI that makes this abundantly clear to users.
	- [Nick’s take]: Anything in cleartext should not be stored on XMTP’s servers. Opens us up to subpoena, and changes our answers to common security questions. I want to still be able to say that we can’t censor based on message contents. I also don’t want to have to worry about hosting unencrypted CSAM or other illegal materials.
	- [Saul's take]: We cannot rely on 3rd-party UIs to properly disclose the "totally public" nature of these messages. This puts our narrative around privacy at risk. For that reason, a "totally public" approach should be sufficiently distanced from the SDK and network to mitigate the risk of a careless implementation that implies privacy. (I'm more willing to accept the risk of developers doing this maliciously.)

## Unacceptable solutions
- Anything that privileges XMTP Labs over the rest of the network. If we can read messages that are otherwise private, it hurts the brand promise we make around E2EE. Not in line with XMTP’s mission.

## Maybe acceptable solutions
- Sender key escrow
	- [Nick’s take]: The semantics around when messages can be read are so janky that it is going to feel “broken” to end users. When Alice sends Bob a message and then Bob checks their inbox, anything other than the message being there and readable is going to look like a bug.     Especially when we offer no guarantee that the message will ever be readable.
	- [Saul's take]: I agree with Nick but consider this janky UX an acceptable starting point. Push notifications and other steps we can take (keyservers) can mitigate this down the line.