Paul HittandClaude Opus 4.8
91f58956cf
Two things this app could describe and not do. **Key transparency was a switch almost nobody found.** `requireKeyLog` was off by default, so the log was published, verified in tests, and checked for approximately no one. The reason it was opt-in — a relay predating §19 keeps no log, and refusing every peer there is worse than the attack — argues for skipping relays that CANNOT answer, never for skipping the ones that can. `enforceKeyLogIfServed` draws that line: ask the head route once, enforce fully if it answers, skip if it is absent. The switch survives as the stricter question underneath — refuse a relay that keeps no log at all — which is a real choice for somebody who knows their server publishes one. Two things make that safe rather than merely automatic. The head is asked for SEPARATELY, because `enforceKeyLog` reads three routes and a relay wanting to skip the check would otherwise only have to 404 the middle one. And a relay that has answered before is remembered, so it cannot publish a log until clients are talking and then stop — logs do not disappear, and that is a fork rather than an absence. The flag is its own vault entry rather than the pin, because the pin can arrive from gossip and would make a logless relay look dishonest. Both subject forms are now accepted for a leaf. A leaf names `fnid:` once an account has claimed an address and `local:` before, and the hash committed to whichever was true when it was written — so a contact who registered a device and then claimed an address has older leaves under one form and newer ones under the other. A verifier computing a single subject would refuse half the network on the day claiming turned on. Either candidate still requires the relay to have appended a leaf binding the exact key it served. **Federation was iOS-only.** The relay has spoken it for a while and so has iPhone; Android could neither send to an address nor read one that arrived. Now: the three remote routes, an always-sealed send that carries our address as the return path, and a receive side that files a federated message under that address rather than under `from_user`, which their relay never set. Filing by user id would drop every message from every other relay into thread 0 — or worse, into a local contact's, if their row numbers happened to collide. The address keyspace is kept apart from the local one throughout, and that is the load-bearing decision. A remote sender is pinned, bound and threaded by `fnid@relay`; they cannot write a local delivery key or avatar, cannot post into a group, and cannot ring a phone, because all four are addressed by a user id that means nothing across the boundary. Wired end to end rather than left as a capability: the add-contact field recognises an address and offers to message it — the QR scanner already prefilled that field and had its address looked up as a handle — and conversations on other relays get their own section, without which a reply is unreachable short of retyping 52 characters of base32. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Flamenet Messenger — Android
The Android app, and the two libraries under it.
engine/ the protocol: X3DH, Double Ratchet, sealed sender, safety numbers,
key transparency. Plain Kotlin/JVM — no Android in it at all.
client/ the relay transport: HTTP, auth, the §8 routes.
app/ the Compose app.
interop/ the cross-engine driver; not shipped.
engine and client are deliberately plain JVM libraries. The protocol has
nothing to do with Android, and keeping it off the platform means their tests
run anywhere a JVM does — no SDK, no emulator, no device, which is also what
lets them gate in CI on Linux:
./gradlew :engine:test :client:test
The app's own unit tests need the Android SDK but still no emulator (Robolectric):
./gradlew :app:testDebugUnitTest
Where it stands
PARITY.md is the definition of done for this app — read that, not this. Every row there names the iOS file it came from so it can be re-checked rather than trusted. Headlines as of 2026-08-28: messaging, groups, attachments, voice notes, stories, calls, sealed sender, key transparency and the encrypted vault are built and tested; a cross-platform round trip against iOS was verified on 2026-08-26.
⚠️ This file said "Nothing here is an app yet" until 2026-08-28, above a tree containing the finished app — the README described the repository as it was when the engine landed and nothing updated it as the app grew around it. If a claim here ever disagrees with PARITY.md or with the tree, believe those, and fix this.
Why the engine came first, and is held to the vectors
An Android client needs the protocol implemented a third time, and the 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 is held to
test/vectors/protocol-v1.json in
flamenet-e2e — the same file the
other two engines are checked against, read from that repository rather than
copied here, because a copied vector file drifts and a drifting vector file
stops being a check. PublishedVectorsTest looks for it beside this checkout
and fails loudly if it cannot find it; FLAMENET_VECTORS overrides the search.
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.
Contributing and security
- CONTRIBUTING.md — building (JDK 21,
JAVA_HOMEis not optional on a Mac), the test gate, and the platform traps that cost an hour each. - PARITY.md — what iOS does, what this does, and what is left. It is the definition of done for this app.
- SECURITY.md — threat model and where to send a vulnerability report. Not an issue tracker matter: security@flamenetmessenger.com.