← All articles
Sovereign XMPP

Do you know how much your messenger weighs?

30 October 2026 · 5 min · xmpp · archive · mam · storage · self-hosting · sovereign · transparency · admin

When did you last ask how much your chats weigh? Not how many messages — how many gigabytes of your life are parked somewhere, right now, growing by the day. For most people the honest answer is “never”. Not because they don’t care, but because there’s no way to find out. The number exists — it lives in the vendor’s cloud bill — but it was never meant for your eyes.

That opacity is the point of this post. Because in a sovereign messenger, the number stops being a corporate secret and becomes something you can simply open and read.

The number nobody shows you

Think about what “your archive” means in a rented messenger. Every message you’ve ever sent or received is stored somewhere — for sync, for search, for the company’s own purposes. The history is real, it’s yours in the only sense that matters to you, and it occupies a concrete amount of disk space. You’ll just never see that amount spelled out.

What you do see instead is the monetized shadow of it. A “storage almost full, upgrade to premium” wall. A per-megabyte pricing tier. A “we deleted accounts inactive for 90 days” notice. The volume of your conversations is a resource the company meters — and the meter face is on their side of the counter.

This has always been the quiet imbalance in owning your history: technically the records are yours, practically you couldn’t measure them if you tried. You own the conversation. The vendor owns the spreadsheet.

A number your own server hands you

This is where the latest Infium release gets concrete. v0.9.83 (released 29 October 2026) gives admins something mainstream messengers never would: the actual size of the message archive, readable at any moment in Settings → Administration → Host.

Open the page and it’s all there, in plain numbers:

  • Total archive size — how much the MAM archive takes across all accounts, in bytes spelled out as something human: “X across N accounts”. (MAM is the XMPP Message Archive Management standard — the extension your server uses to store history so your chats can follow you between devices.)
  • Per-account breakdown — a table with one row per account: size, message count, and the span from the oldest to the newest stored message. Wondering which account (or which group of memories) holds the most? It’s a glance away.
  • Disk usage — how full the drive under your server actually is, with the bar shifting colour as it fills.

And for those who like the details spelled out, the module behind it is an XMPP ad-hoc command (#archive-stats) — a public, protocol-level way to ask your own server what it holds.

The page is read-only, and the app says so with a frankness you won’t find on a vendor’s dashboard: “History is kept forever, so the archive grows without bound — watch this number.” Not a sales pitch. Not a footnote about storage tiers. Just the truth about how archives behave, printed where the admin can see it. A server is only yours if its honest state is visible to you.

A heads-up at 2 GB — and again at 5 GB

Knowing the size is half the story; being told when it matters is the other half. So the same release wires the archive to a quiet warning system.

When the archive crosses 2 GB, the admin gets a notification. It arrives as an XMPP message from the server’s own alert address to the admin’s account — the same app and notification channels as any other message, no separate email to set up, nothing extra to install. The notification is driven by the archive size alone, not by general disk usage: your history is measured by its own weight, against its own thresholds, with a second, critical level at 5 GB.

What’s notable is what the alert doesn’t do: it doesn’t nag. It fires when the severity level changes — once at the warning, once at the critical threshold — and then it goes back to watching. A silent guardian of your own server, not a subscription to daily anxiety. You get the signal exactly when action matters, and the rest of the time it stays out of your way.

What you can actually do with the number

A visible number isn’t just reassurance — it changes what you can do, as an admin:

  • Plan before it’s an emergency. Disk doesn’t fill overnight; archives grow predictably. With the real size on one page, “we should add a drive” becomes a decision you make calmly, not a 3 a.m. panic after the server stops writing.
  • See where the weight is. The per-account table turns “the archive is huge” into “this one account accounts for half of it” — the difference between a vague worry and a concrete conversation.
  • Own the backup question honestly. Sovereign reliability works because someone — usually you — answers “who keeps a copy of this server?” Knowing the archive’s size, you finally know what that answer costs.

None of this sounds glamorous. That’s exactly why it matters: the small fixes are where sovereignty is decided, and being able to measure your own data is one of the most fundamental small fixes there is.

Sovereignty is also a visible number

The usual story about self-hosting your messenger is about the big walls — your keys, your server, your metadata. True, and worth having. But there’s a quieter, more intimate privilege that comes with owning the infrastructure: the numbers stop being the vendor’s and start being yours.

Ask yourself again: how much does your current messenger weigh? If you can’t answer, that’s not your ignorance — that’s the product keeping its books closed. A messenger you actually own doesn’t need to hide the meter. Open Settings → Administration → Host, and your archive tells you exactly what it holds — total, per account, and how close the disk is to full — with a quiet warning at 2 GB and a shake at 5 GB, because the archive lives on your server, and a thing you truly own is a thing you can see in full.

Want to know what weight feels like when it’s yours to read? Request an invite or try the live demo — then imagine the page that counts every byte of it.

← back to infium.net