Paul HittandClaude Opus 5
fdd1ab7ee7
Federation let somebody at another relay write to you. It did not stop your relay being the only place your mail lives — so relay1 going away took the undelivered messages with it, and relay1 refusing to serve you locked you out of your own inbox. That is the gap people actually mean by decentralised, and it is what this closes. An account registers the same devices, with the same identity keys, at several relays and publishes a signed record naming them. A sender fans out to every one. Any single relay can then be unreachable, hostile or gone and the message still arrives, because it was never only there. The record is signed by the ACCOUNT key, not asserted by a relay. A relay that could edit the list would drop the others from it and become the sole delivery target, which is precisely the position multi-homing exists to escape. A sending relay verifies against the key the recipient's address decodes to — the address IS the key — so it never has to trust what the relay it asked handed back. The serial closes the half a signature does not. An OLD list is genuinely signed: a relay could serve one from before a second home was added and it would verify perfectly. Records may only move forward, and the test proves the real attack rather than a forgery — publish serial 2, then replay the still validly signed serial 1, and get a 409. Envelopes carry a client-chosen id, identical in every copy, so a recipient polling two relays sees one message rather than two. Nullable and not unique: an envelope from an older client has none and must still be delivered, and two rows legitimately share an id when one message goes to two devices. `maxHomes` is 4 because a sender fans out to every entry, and a signed record naming a thousand hosts would turn any sender's relay into an amplifier aimed wherever the signer likes — with a signature making it look legitimate. Verified on relay1/2/3.flamenet.io: 12 checks. Alice names only relay2, her relay discovers relay3 from the signed record, and Bob reads the message from either. Local suite 255. ⚠️ Delivery to an unreachable home is reported and NOT retried. A home that is down when you send simply misses that message; closing that needs a queue and this does not have one. ⚠️ Neither app calls any of this yet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Flamenet Messenger — Android
Nothing here is an app yet. This is the engine, and it is deliberately first.
An Android client needs the protocol implemented a third time. That third
implementation is the one that finds the places where the specification says
less than the two existing engines quietly agreed on — but only if it is
written against the spec and the published vectors rather than against a
reading of our own Swift and JavaScript. So the engine comes first, it is a
plain Kotlin/JVM library with no Android in it at all, and it is held to
engine/test/vectors/protocol-v1.json — the same file the other two engines
are checked against, read from that one location rather than copied here.
./gradlew :engine:test
No Android SDK, no emulator, no device. It runs anywhere a JVM does, which is also what lets it run in CI on Linux.
What the engine covers today
| Area | Spec | State |
|---|---|---|
| Safety numbers | §7 | Done — fingerprints and conversation ordering match the published vectors |
| Key transparency verification | §19 | Done — RFC 6962 leaf/node hashing, unbalanced split, bottom-up audit paths |
| Byte helpers | — | Unsigned comparison, constant-time equality |
What it does not cover
Listed rather than left to be discovered, because a table of green ticks with the hard parts quietly missing is worse than no table:
| Area | Spec | State |
|---|---|---|
| X25519 / Ed25519 | §3 | Not started — needs a provider that works on both JVM and Android |
| X3DH key agreement | §4 | Not started |
| Double Ratchet | §6 | Not started |
| Sealed sender | §12 | Not started |
| ML-KEM-768 hybrid | §11 | Not started |
| ML-DSA-65 identities | §20 | Not started |
| Relay client | §8 | Not started |
| The app itself | — | Not started |
Until those exist, Android is honestly marked "not started" on the website, and a conversation gets the protocol's guarantees only when both ends are iOS.
Why the vectors matter more than the code
Two implementations that agree may both be wrong in the same way, especially when one was written while reading the other. The audit-path ordering in §19 is the worked example: a top-down reading of a bottom-up path produces the correct root for every left-spine index, so it passes any test that only checks index 0. The vector file pins a right-descending index for that reason, and the Kotlin tests assert both that the published path verifies and that the same path reversed does not.
If this engine ever disagrees with the file, the interesting question is which of the three is wrong — not this one by default.