Part 8: What we haven't solved
Part 8 of a series introducing Mesaĝkesto, a protocol for secure messaging between self-certifying identifiers.
A series that ends with a summary of its own achievements is marketing. This one ends with the ledger. Every post so far has carried a "what's hard about this" section, and this post collects the debts, adds the ones that didn't fit anywhere, and says how bad each actually is. If you're evaluating whether to build on any of this, these are the paragraphs that matter — the rest was the easy part.
1. Metadata survives all of it
This is the big one, and it's been deferred to this post seven times. Add up what we removed.
Contents: encrypted end to end, unreadable by any box.
Sender identity: sealed inside the ciphertext, so the box authorizes without attributing.
Contact lists: never uploaded, only one-way tokens.
Group membership: known to members, opaque to the relay.
Now what remains, for a box or anyone who compels it: that a message arrived for a given identifier, roughly how large it was, and exactly when. Repeat that over weeks and patterns appear. Two identifiers whose traffic correlates are probably talking. Volume shifts with events. Size distinguishes a text from a photo from a document. Timing exposes time zones, sleep, working hours, and the fact that something happened at 03:00 on a Tuesday.
Traffic analysis does not need names. It has never needed names. Anyone claiming a messaging system is fully private while running it over an ordinary store-and-forward network is either mistaken or selling something.
The known mitigations are real, and so are their costs:
Rotating delivery addresses. Instead of depositing to a stable identifier, senders use short-lived tokens the recipient rotates and distributes through the encrypted channel. Breaks long-term linkability at the box; costs coordination, and fails awkwardly when a sender's cached token has expired.
Padding to size buckets. Round every payload up to one of a few fixed sizes so length reveals a category rather than a fingerprint. Cheap, mostly effective against naive size analysis, and it wastes bandwidth in exactly the proportion it helps.
Cover traffic. Send when there's nothing to send, so silence and speech look alike. It is the only thing that genuinely defeats timing analysis, and it costs battery and data continuously, forever, on devices whose owners notice both.
Delay and batching. Hold messages and release them in batches to blur timing. Effective, and directly opposed to the thing users want most from a messenger.
None of these is on by default, and it would be dishonest to imply they're a configuration switch away. Each is a trade against latency, battery or bandwidth that most people won't accept for most conversations — which points at the actual design question: these protections should probably be per conversation, chosen when they're worth their cost, rather than a global mode that's either off or unusable. Nobody has made that pleasant yet.
Honest status: partially mitigated, structurally better than the alternatives, not solved.
2. Losing your keys is losing yourself
Part 2 explained how rotation makes theft survivable. It says nothing about loss. If you lose every device and every pre-committed key at once, there is no support line, no identity verification call, no "reset password" email — because the entire point was that no party exists with the power to do that for you. The property that protects you from seizure is exactly the property that offers nothing when you're the one who's lost the keys.
The mitigations exist and are partly built: delegation, so no single device holds everything and losing one is routine; multi-signature control, so an identity needs several keys and losing one is survivable; pre-committed keys in cold storage; social recovery, where people you trust jointly help you re-establish control.
Social recovery in particular is where the honesty is required. The cryptography is well understood. The human protocol around it — who you choose, how they verify it's really you and not someone doing a convincing impression in a crisis, what happens when they're unavailable, estranged, or themselves compromised, what happens when they're coerced — is not a solved design, and every system that has shipped something in this space has learned uncomfortable things about it.
Honest status: mitigable with effort by careful users, not yet safe for someone who just wants to message their family.
3. Names, and knowing who you're talking to
Identifiers are hashes. Nobody memorises them, nobody reads them aloud, and nobody should try. Human-meaningful names therefore live locally, in your own address book, under your own control — which is the right architecture (Part 2) and also a real burden. There is no global directory to look someone up in, deliberately: a global directory is a namespace, a namespace has an owner, and Part 1 was about what owners do. So first contact requires an out-of-band moment: a scanned code, a link, a fingerprint read over a call you're confident about.
The failure mode this creates is impersonation by display name. If a contact's label is whatever your client chose to show, someone can arrive calling themselves the same thing. The cryptography is unbroken and the human is fooled anyway — and this is the single most common way secure messaging fails in practice.
There are decent answers: showing that a name is one you assigned versus one that was claimed, surfacing how a contact was introduced and by whom, marking first-time correspondents distinctly. They're client design problems, they're unglamorous, and they matter more to real-world safety than most of the cryptography above them.
Honest status: architecturally right, ergonomically unfinished, and the main place users will actually get hurt.
4. The edge is now the target
Move trust out of the server and it doesn't evaporate — it relocates to the clients. That's the correct trade, and it's worth being clear about what you've bought. Your keys are on your devices. Your history is on your devices. A blind box protects you from your provider, from a breach at your provider, and from anyone who compels your provider. It does absolutely nothing about malware on your phone, a compromised backup, a coerced unlock at a border, or a client implementation that quietly does something dumb. And the last of those is worth dwelling on: in a protocol where clients do all the encryption, group key management and verification, client quality is the security of the system. A correct protocol with a sloppy implementation is a sloppy system. Two independent implementations agreeing on the same wire format is how that gets caught, which is an argument for the protocol being genuinely open rather than nominally so.
Honest status: an inherent consequence, not a defect — but a real redistribution of risk that anyone deploying this should understand.
5. The operational ones, briefly
Availability. Multi-box redundancy is possible and not yet convenient (post 7). Somebody has to run witnesses and discovery for identity to work smoothly (part 2). This is ordinary infrastructure work; it just has to actually be done.
Abuse and moderation. A capability-gated inbox handles spam well (part 4 and 6). It does not handle harassment inside a group you consented to join, or brigading of a public channel, or the fact that no operator can remove content they cannot read. Verifiable membership records are a better substrate than an opaque admin panel, and they are not a moderation system.
Group cryptography. Encrypting for a changing set of members, with forward secrecy and post-compromise recovery, is one of the harder applied problems in the field (part 5). Well-studied designs exist; using one correctly is still where most of the risk sits.
6. Adoption, which is harder than any of it
The most likely way all of this fails is not cryptographic. It's that everyone you want to talk to is somewhere else. Correct protocols do not win by being correct. Email won because it was early and ubiquitous; the messengers won because they were pleasant and everyone was already there. A better trust model is not a reason for a normal person to change how they talk to their friends, and pretending otherwise is how technically excellent projects end up with technically excellent user bases of four hundred people. Which is why bridging matters, and why it belongs at the edge rather than in the box: your client — or an agent acting for you — can carry a conversation out to email, or in from it, without the relay learning anything or growing a protocol adapter. It's not architecturally pure. It's how anything reaches the people who aren't here yet.
What we won't do to fix these
Worth stating, because every item above has a shortcut available that trades away the premise:
No global directory of identifiers, because a namespace has an owner.
No server-side key escrow to solve key loss, because that recreates the party who can become you.
No plaintext-visible-to-the-operator mode to make moderation tractable, because then the blindness was never real.
No privileged clients or official implementations that see more than others, because a protocol only one party can implement well is a platform wearing a protocol's clothes.
If a problem above can only be solved by crossing one of those lines, our answer is that it stays unsolved for now.
Where this leaves the series
Eight posts, and the shape is: names nobody issued and nobody can take (2), a box that holds and orders messages it can't read (3), permission without identification (4), every social form of conversation from the same signed events (5), routing derived from identity instead of from agreements between operators (6), and a provider you can leave in an afternoon (7).
None of that requires our code. It's a protocol: envelopes, signatures, an ordering rule, a capability check, and two signed statements for discovery. Implement it, argue with it, find the parts where this series was too confident. The measure of whether a protocol is real is whether someone else can build it from the description — and the measure of whether it was worth building is the question from part 7: if the operator vanished tomorrow, what would you lose?
This concludes the protocol series. The next one turns to implementation — what it takes to actually build a box, and what we got wrong the first time.
Bonus: Do I really need a box?
