Ephemerality in the Land of Federation

2023-09-09

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.

Mastodon

• you can send deletion requests
• unmodified servers that honor the deletion request will completely get rid of the data
  • however, the data may still live in backups
• modified servers may not honor the deletion request
• I think that servers that de-federated with your home server will not see the deletion request, but I also don’t know if they’re holding onto your data

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.

IRC

• Most IRC servers don’t want to maintain message history
• Most big channels have one or more participants logging the entire history
• Ephemerality exists only to the degree that all participants in a chat have turned off their chat program’s logging features
• No way to request a client redact history
• People using “bouncers” store messages for some period of time to be relayed to their clients, but they can also choose to log in without their bouncer. There’s no reliable way to know if they’re behind a bouncer or not.
• Basically, despite the lack of deletions, it can be ephemeral if all participants want it to be, because ephemerality is the default here and persistence is added on top.

XMPP

• I don’t know a whole lot about this, but
• most servers don’t want to store chat history for long periods
  • usually they store it like a week at most and it’s just for syncing up devices that don’t connect in very often
• clients store extended chat history instead of the server
• if you don’t want the server operator seeing your shit, you end to end encrypt it.
• how do message deletions work? Do they exist at all? I forget, it’s been so long since I’ve used it.

Matrix

• Message history is maintained indefinitely
• A deletion generally does not delete data, it just sends a “this message was deleted” event that hides the original message in the timeline
  • likewise, edits are additive in this way, stacking on top of the original message
• However, matrix supports end to end encryption
  • Encrypted data is only visible to anyone with the decryption keys
  • Some partial protection against the “hacked account” situation. Does not protect against the “hacker computer” situation.
• Matrix-the-protocol also supports the ability to negotiate a temporary peer-to-peer connection that is not tracked by the server. This is used for voice/video calls

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:

• ensuring no current users can access the data
• ensuring no future users can access the data
• avoiding sending data to the server in the first place

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

• I want to talk to you and have the conversation expire after like a few days. Our apps negotiate keys for this (probably: just make a channel under the hood)
• We talk
• After a few degrees, both of our apps delete all the encryption keys for the conversation, making it permanently inaccessible.

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.