Paul HittandClaude Opus 5
b4aadda162
The one third-party library in this app, and unavoidable: the alternative to `io.github.webrtc-sdk:android` is hand-rolling ICE, DTLS-SRTP and an audio pipeline. Worth naming rather than absorbing quietly, because everything else here is deliberately auditable and this is a large native blob that is not. 🔴 **Peer to peer by default.** ICE tries a direct path first — same network, then each side's address as seen through NAT — and only falls back to relaying through TURN when both ends sit behind NAT that refuses one. `iceTransportsType` is ALL rather than RELAY: forcing every call through the server is the opposite of the default chosen here. **Signalling rides the ratchet, not the relay.** The offer and answer are ordinary content envelopes, so the SDP — codecs, and every candidate address — is end-to-end encrypted like any other message. A relay that could read signalling would learn both parties' addresses even on a call it never carries. ⚠️ **A direct call shows the other person your IP address.** That is what makes it direct, and it is not something to find out afterwards. Explained before the FIRST call, and it waits for an answer — once, not every time, because a prompt people see repeatedly is one they stop reading. The acknowledgement lives in ordinary preferences rather than the vault: it is not a secret, and storing it encrypted would re-show the warning on every sign-out, which is how a one-time prompt becomes one people click past. ⚠️ **No TURN server is deployed** — `FN_TURN_SECRET` and `FN_TURN_HOST` are unset, so `/e2e/turn` answers 503. Handled rather than hidden: STUN alone still connects through most NATs, and the banner says plainly that this server has no relay so the call connects only if a direct path exists. "Calling did not connect", with no reason, is the kind of failure people blame on the app for ever. Trickle ICE is off. Candidates are gathered before the offer is sent, so signalling is one encrypted envelope each way rather than a stream of them — a second or two slower to connect, and far simpler over a channel that is polled rather than pushed. ⚠️ The microphone is held by the audio source, not the peer connection. Closing one without disposing the other leaves the mic live with no call attached, which is the worst failure this particular feature has available. ⚠️ **WebRTC's native libraries dominate the APK**: ~41 MB across four ABIs, of which x86 and x86_64 (~24 MB) exist only for emulators. Release is restricted to arm64-v8a and armeabi-v7a — 102 MB debug becomes a 22 MB release — while debug keeps all four so it still runs on an emulator. Restricted rather than split per-ABI on purpose: this app is handed to testers as one file, and per-ABI outputs turn "send them the APK" into "send them the right APK". A second offer while busy is declined rather than dropped, so the caller hears something. Group calls are deliberately absent: different key handling, and an enabled-looking button that cannot work is worse than none. Tested: 108 engine, 67 client, none failing; debug and release APKs both build. 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.