← All articles
Sovereign XMPP

Missing on one device, never lost: how your history stays complete on sovereign XMPP

7 November 2026 · 5 min · xmpp · mam · history · archive · reliability · sovereign · self-hosting

There’s a particular kind of loss that messaging apps make almost invisible. Not the message that never sends, and not the one that sits at one checkmark. It’s the message that arrives — you saw it on your phone, you replied, the conversation moved on — and then, when you open your laptop, it’s simply not there. No error, no “couldn’t load,” no apology. Just a topic that jumps from yesterday afternoon straight to this morning, with a silence where six messages should be.

On a messenger you rent, that silence is the end of the story. On a messenger you own, it’s the beginning.

The archive won’t let a gap hide

Here’s the difference underneath. On sovereign XMPP, every conversation lives in a message archive on your own server — MAM, the protocol’s built-in history mechanism. Your devices don’t each hold a private copy of the past; they read from the same archive, so your history is one record, not several versions that can quietly disagree. When you open your Mac after a day away, the client walks that archive and fills in everything that happened while it was off.

That sync is where the bug we fixed lived. History loading works in batches: the client asks the archive for the next page of older messages, and when a batch is in, it marks that stretch of the conversation as “loaded.” The flaw appeared at exactly that seam. When a batch failed — a dropped connection, a timeout, a laptop waking up mid-sync — the old build would still mark that stretch as loaded. The client believed the gap was full. It stopped asking.

Think about what that means. The messages were in the archive all along: your own server was holding them, and your phone could see them. But the laptop had stamped “complete” over a range it never actually fetched, and nobody ever asked again. The gap didn’t exist in the archive; it existed in a marker on one device. That’s the quiet cruelty of it — the loss wasn’t real anywhere except in the client’s belief that nothing was missing.

This is exactly the shape of the real bug behind the fix: the Mac had been off while the conversation continued on an iPhone. When the Mac came back, the newest messages arrived — and six older ones simply weren’t there. They were on the phone. They were in the archive. The Mac just didn’t know to look.

A sealed gap is a lie the client stopped telling

The recent Infium update — v0.9.105 (2026-11-05) — put it plainly: “Fixed a bug where some messages could be missing in a chat on one of your devices. The full conversation history now loads reliably.”

Under the hood, two things changed, and both are about not papering over holes. First, a failed batch no longer counts as “loaded”: the range stays open, so the sync keeps asking until the archive actually answers. Second, on connect the client re-reads the archive once and collapses every “this is loaded” marker down to what was really fetched. Seals made by the old bug are rolled back — so a device that already had a hidden gap gets it healed, not left with a false “all caught up.”

The phrase worth holding onto is the one that’s easy to miss in a release note: the full conversation history now loads reliably. Reliably, as in — when a load fails, the app knows it failed. The gap stays visible to the system that has to fill it, instead of being declared closed and forgotten.

Who decides whether a gap is visible?

Strip away the protocol, and this bug is a story about accountability. On a rented messenger, “missing on this device” and “gone forever” look identical — from your side, anyway. The vendor’s archive is their bookkeeping; you can’t ask it whether your messages are really there, and the app has no reason to treat a failed background sync as a broken promise worth fixing. The gap gets sealed by design, because nobody has to answer for it.

On sovereign XMPP, the archive is yours, which means the conversation has a ground truth you can check. Your devices are readers of that record, not owners of private copies — so a device that missed something is a device that’s behind: diagnosable, re-synced, healed. The same reliability instincts that make your messages arrive even when a contact’s phone doesn’t are what make your history complete when a device simply sleeps through the fun.

The bottom line

A messenger’s history either has a source of truth or it doesn’t. If it doesn’t — if “what you’ve seen” is each device’s private guess — then a failed sync is a silent, permanent loss, and you’ll never know which of your conversations carries one. If it does, and that record is yours, then a missing message is a temporary state, not a tragedy. The archive still holds it. The device catches up. The gap heals.

That’s the quiet difference between renting a chat and owning one: on the rented messenger, a message that vanishes on one device is just gone, and nobody can even tell you it happened. On yours, it’s waiting in an archive you control — and when the sync fails, the app treats that as a bug against your history, not a shrug.

Infium is a live XMPP server with end-to-end encryption where your conversations live in a MAM archive on your own server — the full record, complete on every device. Request an invite or try the live demo, no signup wall, right in the browser.

← back to infium.net