Paul HittandClaude Opus 5 94337cbc07 Hold an undelivered message and send it when they come back
Asked: how does the sender know to try again when the other person has no
registered device - especially since they are friends. They should not have to.
Marking it undelivered and stopping there moves the problem onto the person who
did nothing wrong: they would have to remember, notice their friend was back,
and retype it.

So the message goes into an outbox and is retried on every poll tick. Nothing
expires and nothing is discarded - a contact who reinstalls in a month gets it
in a month. Timing out would mean deleting something somebody wrote in order to
tidy up a label.

The queue has to live on the sender's phone, and that is forced by the
encryption rather than chosen: every envelope is sealed to a particular
device's keys, so somebody with no device has no keys to seal to, and the relay
could only queue plaintext. The consequence is that it goes out the next time
THIS app runs and polls, not the instant the recipient signs in - so the label
says "Undelivered - will send" rather than implying it is in flight.

Delivery is now a tri-state. PENDING is quiet and grey because it is the normal
thing that happens when a friend is signed out and there is nothing to do about
it; only FAILED is a warning, and the outbox never produces one.

OutboxTest covers it end to end, including delivery against a real second
identity rather than a hand-written bundle: queued while away, sent when they
register, and the bubble restated - a version that delivered the message but
left it reading "undelivered" would pass a test that only checked the queue.

Engine, client and app suites green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-27 18:06:19 -04:00

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.

S
Description
Flamenet Messenger for Android — the Kotlin engine, held to the published protocol vectors. No app yet. MIT.
Readme MIT
22 MiB
Languages
Kotlin 99.3%
Shell 0.6%
Python 0.1%