Paul HittandClaude Opus 5
cfeefa0616
The relay files a key-log leaf under an account's fnid once it has one, and
under `local:<audience>/<user_id>` before that. The subject is inside the
hashed bytes, so a verifier that does not know the address cannot recompute the
leaf — and enforcement refused honest keys from any account that had claimed an
identity. A false positive on a real conversation is how a security setting
gets switched off and left off, so this is the half that decides whether the
feature is usable at all.
No relay change was needed. `GET /e2e/account/identity/{handle}` already
resolves a handle to an address, unauthenticated, and the buddy list already
carries the handle. The contact record now learns the address once and pins it
beside the identity keys, and `enforceKeyLog` recomputes against the pinned one
by default.
⚠️ **Pinned, not looked up per check**, and that is the entire point. Reading it
fresh each time would let a relay that wants to substitute a key simply also
change the name it files that key under, and every verification would agree
with the new answer. Recomputing against the address this contact has always
had is what makes the check about a person rather than about whatever the relay
says today.
First contact is still trust-on-first-use. Taking the relay's word once is not
a check; what it buys is that every later answer has to match it, and the
safety number is what covers the first sighting.
🔴 A CHANGED address is an identity change, for a stronger reason than a
changed key: an fnid is derived from the account key, so a new address is not a
new device — it is a different account key, and therefore a different person.
Accepting a change re-resolves rather than keeping the old address, because if
the address is what changed, keeping it would leave every later check
recomputing against a name the account no longer publishes under, and honest
keys would stay refused for ever.
⚠️ An unreachable relay pins NOTHING rather than pinning "no address".
`rememberIdentity` does nothing once an address is pinned, so a wrong answer
would be permanent — and the next successful lookup would then read as the
address changing, which is the alarm, for a network blip.
Proven against relay1 in three states, because only all three make it legible:
refused with nothing pinned, accepted once the contact carries the right
address, and refused again with a wrong one — so what makes it pass is the
address being right, not the check having been loosened. A changed address is
asserted to come back CHANGED against the real relay too.
Tested: 100 engine, 65 client, none failing, live suites enabled.
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.