Paul HittandClaude Opus 5
98e2580d02
⚠️ NOT BUILT. The machine has been at load 550-640 for three hours with 180 iOS-27 simulator processes on it; xcodebuild was killed rather than failing on its merits. Committed so the work is not lost, and must be compiled before it is trusted. FLAG_SECURE on Android. Blocks screenshots and recording, but the half that matters is the recents thumbnail: without it Android captures the open conversation and WRITES IT TO DISK, so a thread existed as a plaintext bitmap outside the ratchet, the sealed history file and the device-only key. iOS has had the equivalent since app lock landed; Android had nothing. iOS notification previews now default to OFF, and the sender is hidden too. Correcting what I told the owner earlier: Android does NOT leak notification content - it shows "New message" and never the sender or body. I misread the count string for the message text. iOS was the leaky one, and worse than it looked: content.title was set to the sender unconditionally, so turning previews off hid what was said and still announced who said it. On a lock screen that is often the more sensitive half, and the setting was labelled "Show previews". No incognito-keyboard flag, deliberately: Compose has no stable API for it, and FLAG_SECURE already makes most keyboards including Gboard suppress personalised learning. A second mechanism that might be a no-op is worse than the note. docs/PADDING.md designs envelope padding rather than implementing it. It is a wire-format change on a live protocol; the group-decode mismatch in this repository's history is what that looks like when it goes wrong. Includes the three-stage rollout, why stripping cannot be inferred, and why the relay needs no change at all. 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.