Paul HittandClaude Opus 5
6a26668d72
The third of three: this README was rewritten upstream after the split was cut, so the standalone repository still opened with 'Nothing here is an app yet' above the finished app - the exact staleness the rewrite existed to fix. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
64 lines
2.7 KiB
Markdown
64 lines
2.7 KiB
Markdown
# 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](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
|
|
`engine/test/vectors/protocol-v1.json`, the same file the other two engines are
|
|
checked against.
|
|
|
|
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.
|