Part 6: Federation you don't have to configure
Part 6 of a series introducing Mesaĝkesto, a protocol for secure messaging between self-certifying identifiers.
The box or the boxes?
Every post so far has quietly assumed that the people talking to each other keep their boxes in the same place. Time to drop that assumption, because if it holds we haven't built anything — we've built one more silo, with better cryptography.
So: you're on one box, I'm on another. How does your message find me?
Two signed statements
The answer is already in Part 2, which is the nice part. Nothing new has to be invented. Your identity is a log you control, and that log can publish roles alongside your keys. One of them says: this box hosts my mailbox — signed by you. The box, in turn, has its own identity, and its own signed statement saying where on the internet it can be reached.
That's the whole routing table. Two hops, both signed, both verifiable:
From an identifier to the box that hosts it — asserted by the person.
From that box to a network address — asserted by the box.
A sending box takes a recipient's identifier, resolves the recipient's log, reads the current answer, and delivers. It doesn't need to have heard of the destination before, doesn't need an account there, and doesn't need anyone's permission to try.
Notice what's missing: there is no list of servers anywhere. No registry of participating instances, no application to join the network, no bilateral agreement between operators, no configuration file that someone has to keep up to date. Routing is derived — from identity, which is derived from keys, which are yours. If you can verify who someone is, you can compute where to reach them.
And moving is what Part 1 promised: a new signed line in your log. Your correspondents' boxes resolve it and deliver to the new place, without being told, without a forwarding service, and without your name ever having mentioned the old one.
Federation without diplomacy
Compare this to how federated systems normally work. In most of them, membership in the network is a relationship between operators. Servers keep peer lists. Admins allow, block and defederate each other. Joining means being accepted; being cut off means an admin somewhere made a decision about the server you happen to be on, and everyone on it is severed regardless of what they personally did. There's a reason federated networks develop politics: the topology is made of human agreements. Here the topology is made of signatures. A box that has never heard of yours can deliver to it, because the instruction to do so came from you — the recipient — and is verifiable on its face. Two operators who have never communicated, never negotiated, and never heard of each other participate correctly by default. Nobody is admitted, so nobody can be un-admitted.
Operators can of course still refuse specific peers — that's their right, and sometimes their legal obligation. The difference is that refusal is an exception they apply, not a gate everyone else has to pass first.
What actually crosses the wire
A box forwarding on your behalf sends a sealed envelope to the destination box. The receiving box needs a very small amount in the clear: who it's for, and what kind of thing it is, so it knows which local subsystem to hand it to. The rest — content, sender, everything — is opaque. Delivering box, receiving box, and anyone watching in between all learn the same nothing. The envelope is signed by the sending box with its own identity, which is what makes the receiving side able to rate-limit, deduplicate and reject misbehaving peers without any notion of accounts or shared secrets between operators. There are no server-to-server credentials to provision, because signatures do that job. Two details worth stating because they're the sort of thing that quietly matters:
Transport encryption is mandatory, not advisory. The routing header is cleartext by necessity — it has to be, something must read it to route. So peers that can't be reached over an encrypted transport are refused outright. A protocol that carefully seals its contents and then ships the metadata in the open would be doing theatre.
"No such recipient" and "not allowed" look identical. A sending box gets the same answer either way, deliberately, so that nobody can use delivery attempts to probe whether an identifier exists on a box or whether a particular person has blocked them.
Open federation without an open inbox
Here's the part I think is genuinely the point of this post. Email is the great federated success story and the great federated cautionary tale. Anyone could run a mail server and reach anyone — and then spam arrived, and the defence was reputation: blocklists, deliverability scoring, warm-up periods, authentication regimes. Running your own mail server today is possible in the way that hand-forging your own bolts is possible. In practice a handful of large providers decide whether your mail is seen. Openness didn't survive contact with abuse, and centralisation is what replaced it.
The root cause is worth stating precisely: in email, the right to deliver is the default. Any stranger may put something in your inbox, so the only place to intervene is afterwards, by guessing whether the sender is trustworthy — a judgement that requires history, scale and data, which is exactly why it ended up in the hands of a few enormous parties. Part 4 already removed that default. A stranger's box can reach your box — that's the openness — but depositing requires a capability you handed out. No token, no delivery, no matter which box the sender pays. So the network can stay genuinely open at the routing layer, because the write layer was never open to begin with. That's why this works: openness and abuse resistance aren't in tension when they're enforced at different layers. Anyone may reach you. Only people you gave permission may write to you. Spam becomes a problem you solve by rotating a token instead of a problem the ecosystem solves by consolidating.
Agreeing without a coordinator
The last piece is groups, which Part 5 left dangling. When a channel's members are spread across several boxes, and two admins act at the same moment while out of contact with each other, every box has to end up at the same membership. There's no central sequencer to consult. So the ordering is made deterministic instead. Every membership operation carries enough context — a logical counter, plus the identity of the box it originated from as a tiebreaker — that any two replicas sorting the same set of operations produce the same sequence and therefore the same answer. Genuine conflicts (two people editing the same thing) resolve by a fixed rule; the common cases (two admins inviting two different people) don't conflict at all and simply both apply.
It's worth being clear that this is intentionally weaker than the state-resolution machinery in something like Matrix, which handles adversarial scenarios and deep history forks with considerably more complexity. Chat membership doesn't need that. Picking the simpler mechanism that covers the real cases — and being explicit about which cases it doesn't — is the honest engineering trade, and complexity in a security-relevant path is a cost, not a feature.
What this doesn't solve
Boxes see the outside of the envelope. Recipient, size, timing, and kind of traffic are visible to both boxes and to whoever compels them. That's a smaller surface than any mainstream system exposes, and it is not nothing.
Your box can still be down. Federation means the network has no single point of failure. It doesn't mean you don't — while your box is unreachable, messages queue elsewhere and you're not reading them. That's Part 7's problem.
Abuse doesn't disappear, it relocates. A capability stops spam in your inbox; it doesn't stop somebody hammering a box with traffic it must authenticate before rejecting. Rate limits, replay windows and payload caps are ordinary infrastructure work, permanently.
Federation is not decentralisation. If everybody ends up on three large boxes, the topology is federated and the reality is not. Protocols can't prevent that — email couldn't. What they can do is make leaving cheap enough that concentration doesn't become capture, which is the entire subject of the next post.
Next: What happens when your box goes away — the failure that decides whether any of this was real.
