flamenet-messenger-android/PARITY.md

# Android ↔ iOS parity

What the iOS app does, what Android does, and what is left. Read from the
sources listed, not from memory — every row names the iOS file it came from so
it can be re-checked rather than trusted.

**Standing rule: this file is the definition of done for the Android app.** A
row moves to ✅ when the behaviour exists *and* something tests it, not when the
screen renders.

---

## Where things stand

| | iOS | Android |
|---|---|---|
| Protocol engine | `Sources/E2E`, 15 files | `engine`, 10 files |
| App layer | ~9,700 lines, 45 files | accounts, contacts, chat, photos |
| Tests | XCUITest + JS interop | 114 unit + 37 cross-engine + 15 on-device + live round trips |
| Ships to | TestFlight, once a distribution cert is minted (see below) | a debug APK that installs and runs; the release keystore is configured |

Android's engine is **verified against the web engine in both directions**
(`engine/test/interop-kotlin.mjs`), which is a stronger claim than the iOS app
could make for most of its history. What Android has no version of at all is
everything above the protocol.

---

## Protocol engine

| Feature | iOS | Android | Note |
|---|:--:|:--:|---|
| X25519, HKDF, AES-GCM | ✅ | ✅ | Android verified against RFC 5869 / NIST vectors |
| Ed25519 | ✅ | ✅ | RFC 8032 vectors, on the JVM **and on device**; see the provider note below |
| X3DH v1 | ✅ | ✅ | cross-engine verified |
| Double Ratchet | ✅ | ✅ | cross-engine verified, including reordering and loss |
| Safety numbers | ✅ | ✅ | cross-engine verified |
| Transparency log (`KeyLog`) | ✅ | ✅ | canonical leaf + inclusion proofs, cross-engine verified |
| Account KDF / fnid | ✅ | ✅ | both pinned to the published vector file |
| Sealed sender | ✅ | ✅ | cross-engine verified, and the relay records no sender |
| Content envelopes (§6.6–§6.9) | ✅ | ✅ | attachments, replies, reactions, groups, calls — one codec |
| Attachment encryption | ✅ | ✅ | verified end to end; relay holds only ciphertext |
| Envelope + wire codec | ✅ | ✅ | cross-engine verified at the envelope level |
| Session archive / restore | ✅ | ✅ | cross-engine verified, in-flight messages included |
| Device identity + prekey rotation | ✅ | ✅ | retired prekeys retained past the relay window |
| Vault (encryption at rest) | ✅ | ✅ | Android Keystore, AES-GCM, record name bound into the AAD |

| ML-KEM-768 (PQ agreement) | ⚠️ | ⚪ | see below |
| ML-DSA-65 (PQ identity) | ⚠️ | ⚪ | see below |

⚠️ **The post-quantum gap is not what it looks like.** iOS has `PQKEM.swift` and
`PQSign.swift`, and they are inert: CryptoKit exposes ML-KEM only on iOS 26 and
the app targets iOS 16, so no shipped iOS build does post-quantum anything.
Android has no platform ML-KEM at any API level. So the two clients are
*currently equal in effect* and the honest parity target is v1/v2 negotiation
that degrades cleanly — which the Android engine already does, and the interop
harness asserts. Closing this properly is a separate decision (implement, or
take a vetted library) and it should be made once, for both clients.

---

## Accounts and identity

From `Sources/Auth/*` and `Sources/Views/Sign*`.

| Feature | Android |
|---|:--:|
| Sign up — local self-hosted | ✅ verified against `relay1` through the UI |
| Sign up — managed / shared self-hosted | 🟡 `LiveSignUpFleetTest` written, compiles, **unrun** |
| Sign in, session restore | ✅ |
| Sign out (erases the vault key) | ✅ |
| Password reset request + confirm | ✅ on the sign-in screen |
| Change password | ✅ signs the device out, because that is what it does |
| Delete account | ✅ confirms in place, erases the phone too |
| Relay picker / `SiteConfig` equivalent | ✅ `SiteConfig.kt`, a `relay` field, and an `identity-mode` label |
| Deterministic local-relay KDF salt | ⚪ | 
| Multi-homing (publish + read home records) | ⚪ |

⚠️ Sign-up is where the three deployment modes become visible to a user, and
each derives its salt differently. Getting this wrong does not error — it
derives a *different account* from the same passphrase.

---

## Messaging

From `E2E/E2EInbox.swift`, which is the real feature list.

| Feature | Android |
|---|:--:|
| Send / receive text | ✅ **app ↔ the iOS app**, through a real relay — see below |
| Inbox polling | ✅ every 5 s while open; no push channel exists |
| Multi-device fan-out | ✅ one envelope per device, partial delivery reported |
| History at rest | ✅ encrypted, keyed by person not device |
| Session restore across restarts | ✅ credential and device both survive |
| Reactions | 🟡 codec done, no UI — blocked on the transcript carrying a `mid` |
| Edit a sent message (§6.15) | 🟡 codec done, in progress — an inbound edit is recognised and not drawn as a duplicate bubble; applying it needs the same `mid` |
| Drafts that survive a relaunch | ✅ sealed in the vault, not SharedPreferences |
| Forwarding (§6.16) | 🟡 codec done, in progress — an inbound forward is recognised and shown as one; originating needs #10 |
| Group message ids and quotes (§6.9) | ✅ transcript stores both; sent and queued copies share one id |
| Mentions (§6.18) | 🟡 codec done, in progress — an inbound mention parses and is bounded; composing and notifying need the UI |
| Per-message timers (§6.17) | ✅ combining rule and per-message pruning; composer control in progress |
||||||| parent of fa9fdf4 (Search inside messages, across every conversation)
| Reactions | 🟡 codec done, no UI |
| Search inside messages | ✅ scanned, never indexed — no plaintext index at rest |
||||||| parent of 9d33e60 (Recognise a pinned message (§6.19))
| Pinned message (§6.19) | 🟡 codec done, in progress — an inbound pin is recognised and not drawn as an empty bubble |
| Photos | ✅ send via the system picker, render inline |
| Voice notes (record + play) | ✅ AAC/MP4, tap to record, tap to send |
| Stories, and seen-state | ✅ 24h, sent per-contact, expired bytes deleted |
| Groups: create, list, members, leave | ✅ members editable after creation |
| Group text and images | ✅ one upload, one envelope per member |
| Delivery keys + rotation | ✅ published as a digest, rotatable from Account |
| Trust state, verification, identity-change acceptance | ✅ pinned in the vault, surfaced on the thread |
| Key-log enforcement and head gossip | ✅ opt-in enforcement, gossip detects a fork |
| Clear thread | ✅ keeps the session, so the chat still works |
| History at rest (encrypted, device-only key) | ⚪ |
| Presence (read and set) | ✅ shown from the relay, never inferred |
| Buddy list, add by username | ✅ |
| Remove, block, unblock | ✅ |
| Member lookup | ✅ look up before adding; adding is gated on it |
| Buddy commands | — retired; not a feature any more (owner, 2026-08-25) |
| Voice calls (WebRTC, DTLS-SRTP, TURN) | ✅ P2P-first; ⚠️ no TURN deployed |
| Notifications list, read state | ✅ |
| Services (AIM/ICQ via `flamenet-oscar`) | ⚪ |

✅ Calls are built, on `io.github.webrtc-sdk:android` — the one third-party
library in this app, and unavoidable: the alternative is hand-rolling ICE,
DTLS-SRTP and an audio pipeline.

🔴 **Peer to peer by default.** ICE tries a direct path first and only falls
back to TURN when both ends are behind NAT that refuses one. Signalling rides
the ratchet, so the SDP — codecs and every candidate address — is end-to-end
encrypted; a relay that could read it 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. The app says so before the FIRST call and waits for an answer —
once, not every time, because a prompt people see repeatedly is one they stop
reading.

⚠️ **No TURN server is deployed** (`FN_TURN_SECRET` / `FN_TURN_HOST` unset), so
`/e2e/turn` answers 503 and calls are P2P-or-fail. Handled rather than hidden:
STUN alone still connects through most NATs, and the call banner says plainly
that this server has no relay so a call only connects if a direct path exists.

⚠️ **WebRTC's native libraries dominate the APK** — ~41 MB across four ABIs, of
which x86/x86_64 (~24 MB) exist only for emulators. Release is restricted to
arm64-v8a and armeabi-v7a; debug keeps all four so it still runs on an
emulator.

---

## Settings

Every key in `Views/Settings/SettingsKeys.swift` has to exist, because each one
is a promise the UI already makes: push on/off, per-kind notification toggles,
in-app sounds, previews, read receipts, last-seen, online status, app lock and
its grace period, send-on-return, timestamps, larger type, appearance, recent
emoji, photo auto-download.

App lock also needs a lock screen that covers **everything including sheets**,
and obscures on backgrounding rather than only on return.

---

## Build order

Each step is useless without the one before it, which is why they are in this
order and not a nicer-looking one.

1. ~~**Session layer** — envelope codec, device identity, archive/restore.~~ ✅
   Cross-engine verified at the envelope level, restarts included.
2. ~~**`:client`** — REST, relay auth, device registration, prekey upload,
   inbox polling, attachments, groups, transparency log.~~ ✅ 13 tests against
   a real HTTP server, plus an opt-in check against the deployed relay.
3. ~~**Vault** — Android Keystore, encryption at rest.~~ ✅
4. ~~**`:app` scaffolding** — Compose, sign-in/up/out, on-device tests.~~ ✅
5. ~~**Buddy list and chat.**~~ ✅
6. **Voice notes, groups, stories, calls** — in that order.
7. **More instrumented tests** — the JVM tests prove nothing about Conscrypt. This
   engine has already been bitten once by exactly that.

---

## Two findings worth keeping

**Android has no ordinary Ed25519 provider.** Measured on API 35, not assumed:
`KeyPairGenerator.Ed25519` and `KeyFactory.Ed25519` are served by
`AndroidKeyStore` and by nothing else, and Keystore only ever makes keys it
keeps. Every Ed25519 key here is one we must hold — a device identity in our own
vault, an account key derived from a passphrase — so the JCA route cannot work
by construction. It compiled, passed 81 JVM tests, and threw
`IllegalStateException: Not initialized` on a phone. The engine now uses
BouncyCastle's `math.ec.rfc8032.Ed25519` directly: its one real dependency, and
it is there because the platform leaves a hole. `ProviderProbeTest` records the
measurement so nobody has to guess again.

**XDH is fine** — Conscrypt serves it from API 33, which is why `minSdk` is 33.

**The wire shapes were wrong three times, and each was silent.** `prekeys` not
`opks` (relay answered 200 and stored nothing); the send body names the
recipient once at the top, not per envelope (400, at least loud); the buddy
list uses `id`/`presence`/`screen_name`, not `user_id`/`status`. None of these
were findable without a real relay, which is why the live tests exist and why
they are opt-in rather than absent.

## The CRUD rule

**Every capability must be reachable from the UI, with its full create / read /
update / delete surface.** Owner standing instruction, and it exists because
features kept landing in `:client` with a live test proving them and no door for
a person to walk through — remove a contact, block someone, clear a thread,
change a password. `CrudSurfaceTest` walks the app and asserts the controls
exist; it checks reachability rather than behaviour, because behaviour is what
the live tests already cover and the door is what was missing.

It found two real gaps on its first run: sign-out was reachable only from the
contact list rather than from Account, and several controls sat below the fold.

## Cross-platform, 2026-08-25

**iOS → Android is proven, through both UIs.** The iOS app signed up on
`relay1`, added the Android account as a contact, and sent; the Android
instrumentation logged the exact text back:

    ANDROID_HANDLE=andcross073349
    ANDROID_RECEIVED=hello from iOS 073413

That is the direction the parity table's "separate program" row used to mean,
now done against the real client rather than a harness.

**Android → iOS is delivered but not yet *seen*.** The headless `:interop:peer`
decrypted a message from the iOS app and its reply came back from the relay as
`{"delivered":1,"failed":0,"to":239}` — so the envelope reached the iOS
device. What has not been watched is the iOS UI rendering it.

⚠️ The obstacle is the machine, not the protocol. XCUITest starts failing with
"Timed out while synthesizing event" and runs stretch from ~200s to over 1700s
when macOS background daemons are busy — `lsdiagnose`, `mds_stores` and
`wifianalyticsd` were between them taking several cores, with load averages
around 69. Nothing in a test log names that as the cause. Check `uptime` before
believing a slow or flaky XCUITest run.

⚠️ Point `-derivedDataPath` at a directory ending `.noindex`. Spotlight will
otherwise index every build product, which is a large share of the above.

## §19 on Android, 2026-08-25

Pinning, verification, identity-change acceptance, key-log enforcement and head
gossip now exist and are tested. What each one is worth:

**Pinning is always on.** Every identity key a peer offers is compared against
what was pinned the first time, and a send to a changed identity is refused
until a person accepts it. ⚠️ The comparison is `all offered keys are pinned`,
not `any` — a relay adding one key of its own alongside the real ones is the
attack, and every genuine device still working is what makes it invisible.

**Key-log enforcement is opt-in** (`require-key-log` on the Account screen),
for the same reason the web engine's is: a relay older than the log has none,
and refusing every peer there is a worse failure than the one being prevented.

**`verifyConsistency` did not exist in the Kotlin engine and now does.** The
engine had inclusion only, which on its own is worth very little: a relay that
rewrites history reissues perfectly valid inclusion proofs against its new
tree. Consistency against a pinned head is the check it cannot satisfy.

Tested: 100 engine / 52 client, none failing. The consistency tests run over
**every pair of prefix sizes** in the published vectors, because the traversal
has a special case when the old size is a power of two — an implementation that
gets it wrong still passes at 3→5 and fails at 2→5. The refusals are tested
explicitly: a shrinking head, two roots at one size, a tampered proof node, a
served key absent from the log, an inclusion proof for somebody else's leaf,
and a rewritten log that cannot be reconciled with a pinned root.

✅ **Exercised against `relay1`**, 2026-08-25 — `LiveKeyLogTest`, opt-in via
`FN_LIVE_FLEET`. Against the real 231-leaf log: a key the relay genuinely
published verifies; a substituted key is refused; a second check reconciles the
pinned head with a grown tree using proofs the relay generated; a root we never
saw at our pinned size is a fork; and the send path itself refuses on a bad pin
while NOT refusing an honestly published key with enforcement on.

✅ **Contacts carry the peer's global address, and enforcement uses it.**

The relay files a leaf under an account's **fnid** once it has one, and under
`local:<audience>/<user_id>` before that. The subject is inside the hashed
bytes, so a verifier that does not know the address cannot recompute the leaf —
which made an honest key from such an account unverifiable. That was a false
positive on a real conversation, which is how a security setting gets switched
off and left off.

The address is now resolved once from the contact's handle
(`GET /e2e/account/identity/{handle}`, unauthenticated) and **pinned** beside
their identity keys, exactly as the keys are. `enforceKeyLog` recomputes against
the pinned address by default.

⚠️ **Pinned, not looked up per check.** Re-reading it each time would let a
relay that wants to substitute a key simply also change the name it files it
under, and every verification would agree with the new one. First contact is
still trust-on-first-use — taking the relay's word once is not a check; what it
buys is that every later answer has to match. The safety number covers the
first sighting and nothing here replaces it.

🔴 **A changed address is an identity change**, and for a stronger reason than a
changed key: an fnid is derived from the account key, so a new address is not a
new device — it is a different account key, which is to say a different person.

Proven against `relay1` in three states, because only all three make it legible:
refused with nothing pinned, accepted once the contact carries the right
address, and refused again with a wrong one — so what makes it pass is the
address being right, not the check having been softened. A changed address is
asserted to come back CHANGED against the real relay too.

⚠️ A relay that is unreachable pins **nothing** rather than pinning "no
address". Baking that in would be permanent, and the next successful lookup
would then read as the address changing — the alarm, for a network blip.

## Sealed sender, 2026-08-25

✅ **The relay no longer learns who sent a message.** Verified against relay1:
a sealed submission is accepted unauthenticated, the stored row carries
`from_user = 0`, and the recipient still reads it with the sender recovered
from inside the seal.

Cross-engine verified in **both directions** against the normative web engine
(`engine/test/interop-kotlin.mjs`, 43 assertions) — a seal made by Kotlin opens
in JS and vice versa, the inner envelope survives, and a seal addressed to one
device does **not** open on another.

🔴 **The seal is confidentiality, never authentication.** The recipient's
`IK_dh` is published to the world, so anyone can produce a well-formed seal
claiming to be from anybody. The claimed sender selects a session and nothing
more; the ratchet opening it is what makes it a fact. There is a test that
forges a sender on purpose so that nobody later "tidies" the naming into
something that looks authoritative.

⚠️ **The first message to a new contact cannot be sealed**, and `Sent.sealed`
reports which it was rather than letting the UI imply otherwise. Sealing needs
the recipient's delivery key, and that key travels inside an E2E message — so
there has to be a prior exchange. Claiming anonymity for that first message
would be lying about the one thing the feature is for.

⚠️ **Rotation is the only lever against a sealed spammer, and it is blunt.**
There is no sender to block, so the recipient replaces the delivery key and
every contact loses sealed access until the next time they are written to.
Reachable from Account; the copy says so.

The relay stores only `SHA-256(key)` — the key itself reaches contacts inside
E2E messages and never passes through the relay from its owner, which is the
only reason an unauthenticated submission can be authorised at all.

## Known flakiness

⚠️ **The emulator's network drops occasionally** — seen twice as "Failed to
connect" and "Software caused connection abort" on sign-up, with the relay
reachable from the host at the same moment. A rerun succeeds. Worth knowing
before treating a red instrumented run as a regression.

⚠️ **Instrumented tests share a process and a vault.** The Compose rule gives
each test a fresh Activity, but the app spends its first moments reading the
vault behind a spinner. A reset that checks for a signed-in control immediately
finds nothing, concludes "already signed out", and then the session restores
underneath it — so the suite passes one test at a time and fails as a set. Wait
for the app to settle before deciding anything.

⚠️ **Two peer processes on one account race for the inbox.** The one that polls
first takes the message and the other reports zero, which reads as "nothing was
sent". Run a single `autoreply` at a time.

## Signing, on both sides (2026-08-25)

**iOS was pinned to the wrong Apple team, and that — not a missing membership —
is what made TestFlight unreachable.** `project.yml` carried
`DEVELOPMENT_TEAM: "2W7DA3A8W2"`, the free personal team attached to the iCloud
address on the build Mac. Meanwhile an **App Store provisioning profile for
`net.flamenet.messenger` already exists**, issued to team `M5923Y84P5` — the
team that ships hittfitness and shepherdgiving — and valid until 2027-06-04. A
personal team cannot produce a distribution build at all, so every archive would
have failed at signing while naming the certificate rather than the team ID that
put it out of reach. The team is now `M5923Y84P5`.

⚠️ **Still outstanding: no distribution certificate in the build Mac's
keychain.** `security find-identity -v -p codesigning` returns exactly one
identity, the personal-team *development* one. Signing in to Xcode with the App
Store Connect account mints the distribution certificate and the matching
profile; nothing in this repository can do it, and nothing here should try.

**Android needs none of that.** The release `signingConfig` reads
`~/.flamenet-android-signing.properties` — present on the build Mac since
2026-08-23 — so `:app:assembleRelease` produces a signed APK that can go
straight to a tester. That asymmetry is why Android reaches testers first, and
it has nothing to do with which app is more finished.

## Two reproducible symptoms in the iOS pair (2026-08-25)

Found running `TwoSimulatorUITests` against `relay1`. **Both reproduce with the
machine idle**, so neither is the load artifact they were first taken for.

**1. One-way delivery between two fresh accounts.** Alpha receives bravo's
message — test1 passes on alpha's side, 113s. Bravo never shows alpha's, across
a full three-minute wait, on two separate runs. The direction is stable.

Already ruled out: `E2EInbox.transmit` throws before recording anything when the
recipient has no device, and `send` appends to the thread only *after*
`transmit` returns. So alpha's line existing in alpha's thread is positive
evidence the relay accepted envelopes addressed to bravo's device. Bravo
therefore either never fetched them or could not open them. ⚠️ The first reading
of this — "the app records messages it could not deliver" — was **wrong**, and
reading `E2EInbox` is what disproved it. Do not act on that theory.

**2. Creating a group does not produce a group.** The sheet stayed open past two
minutes; the tree captured at failure shows Home, the buddy row present, and the
Groups section reading "No groups yet. Start one with your buddies."
`createGroup` appends to `groups` on success and `groups` is `@Published`, so a
successful create would have rendered a row. It did not — the create threw.

⚠️ Both concern sending **to** the second account. Suggestive, not a diagnosis.
The next run needs the thread dump (added) plus the relay's own view of what is
queued for that device.

### Narrowed 2026-08-25: it is the RECEIVE side, and only when both sides opened first

The headless peer tool settles the direction. `qz89925` (user 402), a real
account driven from a shell, was sent to by the iOS app:

```
CrossPlatformUITests/testAMessageReachesANonIOSClient   passed (39.2s)
peer poll → {"messages":[{"text":"","from_user":403},
                         {"text":"hello from iOS to the peer tool","from_user":403}]}
```

✅ **iOS → non-iOS delivery works.** The sender encrypts correctly and the relay
delivers. (The empty first message is the §14.4 delivery-key prelude, as
designed.) So neither the send path nor the relay explains the two-simulator
failure.

**What differs in the two-simulator case is that both sides initiate a session
with each other at the same time** — each signs up, opens the chat, and sends
before either has received anything. The peer tool never initiates, which is
exactly why it works.

### Disproved, and narrowed further (same day)

🔴 **The `existing != nil` theory is WRONG.** The suspect was
`E2EInbox.swift:995`, where `ingest` returns `true` — consume the envelope —
rather than holding the cursor, whenever the recipient already has its own
session. Two things kill it:

1. `ratchet` is nil there **only when the envelope is not type `prekey`**. An
   inbound prekey envelope always builds a session and never reaches that guard,
   so it cannot drop a first message.
2. Measured. `testARoundTripWithANonIOSClient` **passed in 54.2s**: iOS signed
   up, sent first — creating its own outgoing session — and then received and
   rendered the peer's reply.

```
peer add qrt90210    → {"added":"qrt90210"}
peer send            → {"delivered":1,"failed":0,"to":404}
iOS round trip       → passed (54.234s)
```

✅ So **non-iOS → iOS works even when the iOS client already holds an outgoing
session to that device.** Both directions are proven in isolation.

**What is left is genuine simultaneous initiation.** In the round trip the peer
received iOS's prekey and established its session *before* replying, so both
sides ended up on one chain. In the two-simulator case both sign up, both open
the chat, and both send **before either has processed the other's prekey** — so
each creates its own session and then meets a message on a different chain.

⚠️ **Leading hypothesis, not confirmed:** `E2EInbox.swift:1006` calls
`saveRatchet` on the session built from an inbound prekey **without archiving
the session it replaces**. `saveArchivedRatchet` appears exactly once in the
file, at line 914, and that call only re-saves an already-archived ratchet —
nothing ever archives a *live* session before overwriting it. The
archived-ratchet fallback at line 911 exists precisely for "messages sent on the
old chain before the peer reset", which is this situation, but it can only help
if something was archived.

To confirm, instrument both clients' ratchet ids across a concurrent send. Do
not patch on this reasoning alone: the file's history includes an
advance-unconditionally bug that lost messages silently, and a careless fix here
trades one silent loss for another.

### Why confirming it is expensive

⚠️ **A two-simulator run advances roughly one second of test time per minute of
wall clock**, and this is not machine load — measured with the host healthy
(38 runnable processes, load 27). The cost is `Capturing element debug
description`: XCUITest snapshots the entire accessibility tree on every query,
and this app's home screen carries a stories strip, a buddy list, a groups
section and a tab bar.

A DM run takes 20-40 minutes per side. The group phase has never completed
inside a sitting. **Budget hours, not minutes** — or give the pair a trimmed
screen to work against before running it.

### Reproduced cheaply, and now fixed — verified against relay1

2026-08-25, two `:interop:peer` accounts, no simulators, no UI. Neither polls
before sending, which is the simultaneous-initiation case.

**Before** (retired-session retention alone):

```
p1/p2 send   delivered:1, failed:0    both first messages arrive   ✅
p1/p2 send   delivered:1, failed:0
p1/p2 poll   {"messages":[]}  {"messages":[]}                      ❌ both lost
```

**After**:

```
p1/p2 poll   second-from-Q2 / second-from-Q1                       ✅ both arrive
```

🔴 **What the first attempt got wrong, and it is worth remembering.** Retaining
the retired session was necessary; storing the WRONG OBJECT made it useless.
`DoubleRatchet` is a `final class` on iOS and `E2ESession` is a class on
Android, so the failed `decrypt` attempt that proves the peer is on another
chain **mutates the very instance it was handed** — skipped keys consumed, chain
stepped. Archiving that instance stores a chain that can no longer open
anything, which is indistinguishable from not archiving at all. The copy in the
vault was never handed to a decrypt, so it is the pristine one: **re-read it
before retiring it.**

⚠️ Second thing the first attempt got wrong: **which slot the winner belongs in
is not the same question as which chain opened it.** When the RETIRED chain is
the one that opens an envelope, it must be written back to the retired slot —
promoting it to current swaps the two and discards the chain we are sending on.
Each branch now writes back deliberately.

⚠️ Reproduce in ~2 minutes rather than the 20-40 a simulator pair costs:

```
peer q1.json create <relay> <h1>;  peer q2.json create <relay> <h2>
peer q1.json add <h2>;             peer q2.json add <h1>
peer q1.json send <h2> a;          peer q2.json send <h1> b     # neither polled
peer q1.json poll;                 peer q2.json poll
peer q1.json send <h2> c;          peer q2.json send <h1> d     # the exchange that used to die
peer q1.json poll;                 peer q2.json poll
```

## iOS TestFlight readiness, checked 2026-08-25

Verified against the BUILT PRODUCT, not the source tree — the difference matters,
and caught one thing that would have bounced the upload.

| | |
|---|---|
| `xcodebuild archive`, `generic/platform=iOS` | ✅ succeeded, arm64, WebRTC embedded |
| Unit tests | ✅ 38 passed, 0 failures |
| `PrivacyInfo.xcprivacy` | ✅ added, **confirmed present in the .app bundle** |
| `UILaunchScreen` | ✅ present (empty dict is the modern form) |
| Bundle / version / min OS | `net.flamenet.messenger`, 0.1.0 (1), iOS 16.0 |
| Usage strings | mic + Face ID; no camera use, so none required |
| App icon | 1024×1024 |
| ATS | fully on — no dev exception left behind |
| Third-party SDK manifest | WebRTC ships its own (no ITMS-91061) |
| Trackers | none — grepped for firebase/analytics/crashlytics/sentry/etc. |

🔴 **The privacy manifest was a hard blocker.** Apple requires one for any app
touching a "required reason" API, and this app uses `UserDefaults` in five files
— mute and pin flags, the push toggle, the chosen relay. Without it the upload is
rejected **ITMS-91053 before it ever reaches TestFlight**. ⚠️ The first archive
silently omitted it because the file was added after the project was generated:
**check the bundle, not the repo.**

⚠️ Two things a human must settle before submitting:
- `NSPrivacyCollectedDataTypes` is a legal declaration and must match the privacy
  label in App Store Connect. Written from what the code sends; confirm it.
- `CURRENT_PROJECT_VERSION` is `1`. Fine once; every later upload needs a bump.

⚠️ **`plutil -extract` WRITES BACK IN PLACE** unless given `-o -`. Using it to
"inspect" an archive destroyed that archive's `Info.plist` down to 3 bytes. Use
`plutil -p` to read.

Still unproven: the feature surface end-to-end on a device — voice notes, calls,
groups, stories. Unit tests and an archive do not cover those, and testers will
be the first to exercise them.

## Muted story authors (ios#33)

Both platforms hide one contact's stories without blocking them. Local on each
device: no envelope, no relay call, and the author is never told.

⚠️ **Stored in the vault, not shared preferences.** Who somebody has muted is a
statement about their social graph, and the point of the vault is that such a
statement is not readable by anything that reaches the file. iOS puts it in the
sealed history snapshot for the same reason.

⚠️ **A muted contact's stories are still received and still stored.** The filter
runs on the way out to the strip — `Vault.visibleStories` — and `saveStories`
runs before it. Dropping them on receipt would make unmuting show an empty strip
until their next post, so muting would quietly mean something other than it says.

⚠️ Your own stories are never hidden, even if your own id reaches the muted set
from a restored backup. Hiding somebody's own posts from them reads as the posts
having failed to send.
## Screenshot notices (§6.27, ios#36)
A disappearing-message timer promises the message goes away; a screenshot breaks
that silently. It cannot be prevented on either platform, so it is reported.
🔴 **Both platforms refuse to let the absence of a notice mean anything.** The
device that took the screenshot is the device that reports it, so a modified
build, a second phone photographing the screen, or the platform's own recorder
produce nothing at all. A notice means one was probably taken; **no notice means
nothing**. Neither platform counts notices — a running total would be read as a
measurement, and its zero as "nobody screenshotted", which is exactly the
inference §6.27 forbids.
⚠️ **The platforms genuinely differ, and the copy says so rather than hiding
it.** iOS reports a screenshot to the foreground app reliably. Android has no
callback at all before API 34, and the one added there does not cover screen
recording. So the disclaimer says "you are told when their app can tell", and
the Android text adds its own limitation explicitly. Claiming a symmetry that
does not exist would be worse than the gap, because somebody would rely on it.
⚠️ **Only where a timer is set**, on both. Everywhere else this would be a
general surveillance feature rather than the narrow one it is. The timer check
runs BEFORE the rate-limit check on both, so a suppression window cannot make an
untimed conversation start reporting.
⚠️ **Last-notice times are in memory on both.** Persisting them would store who
screenshotted whom, on disk, to enforce a five-second window.
||||||| parent of 487cead (Post a story that is only words, or a link)
## Text and link stories (§6.21, ios#32)
A story may carry no attachment; the caption is then the whole story. Both
platforms encode, decode, store, render and post one.
🔴 **The decode sits BEFORE the attachment branch on both.** That branch
requires `att` for `kind: "story"`; a text story failing it falls through to
the ordinary-message path and appears as a chat bubble in the conversation that
never expires — both of the things §6.6 says a story must not be. Each engine
has a test named for exactly that.
🔴 **`ref` is nullable/optional rather than a sentinel**, so nothing can read a
blob id off a story that has no blob. Both platforms therefore need a `key` for
seen-marks and de-duplication: with no blob id, a text story is named by what
cannot repeat for one author — when it was posted and what it said.
⚠️ **Android's stored record omits `ref` entirely** rather than writing an
empty object; a reload would otherwise resurrect a blob that fails to fetch.
`expiresAt` folds the two cases so no caller has to know which kind it holds.
⚠️ A text story has no blob, so nothing dies at the server's retention purge.
Client-enforced expiry is the whole mechanism rather than a backstop to one,
and both composers say so instead of implying more.
||||||| parent of 91c5181 (Save a story you posted yourself, before it expires)
## Saving your own story (ios#34)
Both platforms can write a story you posted yourself out to the device gallery
before it expires. Local only; no protocol change.
🔴 **Only ever your own, and the rule lives in the engine** — `Vault.isSaveable`
on Android, `E2EInbox.isSaveable` on iOS — rather than in the button. Saving
somebody else's story keeps a copy of something they were told would disappear,
and a guard living in a view is one refactor away from being lost. Both are
tested from both directions.
⚠️ **Neither asks for broad storage access.** Android writes through
`MediaStore`, which needs no runtime grant; iOS asks for `.addOnly`
authorisation. Requesting read access in order to perform a write would be a
much larger ask than the feature.
⚠️ **iOS needs `NSPhotoLibraryAddUsageDescription`** — without it the app is
terminated on first save rather than warned. Android has no equivalent trap.
⚠️ Both messages say the saved copy has left the disappearing model, and where
it went. "Saved" alone would let somebody assume the expiry still covered it.
||||||| parent of f3db054d (Reply to a story, as a sealed direct message)
## Story replies (§6.20, ios#30)
A reply to a story is an ordinary direct message to its author carrying
`sre.sid`. Stories gain no comment thread and no viewer list.
🔴 **`sre` carries the id and nothing else** — no caption, no thumbnail, no
blob. This diverges from §6.9's `re` on purpose: a quoted message may be one
the recipient never had, but a story's author had it by definition, so the only
way they no longer hold it is that their own timer removed it. Sending a copy
back would resurrect it at a moment they did not choose.
🔴 **`Content.text` returns raw bytes when it has nothing to carry**, so
`storyReplyId` had to join that condition. Left out, a reply with no message id
and no quote would go out as plain text and arrive with the reference silently
dropped — on exactly the path a story reply normally takes.
⚠️ **The disclosure comes before the first reply**, on both platforms.
Replying tells the author you watched, which stories otherwise never reveal.
Neither platform sends anything automatic when a story is merely opened.
||||||| parent of 4c004eb (Keep your own stories in a private archive)
## Private story archive (ios#54)
Your own stories, kept past their expiry. Local only; no protocol change.
🔴 **This keeps something the interface told everybody would disappear**, so
the shape is the argument for it being acceptable: off unless switched on,
labelled as what it is rather than as a feature, and **only ever your own**.
`Vault.archive` / `E2EInbox.archive` refuse anything not the author's own — the
callers filter too, but these are the guards that survive a caller being
rewritten. Both are tested from both directions.
⚠️ **Archiving happens at the moment expiry is applied**, which is the only
moment it can. iOS catches it on restore (a story past its expiry is never
loaded into `stories`); Android catches it in `Session.stories()` before
`saveStories` drops it. Both run repeatedly, so the fold is idempotent —
otherwise one long-expired story would be appended on every pass.
🔴 **The archive is not swept by the expiry rule.** Everything in it is expired
by definition, so reusing `saveStories` would empty it on the next write.
Android has a separate record and a test named for exactly that.
⚠️ Android injects the setting into `Session` as a lambda rather than reading
preferences in the engine layer, which has no Android dependency. An absent
value reads as OFF on both platforms.
||||||| parent of f67edeb (Post several pictures as one story sequence)
## Multi-item stories (§6.23, ios#53)
Several pictures as one sequence. Each item is an ordinary story envelope
carrying a `set` that names the sequence, its position and its size.
🔴 **One envelope per item, not one carrying an array.** The array is the
obvious encoding and degrades badly: a client predating §6.23 requires a single
`att`, fails that guard, and renders the whole set as a message in the
conversation. Separate envelopes degrade to what they actually are — several
stories from one person, in order — which every existing build already draws.
🔴 **Expiry is per set, and the earliest stamp wins.** Items are required to
carry the same `exp`, but a sender can write different ones; if the latest won,
the difference would keep part of a sequence alive after the rest had gone. That
decay is confusing to look at *and* a disclosure — the gaps reveal the order the
author added things. Both engines have `setExpiry` and a test for it. A zero
means "never" and is skipped rather than read as "expires at the epoch", which
would kill the whole set.
⚠️ **Grouping renders what arrived.** `n` is the sender's claim and any item can
fail to arrive, so a set is never held back or shown as incomplete. Stories with
no set are keyed so two of them cannot collide into one group.