Ephemerality in the Land of Federation

Sometimes when we’re talking, we want ephemerality. Messages that do not last. Messages that cannot be read after some period of time. There are many reasons for this, and I’m not going to explain them, because I’d rather spend energy on how it can or can’t be achieved.

TL;DR: you need a threat model

When we talk about this, we also need to ask “ephemeral to whom”? On a service like Discord, when I delete a chat message, that message is probably deleted from Discord’s servers. It might persist in backups somewhere, depending on how they run things. It’s almost certainly not deleted from any government agencies that Discord is sharing streams of messages with, if any (speculation on my part, but I tend to just assume a chat platform as large as discord has the NSA asking for that yumy chat data).

Now even if I’m right about that, the chat servers deleting the data, but governments keeping it, is fine for a lot of use cases. Most of the time when I want a message truly deleted, not just hidden, what I really care about is that if my account gets hacked or the recipients’ accounts are hacked, the hacker can’t go get at that message. Interpersonal feuds are higher on my list of concerns than nation-state actors. Deleting it from the server takes care of that.

I might care that the recipient does not receive the message, but no matter what that is a best effort race of whether I can get the deletion in before they see it.

I might care that the recipient does not share the message, but that is fully reliant on them being trustworthy and is completely unrelated to chat platform we’re using, so I need to determine what I think they’ll do before I even message them.

So then let’s move onto Federation. First I’ll talk about Mastodon, IRC, XMPP, Matrix, as they currently stand.


While a centralized service may honor deletions, the potential for random servers to refuse to handle deletion requests prevents you from achieving reliable ephemerality, particularly because those servers might ALSO continue to make your post publicly viewable. The barrier to viewing the post is just having a link to the copy held on their server- you don’t need to be a server admin and log into the database or something.




I want to highlight that when we talk about “true message deletion”, actually deleting the data from the server is largely irrelevant because a server admin usually has no way to ALSO delete that data from their backups (and they SHOULD have backups). What we can actually care about is one or more of the following:

Mastodon is sort of a lost cause here I think. It doesn’t fit in with what mastodon does, mastodon is all about making data public, in a way that makes redactions exceedingly difficult to guarantee in any way. But it might be worth pursuing for the purpose of mastodon DMs, websiteboy permitting.

IRC- again, if all participants configure their shit right, you can have a high degree of ephemerality today.

Matrix: room for improvement, but the tech is basically already there if clients were convinced to use it.

Making Matrix Better at This

So there’s three main things that can be done here.

Two of them are useful for the purpose of premeditated ephemerality. I know I want this data to be temporary. Let’s make sure of it.

Option 1: Expiring conversations

At a high level the way this works is

This relies on all apps actually dropping the keys (do you trust the person reading your messages? do you trust the app dev to have not messed it up?), and it relies on the encryption used not being cracked at some future date.

Option 2: Peer to peer conversations

Right now as I mentioned, matrix-the-protocol already has a way for apps to start a peer to peer direct connection with each other for video/audio. But like, why not just do that but send text over it? If we did this, the server NEVER sees the data at any point. And only clients actively participating in the conversation can see anything. The main downside is that it would SUCK to use over mobile because you’d need to keep your app open for the whole conversation, since phones are really aggressive at killing background connections. Also, moving between cell towers often breaks connections. But it’s probably the biggest guarantee of ephemerality you can make.

Option 3: The Nuclear Option

If you truly want to redact a message that was already sent…

I don’t know if you can drop the keys retroactively for just part of a conversation (if you can that would rule!). But you can certainly drop the keys for all of one. In theory, we could build a method for me sending you a request to drop all your encryption keys for our existing conversation, you could accept, and then we have essentially buried the entire chat up to that point, never to be read again. Gone. Nobody can decrypt it ever again. Matrix historically has had bugs that cause this scenario to happen anyway (though its been good about it lately for me…), just turn it into a feature.