Encryption has a quiet failure mode that almost nobody talks about. The message that never arrives is easy to miss — because the person waiting for it usually has no idea it’s missing at all. Nothing tells them. No checkmark, no warning, no sound. Their next message went out, and somewhere between the two of you the thread silently snapped, and for days they keep typing into a conversation that will never reach you.
This is the difference between encryption as a badge and encryption you can actually live on: when it breaks on a rented messenger, it stays broken, quietly. When it breaks on a messenger you own, it knows how to fix itself — without ripping up the conversation that’s still alive in the middle.
The message that “sent” but never arrived
The scenario is dull and devastating at the same time. Two people are mid-conversation. One of them — let’s call them the sender — loses the encryption thread. The peer can’t decrypt what the sender sends, so it asks for a re-send. From here, the old behavior did something that seems reasonable on paper and is destructive in practice: before re-sending, it deleted the encryption session to that device, the theory being a fresh handshake would cure the wedged thread.
But here’s the catch. What if there was nothing to re-send? The peer asked, and the answer was “actually, there’s nothing — the messages you asked about aren’t ours, or were already given out.” The old code still deleted the session anyway — and sent nothing in return.
Now the peer tries to send the sender its very next message. There’s no session to receive it. It hangs forever on “Waiting for this message…” with no way back. And the worst part: the peer can’t even re-send it, because it never learned the message was lost. To them, it sent fine. Only one side knows something broke — and the side that owns the problem is the one that can’t see it.
That’s the failure reliability is really about: not the headline key exchange, but whether a broken Tuesday ever gets named out loud.
Two rules the fix is built on
The recent Infium fix (0f0d3ad0, 2026-11-09) reworks that recovery with a rule that’s almost embarrassingly simple to state and hard to get right in code:
- If there’s nothing to re-send, don’t touch the session. Your active session to that device keeps standing, so the peer’s very next message has somewhere to land. The fix that broke this was deleted mid-conversation; the fix that works leaves it alone.
- If there is something to re-send, open a fresh session to exactly the device that asked — the re-send goes out as a PreKey the peer can actually create from — but keep the old ones. The old sessions are still capable of receiving the peer’s messages. Deleting them was precisely what stranded that next message with no return path.
It’s the same honesty that runs through proving the sender of a message: the recovery doesn’t pretend everything is clean. It repairs the broken direction without amputating the direction that still works.
Why “keep what still works” is the sovereign instinct
A rented messenger’s recovery is aimed at one thing: moving on. It deletes rather than preserves, because the vendor would rather you not see the mess. Deleting a session is the easy ten lines; keeping the ones that still work is the careful branch.
Owning the messenger means the repair has to fit your actual life, not the vendor’s metrics. When you own both the client and the server, you can do the thing that’s impossible for a fix that ships to two hundred million phones on autopilot: look at this conversation, notice that one direction is whole and one is wedged, and fix only the wedged one.
It’s the same reasoning as keeping your history when you sign back in — nothing you said is allowed to quietly evaporate. A re-send that deletes a still-working session is exactly the kind of quiet loss sovereignty exists to refuse.
The conversation keeps its thread
The end state matters more than the mechanism. Before the fix, a broken encryption thread could take a message down with it and leave the other person talking into nothing — forever, and unaware. After it, a conversation survives a repair the way it survives a bad stretch of network: the messages in flight get re-sent on a fresh path, the sessions that can still receive are kept alive, and nobody is left typing into a void while the other side stares at “Waiting for this message…”.
Encryption that has to be flawless every single time is a liability. Encryption that can repair without sealing — or losing — your conversation is something you can build a life on. That’s the sign you own the messenger, not just rent its keys.
Infium is a live XMPP server with end-to-end encryption where a broken session repairs itself without breaking the conversation. Request an invite or try the live demo — no signup wall, it runs in your browser.