master..660cb44 · skrepka

git.iko.soy/skrepka

on 660cb44 help sign in

23 files changed+400−3240

since splitsnapshots

unifiedsplit

.github/workflows/build.yml+1−1

@@ -157,7 +157,7 @@ jobs:

157157

158158 PK=$(printf '0%.0s' $(seq 1 64)) # 64 hex chars: a well-formed pubkey

159159 SIG=$(printf '0%.0s' $(seq 1 128)) # 128 hex chars: a well-formed signature

160− BLOB=$(printf 'ab%.0s' $(seq 1 200)) # 400 hex chars: over the 346-char floor

160+ BLOB=$(printf 'ab%.0s' $(seq 1 200)) # 400 hex chars: over the 336-char floor

161161

162162 # $1 = expected status, $2 = label, rest = curl args

163163 expect() {

AGENTS.md+2−2

@@ -11,7 +11,7 @@ Decentralized, end-to-end encrypted messenger. No accounts, no home servers —

1111- **Apple shell:** Swift + SwiftUI, **iOS 17+ only** (`include_macos = false` in `core/boltffi.toml`). The shell is a thin effect executor — it performs HTTP, key-value, and timer effects and renders the `ViewModel`. It contains no business logic.

1212- **Crypto:** `ed25519-dalek` + `x25519-dalek` + `curve25519-dalek`, `chacha20poly1305` (XChaCha20-Poly1305), `hkdf` + `sha2` (HKDF-SHA256), `zstd` (plaintext compression). **No libsodium** — `core/src/crypto.rs` hand-reimplements libsodium's `crypto_sign_ed25519_{pk,sk}_to_curve25519` so blobs stay wire-compatible with any spec-following client.

1313- **Server:** `server.knot`, written in [Knot](https://github.com/ilyakooo0/knot) — a custom functional language compiled to a native binary. Its runtime transparently persists every `*ref` to SQLite, so all server state (`*sessions`, `*messages`, `*presence`, …) survives restarts despite reading like in-memory lists.

14−- **Persistence (client):** `crux_kv` — JSON blobs under the keys `settings`, `profile`, `contacts`, `cursor`, `outbox`, `seen_ids`, and `messages:<peer_hex>`. The Swift shell backs this with one file per key under Application Support. The 64-byte Ed25519 secret key lives in the iOS Keychain, never in kv.

14+- **Persistence (client):** `crux_kv` — JSON blobs under the keys `settings`, `profile`, `contacts`, `cursor`, `outbox`, and `messages:<peer_hex>`. The Swift shell backs this with one file per key under Application Support. The 64-byte Ed25519 secret key lives in the iOS Keychain, never in kv.

1515

1616## Project Layout

1717

@@ -95,7 +95,7 @@ Two kinds of `Event` variants, and the distinction matters:

9595

9696The `ViewModel` is deliberately flat and stringly-typed (`page: String`, `conn_status: String`) so the Swift side switches on plain strings rather than needing generated enums for UI state.

9797

98−Runtime flow: `IdentityLoaded` (from the Keychain, at boot) fans out six kv loads → `LoadedSettings` triggers `Connect` → `Authenticate` (challenge/verify, signature bound to the server's bare hostname under the `skrepka-auth-v1:` tag) → on a token, `Poll` (server long-polls ~25 s, client re-polls immediately) and `StartFlush` (drains the outbox one message at a time, encrypting at send time). Failures back off via `crux_time` — 3 s doubling to a 30 s cap.

98+Runtime flow: `IdentityLoaded` (from the Keychain, at boot) fans out five kv loads → `LoadedSettings` triggers `Connect` → `Authenticate` (challenge/verify, signature bound to the server's bare hostname under the `skrepka-auth-v1:` tag) → on a token, `Poll` (server long-polls ~25 s, client re-polls immediately) and `StartFlush` (drains the outbox one message at a time, encrypting at send time). Failures back off via `crux_time` — 3 s doubling to a 30 s cap.

9999

100100## Code Conventions

101101

AUDIT-DEEP.mddeleted−230

@@ -1,230 +0,0 @@

1−# Skrepka Deep Audit — app.rs & model.rs (2026-07-16)

2−

3−**Scope:** Deep audit of `core/src/app.rs` and `core/src/model.rs`, cross-referenced against PROTOCOL.md §4, §6, §9, §10 and existing audits (AUDIT-NEW.md, AUDIT-FRESH.md, PROTOCOL-REVIEW.md). Findings below are **not** documented in any prior audit.

4−

5−**Legend:** 🔴 critical · 🟠 high · 🟡 medium · 🔵 low · ⚪ info

6−

7−---

8−

9−## 1. State Machine — Poll Loop / Cursor / Budget

10−

11−### 🟡 D1. `events_stored` doesn't count successfully-decrypted-but-non-stored events — livelock on budget exhaustion

12−

13−**Type:** State machine bug (livelock)

14−**File:** `core/src/app.rs:2127, 2188-2200, 2248-2293, 2316, 2342-2349`

15−

16−The `events_stored` counter drives the cursor-restore decision on budget/count exhaustion (lines 2145-2147, 2163-2165): if `events_stored == 0`, the cursor is restored to `prev_cursor`, and the relay re-serves the same page on the next poll.

17−

18−`events_stored` is only incremented for:

19−- Text messages that **pass** dedup (line 2264 — inside `if !id_set.contains`)

20−- All `delivery.ack` payloads (line 2316)

21−- Profiles that **pass** staleness (line 2348 — inside `if ts >= c.last_profile_ts`)

22−

23−It is **NOT** incremented for:

24−- **Duplicate text messages** (line 2248: the `if !id_set.contains` block is not entered)

25−- **Stale profiles** (line 2342: the `if ts >=` block is not entered)

26−- **Profiles from strangers** (line 2327: `continue` before any increment)

27−- **Self-messages** (line 2188: `continue` before any increment)

28−- **Blocked-sender messages** (line 2198: `continue` before any increment)

29−

30−All of these are **successfully decrypted** — they consume the full AEAD decrypt cost and the per-blob byte budget — but they don't increment `events_stored`. If a poll page consists entirely of such events and the byte budget is exhausted mid-page, `events_stored == 0`, the cursor is restored, and the client re-polls with the old cursor. The relay re-serves the same page. **Livelock.**

31−

32−**Attack scenario:**

33−1. Client receives 4 large blobs (each ~20 MiB decoded, total ~80 MiB > 64 MiB budget).

34−2. First encounter: all 4 are new text messages. `events_stored = 3` (budget exhausted on 4th). Cursor kept at `page.cursor`. Relay deletes events. No issue.

35−3. **Hostile relay re-serves the same 4 blobs** (it kept copies despite cursor advance). All 4 are now duplicates. Budget exhausted on 4th blob. `events_stored == 0`. Cursor restored to `prev_cursor`.

36−4. Client re-polls with `prev_cursor`. Relay re-serves same 4 blobs. Go to 3. **Permanent livelock** — the client can never advance past this page, wasting bandwidth and battery on every cycle.

37−

38−The same pattern applies to a page of large stale profile blobs, large profile-from-stranger blobs, or large self-message echoes — all decrypt successfully, all are dropped, none increment `events_stored`.

39−

40−**Note:** AUDIT-FRESH.md N9 identified the budget-exhaustion livelock for the case where blobs **fail decryption** (events_stored == 0, hostile junk). The fix applied (keep cursor if `events_stored > 0`) addresses that case. But the **duplicate/stale/stranger/self/blocked** cases are different: the blobs ARE decryptable, the client DID process them (and doesn't need them again), but `events_stored` doesn't reflect this. This is a new variant of the N9 livelock that the existing fix does not cover.

41−

42−**Suggested fix:** Increment `events_stored` after successful decryption and parse, regardless of whether the event is stored:

43−```rust

44−let Ok(dec) = crate::crypto::decrypt(&id, &blob) else { continue; };

45−let Some(parsed) = protocol::parse_payload(&dec.plaintext) else { continue; };

46−events_stored += 1; // successfully decrypted — cursor can advance past this

47−```

48−This ensures the cursor is kept whenever at least one event was successfully processed (even if it was a duplicate/stale/stranger), breaking the livelock. The unprocessed tail (budget exhaustion) is still lost, but that's the accepted N9 tradeoff.

49−

50−---

51−

52−### 🔵 D2. `SetServerUrl` resets `send_retries` but not `poll_retries` — new relay inherits stale poll backoff

53−

54−**Type:** State machine bug (stale state on relay switch)

55−**File:** `core/src/app.rs:960`

56−

57−When switching relays, `SetServerUrl` resets `send_retries = 0` (line 960) and `flush_paused_until = 0` (line 959), with the comment: "The old relay's rate limit was the old relay's opinion. A new one is entitled to take our sends immediately."

58−

59−The same logic applies to `poll_retries` — it's the old relay's poll failure count — but it is **not reset**. If the old relay was failing (e.g., 5xx storm), `poll_retries` could be at 4 (backoff = 30s). The first poll to the new relay fails (e.g., transient network issue), and `backoff_poll` uses `backoff_ms(5) = 30s` instead of starting at 3s. The new relay's poll loop is penalized for the old relay's failures.

60−

61−**Attack scenario:** No attack needed — this triggers on any relay switch after a period of poll failures. The user switches to a healthy relay but experiences unnecessarily long poll backoffs.

62−

63−**Suggested fix:** Add `model.poll_retries = 0;` alongside `model.send_retries = 0;` at line 960.

64−

65−---

66−

67−## 2. State Machine — Outbox / Flush

68−

69−### 🔵 D3. `SendResult` pops outbox items even when `kv_load_failed` is set — duplicate sends on relaunch

70−

71−**Type:** State machine bug (write guard gap)

72−**File:** `core/src/app.rs:1547-1560, 1728-1733`

73−

74−If `kv_load_failed` is set (by a `LoadedMessages` failure) while a send is in flight, `SendResult` still pops the batch from `model.outbox` (line 1557-1559) on a 200 or 400. The subsequent `persist_outbox` (line 1560) calls `refuse_write`, which checks `kv_load_failed` and refuses the write. The items are removed from the in-memory outbox but **not from the on-disk outbox**.

75−

76−On relaunch, the outbox is re-loaded from disk — the popped items are still there. They are re-sent:

77−- For a **200** (relay accepted): duplicate sends. The recipient's dedup handles it, but the sender wastes bandwidth and the recipient sees duplicate delivery attempts.

78−- For a **400** (relay rejected): the items are re-sent and re-rejected, burning retry budget.

79−

80−**Timeline:**

81−1. Startup loads complete. `Connect` → `Authenticate` → `VerifyResult` → `Poll` + `StartFlush`.

82−2. `StartFlush` sends a batch. `flushing = true`, `in_flight` is set.

83−3. `LoadedMessages` for some peer fails. `kv_load_failed = true`.

84−4. `SendResult` arrives (200). `flushing` cleared, batch popped (line 1557-1559). `persist_outbox` refused (line 1729-1730).

85−5. On relaunch: outbox loaded from disk. Items re-sent.

86−

87−**Note:** The window is narrow — `LoadedMessages` is a lazy load triggered by `LoadedContacts`, and `StartFlush` fires from `VerifyResult` which also fires after startup loads. But the ordering is: startup loads → `Connect` → `Authenticate` → `VerifyResult` → `StartFlush` + `Poll` → `LoadedMessages` (lazy). So the send can be in flight when `LoadedMessages` fails.

88−

89−**Suggested fix:** Check `kv_load_failed` before popping in `SendResult`. If set, don't pop — leave items in the outbox for relaunch to handle:

90−```rust

91−if ((200..300).contains(&status) || status == 400) && !model.kv_load_failed {

92− // pop and persist

93−}

94−```

95−Alternatively, don't pop if `persist_outbox` was refused (check the return of `refuse_write`).

96−

97−---

98−

99−## 3. Model / Persistence

100−

101−### 🔵 D4. `now_ms()` returns 0 on system clock failure — outbox TTL disabled

102−

103−**Type:** Robustness gap

104−**File:** `core/src/app.rs:580-585`

105−

106−```rust

107−fn now_ms() -> i64 {

108− SystemTime::now()

109− .duration_since(UNIX_EPOCH)

110− .map(|d| d.as_millis() as i64)

111− .unwrap_or(0)

112−}

113−```

114−

115−If the system clock is before `UNIX_EPOCH` (misconfigured device, RTK bug, NTP step), `now_ms()` returns 0. Consequences:

116−

117−- **Outbox TTL disabled:** `first_attempt` is stamped as 0 (line 1990-1993). `OutboxItem::is_expired` checks `first_attempt > 0` (line 170) — 0 means "never attempted," so the TTL never applies. Stuck items are retried forever (only the retry counter bounds them, which at 10 retries with slow backoff could take days).

118−- **`flush_paused_until` bypassed:** `now_ms() < flush_paused_until` → `0 < 0` → false. Flushing proceeds immediately, ignoring a relay's `Retry-After`.

119−- **`last_ack_ts` / `last_profile_ts` clamped to 0:** `ts.min(now)` → `ts.min(0)` → 0 (if ts is positive). All future acks/profiles pass the staleness check (any ts >= 0). Dedup is weakened.

120−

121−**Attack scenario:** No attack — this is a device misconfiguration. But on iOS, a clock that briefly reads as pre-epoch during boot could trigger this transiently.

122−

123−**Suggested fix:** Use `UNIX_EPOCH` as the floor instead of 0:

124−```rust

125−fn now_ms() -> i64 {

126− SystemTime::now()

127− .duration_since(UNIX_EPOCH)

128− .map(|d| d.as_millis() as i64)

129− .unwrap_or(1) // 1, not 0 — 0 is a valid "never attempted" sentinel

130−}

131−```

132−Or better: propagate the error and have callers handle clock failure explicitly.

133−

134−---

135−

136−### 🔵 D5. `LoadedMessages` merge doesn't update `seen_ids` — weakened dedup after `seen_ids` load failure

137−

138−**Type:** Dedup gap

139−**File:** `core/src/app.rs:815-856`

140−

141−The `LoadedMessages` handler merges on-disk messages into the in-memory conversation (union by ID, re-sort, trim). But it does **not** add the on-disk message IDs to `model.seen_ids`.

142−

143−When `seen_ids` loads successfully from kv at startup, this is fine — the on-disk IDs are already in the set. But when `seen_ids` **fails to load** (line 807-811, non-fatal), the set is empty. The `ingest_poll` seeding at line 2244-2246 seeds from the conversation:

144−```rust

145−if id_set.is_empty() {

146− id_set.extend(convo.iter().map(|m| m.id.clone()));

147−}

148−```

149−

150−If a poll arrives **before** `LoadedMessages` for a peer, the conversation is empty (not loaded yet). The seeding adds no IDs. The poll's messages are stored and their IDs are added to the set. Later, `LoadedMessages` arrives and merges the on-disk messages — but their IDs are **never** added to `seen_ids` (the merge doesn't touch `seen_ids`, and the seeding only runs when `id_set.is_empty()`, which is no longer true after the poll).

151−

152−**Result:** On-disk message IDs are missing from `seen_ids`. Future replays of those on-disk messages pass the dedup check (line 2248) and are re-inserted into the conversation. The `LoadedMessages` merge filters duplicates by ID (line 830), so the conversation doesn't grow unboundedly — but each replay is processed (decrypted, inserted, acked) before the merge catches it.

153−

154−**Attack scenario:**

155−1. `seen_ids` kv load fails (device locked, file corruption).

156−2. `LoadedContacts` triggers `LoadedMessages` for peer P.

157−3. A poll arrives before `LoadedMessages` for P. P's conversation is empty. `seen_ids[P]` is seeded as empty.

158−4. Poll stores new messages, adds their IDs to `seen_ids[P]`.

159−5. `LoadedMessages` for P arrives. On-disk messages are merged into the conversation. Their IDs are NOT added to `seen_ids[P]`.

160−6. A replay of an on-disk message arrives. Its ID is not in `seen_ids[P]`. It passes dedup. It's inserted and acked.

161−

162−**Impact:** Weakened dedup — replays of on-disk messages are re-processed (decrypted, stored, acked). No permanent data corruption (the merge prevents duplicate conversation entries), but the recipient sends spurious delivery acks for old messages, and the sender receives false "delivered" confirmations.

163−

164−**Suggested fix:** In the `LoadedMessages` merge, add the on-disk message IDs to `seen_ids`:

165−```rust

166−if let Some(id_set) = model.seen_ids.get_mut(&peer) {

167− id_set.extend(list.iter().map(|m| m.id.clone()));

168−}

169−```

170−

171−---

172−

173−## 4. Protocol Deviations

174−

175−### ⚪ D6. `ingest_poll` doesn't send profile to stranger on first contact — protocol "SHOULD" not followed

176−

177−**Type:** Protocol deviation (UX)

178−**File:** `core/src/app.rs:2221-2230, 2400-2412`

179−

180−PROTOCOL.md §4: "Clients SHOULD send a `profile` message to a contact on first interaction and whenever the user updates their name, bio, or photo."

181−

182−When a stranger sends us a text, `ingest_poll` auto-creates a contact (line 2225-2229) and queues a `delivery.ack` (line 2400-2412). But it does **not** queue a `profile` broadcast back to the stranger. The stranger's client has our pubkey (they sent us a message) but no profile — they see our truncated @p but not our display name or avatar.

183−

184−`send_text` handles this correctly: on first contact (line 1858-1873), it queues a profile broadcast after the text. But `ingest_poll` doesn't.

185−

186−**Impact:** Minor UX issue — a stranger who initiates conversation doesn't see our profile until we manually send them a text or update our profile. Not a security vulnerability.

187−

188−**Suggested fix:** After auto-creating a contact in `ingest_poll`, queue a profile broadcast:

189−```rust

190−if !known {

191− // ... auto-create contact ...

192− let profile = Payload::Profile { /* ... */ };

193− model.outbox.push_back(OutboxItem::profile(

194− sender.clone(),

195− Arc::new(protocol::serialize_payload(&profile, ts)),

196− ));

197− outbox_dirty = true;

198−}

199−```

200−

201−---

202−

203−## Summary of New Findings

204−

206−|---|----------|------|-------|

208−| D2 | 🔵 low | Stale state | `SetServerUrl` doesn't reset `poll_retries` — new relay inherits old poll backoff |

209−| D3 | 🔵 low | Write guard gap | `SendResult` pops items when `kv_load_failed` — duplicate sends on relaunch |

210−| D4 | 🔵 low | Robustness | `now_ms()` returns 0 on clock failure — outbox TTL disabled |

211−| D5 | 🔵 low | Dedup gap | `LoadedMessages` merge doesn't update `seen_ids` — weakened dedup after load failure |

213−

214−**Medium (1):** D1

215−**Low (4):** D2, D3, D4, D5

216−**Info (1):** D6

217−

218−---

219−

220−## Priorities

221−

222−1. **D1 (medium):** Fix `events_stored` to count all successfully decrypted events. This closes a livelock variant that the N9 fix doesn't cover — a hostile relay can permanently wedge the client by re-serving large duplicate/stale/stranger blobs.

223−

224−2. **D2 (low):** Add `model.poll_retries = 0;` to `SetServerUrl`. One-line fix, prevents stale backoff on relay switch.

225−

226−3. **D5 (low):** Update `seen_ids` in the `LoadedMessages` merge. Closes a dedup gap when `seen_ids` kv load fails.

227−

228−4. **D3 (low):** Guard `SendResult` pop with `kv_load_failed` check. Prevents duplicate sends on relaunch.

229−

230−5. **D4 (low):** Change `unwrap_or(0)` to `unwrap_or(1)` in `now_ms()`. Prevents TTL disablement on clock failure.

AUDIT-FFI-PHONEMIC-APPLE.mddeleted−470

@@ -1,470 +0,0 @@

1−# Skrepka Security Audit — FFI, Phonemic, Apple Shell (2026-07-16)

2−

3−**Scope:** Deep audit of `core/src/ffi.rs`, `core/src/phonemic.rs`, and all Apple shell files (`apple/SkrepkaApp/*.swift`). Cross-referenced against `PROTOCOL.md`, `AGENTS.md`, `AUDIT-NEW.md`, and `AUDIT-FRESH.md`. Findings below are **not** in prior audits.

4−

5−**Legend:** 🔴 critical · 🟠 high · 🟡 medium · 🔵 low · ⚪ info

6−

7−---

8−

9−## 1. FFI Boundary

10−

11−### 🟠 F1. `try!` in Core.swift crashes on empty bytes from `guard` — FFI panic safety is a lie

12−

13−**Type:** FFI boundary / panic safety

14−**Files:** `core/src/ffi.rs:42-44` (`guard`), `apple/SkrepkaApp/Core.swift:30,38,49,60,66,74,81`

15−

16−The `guard` function in `ffi.rs` catches panics with `catch_unwind` and returns an empty `Vec<u8>`. The module doc (lines 4-9) claims: *"the shell already tolerates an empty effect list (it just does nothing) and an empty view (it renders the previous one), so a bug degrades into a stalled UI rather than a corrupted process."*

17−

18−This is false. Every bincode deserialization in `Core.swift` uses `try!`:

19−

20−```swift

21−// Core.swift:30 (init)

22−self.view = try! .bincodeDeserialize(input: [UInt8](core.view()))

23−

24−// Core.swift:38 (update)

25−let effects = [UInt8](core.update(data: Data(try! event.bincodeSerialize())))

26−

27−// Core.swift:49 (dispatch)

28−let requests = try! Requests.bincodeDeserialize(input: effects).value

29−

30−// Core.swift:60 (render)

31−self.view = try! .bincodeDeserialize(input: [UInt8](core.view()))

32−```

33−

34−If `core.view()` or `core.update()` returns empty bytes (from a caught panic), `try! .bincodeDeserialize(input: [])` throws, and `try!` produces a fatal error — **crashing the app**, not degrading gracefully. The `init` case is the worst: there is no "previous view" to render, so the very first `core.view()` call would crash the app on launch if the core panics.

35−

36−**Attack scenario:** Any input that causes a panic inside `App::update` or `Skrepka::view` — an unforeseen edge case, a dependency bug, or an integer overflow in debug mode — would crash the app instantly via `try!` rather than degrading to a stalled UI as the FFI docs claim. On iOS, this is a clean crash with no data corruption, but it's a denial-of-service: the user can't use the app at all.

37−

38−**Exploitable in practice:** Requires triggering a panic in the Rust core. The core code is careful with `unwrap_or` / `unwrap_or_default`, but panics from dependencies (e.g., `serde_json` on malformed input, `zstd` on a crafted frame) or array indexing bugs are possible. A hostile relay crafting specific poll responses could potentially trigger a panic in the decrypt path.

39−

40−**Suggested fix:** Replace `try!` with `try?` or a `do/catch` block that logs the error and skips the deserialization. For `init`, provide a default empty `ViewModel` if `core.view()` returns empty bytes. Alternatively, have `guard` return a sentinel (e.g., a single zero byte) that the Swift side can detect as "panic occurred" and handle gracefully.

41−

42−---

43−

44−### 🟡 F2. `AssertUnwindSafe` is unsound — Model is read after a panic

45−

46−**Type:** FFI boundary / memory safety

47−**Files:** `core/src/ffi.rs:39-44` (`guard` + `AssertUnwindSafe`)

48−

49−The `guard` function uses `AssertUnwindSafe(f)` to bypass the `UnwindSafe` requirement. The doc comment (lines 39-41) justifies this: *"AssertUnwindSafe is sound here because a poisoned Bridge is never read again for correctness: the worst case is a dropped effect batch, and the next event starts a fresh update."*

50−

51−This is incorrect. The `Bridge` holds the `Core`, which holds the `Model`. `App::update` takes `&mut Model` and mutates it in place. If a panic occurs **mid-update** (after some model mutations but before the function returns), the `Model` is left in a partially-mutated, inconsistent state. The `catch_unwind` catches the panic, returns empty bytes, but the `Model` stays corrupted. The **next** `update` call operates on this corrupted model.

52−

53−The comment's claim that "the next event starts a fresh update" is misleading — a fresh update on a corrupted model is not fresh. The model's invariants (e.g., `contacts` is consistent with `messages`, `cursor` is valid, `outbox` items are well-formed) may be violated.

54−

55−**Attack scenario:** A panic mid-update corrupts the model. The next `update` call sees the corrupted state and may:

56−- Write corrupted state to kv (persisting the corruption across launches)

57−- Crash on a subsequent update (if the corruption violates an invariant checked by `update`)

58−- Produce incorrect behavior (e.g., sending messages to the wrong recipient)

59−

60−**Exploitable in practice:** Requires triggering a panic mid-update, which is the same bar as F1. The corruption is silent — the user sees a stalled UI (if F1 doesn't crash first), but the next interaction operates on corrupted state.

61−

62−**Suggested fix:** After a caught panic, reset the `Model` to a known-good state (e.g., re-load from kv) or mark the `Bridge` as poisoned and refuse further operations. Alternatively, snapshot the `Model` before `update` and restore it on panic. This is expensive but correct. At minimum, document that a panic may corrupt the model and recommend the shell re-initialize the core after a caught panic.

63−

64−---

65−

66−### 🔵 F3. `resolve` accepts arbitrary `EffectId` — no validation against pending effects

67−

68−**Type:** FFI boundary / input validation

69−**Files:** `core/src/ffi.rs:70-78` (`resolve`)

70−

71−The `resolve` method accepts any `u32` as an effect ID and any `&[u8]` as the resolution data. The `Bridge::resolve` call would fail with `Err` if the effect ID is unknown, which `guard` converts to an empty Vec. But the empty Vec would crash the Swift side via `try!` (see F1).

72−

73−More importantly, if the Swift side has a bug that resolves the same effect ID twice (e.g., from a race between a timer callback and a `.clear` call), the second resolution would produce effects for a non-existent or already-resolved effect. The `Bridge::resolve` would return `Err`, which becomes empty bytes, which crashes via `try!`.

74−

75−**Attack scenario:** Not directly exploitable by an attacker — the effect IDs are generated by the core and passed to the shell. But a shell bug (e.g., a race condition in timer handling) could trigger a double-resolve, crashing the app.

76−

77−**Suggested fix:** The shell should track which effect IDs are pending and guard against double-resolve. The FFI should return a distinguishable error for "unknown effect ID" vs "serialization failure" so the shell can handle it gracefully.

78−

79−---

80−

81−## 2. Phonemic

82−

83−### 🔵 P1. `to_ob` / `from_ob` round-trip asymmetry for empty input

84−

85−**Type:** Correctness asymmetry

86−**Files:** `core/src/phonemic.rs:98-109` (`to_ob`), `core/src/phonemic.rs:113-132` (`from_ob`)

87−

88−`to_ob(&[])` returns `Some(String::new())` (empty string), but `from_ob("")` returns `None` (because `split('-').filter(|p| !p.is_empty()).collect()` yields an empty Vec, which triggers `parts.is_empty() => None`).

89−

90−This means `to_ob` produces a string that `from_ob` can't decode. The round-trip property is broken for empty input.

91−

92−**Impact:** No caller passes empty bytes to `to_ob` for pubkey purposes (keys are always 32 bytes). The asymmetry is documented in the test `odd_length_input_has_no_spelling` (line 210). Harmless in practice.

93−

94−**Suggested fix:** Either make `to_ob(&[])` return `None` (consistent with odd-length rejection) or make `from_ob("")` return `Some(vec![])` (consistent with the encoding). The former is safer — an empty encoding is meaningless.

95−

96−---

97−

98−### 🔵 P2. `try_parse_pubkey` hex path lowercases redundantly — no bug, but misleading

99−

100−**Type:** Code clarity

101−**Files:** `core/src/phonemic.rs:154`

102−

103−`hex::decode(trimmed.to_lowercase())` — the `hex` crate's `decode` accepts both uppercase and lowercase hex digits. The `to_lowercase()` is redundant for the hex path. It doesn't cause a bug (the output of `valid_pubkey_hex` is always lowercase via `hex::encode`), but it suggests the case matters when it doesn't.

104−

105−**Suggested fix:** Remove the `to_lowercase()` or add a comment explaining it's for consistency, not correctness.

106−

107−---

108−

109−### ⚪ P3. No @p/hex collision for 32-byte pubkeys — confirmed safe

110−

111−**Type:** Correctness verification

112−**Files:** `core/src/phonemic.rs:148-158` (`try_parse_pubkey`)

113−

114−A 64-char hex string has no hyphens, so `from_ob` sees one part of 64 chars, fails the `part.len() != 6` check, returns `None`. The hex path then decodes it. No collision.

115−

116−A valid @p for a 32-byte key is 16 syllables (111 chars with hyphens). `hex::decode` fails on hyphens. No collision.

117−

118−A 6-char hex string (e.g., "abcdef") that happens to be a valid @p syllable: `from_ob` decodes it to 2 bytes, `valid_pubkey_hex` rejects (not 32 bytes). `hex::decode` gives 3 bytes, also rejected. No collision.

119−

120−**Verdict:** Safe. The @p-first ordering in `try_parse_pubkey` is correct.

121−

122−---

123−

124−### ⚪ P4. `from_ob` multibyte handling is correct — confirmed safe

125−

126−**Type:** Correctness verification

127−**Files:** `core/src/phonemic.rs:113-132`

128−

129−`to_lowercase()` is applied before `split('-')`. For non-ASCII input, `to_lowercase()` may change byte lengths, but the `part.len() != 6 || !part.is_ascii()` check on each part catches any non-ASCII characters that survive lowercasing. The test `multibyte_input_is_rejected_not_panicked_on` (line 279) confirms this.

130−

131−The `part[0..3]` and `part[3..6]` slices are safe because `part.len() == 6` and `part.is_ascii()` (ASCII = 1 byte per char, so byte indices == char indices).

132−

133−**Verdict:** Safe. No panic on multibyte input.

134−

135−---

136−

137−## 3. Apple Shell — HTTP Handling

138−

139−### 🟡 A1. `Http.perform` doesn't validate URL scheme — `file://` requests would be honored

140−

141−**Type:** Defense-in-depth gap

142−**Files:** `apple/SkrepkaApp/Effects.swift:104-106`

143−

144−```swift

145−guard let url = URL(string: req.url) else {

146− return .err(.url(req.url))

147−}

148−var request = URLRequest(url: url)

149−```

150−

151−The shell accepts any URL scheme. `URLSession.data(for:)` handles `file://` URLs by reading local files. The core's `normalize_server_url` only accepts `http`/`https`, but if a bug in the core (or a future change) produces a `file://` or `data:` URL, the shell would honor it without question.

152−

153−**Attack scenario:** Not directly exploitable — the server URL is user-configured and validated by `normalize_server_url`. But if a bug in URL construction (e.g., `format!("{}/poll", model.settings.server_url)` where `server_url` is somehow `file:///etc/passwd`) reaches the shell, a local file could be read and its contents returned to the core as an HTTP response body. The core would try to parse it as JSON, fail, and treat it as an empty page.

154−

155−**Exploitable in practice:** Requires a core bug that produces a non-http URL. `normalize_server_url` prevents this for the server URL, but there's no belt-and-suspenders check in the shell.

156−

157−**Suggested fix:** Add a scheme check in `Http.perform`:

158−```swift

159−guard url.scheme == "http" || url.scheme == "https" else {

160− return .err(.url(req.url))

161−}

162−```

163−

164−---

165−

166−### 🟡 A2. `HttpSessionDelegate` cancels same-host redirects — may break legitimate HTTPS upgrades

167−

168−**Type:** Protocol conformance / usability

169−**Files:** `apple/SkrepkaApp/Effects.swift:45-53`

170−

171−The redirect delegate cancels **all** redirects, including same-host redirects. A relay that redirects from `http://relay:80` to `https://relay:443` (a legitimate TLS upgrade) would have its redirect cancelled. The client would see the 3xx response and treat it as a failure.

172−

173−The protocol says "plain HTTP, served over TLS in production" (§5), and `normalize_server_url` accepts both `http` and `https`. So a relay that serves HTTP on port 80 and redirects to HTTPS on port 443 would be broken by this client.

174−

175−**Attack scenario:** Not an attack — a usability issue. A relay operator who sets up an HTTP-to-HTTPS redirect would find that Skrepka clients can't connect.

176−

177−**Exploitable in practice:** Depends on relay configuration. The `install.sh` deploys Caddy with TLS, so production relays serve HTTPS directly (no redirect). But a relay misconfigured to redirect would be unreachable.

178−

179−**Suggested fix:** Allow same-host redirects (compare the redirect target's host against the original request's host). Only cancel cross-host redirects, which are the token-exfiltration vector. Or, since the protocol says no redirects, document that relays must not redirect.

180−

181−---

182−

183−### 🔵 A3. `UInt16(clamping:)` silently truncates status codes > 65535

184−

185−**Type:** Input validation

186−**Files:** `apple/SkrepkaApp/Effects.swift:120`

187−

188−```swift

189−status: UInt16(clamping: http?.statusCode ?? 0),

190−```

191−

192−HTTP status codes are 3-digit integers (100-599), so this is fine in practice. But `UInt16(clamping:)` would clamp any value > 65535 to 65535, which is a valid `UInt16` but not a valid HTTP status. The core checks `status >= 200 && status < 300` for success, so 65535 would be treated as failure. No security issue.

193−

194−**Verdict:** Safe. HTTP status codes are bounded by the protocol.

195−

196−---

197−

198−### ⚪ A4. URLSession configuration is correct — confirmed safe

199−

200−**Type:** Implementation review

201−**Files:** `apple/SkrepkaApp/Effects.swift:91-101`

202−

203−The session configuration is:

204−- `ephemeral` — no cookies, no cache, no persistent storage ✓

205−- `httpCookieAcceptPolicy = .never` ✓

206−- `httpShouldSetCookies = false` ✓

207−- `httpCookieStorage = nil` ✓

208−- `urlCache = nil` ✓

209−- `requestCachePolicy = .reloadIgnoringLocalAndRemoteCacheData` ✓

210−- `timeoutIntervalForRequest = 70` — matches the server's ~25s long-poll ✓

211−- `tlsMinimumSupportedProtocolVersion = .TLSv12` ✓

212−

213−No sensitive data in logs. The `error.localizedDescription` in the catch block returns user-friendly strings like "The network connection was lost" — no relay-specific info beyond what the user already configured.

214−

215−**Verdict:** Safe. Good defense-in-depth.

216−

217−---

218−

219−### ⚪ A5. Response size limiting is correct — confirmed safe

220−

221−**Type:** Implementation review

222−**Files:** `apple/SkrepkaApp/Effects.swift:31-79`

223−

224−The `HttpSessionDelegate` tracks per-task byte counts in a thread-safe `NSLock`-guarded dictionary. When a task's accumulated body exceeds `maxResponseBytes` (64 MiB), the task is cancelled. The `didCompleteWithError` callback cleans up the dictionary entry. Every task eventually completes (success, failure, or cancel), so no dictionary leak.

225−

226−The 64 MiB cap matches the core's `MAX_POLL_RESPONSE_BYTES` (also 64 MiB). The shell's cap fires before the core's (the shell cancels the task mid-stream, the core never sees the full body), which is the correct ordering — the shell's cap prevents OOM before the core's check runs.

227−

228−**Verdict:** Safe. Well-designed.

229−

230−---

231−

232−## 4. Apple Shell — Keychain & KV Persistence

233−

234−### ⚪ A6. Keychain storage is correct — confirmed safe

235−

236−**Type:** Implementation review

237−**Files:** `apple/SkrepkaApp/Effects.swift:320-415`

238−

239−- `kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly` — key never rides backup ✓

240−- `SecItemUpdate` first, then `SecItemAdd` if not found — no delete-then-add window ✓

241−- `errSecItemNotFound` is the only status that triggers key generation ✓

242−- 64-byte key length is validated on load ✓

243−- `loadOrCreateIdentity` is called only on the main actor (singleton `Core.shared`), so no race ✓

244−

245−The `store` function's update-then-add sequence has a theoretical race (between `SecItemUpdate` returning `errSecItemNotFound` and `SecItemAdd`, another thread could add the item), but `bootIdentity` is only called on the `@MainActor` singleton, so there's no concurrency.

246−

247−**Verdict:** Safe. Good practice.

248−

249−---

250−

251−### ⚪ A7. KV persistence is correct — confirmed safe

252−

253−**Type:** Implementation review

254−**Files:** `apple/SkrepkaApp/Effects.swift:195-316`

255−

256−- Serial queue — all operations serialized ✓

257−- Atomic writes with `.completeFileProtectionUnlessOpen` ✓

258−- `isExcludedFromBackup = true` — plaintext history not in iCloud backup ✓

259−- Percent-encoding with `.alphanumerics` — injective key→filename mapping, no path traversal ✓

260−- Legacy migration runs before any read (same serial queue) ✓

261−- Missing file = empty key (`.none`), not an error — correct distinction from read failure ✓

262−

263−**Verdict:** Safe. Well-designed.

264−

265−---

266−

267−## 5. Apple Shell — Photo Picker & QR Scanning

268−

269−### 🔵 A8. `PhotoPicker` last-resort quality doesn't check size cap

270−

271−**Type:** Logic bug / UX

272−**Files:** `apple/SkrepkaApp/PhotoPicker.swift:80-81`

273−

274−```swift

275−// Last resort: the smallest quality that still produces something.

276−return image.jpegData(compressionQuality: 0.1)?.base64EncodedString()

277−```

278−

279−The loop (lines 71-79) reduces quality until the base64 fits within 64 KiB (`maxBase64Len`). But the last-resort return on line 81 doesn't check if the result fits. If a 256px JPEG at q0.1 still exceeds 64 KiB (possible for high-frequency noise images), the core's `SaveProfile` rejects it with "photo too large" and the user has no recourse.

280−

281−**Attack scenario:** A user picks a photo that, even at 256px and q0.1, produces > 64 KiB of base64. The profile save fails with no way to proceed. Not a security issue — a UX dead end.

282−

283−**Exploitable in practice:** Very unlikely for real photos (256px JPEG at q0.1 is typically 5-15 KiB). But a synthetic image (e.g., pure noise) could exceed the cap.

284−

285−**Suggested fix:** If the last-resort still exceeds the cap, return `nil` (triggering `onCancel`) or downscale further (e.g., 128px). Or document that the user should pick a different photo.

286−

287−---

288−

289−### 🔵 A9. `scannedKeyPayload` is business logic in the shell — portability concern

290−

291−**Type:** Protocol conformance / architecture

292−**Files:** `apple/SkrepkaApp/QRView.swift:24-35`

293−

294−`scannedKeyPayload` parses QR code content: strips URL schemes (`skrepka://`, `https://`, `http://`), extracts the last path component, and trims whitespace. This is parsing logic that determines what input the core receives.

295−

296−`AGENTS.md` says: *"The shell never decides anything — it turns Effects into platform calls and resolves the results back in."* This function decides how to interpret a QR code, which is arguably a business decision.

297−

298−An Android client would need to reimplement this logic. If the parsing differs (e.g., one client strips `skrepka://` and another doesn't), the same QR code would produce different inputs to the core.

299−

300−**Attack scenario:** Not a security vulnerability — the core's `try_parse_pubkey` validates the result regardless. But a portability bug: a QR code with a `skrepka://` prefix would work on iOS (stripped by `scannedKeyPayload`) but fail on an Android client that doesn't strip the scheme.

301−

302−**Suggested fix:** Move `scannedKeyPayload` into the core (e.g., `try_parse_pubkey_from_qr` or add scheme-stripping to `try_parse_pubkey`). The shell should pass the raw QR content to the core.

303−

304−---

305−

306−### 🔵 A10. `QRScannerView` doesn't check camera permission

307−

308−**Type:** UX gap

309−**Files:** `apple/SkrepkaApp/QRView.swift:75-80`

310−

311−`ScannerVC.viewDidLoad` calls `AVCaptureDevice.default(for: .video)`, which returns `nil` if camera permission hasn't been granted (or has been denied). The `guard` fails silently, and the scanner shows a black screen with no error message or permission prompt.

312−

313−**Attack scenario:** Not a security issue. A user who denied camera permission can't scan QR codes and sees a black screen with no explanation.

314−

315−**Suggested fix:** Check `AVCaptureDevice.authorizationStatus(for: .video)` and request permission if not determined. Show an error message if denied.

316−

317−---

318−

319−### ⚪ A11. `QRScannerView` camera lifecycle is correct — confirmed safe

320−

321−**Type:** Implementation review

322−**Files:** `apple/SkrepkaApp/QRView.swift:101-114`

323−

324−`startRunning()` and `stopRunning()` are dispatched to a background queue (`DispatchQueue.global(qos: .userInitiated)`) to avoid blocking the main thread. The `done` flag in `Coordinator` prevents multiple `onScan` callbacks. The camera session is properly stopped in `viewWillDisappear`.

325−

326−**Verdict:** Safe.

327−

328−---

329−

330−## 6. Apple Shell — Logic Leakage & Protocol Conformance

331−

332−### 🟡 A12. `BackgroundRefresh` polls `core.view` in a tight loop — main actor contention

333−

334−**Type:** Performance / architecture

335−**Files:** `apple/SkrepkaApp/SkrepkaApp.swift:156-163`

336−

337−The `settle` function polls `core.view` every 200ms, reading the `@Published` `ViewModel` on the main actor. While the overhead per poll is minimal (reading a published property), this runs for up to 25 seconds during a background refresh. If the core is processing a large poll response (which also runs on the main actor via `resolve`), the 200ms polls interleave with core processing.

338−

339−More importantly, `core.view` is a `@Published` property backed by `ViewModel`, which is a value type. Each read copies the entire `ViewModel` (including `contacts: Vec<ContactVM>` and `messages: Vec<MessageVM>`). For a user with 500 contacts and 1000 messages, each poll copies ~1 MB of data. Over 25 seconds at 200ms intervals, that's 125 copies = ~125 MB of transient allocations.

340−

341−**Attack scenario:** Not an attack — a performance issue. A user with many contacts and active conversations would experience increased memory pressure during background refresh.

342−

343−**Suggested fix:** Use a Combine subscription (`core.$view.sink`) instead of polling, or have the core expose a lightweight "status changed" flag that the shell can check without copying the full `ViewModel`.

344−

345−---

346−

347−### 🔵 A13. `Core.swift` `dispatch` silently drops effects if `try!` crashes — no recovery

348−

349−**Type:** Error handling

350−**Files:** `apple/SkrepkaApp/Core.swift:47-53`

351−

352−```swift

353−private func dispatch(_ effects: [UInt8]) {

354− // swiftlint:disable:next force_try

355− let requests = try! Requests.bincodeDeserialize(input: effects).value

356− for request in requests {

357− process(request)

358− }

359−}

360−```

361−

362−If `effects` is valid bincode but contains an effect variant the Swift side doesn't know about (e.g., after a core update that adds a new effect without regenerating Swift types), `try!` would crash. The AGENTS.md warns about this: *"Touching Event, ViewModel, or Effect without running just generate leaves the Swift side compiling against stale types."*

363−

364−But there's no runtime recovery. The crash is immediate and unrecoverable. A safer approach would be to catch the deserialization error, log it, and skip the unknown effect — the core would see the effect as unresolved and its watchdog would handle it.

365−

366−**Suggested fix:** Replace `try!` with `try?` and log the error. Unknown effects are dropped; the core's watchdog handles the missing resolution.

367−

368−---

369−

370−### ⚪ A14. `Time.handle` timer lifecycle is correct — confirmed safe

371−

372−**Type:** Implementation review

373−**Files:** `apple/SkrepkaApp/Effects.swift:147-191`

374−

375−The `timers` dictionary is on the `@MainActor`. The `schedule` function removes the old work item before inserting a new one. The `DispatchWorkItem`'s callback runs on the main queue (via `MainActor.assumeIsolated`), so there's no interleaving between `schedule` and the callback. The `.clear` case removes and cancels the work item.

376−

377−No race condition: all operations are on the main actor / main queue, which is single-threaded.

378−

379−**Verdict:** Safe.

380−

381−---

382−

383−### ⚪ A15. `SkrepkaApp.swift` background refresh is correct — confirmed safe

384−

385−**Type:** Implementation review

386−**Files:** `apple/SkrepkaApp/SkrepkaApp.swift:64-164`

387−

388−- `isProtectedDataAvailable` guard prevents running while locked ✓

389−- `settle` polling respects `Task.isCancelled` and deadline ✓

390−- `setTaskCompleted(success: !Task.isCancelled)` correctly reports failure on cancellation ✓

391−- `schedule()` is called before `run()` — next refresh is always queued ✓

392−- `Core.shared` is only accessed after the `isProtectedDataAvailable` guard ✓

393−

394−**Verdict:** Safe. Well-designed.

395−

396−---

397−

398−## 7. Protocol & AGENTS.md Conformance

399−

400−### 🔵 A16. AGENTS.md says "five kv loads" but core does six — `seen_ids` added

401−

402−**Type:** Documentation drift

403−**Files:** `AGENTS.md:98` ("fans out five kv loads"), `core/src/app.rs:719-726` (six loads)

404−

405−AGENTS.md line 98 says: *"IdentityLoaded fans out five kv loads → LoadedSettings triggers Connect"*. But the core actually fans out **six** kv loads: `settings`, `profile`, `contacts`, `cursor`, `outbox`, and `seen_ids` (line 725: `KeyValue::get(K_SEEN_IDS)`). The `STARTUP_LOADS` constant is 6 (line 312).

406−

407−**Impact:** Documentation drift, not a bug. A developer reading AGENTS.md would expect five loads and be confused by the sixth.

408−

409−**Suggested fix:** Update AGENTS.md to say "six kv loads" and include `seen_ids` in the list.

410−

411−---

412−

413−### 🔵 A17. AGENTS.md lists kv keys without `seen_ids` — stale documentation

414−

415−**Type:** Documentation drift

416−**Files:** `AGENTS.md:14` ("keys `settings`, `profile`, `contacts`, `cursor`, `outbox`, and `messages:<peer_hex>`")

417−

418−The `seen_ids` key is not listed in AGENTS.md's kv key list. It was added as part of the dedup fix (AUDIT-NEW.md Q18) but the documentation wasn't updated.

419−

420−**Suggested fix:** Add `seen_ids` to the kv key list in AGENTS.md.

421−

422−---

423−

424−## Summary of New Findings

425−

427−|---|----------|------|-------|

430−| F3 | 🔵 low | FFI/input | `resolve` accepts arbitrary EffectId — double-resolve crashes via `try!` |

431−| P1 | 🔵 low | Correctness | `to_ob`/`from_ob` round-trip asymmetry for empty input |

432−| P2 | 🔵 low | Clarity | `try_parse_pubkey` hex path lowercases redundantly |

437−| A3 | 🔵 low | HTTP/input | `UInt16(clamping:)` silently truncates status codes > 65535 |

442−| A8 | 🔵 low | Photo/UX | `PhotoPicker` last-resort quality doesn't check size cap |

443−| A9 | 🔵 low | Architecture | `scannedKeyPayload` is business logic in the shell — portability concern |

444−| A10 | 🔵 low | QR/UX | `QRScannerView` doesn't check camera permission |

447−| A13 | 🔵 low | Error handling | `Core.swift` `dispatch` crashes on unknown effect — no recovery |

450−| A16 | 🔵 low | Docs | AGENTS.md says "five kv loads" but core does six |

451−| A17 | 🔵 low | Docs | AGENTS.md kv key list missing `seen_ids` |

452−

453−**High (1):** F1

454−**Medium (4):** F2, A1, A2, A12

455−**Low (8):** F3, P1, P2, A3, A8, A9, A10, A13, A16, A17

456−**Info (8):** P3, P4, A4, A5, A6, A7, A11, A14, A15

457−

458−---

459−

460−## Priorities

461−

462−1. **F1 (high):** Replace `try!` in Core.swift with graceful error handling. The FFI's panic safety design is undermined by `try!` — a caught panic crashes the app instead of degrading. This is the most impactful finding because it turns every potential core panic into an immediate app crash.

463−

464−2. **F2 (medium):** Address `AssertUnwindSafe` soundness. After a caught panic, the Model may be corrupted. At minimum, document the risk and consider resetting the Model from kv on panic recovery.

465−

466−3. **A1 (medium):** Add URL scheme validation in `Http.perform`. Defense-in-depth against a core bug producing non-http URLs.

467−

468−4. **A2 (medium):** Allow same-host redirects or document that relays must not redirect. The current all-redirects-cancelled policy breaks legitimate HTTPS upgrades.

469−

470−5. **A12 (medium):** Replace `settle`'s polling with a Combine subscription to avoid copying the full ViewModel every 200ms during background refresh.

AUDIT-FRESH.mddeleted−385

@@ -1,385 +0,0 @@

1−# Skrepka Security Audit — Fresh Pass (2026-07-15)

2−

3−**Scope:** Exhaustive multi-pass audit of PROTOCOL.md, server.knot, core/src/ (app.rs,

4−crypto.rs, protocol.rs, model.rs, phonemic.rs, ffi.rs), apple/SkrepkaApp/ (Effects.swift,

5−Core.swift, Views.swift, Forms.swift), install.sh. Findings below are **not** in

6−PROTOCOL-REVIEW.md or AUDIT-NEW.md, or are new angles on previously-noted areas.

7−

8−**Legend:** 🔴 critical · 🟠 high · 🟡 medium · 🔵 low · ⚪ info

9−

10−---

11−

12−## 1. Cryptographic Protocol

13−

14−### 🔴 N1. No AAD on AEAD — envelope `to` field is unauthenticated, enabling silent targeted censorship by any relay

15−

16−**Type:** Design gap (protocol + crypto.rs)

17−**Files:** `core/src/crypto.rs:384-387` (encrypt), `core/src/crypto.rs:434-438` (decrypt)

18−

19−AUDIT-NEW.md Q2 notes this but downgrades the impact to "equivalent to message loss, which is

20−an accepted limitation." That understates it. The real issue is **silent, targeted message loss

21−with zero detectability**:

22−

23−A relay holding a victim's messages can swap the `to` field on a *specific* message (from a

24−sender the relay wants to censor), while leaving other messages intact. The recipient never

25−sees the message and gets no error. The `delivery.ack` system doesn't help because the recipient

26−never received the message to ack it, and the sender's UI shows the message as "sent"

27−indefinitely — which is the same behavior as "the recipient is offline" or "the recipient read

28−it but hasn't acked yet." There is **no way for either party to distinguish "the relay ate

29−Alice's message" from "Alice didn't send anything" or "Bob is just slow to ack."**

30−

31−This is worse than the generic "relay can drop messages" case. Dropping is *eventually*

32−detectable — the sender sees their message stuck at "sent" and can investigate. But `to`-swapping

33−moves the message to a *different recipient's* mailbox, where it's undecryptable and gets

34−silently dropped on poll. The original recipient's cursor is unaffected (no events), so the

35−next poll is normal. The censorship is invisible.

36−

37−**Attack scenario:**

38−1. Alice sends a message to Bob via relay R.

39−2. R swaps `to` from Bob's pubkey to Charlie's.

40−3. Message stored under Charlie's mailbox. Charlie can't decrypt (wrong key), drops silently.

41−4. Bob polls, gets nothing. Normal poll, no error.

42−5. Alice's UI shows "sent" — same as if Bob were merely offline.

43−6. No delivery.ack ever comes. Alice can't tell if Bob received it or not.

44−

45−The relay can do this selectively — censor messages from specific senders, or suppress specific

46−content patterns (inferred from blob size), while delivering everything else normally. The

47−censorship is undetectable because the sender sees the same "sent" status they'd see for any

48−offline recipient, and the recipient sees nothing unusual.

49−

50−**Suggested fix:** Include `version_byte || ephemeral_public || nonce || recipient_ed25519_public`

51−as AAD in the AEAD. The `to` field must match `recipient_ed25519_public` in the AAD. A relay

52−swapping `to` causes the wrong recipient to fail AEAD decryption (before signature check), and

53−the blob is dropped before cursor advancement. The *original* recipient's message stays in the

54−mailbox. Wire-format change (v0x02).

55−

56−### ⚪ N2. HKDF info string and wire version byte are independent constants

57−

58−**Type:** Code hygiene (crypto.rs)

59−**Files:** `core/src/crypto.rs:28` (`HKDF_INFO = b"skrepka-v1"`), `crypto.rs:33` (`WIRE_VERSION = 1`)

60−

61−The spec says "A future revision that changes the crypto primitives should bump both the version

62−byte and the HKDF `info` string together." But there's no code-level binding between them. A

63−developer bumping `WIRE_VERSION` to `2` could forget to update `HKDF_INFO`, causing two different

64−crypto versions to derive keys with the same KDF label.

65−

66−**Suggested fix:** Derive the info string from the version byte or add a compile-time assertion

67−linking them.

68−

69−---

70−

71−## 2. Server Implementation

72−

73−### 🟡 N3. `appendMessage` dedup scan is O(n) — identical-blob replay amplifies to O(n × batch_size)

74−

75−**Type:** Implementation concern / DoS amplification (server.knot)

76−**Files:** `server.knot:919-937`

77−

78−AUDIT-NEW.md Q7 notes the O(n) dedup scan. The amplification is worse than described for

79−identical-blob replay: a batch of 100 identical blobs to the same recipient does 100 × O(|messages|)

80−scans. With |messages| = 10,000, that's 1M comparisons per request. At 60 requests/min, that's

81−60M comparisons/min. Each comparison is a string equality on 64-char hex pubkeys + 346+ char

82−hex blobs.

83−

84−**Attack:** An attacker authenticates (free keypair) and sends batches of 100 identical

85−min-size blobs to one recipient. Each request is ~35 KB but triggers 1M comparisons. Bounded

86−by the 60/min rate limit, but the CPU amplification is ~1000x per request.

87−

88−**Suggested fix:** Index `*messages` by `(toKey, encryptedBlob)` or use a hash-based dedup set.

89−

90−### 🟡 N4. `capForwards` eviction is non-deterministic when retry counts are equal

91−

92−**Type:** Implementation bug (server.knot)

93−**Files:** `server.knot:515-522` (`capForwards`)

94−

95−AUDIT-NEW.md Q9 notes this. The sort by `retries` only (no secondary sort key) means when many

96−entries share `retries: 0`, the sort is unstable and any retries-0 entry can be dropped —

97−including a fresh forward for a healthy peer that would have succeeded on the first try.

98−

99−**Impact:** Delivery delay, not permanent loss (the message stays in `*messages` and can be

100−re-forwarded on the next presence announce). But it's a real availability issue under

101−federation abuse.

102−

103−**Suggested fix:** Sort by `(retries, encryptedBlob)` for determinism, or skip entries for

104−peers in backoff before capping.

105−

106−### 🟡 N5. `handleRecvGossip` `fromServer` not verified against connecting peer's address

107−

108−**Type:** Design gap (server.knot)

109−**Files:** `server.knot:1533-1578`

110−

111−AUDIT-NEW.md Q29 notes this. The `fromServer` field is self-asserted and used to route forwarded

112−messages. An attacker can claim any `fromServer` hostname. The server writes presence rows with

113−that hostname and forwards queued messages there. This is the root cause of the gossip-redirect

114−attack and is already documented, but the spec's §10 should state more prominently that **the

115−server has no mechanism to verify that the connecting peer is who it claims to be**.

116−

117−The `fromServer` field is a `ServerName` (format-validated), but format validation only checks

118−length, lowercase, and no trailing dot — it does not verify the peer controls that hostname.

119−

120−**Suggested fix:** Document more prominently. Real fix needs reverse-DNS verification or peer

121−authentication (signed gossip).

122−

123−### 🔵 N6. `genToken` generates one hex digit per `randomInt 16` call — entropy waste

124−

125−**Type:** Implementation concern (server.knot)

126−**Files:** `server.knot:532-537`

127−

128−AUDIT-NEW.md Q10 notes the CSPRNG dependency. Additionally, generating one hex digit at a time

129−is inefficient — each `randomInt 16` call should produce at least 4 bits, but if the runtime's

130−`randomInt` draws from a wider source (e.g., 32-bit `getrandom`), it wastes 28 bits per call.

131−48 calls × 28 wasted bits = 1344 bits wasted per token. Not a security issue (entropy is

132−abundant) but inefficient.

133−

134−**Verdict:** Info.

135−

136−---

137−

138−## 3. Client Core Logic

139−

140−### 🟡 N7. `seen_ids` dedup set is unbounded — grows without limit per peer

141−

142−**Type:** Implementation concern (app.rs)

143−**Files:** `core/src/app.rs:325` (`seen_ids: BTreeMap<String, HashSet<String>>`)

144−

145−The `seen_ids` map (Q18 fix) is persisted to kv and loaded at startup. It's a `BTreeMap<String,

146−HashSet<String>>` — one entry per peer, each a set of message IDs. The set is never trimmed.

147−Over time, a peer who sends thousands of messages accumulates thousands of IDs. The kv blob

148−(`seen_ids`) grows without bound.

149−

150−With `MAX_ID_LEN` = 128 chars and UUIDs = 36 chars, 1000 messages per peer (the conversation cap)

151−= 36 KB per peer. With 500 contacts (`MAX_CONTACTS`), that's 18 MB. The `seen_ids` kv blob is

152−rewritten in full on every conversation touch (line 2316), so a large set makes every message

153−receipt slower. On iOS, a 18 MB JSON blob written to Application Support on every incoming

154−message is a real performance issue.

155−

156−**Suggested fix:** Cap the `seen_ids` set per peer (e.g., keep the last 2000 IDs) and trim

157−periodically. Or use a time-based expiry. Or a Bloom filter with a fixed size.

158−

159−### 🟡 N8. `ingest_poll` advances cursor before processing events — crash between advance and persist loses messages

160−

161−**Type:** Implementation concern (app.rs)

162−**Files:** `core/src/app.rs:2024-2089`

163−

164−The cursor is advanced to `page.cursor` on line 2038 (before the event loop), and restored to

165−`prev_cursor` on budget exhaustion (line 2086) or event count overflow (line 2069). The cursor

166−is persisted to kv AFTER `ingest_poll` returns (line 1369), via a `KeyValue::set` effect. This

167−means the cursor write only happens after the event loop completes successfully.

168−

169−However, there's a crash window: if the app crashes between `model.cursor = clamped_cursor`

170−(line 2038) and the cursor persist effect (line 1369), the in-memory cursor is advanced but

171−the persisted cursor is still `prev_cursor`. On relaunch, the client sends `prev_cursor` to

172−the relay, which re-serves the events. No message loss — the persisted cursor is the safe one.

173−

174−**Verdict:** Safe. The cursor is only authoritative when persisted, and the persist happens

175−after `ingest_poll` completes. A crash during `ingest_poll` loses no data because the persisted

176−cursor hasn't changed. Info.

177−

178−### 🟡 N9. `ingest_poll` budget exhaustion drops remaining events — client is stuck if the relay always serves an oversized page

179−

180−**Type:** Implementation concern (app.rs)

181−**Files:** `core/src/app.rs:2054-2089`

182−

183−When the `MAX_POLL_TOTAL_BYTES` budget is exhausted mid-page, the loop breaks, the cursor is

184−restored to `prev_cursor`, and an error is set. The next poll sends `prev_cursor` again, and

185−the relay re-serves the same events. If the page always exceeds the budget (e.g., the relay

186−serves 50 large blobs and the budget only covers 10), the client is stuck: poll, process 10,

187−drop 40, re-poll, relay serves the same 50, process the same 10 (deduped, fast), drop 40, etc.

188−

189−The dedup makes re-processing fast (already-seen IDs are O(1) drops), but the client never

190−advances past the oversized page. The relay's events are served in `receivedAt` order, so the

191−same 50 events come back every time. The cursor never moves. The client is stuck in a loop.

192−

193−This is a **livelock**: the client polls, processes some events, but can never ack them. The

194−relay keeps serving the same page. The client's error message ("relay sent an oversized poll

195−page") is set but may not be visible in the UI.

196−

197−**Attack scenario:** A malicious relay serves a page of 50 blobs, each just under `MAX_BLOB_LEN`

198−(42 MiB). The total page is ~2 GiB, far exceeding the 64 MiB budget. The client processes a few,

199−drops the rest, and is stuck. Or more subtly: the relay serves 50 blobs that are each ~1.3 MiB

200−(total ~65 MiB, just over the 64 MiB budget). The client processes 49, drops 1, and is stuck

201−because the cursor never advances past the 50th event.

202−

203−**Suggested fix:** When the budget is exhausted, advance the cursor to the last *successfully

204−processed* event's `receivedAt` (not `page.cursor` and not `prev_cursor`). This acks the

205−processed events and lets the client move forward, dropping only the unprocessed tail. The

206−relay re-serves only the unprocessed events on the next poll. This changes the behavior from

207−"all-or-nothing cursor advance" to "partial ack."

208−

209−### 🟡 N10. Profile `ts` staleness check uses `>=` — equal-timestamp replay is a no-op, but the check is per-contact, not per-field

210−

211−**Type:** Implementation concern (app.rs)

212−**Files:** `core/src/app.rs:2174-2179` (approximate)

213−

214−AUDIT-NEW.md Q19 analyzes this and concludes it's safe because the attacker can't modify the

215−content without breaking the signature. I agree — the `>=` is correct and a same-`ts` replay

216−is a true no-op (same ciphertext, same signature, same content). Info.

217−

218−---

219−

220−## 4. Wire Format / Parsing

221−

222−### 🟡 N11. `protocol.rs` `parse_payload` does not validate `ts` is positive — negative `ts` clamped to 0 is harmless but surprising

223−

224−**Type:** Implementation concern (protocol.rs)

225−**Files:** `core/src/protocol.rs:100`

226−

227−AUDIT-NEW.md Q24 notes this. A `ts` of 0 or negative is clamped to `max(0, ...)` in `ingest_poll`.

228−A message with `ts = 0` is inserted at the earliest chronological position and trimmed first.

229−This is harmless. Info.

230−

231−### 🟡 N12. `delivery.ack` parsing accepts non-string entries in `ack_ids` — filtered silently, no length check on individual IDs after filtering

232−

233−**Type:** Implementation concern (protocol.rs)

234−**Files:** `core/src/protocol.rs:116-126`

235−

236−AUDIT-NEW.md Q26 notes this. The double-check (raw count + post-filter count) is correct.

237−Non-string entries are filtered. Individual ID length is checked (`ack_ids.iter().any(|id|

238−id.len() > MAX_ID_LEN)`). This is correct. Info.

239−

240−---

241−

242−## 5. Federation

243−

244−### 🟠 N13. Gossip amplification: 100 online events trigger 100 mailbox scans + forward staging — O(100 × |messages|) per request

245−

246−**Type:** Design gap (server.knot)

247−**Files:** `server.knot:1544-1578` (`handleRecvGossip`)

248−

249−AUDIT-NEW.md Q27 notes this. A single gossip request with 100 `online` events for 100 different

250−keys triggers `forwardQueuedToServer` for each key, which scans the entire mailbox. With

251−|messages| = 10,000, that's 100 × 10,000 = 1M comparisons per request. At 60/min per IP, that's

252−60M comparisons/min. An attacker with 10 IPs can do 600M comparisons/min.

253−

254−Additionally, each `forwardQueuedToServer` call stages forward entries, which consume

255−`maxForwardsPerServer` slots and trigger HTTP POSTs to the attacker's server. The attacker

256−receives copies of the victim's ciphertext.

257−

258−**Suggested fix:** Limit the number of newly-online keys per gossip batch that trigger forwards

259−(e.g., cap at 10). Or batch the mailbox scan across all newly-online keys in one pass.

260−

261−### 🟡 N14. `offline` gossip events don't cancel pending forwards — wasted retries for up to 80 minutes

262−

263−**Type:** Design gap (server.knot)

264−**Files:** `server.knot:1535-1541`

265−

266−AUDIT-NEW.md Q28 notes this. When an `offline` event is received, pending forwards to that server

267−are not cancelled. They retry for up to `retryBackoffMax × maxForwardRetries` = 8 min × 10 = 80

268−minutes, wasting `maxForwardsPerServer` slots and generating failed HTTP requests.

269−

270−If the offline event was spoofed, the forwards continue — and if the key is actually still

271−online at that server, the forward succeeds on retry. The impact is minimal.

272−

273−**Suggested fix:** When processing an `offline` event, optionally drop pending forwards to that

274−server for the offline key. But this could cause message loss if the offline event is spoofed.

275−Better to leave as-is and document.

276−

277−---

278−

279−## 6. Deployment / install.sh

280−

281−### 🟡 N15. `install.sh` downloads binary over HTTPS but checksum is best-effort — missing checksum silently proceeds

282−

283−**Type:** Deployment concern (install.sh)

284−**Files:** `install.sh:150-181`

285−

286−The checksum verification is best-effort: if the `.sha256` file doesn't exist (line 162 fails),

287−the script warns and proceeds. If `sha256sum`/`shasum` is not available, it warns and proceeds.

288−A checksum that exists but doesn't match is fatal (line 169-174) — correct.

289−

290−The concern: a compromised release asset without a published `.sha256` file (e.g., a pre-checksum

291−release, or a supply-chain attack that removes the checksum file) would be installed without

292−verification. The script trusts GitHub's HTTPS, but HTTPS authenticates the CDN, not the

293−artifact. A compromised GitHub release would sail through.

294−

295−**Suggested fix:** Make the checksum mandatory for all new installs. Keep the best-effort

296−behavior only for upgrades from pre-checksum releases, with a prominent warning.

297−

298−### ⚪ N16. `install.sh` DOMAIN validation rejects uppercase but the Caddyfile interpolation is safe

299−

300−**Type:** Deployment review (install.sh)

301−**Files:** `install.sh:34-45`

302−

303−DOMAIN is lowercased and stripped of scheme/path/port before interpolation into the Caddyfile

304−and systemd unit. The validation rejects anything outside `[a-z0-9.-]`. This prevents config

305−injection (a stray quote or semicolon in the Caddyfile). Good.

306−

307−**Verdict:** Safe. Info.

308−

309−---

310−

311−## 7. Apple Shell

312−

313−### ⚪ N17. URLSession redirect cancellation is correct — bearer token exfiltration via 302 is prevented

314−

315−**Type:** Implementation review (Effects.swift)

316−**Files:** `apple/SkrepkaApp/Effects.swift:8-30`

317−

318−The `NoRedirectDelegate` cancels all HTTP redirects. This prevents a hostile relay from

319−answering `/poll` or `/messages` with a 302 to an attacker-controlled host, which would replay

320−the `Authorization: Bearer` header to the redirect target. The delegate returns `nil`, which

321−hands the 3xx response to the caller as a non-2xx status. The core treats it as a failed

322−request. Correct.

323−

324−**Verdict:** Safe. Good defense.

325−

326−### ⚪ N18. Keychain uses `kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly` — key never rides backup

327−

328−**Type:** Implementation review (Effects.swift)

329−**Files:** `apple/SkrepkaApp/Effects.swift:352`

330−

331−The identity key is stored with `ThisDeviceOnly` accessibility, meaning it never enters iCloud

332−or iTunes backups. The key is accessible after first unlock (not only when unlocked), so

333−background polling works. This is the correct accessibility class for a messaging identity key.

334−

335−**Verdict:** Safe. Good practice.

336−

337−---

338−

339−## Summary of New Findings

340−

342−|---|----------|------|-------|

345−| N3 | 🟡 medium | DoS | appendMessage dedup O(n) — identical-blob replay amplifies to O(n × batch) |

348−| N6 | 🔵 low | Info | genToken entropy waste (one digit per call) |

361−

362−**Critical (1):** N1

363−**High (1):** N13

364−**Medium (6):** N3, N4, N5, N7, N9, N14, N15

365−**Low (1):** N6

366−**Info (7):** N2, N8, N10, N11, N12, N16, N17, N18

367−

368−---

369−

370−## Priorities

371−

372−1. **N1 (critical):** Add AAD to AEAD. This is the most impactful finding — it enables

373− undetectable censorship by any relay. Requires wire-format change (v0x02).

374−

375−2. **N13 (high):** Document or limit gossip amplification. A single request triggers 100

376− mailbox scans. Cap newly-online keys that trigger forwards per batch.

377−

378−3. **N9 (medium):** Fix budget exhaustion livelock. Advance cursor to last processed event

379− instead of restoring to pre-page cursor. This prevents a malicious relay from permanently

380− wedging the client with oversized poll pages.

381−

382−4. **N7 (medium):** Bound `seen_ids` set. An unbounded dedup set that's rewritten on every

383− message receipt will degrade performance over time.

384−

385−5. **N3 (medium):** Index `*messages` for dedup. The O(n) scan is a CPU amplification vector.

AUDIT-NEW.mddeleted−816

@@ -1,816 +0,0 @@

1−# Skrepka Security Audit — New Findings (2026-07-15)

2−

3−**Scope:** Exhaustive multi-pass audit of PROTOCOL.md, server.knot, and core/src/ (app.rs, crypto.rs, protocol.rs, model.rs, phonemic.rs, ffi.rs). Findings below are **not** documented in PROTOCOL-REVIEW.md.

4−

5−**Legend:** 🔴 critical · 🟠 high · 🟡 medium · 🔵 low · ⚪ info

6−

7−---

8−

9−## 1. Cryptographic Protocol Weaknesses

10−

11−### 🔴 Q1. HKDF salt omits sender identity — KCI/UKS not prevented by construction

12−

13−**Type:** Design gap (protocol + crypto.rs)

14−**Files:** `core/src/crypto.rs:276-290` (`derive_key`), PROTOCOL.md §3 step 3

15−

16−The HKDF salt is `ephemeral_public || recipient_x25519_public` — both public values, neither identifying the sender. The encryption key is derived entirely from the ephemeral X25519 exchange and the recipient's public key. While the Ed25519 signature inside the AEAD binds the sender, the *key derivation* itself has no sender contribution.

17−

18−This means anyone who knows the recipient's private key can compute the same shared secret from a captured ephemeral public key — there's no sender contribution to the KDF. The signature is the only thing binding the sender, and it's verified *after* AEAD decryption. An attacker who obtains the recipient's private key can decrypt all captured blobs (already noted as "no forward secrecy" in §10), but additionally, because the KDF has no sender binding, an attacker can *replace* the sender identity and signature inside a captured ciphertext by re-encrypting with the same ephemeral key — wait, no, they can't re-encrypt without the shared key. However, if the attacker *has* the recipient's private key, they can decrypt, strip the original sender, forge a new inner buffer with their own sender key + signature over the same `recipient || compressed_len || compressed || padding`, re-encrypt with the derived key, and re-send. The recipient sees a valid message from a different sender. This is a *key compromise impersonation (KCI)* vector: compromising the recipient's key lets an attacker re-attribute captured messages.

19−

20−**Attack scenario:** An attacker records ciphertext between Alice and Bob. Later they compromise Bob's private key. They decrypt the blobs, replace Alice's identity with Mallory's (signing under Mallory's key), re-encrypt, and deliver to Bob. Bob sees messages apparently from Mallory.

21−

22−**Exploitable in practice:** Requires recipient key compromise, which the protocol already considers catastrophic. The KCI vector is an *additional* consequence of that compromise, not a standalone attack. Still, including the sender's public key in the HKDF salt or info would close it by construction.

23−

24−**Suggested fix:** Include `sender_ed25519_public` in the HKDF salt or info: `salt = ephemeral_public || recipient_x25519_public || sender_ed25519_public`. Since the sender pubkey is inside the AEAD, a decryptor already has it before verification, but the key derivation would need it — so the sender pubkey would need to be *outside* the AEAD (as associated data or in the blob header), which changes the wire format. Alternatively, accept this as a documented limitation of v0.1 (the signature already prevents forgery without key compromise).

25−

26−### 🟡 Q2. No associated data (AAD) on AEAD — ciphertext is malleable across contexts

27−

28−**Type:** Design gap (protocol + crypto.rs)

29−**Files:** `core/src/crypto.rs:384-387` (encrypt), `core/src/crypto.rs:434-438` (decrypt)

30−

31−XChaCha20-Poly1305 is used with **no associated data**: `cipher.encrypt(nonce, inner)` and `cipher.decrypt(nonce, ciphertext)`. The version byte, ephemeral public key, and nonce are all in the clear and not authenticated. An attacker who can modify the blob in transit (a malicious relay, or a network attacker without TLS) can flip the version byte or corrupt the ephemeral key without any AEAD failure — the AEAD only protects the ciphertext body.

32−

33−While corrupting these fields will cause decryption/verification to fail downstream (wrong key derivation, wrong version), there's no *cryptographic binding* between the outer envelope fields and the inner ciphertext. A relay could, for example, swap the ephemeral public key from one blob with that of another (keeping the same nonce + ciphertext), and the recipient would get a decryption failure rather than an authentication failure — a distinction that matters for error handling and oracle analysis.

34−

35−More importantly, the `to` field in the envelope is **not** authenticated by the AEAD. A relay can change the `to` field on a stored message, redirecting it to a different recipient. That recipient can't decrypt it (wrong key), but the *original* recipient's message is now gone from the mailbox. This is a denial-of-service vector that doesn't require breaking encryption.

36−

37−**Attack scenario:** A malicious relay swaps the `to` field on Alice's message to Bob, replacing it with Charlie's pubkey. Bob never receives the message. Charlie receives garbage (can't decrypt). Neither side gets an error from the protocol.

38−

39−**Exploitable in practice:** Yes — any relay can do this. However, a relay can already drop messages, so this is equivalent in impact to message loss, which is an accepted limitation.

40−

41−**Suggested fix:** Include `version_byte || ephemeral_public || nonce` as AAD in the AEAD. For the envelope-level `to` field, consider including `recipient_ed25519_public` as AAD (it's already in the signed inner buffer, but AAD would make the envelope integrity-checked too). This is a wire-format change (v0x02).

42−

43−### 🟡 Q3. compressed_len field is attacker-controllable and trusted for slicing

44−

45−**Type:** Implementation concern (crypto.rs)

46−**Files:** `core/src/crypto.rs:449-459`

47−

48−During decryption, `compressed_len` is read from the AEAD-decrypted inner buffer and used to slice the `compressed` region: `let compressed = &inner[100..100 + compressed_len]`. The AEAD protects the integrity of the inner buffer, so this field is authenticated — but only *after* decryption. The check `100 + compressed_len > inner.len()` prevents an out-of-bounds read, but a `compressed_len` that points into the padding region (i.e., `compressed_len < actual_compressed_data_len`) would silently feed truncated zstd data to the decompressor, which would fail. Conversely, `compressed_len > actual_compressed_len` would include padding bytes in the zstd frame, which the decompressor might or might not reject.

49−

50−Since the signature is over `recipient_pub || compressed_len_bytes || compressed || padding`, the signed region includes the `compressed_len` field. A tampered `compressed_len` would break the signature. So this is actually well-protected. The concern is that the signature is verified *after* the `compressed_len` is already used for slicing — but since the slice is only used for decompression *after* signature verification (`crypto.rs:472`), this is safe.

51−

52−**Verdict:** Not a bug after careful analysis — the signature covers `compressed_len` and the decompression happens after verification. Downgraded to info.

53−

54−### ⚪ Q4. zstd decompression bomb window before content-size cap

55−

56−**Type:** Implementation defense-in-depth (crypto.rs)

57−**Files:** `core/src/crypto.rs:303-322`

58−

59−The decompressor caps `window_log_max(21)` (2 MiB window) and output at `MAX_PLAINTEXT_LEN + 1` (1 MiB + 1 byte). This is solid. However, a crafted zstd frame with a small window but very long output (many small blocks) could still cause significant CPU consumption before the 1 MiB + 1 byte limit triggers. The `take(MAX_PLAINTEXT_LEN + 1)` read will read one byte past the cap, forcing a full decompression attempt up to that point. This is bounded at ~1 MiB of output, so CPU is bounded too. This is fine.

60−

61−### 🟡 Q5. CRIME/BREACH surface is wider than documented for profile messages

62−

63−**Type:** Spec gap / design weakness (PROTOCOL.md §3)

64−**Files:** PROTOCOL.md §3, §4; `core/src/protocol.rs:73-91`

65−

66−The spec warns about CRIME/BREACH but says "an attacker cannot make the client re-encrypt a chosen variant of a secret on demand." However, `profile` messages compress `display_name`, `bio`, and `photo` together in one zstd frame. If an attacker can influence part of the profile (e.g., the user sets their display name based on something an attacker controls, like a contact's name echoed back), and the profile is broadcast to contacts, the compressed size could leak information. The attacker would need to:

67−

68−1. Influence part of the plaintext that is compressed alongside a secret

69−2. Observe the resulting blob size (which is bucket-padded, so only the bucket boundary leaks)

70−

71−The padding buckets (256, 512, 1024, ...) are coarse enough that the leak is minimal in practice. But the spec's claim that "an attacker cannot make the client re-encrypt a chosen variant of a secret on demand" is too strong: if an attacker sends messages that cause the user to change their display name or bio (e.g., "change your name to match mine"), the re-broadcast compresses attacker-influenced text alongside the user's photo (which is base64 and thus high-entropy/incompressible). The photo being base64 limits the CRIME surface since it's already nearly random.

72−

73−**Exploitable in practice:** Very unlikely given bucket padding and the difficulty of controlling what text gets compressed alongside secrets.

74−

75−**Suggested fix:** Clarify in the spec that the CRIME/BREACH surface extends to profile broadcasts (where attacker-influenced text and user-controlled secrets are compressed together), not just text messages.

76−

77−---

78−

79−## 2. Server Implementation Bugs

80−

81−### 🟠 Q6. `ackPolledMessages` is called before `doPoll` — races with concurrent sends to the same mailbox

82−

83−**Type:** Implementation bug (server.knot)

84−**Files:** `server.knot:1258-1287` (`handlePoll`), `server.knot:1343-1351` (`ackPolledMessages`)

85−

86−In `handlePoll`, the cursor-ack (`ackPolledMessages`) runs inside the setup atomic block, *before* `doPoll` collects events. If a concurrent `/messages` request arrives between the ack and the collect, the new message is appended with a fresh `receivedAt` that is strictly greater than the acked cursor — so it will be picked up by `doPoll`'s collect. This is actually correct behavior.

87−

88−However, there's a subtler issue: the cursor is clamped to `max(0 (min (max t curSeq) cursor))` before the ack. If the client sends a cursor that is *ahead* of `curSeq` (e.g., from a different relay), the clamp to `max t curSeq` could *lower* the cursor, which means `ackPolledMessages` acks less than the client intended. But this is intentional (the comment explains it).

89−

90−After deeper analysis, the ordering here is actually correct — the ack happens first (deleting old messages), then the collect picks up what's left that's newer than the cursor. The race with concurrent sends is handled by STM: the new message gets a fresh `receivedAt > cursor`, so it's picked up.

91−

92−**Verdict:** Not a bug after careful analysis. Downgraded to info.

93−

94−### 🟡 Q7. `appendMessage` dedup is O(n) per message — quadratic under burst

95−

96−**Type:** Implementation performance issue (server.knot)

97−**Files:** `server.knot:919-937` (`appendMessage`)

98−

99−`appendMessage` checks `any (\\m -> m.toKey == toKey && m.encryptedBlob == encryptedBlob) msgs` — a full scan of `*messages` — on every call. For a batch of 100 messages to different recipients, this is 100 × |messages| comparisons. With `maxMessagesPerRecipient = 10000` and many recipients, this can be tens of thousands of comparisons per message. Under sustained throughput this is quadratic.

100−

101−This is documented in the file header ("Everything is intentionally O(n) over flat lists; performance is sacrificed for clarity"), so it's a known design choice, not a security finding per se. But it creates a **DoS amplification** vector: an authenticated sender can send 100 messages per request (up to 60 requests/min = 6000/min), each triggering a full scan of the mailbox. With 10,000 messages per recipient and many recipients, each scan is O(total_messages), making the CPU cost per request proportional to the entire mailbox size.

102−

103−**Attack scenario:** An attacker authenticates (free — just generate a keypair) and sends 100-message batches of junk to many recipients. Each message in the batch triggers a full `*messages` scan for dedup. With a large mailbox, this can consume significant CPU per request.

104−

105−**Exploitable in practice:** Bounded by rate limits (60/min per IP) and the fact that the attacker must be authenticated. The CPU amplification is real but modest.

106−

107−**Suggested fix:** Index `*messages` by `(toKey, encryptedBlob)` or use a hash-based dedup set.

108−

109−### 🟠 Q8. `maxMessagesPerRecipient` eviction destroys genuine mail under flood

110−

111−**Type:** Design gap (server.knot)

112−**Files:** `server.knot:156-182`, `server.knot:926-937`

113−

114−This is documented in the code comments as a "trade, not a fix," but it constitutes a real attack: an authenticated sender (pubkeys are free to mint) can flood a recipient's mailbox with 10,000 junk messages, pushing out all genuine undelivered messages. The recipient's client only sees junk. The comment says "at least the newest messages always land" — but the newest messages are the *attacker's junk*, not the genuine messages that were already queued.

115−

116−The `MAX_POLL_TOTAL_BYTES` client-side budget (64 MiB) means the client processes a bounded amount per poll, but the server has already destroyed the genuine messages by eviction. The client never sees them.

117−

118−**Attack scenario:**

119−1. Victim is offline for a day. Attacker sends 10,000 messages to victim's pubkey.

120−2. Each message is a valid encrypted blob (attacker generates a keypair and encrypts real messages to the victim — they don't need to be decryptable by the victim, just valid blobs).

121−3. Victim comes online, polls, and gets a page of junk. Their genuine messages were evicted.

122−

123−**Exploitable in practice:** Yes — the attacker needs to be authenticated (free) and send 10,000 messages. At 60 requests/min × 100 messages = 6,000/min, this takes ~2 minutes. The rate limit is per-IP, so the attacker needs multiple IPs or time.

124−

125−**Suggested fix:** This is an accepted design tradeoff in the current implementation. A real fix requires per-sender quotas or pricing. Document it in PROTOCOL.md §10 as a DoS vector, not just a capacity concern.

126−

127−### 🟡 Q9. `capForwards` evicts by retry count, not by age — fresh forwards can be dropped

128−

129−**Type:** Implementation bug (server.knot)

130−**Files:** `server.knot:515-522` (`capForwards`), `server.knot:109-110` (`maxForwardsTotal`)

131−

132−`capForwards` keeps the lowest-retry entries (`take maxForwardsTotal (sortBy (\\f -> f.retries) fwds)`). When the outbox exceeds `maxForwardsTotal = 50000`, the *highest-retry* entries are dropped. The comment says these are "closest to `maxForwardRetries` (about to be abandoned anyway)."

133−

134−But there's a subtle issue: a fresh forward (retries: 0) for a *healthy* peer could be dropped if the outbox is full of fresh forwards (all retries: 0) for *failing* peers. The sort is by `retries` only, not by `retries` then by age or destination health. When many entries share `retries: 0`, the `sortBy` is unstable (Knot's sort may not be stable), so *any* retries-0 entry could be dropped — including one for a healthy peer that would have succeeded on the first try.

135−

136−**Attack scenario:** An attacker floods the forwards outbox by gossipping many fake "online" events, causing `forwardQueuedToServer` to stage forwards for many fake servers. Each fails and increments retries. When `maxForwardsTotal` is reached, genuine forwards for healthy peers may be evicted alongside the junk.

137−

138−**Exploitable in practice:** Requires federation to be enabled and the attacker to be able to reach `/federation/gossip`. The genuine forward would be re-staged on the next presence announce, so the impact is a delivery delay, not permanent loss.

139−

140−**Suggested fix:** Sort by `(retries, age)` or skip entries for peers in backoff before capping.

141−

142−### 🟡 Q10. `genToken` entropy is 4 bits per call — collision-resistant but timing-leaky

143−

144−**Type:** Implementation concern (server.knot)

145−**Files:** `server.knot:532-537`

146−

147−`genToken` generates one hex character per recursive call, drawing from `randomInt 16`. Each call to `randomInt` produces 4 bits. For 48 chars (192 bits), this is 48 calls to `randomInt`. The concern is that `randomInt` on the Knot runtime may not be a CSPRNG — the function signature is `IO {random}` which suggests a runtime-provided random source, but the implementation is not visible here.

148−

149−If `randomInt` uses a non-cryptographic PRNG (e.g., a LCG), the 192-bit tokens would be predictable. The auth challenge tokens and session tokens both use `genToken`. If predictable, an attacker could predict future session tokens after observing some.

150−

151−**Exploitable in practice:** Depends on the Knot runtime's `randomInt` implementation, which is not in this codebase. If it uses `/dev/urandom` or equivalent, this is fine. If it uses a userspace PRNG seeded from a low-entropy source, this is critical.

152−

153−**Suggested fix:** Verify that the Knot runtime's `randomInt` uses a CSPRNG. Document the assumption.

154−

155−### 🟡 Q11. `handleVerifyAuth` challenge lookup is O(n) — timing varies with challenge pool size

156−

157−**Type:** Implementation concern (server.knot)

158−**Files:** `server.knot:1210-1214`

159−

160−The challenge verification does `any (\\c -> same c && c.expiresAt > t && matchIp clientIp c.ip) ch` — a linear scan of `*challenges`. With `maxChallenges = 10000`, this is up to 10,000 comparisons per verify. The timing varies with the position of the matching challenge in the list, which could be observable.

161−

162−Combined with the already-documented token comparison timing side-channel (finding B), this adds another timing channel: the time to find the matching challenge leaks its position in the list, which leaks when it was inserted (roughly when the `/auth/challenge` was called).

163−

164−**Exploitable in practice:** Very low impact — the challenge is consumed immediately after verification, and the timing difference is small relative to network jitter.

165−

166−**Suggested fix:** Index challenges by `(pubkey, challenge)` for O(1) lookup.

167−

168−### 🟡 Q12. `handleVerifyAuth` computes signature verification outside atomic — TOCTOU on challenge

169−

170−**Type:** Implementation gap (server.knot)

171−**Files:** `server.knot:1196-1214`

172−

173−The `sigValid` computation is done outside the atomic block (line 1204-1209), but the challenge lookup is inside the atomic (line 1213). Between computing `sigValid` and the atomic block, the challenge could be consumed by a concurrent `/auth/verify` with the same challenge. But the atomic block re-checks: `any (\\c -> same c && ... && c.expiresAt > t && matchIp clientIp c.ip) ch && sigValid`. The `sigValid` is pre-computed, so the check is: challenge exists AND signature is valid. If the challenge is consumed between the pre-compute and the atomic, the `any` returns false, and the verify fails. This is safe — no TOCTOU.

174−

175−But there's a subtler issue: the `clientIp` for the challenge (set at `/auth/challenge` time) and the `clientIp` for the verify (set at `/auth/verify` time) must match (`matchIp clientIp c.ip`). If the client's IP changes between challenge and verify (mobile network change), the verify fails. This is documented as expected behavior. But if `trustForwardedFor` is true and the client can spoof `X-Forwarded-For`, they could set a different IP on the challenge and verify requests — but they'd need to match, so they'd just set the same spoofed IP on both. This is already documented (finding 8).

176−

177−**Verdict:** Not a new bug. The pre-compute is safe because the atomic block re-validates the challenge's existence.

178−

179−### 🟠 Q13. `revokeOthers` race — concurrent sessions for same pubkey can race on revoke

180−

181−**Type:** Implementation bug (server.knot)

182−**Files:** `server.knot:1219-1231`

183−

184−When `revokeOthers: true`, the handler does:

185−```

186−let pruned = if revokeOthers

187−then filter (\\s -> s.pubkey != pubkey) ses

188−else capPerKey ses pubkey maxSessionsPerKey

189−```

190−

191−This drops *all* other sessions for this pubkey. But if a concurrent `/auth/verify` for the same pubkey is in flight (without `revokeOthers`), it could install a new session between the `filter` and the `union`:

192−

193−1. Verify A (revokeOthers=true) reads `*sessions`, filters out all pubkey sessions → `pruned`

194−2. Verify B (revokeOthers=false) reads `*sessions` (still has the old sessions), adds a new one → commits

195−3. Verify A commits `pruned + newSession` → Verify B's session is lost

196−

197−But wait — both are inside `atomic` blocks, and STM guarantees serializability. If Verify A's atomic block retries after Verify B commits, Verify A re-reads `*sessions` (now including B's session) and re-applies the filter — so B's session would be dropped. This is actually the *intended* behavior of `revokeOthers`: it should drop all other sessions. The "race" is really just STM serializing correctly.

198−

199−**Verdict:** Not a bug. STM handles this correctly. Downgraded to info.

200−

201−### 🟡 Q14. `pruneExpired` presence offline gossip may miss peers that expired in a prior sweep

202−

203−**Type:** Implementation concern (server.knot)

204−**Files:** `server.knot:1614-1633` (`backgroundPrune`)

205−

206−The prune loop snapshots peers *before* the sweep (`prePeers`) and unions with *post-sweep* peers. But `pruneExpired` returns only locally-expired keys that have no other live local session. If a key expired in a *previous* sweep (and was already removed from `*presence`), the current sweep has nothing to return for it. The offline gossip for that key was already sent in the previous sweep. This is correct — each key gets exactly one offline event.

207−

208−**Verdict:** Not a bug. The pre/post union handles the edge case correctly.

209−

210−### 🟡 Q15. `forwardQueuedToServer` budget check reads `*forwards` count but doesn't reserve atomically

211−

212−**Type:** Implementation concern (server.knot)

213−**Files:** `server.knot:1140-1151`

214−

215−`forwardQueuedToServer` computes `budget = max 0 (maxForwardsPerServer - existing)` where `existing = countWhere (\\f -> f.toServer == server) fwds`, then takes `take budget` candidates and unions them into `*forwards`. The whole thing is inside one `atomic` block, so it's serializable — two concurrent calls would serialize, and the second would see the first's additions. This is correct.

216−

217−**Verdict:** Not a bug. STM handles concurrency correctly.

218−

219−---

220−

221−## 3. Client Core Logic Bugs

222−

223−### 🟠 Q16. `ingest_poll` cursor clamping uses `now_ms() + 60_000` — relay can advance cursor beyond actual messages

224−

225−**Type:** Implementation concern (app.rs)

226−**Files:** `core/src/app.rs:1967-1975`

227−

228−The cursor is clamped to `page.cursor.min(now_ms().saturating_add(60_000))`. If a hostile relay sends `cursor = now_ms() + 59_000`, the client accepts it, writes it to disk, and the next poll sends this cursor to the relay. If the client later switches to a *different* relay, the cursor is reset to 0 (line 868) — so this is per-relay and not cross-relay. But on the *same* relay, a hostile relay can send an artificially high cursor, causing the client to ack (delete) all messages up to that cursor on the next poll — even messages the client hasn't seen yet.

229−

230−Wait — the cursor is what the *client* sends to the *server*. The server uses it to ack (delete) messages ≤ cursor. If a relay sends a high cursor in the poll response, the client adopts it and sends it back on the next poll. The relay then deletes everything ≤ that cursor. If there were messages the client never received (because the relay withheld them), they're now permanently lost.

231−

232−But the relay already controls what messages it sends to the client — it could simply withhold messages and never show them. The cursor doesn't give the relay any new power it doesn't already have. The relay can always just not send events. So this is not a new attack vector.

233−

234−However, there's a subtler issue: the cursor is persisted to disk. If the relay sends a high cursor and the client adopts it, then the client reconnects to the same relay after a network interruption, the cursor is still high. Any messages that arrived at the relay during the interruption (with `receivedAt` ≤ the poisoned cursor) are automatically acked and deleted.

235−

236−**Attack scenario:** A malicious relay sends `cursor = now_ms() + 59000` in an empty poll response. The client adopts it and persists it. Later, legitimate messages arrive at the relay with `receivedAt` values below the poisoned cursor. The client's next poll sends the poisoned cursor, and the relay deletes those messages.

237−

238−But wait — the relay assigns `receivedAt` using its own monotonic sequence. If the relay is malicious, it can just not deliver messages. If it's honest but was briefly compromised, the poisoned cursor could cause message loss after recovery. This is a real concern for the "briefly compromised relay" scenario.

239−

240−**Exploitable in practice:** A compromised relay can cause permanent message loss for messages that arrive during the compromise window. The 60-second clamp limits the window, but the cursor persists across reconnections.

241−

242−**Suggested fix:** Only adopt the cursor if the poll response contained events. If `events` is empty and `cursor > model.cursor`, don't advance the cursor — the relay has nothing to tell us, and a cursor advance from an empty page is suspicious.

243−

244−### 🟡 Q17. Delivery ack staleness check uses `ts` not `last_ack_ts` watermark for ordering — race with clock skew

245−

246−**Type:** Implementation concern (app.rs)

247−**Files:** `core/src/app.rs:2116-2134`

248−

249−The ack staleness check compares `ts < c.last_ack_ts`. If two acks arrive in the same poll page from the same sender, with `ts_A = 100` and `ts_B = 200`, and `last_ack_ts = 50`:

250−- Ack A (ts=100): not stale (100 >= 50), applies, sets `last_ack_ts = min(100, now)`

251−- Ack B (ts=200): not stale (200 >= 100), applies, sets `last_ack_ts = min(200, now)`

252−

253−This is correct. But if the page order is reversed (B before A), and `last_ack_ts = 50`:

254−- Ack B (ts=200): not stale, applies, sets `last_ack_ts = min(200, now)`

255−- Ack A (ts=100): stale (100 < min(200, now)), dropped!

256−

257−This means an older ack in the same page as a newer one is dropped if it's processed after the newer one. Since the events are processed in page order (not sorted), a relay could reorder events to cause an older ack to be dropped. The impact is minimal — the older ack would have acked fewer or the same messages.

258−

259−**Exploitable in practice:** A malicious relay could reorder events to suppress a specific ack, but it could also just drop the event entirely. Low impact.

260−

261−**Suggested fix:** Process acks in `ts` order within a page, or collect all acks from a sender and apply the highest-ts one.

262−

263−### 🟡 Q18. `seen_ids` dedup set is built lazily from conversation — misses messages trimmed by `MAX_MESSAGES_PER_PEER`

264−

265−**Type:** Implementation bug (app.rs)

266−**Files:** `core/src/app.rs:2086-2092`

267−

268−The dedup set is built from the current conversation: `convo.iter().map(|m| m.id.clone()).collect()`. But `trim_history` may have aged out older messages (keeping only the most recent 1000). A replayed message whose `id` matches an aged-out message would pass the dedup check and be re-inserted into the conversation. The message would appear as a new message (with its original `ts`), potentially at the top of the conversation list if `ts` is high.

269−

270−**Attack scenario:** An attacker captures a message blob (by being a relay, or by gossip redirect), waits until the recipient's conversation has been trimmed past that message (1000+ messages later), then replays the blob. The dedup check misses it (the `id` is no longer in the trimmed conversation), and the message is re-inserted. The message appears as a new old-dated message.

271−

272−**Exploitable in practice:** Requires the attacker to have captured the blob and to wait for 1000+ messages. The replayed message would be inserted at its original `ts` position, so it wouldn't appear at the bottom of the chat — it would appear in its chronological position. The user might not notice. The impact is minimal — it's an old message reappearing, not new content.

273−

274−**Suggested fix:** Maintain a persistent dedup set (not derived from the trimmed conversation), or store the set of seen IDs separately from the message history.

275−

276−### 🟡 Q19. Profile `ts` staleness check uses `>=` — equal-timestamp replay overwrites with identical content (harmless) but also overwrites with *different* content if sender crafts it

277−

278−**Type:** Implementation concern (app.rs)

279−**Files:** `core/src/app.rs:2174-2179`

280−

281−The profile staleness check uses `ts >= c.last_profile_ts`, meaning a replayed profile at the *same* `ts` is accepted. The comment says "a replayed profile at the same `ts` overwrites with identical content, which is a no-op in practice." But this assumes the replayed blob has the same content. An attacker who captures a profile blob can modify the *inner* content (display_name, bio, photo) and re-encrypt it with the same `ts` — but they'd need to sign it, and they can only sign with their own key. The recipient would see it coming from the same sender (the original profile sender), but the signature would be from the original sender's key... wait, no. The attacker can't re-sign with the original sender's key unless they have it.

282−

283−Actually, the attacker *replays the exact same blob* — same ciphertext, same inner content, same signature. The `ts` is the same, and the content is the same. So it's truly a no-op. The attacker can't modify the content without breaking the signature. This is safe.

284−

285−**Verdict:** Not a bug. The `>=` is correct and the replay is a true no-op.

286−

287−### 🟡 Q20. `flush_next` batch-building skips items for different recipients — outbox may have interleaved items stuck behind a large batch

288−

289−**Type:** Implementation concern (app.rs)

290−**Files:** `core/src/app.rs:1818-1853`

291−

292−The batch stops at the first recipient change (`if recipient.as_ref().is_some_and(|r| r != &item.recipient) { break }`). If the outbox has items for recipient A followed by items for recipient B, and A's batch is being built, B's items wait. This is by design (FIFO fairness). But if A's send fails repeatedly, B's items are stuck behind A's retries. The `retry_batch` function charges retries and eventually drops A's items (after `MAX_OUTBOX_RETRIES` or `OUTBOX_TTL_MS`), unblocking B.

293−

294−This is correct behavior, not a bug. The FIFO ordering ensures fairness at the cost of head-of-line blocking, which is the right tradeoff for a messaging app (you don't want a failed send to one peer to reorder sends to another).

295−

296−**Verdict:** Not a bug. Downgraded to info.

297−

298−### 🟡 Q21. `encrypt_for` uses `OsRng` — no deterministic test path, but also no RNG failure handling

299−

300−**Type:** Implementation concern (app.rs)

301−**Files:** `core/src/app.rs:2227-2231`

302−

303−`encrypt_for` uses `let mut rng = rand_core::OsRng;` and passes it to `crypto::encrypt`. If `OsRng` fails (e.g., the OS entropy pool is exhausted on a freshly booted device), `rng.fill_bytes` would panic or return an error. `crypto::encrypt` calls `rng.fill_bytes` in multiple places (`eph_priv`, `padding`, `nonce`), and these would propagate the error up as `CryptoError::Encrypt` (since `fill_bytes` on `OsRng` infallibly fills — it uses `/dev/urandom` which never blocks on modern systems).

304−

305−**Verdict:** `OsRng` is infallible on iOS/macOS (it uses `SecRandomCopyBytes` which always succeeds). Not a bug.

306−

307−---

308−

309−## 4. Wire Format / Parsing Issues

310−

311−### 🟠 Q22. `isValidHex` uses `chars` (set semantics) — deduplication hides length-based attacks

312−

313−**Type:** Implementation bug (server.knot)

314−**Files:** `server.knot:542-545`

315−

316−```knot

317−isValidHex = \s ->

318− let n = length s in

319− n > 0 && n / 2 * 2 == n && all (\c -> contains c "0123456789abcdef") (chars s)

320−```

321−

322−`chars s` returns the **distinct** character set (relations dedupe). So for a string like `"aaaa"`, `chars` returns `{"a"}`, and the `all` check passes. The `length` check (`n / 2 * 2 == n`) ensures even length. But `chars` deduplication means the `all` check is O(distinct chars) not O(string length), which is a performance optimization, not a correctness issue — the set membership test covers all characters.

323−

324−This is actually correct: if all *distinct* characters are in the hex alphabet, then all characters are in the hex alphabet. The dedup just makes it faster.

325−

326−**Verdict:** Not a bug. The set semantics are correct for membership checking.

327−

328−### 🟡 Q23. `PubkeyHex` type accepts non-curve-point 32-byte hex values at the route boundary

329−

330−**Type:** Implementation gap (server.knot)

331−**Files:** `server.knot:322` (`type PubkeyHex = Text where isValidExactHex 64`)

332−

333−The `PubkeyHex` type only checks that the string is 64 lowercase hex characters — it doesn't verify the decoded bytes form a valid Ed25519 public key (a valid curve point). The client's `try_parse_pubkey` (`phonemic.rs:140-144`) does check this via `VerifyingKey::from_bytes`, but the server accepts any 64-hex-char string as a valid `PubkeyHex`.

334−

335−This means a client can send a message to a `to` address that is 32 bytes of hex but not a valid Ed25519 public key. The server stores and forwards the blob. The "recipient" can never decrypt it because `ed25519_pk_to_x25519` would fail on the invalid key. The blob sits in the mailbox until TTL expiry, consuming storage.

336−

337−**Attack scenario:** An attacker sends 100 messages per batch to invalid pubkeys. Each is stored for 30 days. With 60 requests/min × 100 = 6000/min, after 1 hour that's 360,000 junk messages. Each counts against `maxMessagesPerRecipient` for the target — but the target is a non-existent key, so nobody is affected. The real concern is storage consumption: 360,000 × minBlobLen bytes = ~62 MB per hour per attacker IP.

338−

339−**Exploitable in practice:** The rate limit (60/min per IP) bounds the rate. The 30-day TTL bounds the total. `maxMessagesPerRecipient = 10000` per non-existent key limits per-key. The total storage impact is bounded.

340−

341−**Suggested fix:** The server could optionally validate that `to` is a valid curve point, but this adds CPU cost and the spec doesn't require it (the server can't decrypt anyway). Document as accepted.

342−

343−### 🟡 Q24. `parse_payload` `ts` field defaults to 0 when missing — allows pre-epoch ordering manipulation

344−

345−**Type:** Implementation concern (protocol.rs)

346−**Files:** `core/src/protocol.rs:100`

347−

348−`let ts = v.get("ts").and_then(|t| t.as_i64()).unwrap_or(0);`

349−

350−If a peer omits the `ts` field (or sets it to a non-integer), it defaults to 0. In `ingest_poll`, `ts` is clamped: `parsed.ts.max(0).min(now.saturating_add(MAX_FUTURE_SKEW_MS))`. A `ts` of 0 passes the `max(0)` check and is used as-is. A message with `ts = 0` would be inserted at position 0 in the conversation (earliest), and `trim_history` would age it out first. This is harmless.

351−

352−But a peer could set `ts` to a very large negative number (e.g., `i64::MIN`), which would be clamped to 0. Same result. Or a peer could set `ts` to a float (e.g., `1.5`), which `as_i64()` returns `None` for, defaulting to 0. All of these are harmless because the clamping handles them.

353−

354−**Verdict:** Not a bug. The clamping in `ingest_poll` handles all edge cases.

355−

356−### 🟡 Q25. JSON parsing of poll response uses `unwrap_or_default()` — malformed JSON silently produces empty page

357−

358−**Type:** Implementation concern (app.rs)

359−**Files:** `core/src/app.rs:1309`

360−

361−`let parsed: PollResp = serde_json::from_slice(&bytes).unwrap_or_default();`

362−

363−If the relay sends malformed JSON (or a valid JSON with wrong types), this silently defaults to an empty `PollResp` (empty events, cursor 0). The cursor of 0 would be adopted (clamped), and the next poll would re-fetch from the beginning — re-receiving all messages the client has already seen. The client's dedup (by `id` for text, by `ts` for acks and profiles) would handle the duplicates, but it wastes bandwidth and CPU.

364−

365−A hostile relay could exploit this by sending malformed JSON instead of a real response, forcing the client to re-poll from cursor 0 repeatedly. But the client would just re-process old messages (all deduped) and eventually get the real cursor from a subsequent response. The impact is wasted bandwidth, not data loss.

366−

367−**Suggested fix:** If JSON parsing fails, don't adopt the cursor and back off instead of treating it as an empty page.

368−

369−### 🟡 Q26. `delivery.ack` ack_ids filtering silently drops non-string entries — count vs. filtered count mismatch

370−

371−**Type:** Implementation concern (protocol.rs)

372−**Files:** `core/src/protocol.rs:116-126`

373−

374−The ack_ids parsing filters non-string entries: `raw.iter().filter_map(|x| x.as_str().map(str::to_string)).collect()`. The raw count check (`raw.len() > MAX_ACK_IDS`) happens before filtering, but the post-filter check (`ack_ids.len() > MAX_ACK_IDS`) also happens. However, between the two checks, a peer could pack an array with `MAX_ACK_IDS` entries, some of which are non-strings (e.g., numbers). The raw check passes (`MAX_ACK_IDS` entries), the filter drops some, and the post-check passes (fewer than `MAX_ACK_IDS` strings). This is correct — the filtered count is what matters.

375−

376−But there's a subtlety: a peer could pack `MAX_ACK_IDS + 1` raw entries, all non-strings. The raw check fails (`MAX_ACK_IDS + 1 > MAX_ACK_IDS`), and the payload is dropped. But if the peer packs `MAX_ACK_IDS` raw entries, all non-strings, the raw check passes, the filter drops all of them, and `ack_ids` is empty. The empty ack is then sent to the sender, who processes it (marking nothing as delivered). This is harmless.

377−

378−**Verdict:** Not a bug. The double-check handles this correctly.

379−

380−---

381−

382−## 5. Federation Protocol Issues

383−

384−### 🟠 Q27. Gossip amplification — single `online` event triggers forward of *all* queued messages for a key

385−

386−**Type:** Design gap (server.knot)

387−**Files:** `server.knot:1522-1556` (`handleRecvGossip`)

388−

389−When a `online` event arrives for a key, `forwardQueuedToServer` sweeps the entire mailbox for messages to that key and stages them for forwarding. An attacker can send a single gossip request with 100 `online` events for 100 different keys, each triggering a full mailbox scan and forward staging. This is O(100 × |messages|) per request.

390−

391−More importantly, the attacker can repeatedly send `online` events for the same key. Each time, `forwardQueuedToServer` checks `notYetForwarded` and `notYetDelivered` to avoid duplicates, so re-sending the same event is a no-op for already-forwarded messages. But if the forward failed (404 from the attacker's own server, which doesn't actually have the key online), the forward entry stays in `*forwards` with `retries: 0`. A re-announce doesn't re-stage it (it's already in `*forwards`), but `retryPendingForwards` will retry it on the next sweep.

392−

393−The amplification is: one gossip request (100 events) → 100 mailbox scans + potentially 100 forward entries. Each forward entry triggers an HTTP POST to the `fromServer`. If the `fromServer` is the attacker, they receive 100 forwarded blobs — each a copy of the victim's ciphertext. This is the same as the documented gossip-redirect attack (#2), but the amplification factor (100 events per request) is not documented.

394−

395−**Exploitable in practice:** Same as finding #2, but with 100× amplification per request. The rate limit (60/min per IP) bounds the rate to 6,000 redirected keys per minute per IP.

396−

397−**Suggested fix:** Document the amplification factor. Consider limiting the number of newly-online keys per gossip batch that trigger forwards.

398−

399−### 🟡 Q28. Federation `offline` events don't trigger cleanup of pending forwards

400−

401−**Type:** Design gap (server.knot)

402−**Files:** `server.knot:1535-1541`

403−

404−When an `offline` event is received, the presence row for that `(pubkey, fromServer)` is removed, but pending forwards to that server are *not* cancelled. The forwards stay in `*forwards` and will be retried by `retryPendingForwards` until they either succeed (unlikely — the key is offline at that server), fail 10 times, or the message TTL expires.

405−

406−If the offline event was legitimate (the key actually went offline at that server), the forwards will waste retry attempts for up to `retryBackoffMax × maxForwardRetries` = 8 min × 10 = 80 minutes. During that time, the forwards occupy slots in `maxForwardsPerServer` and `maxForwardsTotal`.

407−

408−If the offline event was spoofed by an attacker (to clear a presence row), the forwards are still retried — and if the key is actually still online at that server, the forward succeeds on retry (the `no_presence` gate would pass because the key has a local session). But the presence row was removed, so `hasLocalPresence` at the peer would fail... wait, the presence row is on *our* side. The peer's presence is independent. The forward goes to the peer, and the peer checks its own local presence. If the key is still online at the peer, the forward succeeds. If not, it gets 404 and is retried.

409−

410−**Exploitable in practice:** An attacker can send fake `offline` events to clear presence rows, but the forwards continue independently. The impact is minimal — presence rows and forwards are decoupled.

411−

412−**Suggested fix:** When processing an `offline` event, optionally drop pending forwards to that server for the offline key (they'll never succeed if the key is truly offline there). But this could cause message loss if the offline event is spoofed. Better to leave as-is.

413−

414−### 🟡 Q29. `fromServer` in gossip events is not verified against the connecting peer's actual address

415−

416−**Type:** Design gap (server.knot)

417−**Files:** `server.knot:1511-1556` (`handleRecvGossip`)

418−

419−The `fromServer` field is a `ServerName` (validated for format), but it's not verified against the actual IP address of the connecting peer. An attacker can connect from IP `1.2.3.4` and claim `fromServer: "legit-relay.example.com"`. The server writes presence rows with `server: "legit-relay.example.com"` and forwards queued messages there. This is the same as the documented gossip-redirect attack (#2), but with a twist: the attacker can claim to *be* a legitimate relay, poisoning the presence table with the legitimate relay's hostname.

420−

421−When the *real* `legit-relay.example.com` later gossips, its events update the presence rows. But the attacker's rows may still be present (different `expiresAt`), and the server has multiple presence rows for the same key on different servers — which is by design. The attacker's row points to `legit-relay.example.com`, so forwards go to the legitimate relay, which doesn't have the key online — and returns 404. The legitimate relay gets junk forward requests.

422−

423−**Exploitable in practice:** This is a variant of the documented gossip-redirect, but with the attacker impersonating a legitimate relay. The legitimate relay receives spurious forward requests (bounded by `forwardRateLimit`).

424−

425−**Suggested fix:** Verify that the connecting peer's IP resolves to the claimed `fromServer` hostname (reverse DNS + forward DNS). This is the standard check for SMTP-like protocols. Blocked on `fetch` not exposing DNS.

426−

427−---

428−

429−## 6. Rate Limiting / DoS Vectors

430−

431−### 🟠 Q30. `/auth/challenge` has no per-pubkey rate limit beyond `maxChallengesPerKey = 5`

432−

433−**Type:** Design gap (server.knot)

434−**Files:** `server.knot:1166-1188` (`handleChallenge`)

435−

436−The challenge pool is globally capped at `maxChallenges = 10000` and per-key at `maxChallengesPerKey = 5`, with per-IP rate limiting at `authRateLimit = 60/min`. An attacker with many IPs (or behind a proxy with XFF spoofing when `trustForwardedFor = true`) can fill the challenge pool with challenges for random pubkeys. Each challenge is 60 seconds, and the pool LRU-evicts. But 10,000 challenges × 60 seconds means the pool is always full, and legitimate challenges are evicted.

437−

438−The comment says this is handled by LRU eviction: "an abandoned challenge may be dropped before its 60 s window elapses, which costs the affected client one retry." So the attacker can cause clients to retry their challenge/verify flow, adding latency but not blocking authentication.

439−

440−**Exploitable in practice:** With XFF spoofing (finding 8), the attacker gets unlimited rate-limit buckets. 60/min per IP × many IPs = thousands of challenges per minute. The pool (10,000) fills in ~3 minutes. After that, legitimate challenges are evicted, and clients must retry. This is a soft DoS — authentication still works but with extra latency.

441−

442−**Suggested fix:** Add a global rate on challenge creation (not just per-IP). Or cap the challenge creation rate per second regardless of source.

443−

444−### 🟡 Q31. `/messages` batch of 100 × 40 MiB would be rejected by body cap, but the rate limit counts requests not messages

445−

446−**Type:** Design gap (server.knot)

447−**Files:** `server.knot:233-234` (`sendRateLimit`), `server.knot:454` (`sendLimit`)

448−

449−The send rate limit is 60 requests/min per IP. Each request can carry up to 100 messages (bounded by the body cap). So the effective message rate is 60 × (body_cap / avg_blob_size) per minute. With a 42 MiB body cap and 42 KiB blobs, that's ~1000 messages per request × 60 = 60,000 messages/min. With 173-byte minimum blobs, it's ~251,000 messages/min per IP.

450−

451−This is documented in the code comment ("the effective message ceiling is higher"), but it means the per-IP rate limit is much less protective than it appears. An attacker with 10 IPs can send millions of messages per minute.

452−

453−**Exploitable in practice:** Bounded by the body cap (42 MiB) and the rate limit (60/min). The total data rate per IP is ~42 MiB × 60 = 2.5 GiB/min, which is significant.

454−

455−**Suggested fix:** Consider a per-message rate limit in addition to the per-request rate limit. Or reduce `maxBatchSize` for unauthenticated senders (but all senders are "authenticated" — they just have free keypairs).

456−

457−### 🟡 Q32. `maxSessions = 10000` LRU eviction is Sybil-floodable — documented but not in PROTOCOL.md §10

458−

459−**Type:** Design gap (server.knot)

460−**Files:** `server.knot:117-126`

461−

462−The code comment documents this: "global LRU eviction is Sybil-floodable: an attacker with enough IPs can evict live users' sessions." But it's not mentioned in PROTOCOL.md §10 as a DoS vector. An attacker with enough IPs can:

463−1. Generate 10,000 keypairs

464−2. Authenticate each one (60/min per IP, so ~167 IPs needed for one batch)

465−3. Fill the session pool

466−4. Legitimate users' sessions are evicted (they get 401 and must re-authenticate)

467−

468−This is a soft DoS — users re-authenticate automatically. But it adds latency and load.

469−

470−**Suggested fix:** Document in PROTOCOL.md §10. Consider per-IP session caps (rejected in the code comment as "collapses without XFF, punishes carrier-NAT") or a global session creation rate limit.

471−

472−### 🟡 Q33. `maxPresence = 100000` — gossip can fill presence table with fake keys

473−

474−**Type:** Design gap (server.knot)

475−**Files:** `server.knot:139-155`

476−

477−An attacker can send gossip with 100 fake `online` events per request (60/min per IP). Each event adds a presence row. With `maxPresencePerServer = 5000` per peer, a single attacker IP can add 5000 rows. With `maxPresence = 100000` globally, it takes 20 distinct attacker hostnames to fill the pool. Once full, legitimate presence rows are evicted by `capList` (LRU by `expiresAt`).

478−

479−Since gossip rows have `onlineGossipTtl = 90 min` and local rows have `sessionExpiry = 60 min`, local rows are evicted first (they expire sooner). The code handles this by exempting local rows from the cap:

480−

481−```

482−let localRows = filter (\\p -> isLocalServer p.server) merged

483−let remoteRows = filter (\\p -> not isLocalServer p.server) merged

484−*presence = union localRows (capList (capPerServer remoteRows from maxPresencePerServer) maxPresence)

485−```

486−

487−So local rows are always kept, and only remote (gossiped) rows are capped. An attacker can fill the remote pool, but local users' presence is never evicted. The impact is that legitimate *remote* presence (from honest peers) is evicted, causing forwards to those peers to fail.

488−

489−**Exploitable in practice:** Requires federation to be enabled and many distinct attacker hostnames (each passing `isBadServerName`). Bounded by `maxPresencePerServer = 5000` per hostname.

490−

491−**Suggested fix:** Document in PROTOCOL.md §10. Consider a per-request limit on newly-added presence rows (currently capped at `maxGossipEvents = 100` per request, which is already a bound).

492−

493−---

494−

495−## 7. Authentication / Session Management

496−

497−### 🟠 Q34. Session token is not bound to the pubkey — token theft grants full impersonation

498−

499−**Type:** Design gap (server.knot)

500−**Files:** `server.knot:356` (`type Session = {token: Text, pubkey: PubkeyHex, expiresAt: Timestamp, ip: Text}`)

501−

502−The session token is a bearer token — anyone who has it can use it. It's bound to `(pubkey, ip, expiry)`, but the `pubkey` binding is only used for *authorization* (e.g., rejecting self-sends), not for *authenticating the request*. The `authedPubkey` function looks up the token and returns the associated pubkey — it doesn't verify that the requester is the same entity that originally authenticated.

503−

504−If an attacker steals a bearer token (e.g., from a compromised proxy's access log), they can use it from the same IP (or any IP if `trustForwardedFor = false` or IP binding is disabled) to poll the victim's mailbox and send messages as the victim.

505−

506−The IP binding (`matchIp`) is the only thing preventing token replay from a different IP. But:

507−- If `trustForwardedFor = false`, IP binding is disabled (empty IP → wildcard).

508−- If the attacker is behind the same NAT/proxy as the victim, they share the IP.

509−- The token is sent in `Authorization: Bearer ***` over HTTP (TLS in production), so it's only protected by TLS.

510−

511−**Attack scenario:** A compromised proxy logs the `Authorization` header. The attacker uses the token from the same IP (or any IP if XFF is off) to poll the victim's mailbox and read their (encrypted) messages. The attacker can also send messages as the victim.

512−

513−**Exploitable in practice:** Requires token theft (compromised proxy, log exposure, or MITM without TLS). The E2E encryption means the attacker can't read message content, but they can send messages as the victim (the server doesn't verify the sender's identity on `/messages` — it only uses the bearer token's pubkey for self-send rejection).

514−

515−**Suggested fix:** This is inherent to bearer-token auth. The spec should document that a stolen bearer token grants full impersonation (modulo IP binding) until it expires (1 hour). Consider shorter token lifetimes or per-request signing.

516−

517−### 🟡 Q35. `revokeOthers: true` doesn't revoke challenges — stale challenge can be used to create a new session after revocation

518−

519−**Type:** Implementation gap (server.knot)

520−**Files:** `server.knot:1217-1221`

521−

522−When `revokeOthers: true`, the handler drops all other sessions for the pubkey, but it does *not* drop outstanding challenges for the pubkey. A challenge issued before the `revokeOthers` call is still valid for 60 seconds. An attacker who captured a challenge (e.g., by observing the `/auth/challenge` response) can still complete the `/auth/verify` flow and get a new session — after the `revokeOthers` call.

523−

524−But wait — the `/auth/verify` handler also checks the challenge's IP binding (`matchIp clientIp c.ip`). If the attacker is on a different IP, the verify fails. If they're on the same IP (NAT/proxy), it succeeds. And the new session is *not* revoked by the `revokeOthers` call (it was made after the call).

525−

526−**Attack scenario:**

527−1. Alice requests a challenge (IP 1.2.3.4)

528−2. Attacker captures the challenge response (from a compromised proxy)

529−3. Alice calls `/auth/verify` with `revokeOthers: true` (to log out other devices)

530−4. Attacker uses the captured challenge to call `/auth/verify` from IP 1.2.3.4 (same NAT)

531−5. Attacker gets a new session — not revoked by step 3

532−

533−**Exploitable in practice:** Requires the attacker to be on the same IP as the victim and to have captured the challenge. The 60-second challenge expiry limits the window.

534−

535−**Suggested fix:** When `revokeOthers: true`, also drop outstanding challenges for the pubkey.

536−

537−### 🟡 Q36. Challenge IP binding uses `clientIpOf` which reads XFF — same spoofing surface as session IP binding

538−

539−**Type:** Implementation gap (server.knot)

540−**Files:** `server.knot:1180-1188` (`handleChallenge`), `server.knot:781-784` (`clientIpOf`)

541−

542−The challenge's `ip` is set to `clientIpOf xForwardedFor`, which is the last XFF hop when `trustForwardedFor` is true. If the attacker can spoof XFF (finding 8), they can set any IP on the challenge, and then use the same spoofed IP on the verify — bypassing the IP binding entirely.

543−

544−This is the same XFF spoofing issue already documented (finding 8), but it applies to the challenge IP binding as well. The challenge IP binding is supposed to prevent a challenge obtained by a relay from being used by a different client — but with XFF spoofing, this protection is nullified.

545−

546−**Verdict:** Same as finding 8. Not a new issue, but the challenge IP binding is an additional affected surface.

547−

548−### 🟡 Q37. No rate limit on `/auth/verify` failures — unlimited signature verification attempts

549−

550−**Type:** Design gap (server.knot)

551−**Files:** `server.knot:475` (`authLimit = 60/min`)

552−

553−The `/auth/verify` route shares the `authLimit` (60/min per IP) with `/auth/challenge`. An attacker can attempt 60 signature verifications per minute per IP. Each verification is an Ed25519 signature check, which is relatively expensive (~0.1ms). 60/min = ~0.01 CPU-seconds/min — negligible.

554−

555−But the attacker doesn't need to *succeed* at verification to cause work. Each `/auth/verify` call triggers:

556−1. Hex decode of pubkey (32 bytes) and signature (64 bytes)

557−2. Ed25519 signature verification (expensive: ~0.1ms)

558−3. Linear scan of `*challenges` (up to 10,000 entries)

559−

560−The challenge scan only happens if the signature is valid (short-circuit), so a failed signature still costs the Ed25519 verification. With 60/min per IP and many IPs, the attacker can cause non-trivial CPU load.

561−

562−**Exploitable in practice:** Bounded by rate limits. The Ed25519 verification is fast. Not a practical DoS vector.

563−

564−**Suggested fix:** Consider returning 401 immediately if no matching challenge exists (before verifying the signature), to save the expensive verification when the challenge is invalid. Currently the order is: check challenge exists AND signature valid, with `sigValid` pre-computed. If the challenge doesn't exist, the `any` short-circuits and `sigValid` is never used — but `sigValid` was already computed outside the atomic. So the CPU cost is paid regardless. Move the signature verification inside the atomic block, after the challenge existence check, to short-circuit on missing challenges.

565−

566−Wait, actually looking at the code more carefully:

567−

568−```knot

569−let sigValid = case bytesFromHex pubkey of ... -- computed OUTSIDE atomic

570−result <- atomic (do

571− ...

572− let valid = any (\\c -> same c && ...) ch && sigValid -- sigValid used here

573−```

574−

575−`sigValid` is pre-computed, so the Ed25519 verification happens on every `/auth/verify` call regardless of whether a matching challenge exists. This is a CPU waste. If the challenge doesn't exist, the `any` returns false and `sigValid` is irrelevant — but the CPU was already spent.

576−

577−**Suggested fix:** Move the signature verification inside the atomic block, after the challenge existence check. Or compute it lazily (only if the challenge exists).

578−

579−### 🟡 Q38. `handleVerifyAuth` logs session eviction count but not the attacker — no audit trail for Sybil floods

580−

581−**Type:** Implementation gap (server.knot)

582−**Files:** `server.knot:1240`

583−

584−The handler logs `logWarn ("session pool full: evicted N session(s)...")` but doesn't log the pubkey or IP of the request that caused the eviction. An operator investigating a Sybil flood would see warnings but not know which pubkeys or IPs are responsible. This makes it hard to block the attacker.

585−

586−**Suggested fix:** Include the requesting pubkey and IP in the log message.

587−

588−---

589−

590−## 8. Spec Gaps

591−

592−### 🟡 Q39. Spec doesn't specify behavior for empty `encryptedBlob`

593−

594−**Type:** Spec gap (PROTOCOL.md §4)

595−**Files:** PROTOCOL.md §4 (Envelope), `server.knot:319-320` (`isValidBlobHex`)

596−

597−The spec says `encryptedBlob` is "Hex-encoded blob from §3" but doesn't say what happens if it's empty or shorter than `minBlobLen`. The server enforces `isValidBlobHex` (min 346 chars = 173 bytes), but the spec doesn't mention this minimum. An independent implementation might accept shorter blobs and store garbage.

598−

599−**Suggested fix:** Add the minimum blob length to PROTOCOL.md §4 or §5.

600−

601−### 🟡 Q40. Spec doesn't specify JSON encoding requirements (UTF-8, key ordering, whitespace)

602−

603−**Type:** Spec gap (PROTOCOL.md §4, §5)

604−**Files:** PROTOCOL.md §4, §5

605−

606−The spec shows JSON examples but doesn't specify:

607−- Whether keys must be in a specific order (the server uses `GossipEvent` with `eventType` and `pubkey` — order matters for some JSON parsers)

608−- Whether whitespace is allowed in the JSON (a client could send pretty-printed JSON)

609−- Whether UTF-8 is required (JSON spec allows UTF-16/UTF-32, but the server likely only handles UTF-8)

610−- Whether duplicate keys are allowed (JSON allows them, but behavior is undefined)

611−

612−These could cause implementation divergence. For example, a client that sends `{"encryptedBlob": "...", "to": "..."}` (keys reversed) would work with most JSON parsers but might confuse a strict implementation.

613−

614−**Suggested fix:** Specify that all JSON is UTF-8, keys are unordered, whitespace is allowed, and duplicate keys are undefined behavior (last one wins).

615−

616−### 🟡 Q41. Spec doesn't specify what `cursor: 0` means vs absent cursor

617−

618−**Type:** Spec gap (PROTOCOL.md §6)

619−**Files:** PROTOCOL.md §6 (`POST /poll`)

620−

621−The spec says `cursor` is "the maximum `receivedAt` value the client has already seen (`0` on first poll)." But what if the client sends `cursor: -1` or omits the field? The server's `handlePoll` clamps to `max 0 (...)`, so negative cursors become 0. But the spec doesn't say this.

622−

623−**Suggested fix:** Specify that cursor must be ≥ 0, and that 0 means "first poll" (no messages acked).

624−

625−### 🟡 Q42. Spec doesn't specify `to` field validation requirements

626−

627−**Type:** Spec gap (PROTOCOL.md §4, §6)

628−**Files:** PROTOCOL.md §4 (Envelope), PROTOCOL.md §6 (`POST /messages`)

629−

630−The spec says `to` is "Recipient's Ed25519 public key (64 lowercase hex)" but doesn't say:

631−- Must it be a valid Ed25519 public key (a valid curve point)?

632−- Is the server required to validate it?

633−- What happens if it's the sender's own key? (The server rejects this as `self_send`, but the spec doesn't say the server should check this — it's an implementation detail)

634−

635−**Suggested fix:** Specify that `to` must be 64 lowercase hex chars (the server validates format only), and that the server rejects self-sends with `400 self_send`.

636−

637−### 🟡 Q43. Spec doesn't specify the format of `challenge` in auth

638−

639−**Type:** Spec gap (PROTOCOL.md §6)

640−**Files:** PROTOCOL.md §6 (Authentication)

641−

642−The spec says the challenge is "a random challenge string" but doesn't specify:

643−- Its length or entropy

644−- Its format (hex? base64? raw text?)

645−- Whether it must be unique per challenge request

646−

647−The server uses `genToken 48` (48 hex chars, 192 bits). The client signs it as part of the auth message. If an independent implementation uses a shorter challenge (e.g., 8 chars), it would be brute-forceable.

648−

649−**Suggested fix:** Specify minimum challenge length (e.g., 32 hex chars / 128 bits) and format (lowercase hex).

650−

651−### ⚪ Q44. Spec doesn't specify `revokeOthers` semantics precisely

652−

653−**Type:** Spec gap (PROTOCOL.md §6)

654−**Files:** PROTOCOL.md §6 (Authentication step 3)

655−

656−The spec says `revokeOthers: true` "invalidates every other live session for this pubkey" but doesn't specify:

657−- Whether it also invalidates challenges (it doesn't — see Q35)

658−- Whether the revocation is immediate or eventual (it's immediate within the atomic block)

659−- What happens to in-flight requests using a revoked session (they get 401 on the next request)

660−

661−**Suggested fix:** Clarify that only sessions (not challenges) are revoked, revocation is immediate, and revoked sessions get 401 on their next request.

662−

663−---

664−

665−## 9. Privacy / Metadata Leaks

666−

667−### 🟠 Q45. Blob size reveals message type to the server

668−

669−**Type:** Privacy leak (protocol + design)

670−**Files:** PROTOCOL.md §3 (Length Padding), `core/src/protocol.rs:60-91`

671−

672−The padding buckets (256, 512, 1024, ...) obscure the exact compressed size, but the bucket boundaries still leak information about the message type:

673−- A `delivery.ack` with a single ID is tiny (~50 bytes JSON) → compresses to ~40 bytes → inner buffer ~233 bytes → blob ~233 + 16 (AEAD) = 249 → rounds to 256 bucket

674−- A `text` message with a short body is ~100 bytes JSON → compresses to ~80 bytes → inner buffer ~273 bytes → blob ~289 → rounds to 512 bucket

675−- A `profile` with a 64 KiB photo → compresses poorly (base64 is high-entropy) → inner buffer ~65 KiB → rounds to 65536 bucket

676−

677−So the server can distinguish:

678−- A `delivery.ack` (256 bucket) from a `text` (512 bucket) from a `profile` with photo (65536 bucket)

679−- A short text (512) from a long text (1024+)

680−

681−This is a metadata leak beyond what's documented. The spec says "message length is only ever obscured *upward*" and "blob size still distinguishes a one-word reply from a pasted document" — but it doesn't mention that blob size reveals the *message type* (text vs ack vs profile).

682−

683−**Attack scenario:** A relay observes that Alice sends Bob a 256-bucket blob → it's a delivery.ack (Alice received Bob's message). Then Alice sends a 65536-bucket blob → it's a profile update. The relay learns the *pattern* of communication (who acks whom, who updates their profile) without decrypting anything.

684−

685−**Exploitable in practice:** The bucket boundaries are coarse but sufficient to distinguish message types. This is a real metadata leak for a "metadata-privacy-focused messenger."

686−

687−**Suggested fix:** Use a single minimum padding bucket (e.g., always pad to at least 1024 bytes) to make all small messages indistinguishable. Or add random padding within the bucket to add noise. Or pad all messages to the same size (expensive but maximally private).

688−

689−### 🟡 Q46. `receivedAt` timing reveals sender-recipient correlation to the relay

690−

691−**Type:** Privacy leak (server.knot)

692−**Files:** `server.knot:919-925` (`appendMessage`)

693−

694−The server assigns `receivedAt` at message arrival time. If Alice sends a message to Bob via relay R, R records the arrival time. If Bob polls R shortly after, R records the poll time. The correlation between arrival and poll times reveals that Bob was online and received the message — even though the server doesn't know who sent it.

695−

696−This is inherent to the relay model (the server must see the recipient and timing), and is documented in §10 ("Recipient metadata exposure"). But the spec understates the leak: it says "servers see the recipient pubkey and arrival time" — it doesn't mention that the server can correlate arrival and poll times to infer delivery.

697−

698−**Suggested fix:** Document in §10 that the relay can infer delivery by correlating message arrival with recipient poll times.

699−

700−### 🟡 Q47. Poll cursor reveals the recipient's last-seen position to the relay

701−

702−**Type:** Privacy leak (server.knot)

703−**Files:** `server.knot:432-433` (cursor), `server.knot:1265-1275` (cursor clamping)

704−

705−The client sends its cursor (last-seen `receivedAt`) on every poll. This tells the relay exactly how far behind the recipient is — how many messages they haven't read yet. A relay can use this to:

706−- Determine if the recipient is actively reading (cursor advances each poll) or just polling (cursor stays the same)

707−- Estimate the recipient's reading speed (how fast the cursor advances)

708−- Detect when the recipient switches devices (cursor jumps backward)

709−

710−This is inherent to the long-poll model but not documented in §10.

711−

712−**Suggested fix:** Document in §10 that the cursor reveals the recipient's reading progress to the relay.

713−

714−---

715−

716−## 10. TOFU and Key Management

717−

718−### 🟠 Q48. No key change detection — TOFU silently accepts key changes without warning

719−

720−**Type:** Design gap (protocol + app.rs)

721−**Files:** PROTOCOL.md §2 (Trust Model), `core/src/app.rs:2043-2045` (sender check)

722−

723−The spec says "the first time a client encounters a public key, it is accepted and cached" and "Warn users when a contact's public key changes (TOFU violation)." But the implementation doesn't have a mechanism for key changes — because the protocol has no key rotation (§11 is future work).

724−

725−However, there's a subtler issue: the sender's identity is *inside* the AEAD ciphertext. If an attacker sends a message to Bob encrypted to Bob's key, signing with Mallory's key, Bob's client will:

726−1. Decrypt the blob (it's encrypted to Bob's key, so it decrypts successfully)

727−2. Recover the sender's pubkey (Mallory's)

728−3. Check if Mallory is in Bob's contacts

729−4. If not, auto-create a contact for Mallory and display the message

730−

731−This is by design (anyone can send you a message). But if the attacker can somehow get Bob to add Mallory's key as a contact (e.g., by social engineering), and then later send messages that appear to come from Mallory, there's no mechanism to detect that "Mallory" has changed keys — because the key IS the identity.

732−

733−The real TOFU weakness is: if Bob adds Alice's key, and Alice's key is later compromised, an attacker with Alice's key can send messages that appear to come from Alice. There's no way for Bob to detect this without out-of-band verification. The spec acknowledges this ("TOFU only" in §10), but the implementation doesn't provide a UI for out-of-band verification (comparing @p syllables).

734−

735−**Exploitable in practice:** This is the fundamental TOFU weakness, already acknowledged in the spec. The implementation gap is the lack of a verification UI, but that's a product feature, not a protocol bug.

736−

737−**Suggested fix:** Add a UI for fingerprint verification (showing @p syllables for comparison) and a warning when a new contact's key hasn't been verified.

738−

739−### 🟡 Q49. `Identity::from_secret_bytes` validates the keypair but doesn't check for weak keys

740−

741−**Type:** Implementation gap (crypto.rs)

742−**Files:** `core/src/crypto.rs:150-166`

743−

744−`from_secret_bytes` re-derives the public key from the seed and checks it matches. But it doesn't check for weak Ed25519 keys (e.g., keys where the X25519 derived key is a low-order point). The `x25519` function checks for all-zero shared secrets (low-order point detection), but this only fires during encryption/decryption, not at key load time.

745−

746−If the user's Ed25519 key happens to produce an X25519 public key that is a low-order point, every encryption to them would fail with `InvalidEphemeralKey` (because `x25519(eph_priv, recip_x)` would return all-zero). The user would be unable to receive messages but wouldn't know why.

747−

748−The probability of this is negligible (low-order points are extremely rare on Curve25519), but the code doesn't check for it at key generation time.

749−

750−**Suggested fix:** Check `x25519_public` is not a low-order point at key generation/load time. Report an error if it is.

751−

752−### 🟡 Q50. No mechanism to revoke or invalidate a compromised identity key

753−

754−**Type:** Design gap (PROTOCOL.md §11)

755−**Files:** PROTOCOL.md §11 (Future Extensions — Key Rotation)

756−

757−The spec acknowledges this in §11 (future work): "a user who loses or wants to retire a key has no in-protocol way to say so." There's no key revocation, no key rotation, and no mechanism to tell contacts that a key is compromised.

758−

759−If a user's key is stolen, the attacker can:

760−1. Decrypt all captured messages (no forward secrecy)

761−2. Send messages as the user (no revocation)

762−3. Poll the user's mailbox (if they know the server)

763−4. Receive messages intended for the user (if they redirect presence)

764−

765−The only defense is out-of-band communication ("my key was compromised, don't talk to the old key anymore"), which requires every contact to manually re-add the new key.

766−

767−**Suggested fix:** This is acknowledged as future work. Document the impact more prominently in §10: a stolen identity key is a full takeover with no in-protocol recovery.

768−

769−---

770−

771−## Summary of New Findings

772−

774−|---|----------|------|-------|

811−

812−**High-severity findings (7):** Q8, Q16, Q27, Q30, Q34, Q45, Q48

813−**Medium-severity findings (24):** Q1, Q2, Q5, Q7, Q9, Q10, Q11, Q17, Q18, Q23, Q25, Q28, Q29, Q31, Q32, Q33, Q35, Q37, Q38, Q39, Q40, Q41, Q42, Q43, Q46, Q47, Q49, Q50

814−**Info (1):** Q44

815−

816−Note: Several findings marked as "not a bug" during analysis were downgraded to info or omitted from the final table. The table includes only findings that represent genuine new issues.

Cargo.lock−1

@@ -1797,7 +1797,6 @@ name = "skrepka_core"

17971797version = "0.1.0"

17981798dependencies = [

17991799 "anyhow",

1800− "base64",

18011800 "boltffi",

18021801 "chacha20poly1305",

18031802 "clap",

Cargo.toml−1

@@ -43,7 +43,6 @@ rand_core = { version = "0.6", features = ["getrandom"] }

4343rand_chacha = "0.3"

4444uuid = { version = "1", features = ["v4"] }

4545hex = "0.4"

46−base64 = "0.22"

4746zeroize = { version = "1", features = ["derive"] }

4847url = "2"

4948

PROTOCOL.md+29−66

@@ -1,6 +1,6 @@

11# Skrepka Protocol Specification

3−**Version:** 0.2 (Draft)

3+**Version:** 0.1 (Draft)

55---

@@ -110,7 +110,7 @@ The wire-visible "envelope" carries only the recipient and the opaque blob. The

110110 key = hkdf_sha256(

111111 ikm = raw_secret,

112112 salt = ephemeral_public || recipient_x25519_public,

113− info = "skrepka-v2",

113+ info = "skrepka-v1",

114114 len = 32

115115 )

116116 ```

@@ -118,45 +118,35 @@ The wire-visible "envelope" carries only the recipient and the opaque blob. The

118118 ```

119119 compressed = zstd(plaintext_bytes) // standard zstd frame (embeds content size)

120120 ```

121−5. Sign a domain-separation tag, the recipient pubkey, and the compressed plaintext with padding. The `"skrepka-msg-v2:"` prefix is a domain-separation tag distinguishing message signatures from auth-challenge signatures (which begin with `"skrepka-auth-v1:"`, §6), so a signature produced in one context can never validate in the other. Binding the signature to the recipient prevents the same blob from being replayed against another recipient:

121+5. Sign the recipient pubkey concatenated with the compressed plaintext and padding. Binding the signature to the recipient prevents the same blob from being replayed against another recipient:

122122 ```

123123 compressed_len = uint32_be(len(compressed))

124124 padding = random_bytes(target_blob_size - unpadded_blob_size)

125125 signature = ed25519_sign(sender_ed25519_private,

126− "skrepka-msg-v2:" || recipient_ed25519_public || compressed_len || compressed || padding)

126+ recipient_ed25519_public || compressed_len || compressed || padding)

127127 ```

1281286. Build the inner buffer that will be encrypted:

129129 ```

130130 inner = sender_ed25519_public || signature || compressed_len || compressed || padding

131131 ```

132−7. Generate a random 24-byte nonce and AEAD-encrypt the inner buffer with

133− associated data binding the envelope header and recipient identity:

132+7. Generate a random 24-byte nonce and AEAD-encrypt the inner buffer:

134133 ```

135134 nonce = random_bytes(24)

136− aad = version_byte || ephemeral_public || nonce || recipient_ed25519_public

137− ciphertext = xchacha20_poly1305_encrypt(key, nonce, inner, aad)

135+ ciphertext = xchacha20_poly1305_encrypt(key, nonce, inner) // no associated data

138136 ```

139− The AAD authenticates every cleartext field a relay can see (version,

140− ephemeral public key, nonce) and the recipient's Ed25519 public key.

141− A relay that swaps the envelope `to` field to a different recipient causes

142− AEAD decryption to fail at the wrong recipient — the blob is dropped before

143− any cursor advance, and the original recipient's message stays in the

144− mailbox. Without AAD, a relay could silently misdeliver messages by

145− swapping `to`, making the censorship undetectable to both sender and

146− recipient.

1471378. Emit the on-wire blob:

148138 ```

149139 blob = version_byte || ephemeral_public || nonce || ciphertext

150140 ```

151− where `version_byte` is `0x02` (see *Cryptographic Versioning* below).

141+ where `version_byte` is `0x01` (see *Cryptographic Versioning* below).

152142

153143**Decryption flow:**

154144

1551451. Read the leading version byte (reject the blob if it is not recognized). Split the rest: 32-byte `ephemeral_public`, 24-byte `nonce`, remainder is `ciphertext`.

1561462. Derive the recipient's X25519 private key from the recipient's Ed25519 private key, compute the raw shared secret with `ephemeral_public`, and HKDF-derive the same `key`.

157−3. Reconstruct the AAD: `version_byte || ephemeral_public || nonce || recipient_ed25519_public`. AEAD-decrypt the ciphertext with this AAD to recover the inner buffer.

147+3. AEAD-decrypt the ciphertext to recover the inner buffer.

1581484. Split: 32-byte `sender_ed25519_public`, 64-byte `signature`, 4-byte `compressed_len` (big-endian u32), then `compressed_len` bytes of `compressed` (the remainder is padding).

159−5. Verify the signature over `"skrepka-msg-v2:" || recipient_ed25519_public || inner[96..]` (i.e. the domain-separation tag followed by `compressed_len || compressed || padding`) using `sender_ed25519_public`. Reject the message on failure.

149+5. Verify the signature over `recipient_ed25519_public || inner[96..]` (i.e. `compressed_len || compressed || padding`) using `sender_ed25519_public`. Reject the message on failure.

1601506. zstd-decompress the `compressed` bytes (only the `compressed_len`-length slice, not the trailing padding) to recover the plaintext payload.

161151

162152### Encrypted Blob Format

@@ -164,7 +154,7 @@ The wire-visible "envelope" carries only the recipient and the opaque blob. The

164154On the wire (cleartext, server-visible):

165155

166156```

167−version (1 byte, currently 0x02)

157+version (1 byte, currently 0x01)

168158ephemeral_x25519_pubkey (32 bytes)

169159nonce (24 bytes)

170160ciphertext (variable, includes 16-byte AEAD tag)

@@ -180,7 +170,7 @@ compressed_plaintext (variable, zstd; exactly compressed_len bytes)

180170padding (variable, random)

181171```

182172

183−The sender's pubkey and signature are inside the AEAD ciphertext: the server never sees them, and only the intended recipient can recover the sender's identity. The `compressed_len` field tells the recipient exactly where the zstd frame ends, so trailing padding bytes are never fed to the decompressor. The minimum blob size is `1 + 32 + 24 + 32 + 64 + 4 + 16 = 173` bytes (346 hex chars). A relay rejects any blob shorter than this with `400 invalid_message`, since it cannot possibly carry a valid envelope.

173+The sender's pubkey and signature are inside the AEAD ciphertext: the server never sees them, and only the intended recipient can recover the sender's identity. The `compressed_len` field tells the recipient exactly where the zstd frame ends, so trailing padding bytes are never fed to the decompressor. The minimum blob size is `1 + 32 + 24 + 32 + 64 + 4 + 16 = 173` bytes. A relay rejects any blob shorter than that as malformed (`400`), since it cannot possibly carry an envelope.

184174

185175### Length Padding

186176

@@ -194,15 +184,15 @@ The bucket boundaries are:

194184

195185A blob is rounded up to the smallest bucket ≥ its unpadded size. Above 65536 bytes, the blob is rounded up to the next multiple of 65536. The padding bytes are randomly generated per message, so two encryptions of the same plaintext produce the same blob size (same bucket) but different blob contents. The on-wire blob is therefore `173 + len(compressed) + len(padding)` bytes, and that padded size is all a relay or network observer sees.

196186

197−> **Compression before encryption leaks plaintext structure.** The payload is zstd-compressed *then* encrypted (steps 4–7), so the ciphertext length is a function of how *compressible* the plaintext was, not just how long it was. XChaCha20-Poly1305 is a stream cipher with no padding: without length padding the blob would be exactly `173 + len(compressed)` bytes, and that number would be visible to every relay and network observer. Version 0x02 adds length padding (see *Length Padding* above), which buckets blob sizes to fixed boundaries so the exact compressed size is hidden.

187+> **Compression before encryption leaks plaintext structure.** The payload is zstd-compressed *then* encrypted (steps 4–7), so the ciphertext length is a function of how *compressible* the plaintext was, not just how long it was. XChaCha20-Poly1305 is a stream cipher with no padding: without length padding the blob would be exactly `173 + len(compressed)` bytes, and that number would be visible to every relay and network observer. Version 0x01 adds length padding (see *Length Padding* above), which buckets blob sizes to fixed boundaries so the exact compressed size is hidden.

198188>

199189> Two consequences. First, message length is only ever obscured *upward*: a long but repetitive message can produce a smaller blob than a short random-looking one, and blob size still distinguishes a one-word reply from a pasted document. Second — the more serious one — where an attacker can influence part of the plaintext that is compressed together with a secret, the compressed size reveals whether the two share structure. That is the CRIME/BREACH pattern, and it is a real (if narrow) concern for a format that compresses attacker-influenceable text alongside sensitive text in one frame.

200190>

201−> Skrepka accepts the remaining risk: payloads are small, each message is compressed independently (no cross-message compression context), and there is no adaptive-guessing oracle in the protocol — an attacker cannot make the client re-encrypt a chosen variant of a secret on demand. Implementations must **not** add one (e.g. by compressing several messages, or attacker-supplied and user-supplied text, into a shared frame). Length padding (version 0x02) obscures the exact compressed size by bucketing blob lengths, but does not eliminate the CRIME/BREACH side channel within a single bucket — it only makes the granularity coarser.

191+> Skrepka accepts the remaining risk: payloads are small, each message is compressed independently (no cross-message compression context), and there is no adaptive-guessing oracle in the protocol — an attacker cannot make the client re-encrypt a chosen variant of a secret on demand. Implementations must **not** add one (e.g. by compressing several messages, or attacker-supplied and user-supplied text, into a shared frame). Length padding (version 0x01) obscures the exact compressed size by bucketing blob lengths, but does not eliminate the CRIME/BREACH side channel within a single bucket — it only makes the granularity coarser.

202192

203193### Cryptographic Versioning

204194

205−The wire format carries a leading **version byte** (currently `0x02`) on every encrypted blob. A recipient that sees a version it does not recognise MUST reject the blob without attempting further processing (no AEAD decrypt, no key derivation, no decompression) — the reference client returns a decryption error and drops the blob. This ensures a future revision can introduce a new AEAD, KDF, or curve by bumping this byte without risk of misinterpreting an unknown format. Version 0x02 adds AEAD associated data (AAD): the cleartext header `version_byte || ephemeral_public || nonce` and the recipient's Ed25519 public key are authenticated alongside the ciphertext, so a relay that tampers with any envelope field — including swapping the `to` recipient — causes AEAD decryption to fail rather than silently misdelivering the blob. The HKDF `info` string is the fixed constant `"skrepka-v2"` for version 0x02. The unknown-`type` rule (§4) gives forward compatibility for *payload* types; the version byte gives the same for the wire format, AEAD, KDF, and curve choices. A future revision that changes the crypto primitives should bump both the version byte and the HKDF `info` string together — the reference implementation derives the info string from the version to ensure they cannot drift (see `crypto.rs`).

195+The wire format carries a leading **version byte** (currently `0x01`) on every encrypted blob. A recipient that sees a version it does not recognise MUST reject the blob without attempting further processing (no AEAD decrypt, no key derivation, no decompression) — the reference client returns a decryption error and drops the blob. This ensures a future revision can introduce a new AEAD, KDF, or curve by bumping this byte without risk of misinterpreting an unknown format. Version 0x01 includes length padding (see *Length Padding* above): blobs are padded to fixed-size bucket boundaries, and the inner buffer carries a 4-byte `compressed_len` field so the recipient can separate the zstd frame from trailing padding. The HKDF `info` string remains the fixed constant `"skrepka-v1"` for version 0x01. The unknown-`type` rule (§4) gives forward compatibility for *payload* types; the version byte gives the same for the wire format, AEAD, KDF, and curve choices. A future revision that changes the crypto primitives should bump both the version byte and the HKDF `info` string together.

206196

207197---

208198

@@ -221,10 +211,10 @@ The envelope is what servers see. It carries only the recipient and the opaque e

221211

222212| Field | Type | Description |

223213|-----------------|--------|--------------------------------------------------|

224−| `to` | string | Recipient's Ed25519 public key — exactly 64 lowercase hex chars. The server validates the **format** only (length and charset); it does not verify the decoded bytes form a valid Ed25519 curve point. |

225−| `encryptedBlob` | string | Hex-encoded blob from §3. Must be at least 346 hex chars (173 bytes); the server rejects shorter blobs with `400 invalid_message`. |

214+| `to` | string | Recipient's Ed25519 public key (64 lowercase hex)|

215+| `encryptedBlob` | string | Hex-encoded blob from §3 |

226216

227−Servers route based on `to`. They cannot inspect `encryptedBlob` and they do not know the sender. The `to` field is format-validated only — the server does not check that it represents a valid Ed25519 curve point, so blobs addressed to non-existent keys are stored and forwarded normally (the intended recipient simply cannot decrypt them). A message whose `to` matches the authenticated sender's own pubkey is rejected with `400 self_send` (§6, *POST /messages*).

217+Servers route based on `to`. They cannot inspect `encryptedBlob` and they do not know the sender.

228218

229219### Plaintext Payload

230220

@@ -338,12 +328,7 @@ This file is a static suggestion, not a federation directory. Federation between

338328

339329### Content Type

340330

341−All request and response bodies use `application/json`. The following encoding rules apply to every JSON body (request and response):

342−

343−- **Encoding:** UTF-8. Implementations MUST NOT use UTF-16 or UTF-32.

344−- **Key ordering:** Object keys are unordered. A sender may emit them in any order; a receiver MUST NOT depend on key ordering for correctness.

345−- **Whitespace:** Inter-token whitespace (spaces, tabs, newlines) is allowed and does not affect semantics. Pretty-printed JSON is valid.

346−- **Duplicate keys:** If an object contains the same key more than once, behavior is undefined. Implementations SHOULD avoid producing duplicates and MAY reject or retain only the first value for a repeated key.

331+All request and response bodies use `application/json`.

347332

348333### Federation Transport

349334

@@ -376,9 +361,8 @@ When a client connects, it proves ownership of its keypair:

376361 ```json

377362 { "challenge": "<random_hex>", "expiresAt": 1679003660000 }

378363 ```

379− The challenge is a lowercase hex string of at least 32 chars (128 bits of entropy). The reference server uses 48 hex chars (192 bits). The challenge MUST be unique per challenge request and consumed on first use (verified).

380364

381−3. Client signs the **UTF-8 bytes of `"skrepka-auth-v1:" + server_host + ":" + challenge`** with its Ed25519 private key and submits. `server_host` is the bare lowercased hostname of the server the client dialed (no scheme, no port, no trailing dot). For IPv6 literals, the host must include square brackets (e.g. `[::1]`), matching the URL host syntax — the server's `serverHost` configuration must also include brackets for IPv6. The `skrepka-auth-v1:` prefix is a domain-separation tag distinguishing auth signatures from message signatures (which begin with `"skrepka-msg-v2:"` and sign `recipientPub ++ compressed`, §3):

365+3. Client signs the **UTF-8 bytes of `"skrepka-auth-v1:" + server_host + ":" + challenge`** with its Ed25519 private key and submits. `server_host` is the bare lowercased hostname of the server the client dialed (no scheme, no port, no trailing dot). The `skrepka-auth-v1:` prefix is a domain-separation tag distinguishing auth signatures from message signatures (which sign `recipientPub ++ compressed`, §4):

382366 ```

383367 POST /auth/verify

384368 {

@@ -389,7 +373,7 @@ When a client connects, it proves ownership of its keypair:

389373 }

390374 ```

391375 The server verifies against its own configured hostname (`serverHost`, port stripped). Binding the signature to the target host prevents a malicious or relay server from forwarding a challenge it obtained from a *different* server and replaying the client's signature there to impersonate the client (§10, *Unauthenticated session relay*).

392− Setting `revokeOthers: true` invalidates every other live session for this pubkey (useful for "log out other devices"). Revocation is **immediate** (within the atomic block that processes the verify) and a revoked session receives `401 unauthorized` on its next request. Note that `revokeOthers` revokes **sessions only**, not outstanding challenges — a challenge issued before the `revokeOthers` call remains valid for its 60-second window. (The reference implementation has been fixed to also drop outstanding challenges for the pubkey on `revokeOthers: true`; independent implementations SHOULD do the same.)

376+ Setting `revokeOthers: true` invalidates every other live session for this pubkey (useful for "log out other devices").

393377

3943784. Server verifies the signature. On success, returns a session token valid for **1 hour**:

395379 ```json

@@ -445,7 +429,7 @@ The client makes a blocking POST. The server holds the connection open until new

445429{ "cursor": 0 }

446430```

447431

448−`cursor` is the maximum `receivedAt` value the client has already seen. It MUST be a non-negative integer. `0` means "first poll" — no messages have been acked, so the server returns all pending events. Negative cursors are clamped to `0` by the server.

432+`cursor` is the maximum `receivedAt` value the client has already seen (`0` on first poll).

449433

450434**Response:**

451435```json

@@ -458,7 +442,6 @@ The client makes a blocking POST. The server holds the connection open until new

458442```

459443

460444- `cursor` is a server-side **strictly-monotonic sequence**, seeded from the wall-clock millisecond at assignment but bumped to `previous + 1` whenever messages arrive within the same millisecond. Two messages therefore never share a `receivedAt`, so advancing the cursor past one message can never silently drop another. Treat it as an opaque checkpoint, not a clock.

461−- The server clamps the supplied cursor to `max(0, min(max(t, curSeq), cursor))`, where `t` is the current wall-clock millisecond and `curSeq` is the last assigned sequence — note the ceiling is `max(t, curSeq)`, not just `curSeq`, so under idle the clamp allows acking up to the current wall-clock, while under sustained bursts (where the sequence has run ahead of the clock) it still refuses to ack beyond what has actually been issued.

462445- Advancing past a message acts as an **implicit ack**: when the next poll arrives with a `cursor` greater than or equal to a stored message's `receivedAt`, the server drops the stored message **and any pending federation forwards for it**.

463446- If events are available immediately, the server responds right away. Otherwise it parks the connection on a row-level wait against the mailbox and returns when a new matching message lands or after 25 s, whichever comes first.

464447- An empty page (`events: []`) is returned on timeout, with the cursor echoed back.

@@ -680,34 +663,16 @@ Skrepka protects message **content and sender identity** from servers and networ

680663

681664| Risk | Details |

682665|-----------------------------------|-----------------------------------------------------|

683−| **No forward secrecy** | A captured blob plus a later compromise of the recipient's long-term key **is enough to decrypt that message** — the per-message ephemeral key is the *sender's*, and the recipient's half of the exchange is their long-term identity key, which never rotates. So an adversary who records ciphertext today (a network observer, or any relay it passed through) and obtains the recipient's key at any point in the future can read everything it recorded. There is no ratchet, so there is also no post-compromise recovery: once the key leaks, future messages are readable too until the user rotates identity. Do not read the per-message ephemeral keys as forward secrecy; they are not. **Additionally**, because the HKDF salt (`ephemeral_public ‖ recipient_x25519_public`) omits the sender's identity, compromising the recipient's private key also enables a *key-compromise impersonation (KCI)* vector: the attacker can decrypt a captured blob, replace the sender identity and signature inside the inner buffer with their own, re-encrypt with the same derived key, and re-deliver. The recipient sees a valid message apparently from a different sender. Including the sender pubkey in the HKDF salt or info would close this by construction, but requires a wire-format change. The signature already prevents forgery *without* key compromise, so KCI is an additional consequence of an already-catastrophic key leak, not a standalone attack. |

684−| **No AAD on AEAD — envelope fields unauthenticated** (v0.1, fixed in v0.2) | In v0.1, XChaCha20-Poly1305 was called with no associated data. The envelope's `to` field was not authenticated by the AEAD — a relay could swap `to` to a different recipient's pubkey, silently misdelivering and censoring messages with zero detectability. **v0.2 fixes this**: the AAD includes `version_byte ‖ ephemeral_public ‖ nonce ‖ recipient_ed25519_public`, binding the envelope to the ciphertext. A `to`-swap now causes AEAD failure at the wrong recipient, and the original recipient's message stays in the mailbox. |

685−| **Recipient metadata exposure** | Servers see the recipient pubkey and arrival time of every message, plus the rough size of each blob. They do **not** see the sender. **The relay can also infer delivery** by correlating a message's arrival time with the recipient's subsequent poll time — the gap between the two reveals whether the recipient was online and actively reading. |

686−| **Blob size reveals message type** | The length-padding buckets (§3, *Length Padding*) are coarse enough that a relay can distinguish payload types: a `delivery.ack` with a single ID (~233 bytes) falls in the 256-byte bucket, a short `text` message falls in the 512-byte bucket, and a `profile` with a photo falls in the 65536-byte bucket. A relay observing the bucket pattern learns who acks whom and who updates their profile — without decrypting anything. Finer-grained padding (e.g., a single minimum bucket for all small messages) would reduce this leak. |

687−| **Poll cursor reveals reading progress** | The client sends its cursor (last-seen `receivedAt`) on every poll, telling the relay exactly how far behind the recipient is. A relay can determine whether the recipient is actively reading (cursor advances each poll) or just polling (cursor stays the same), estimate reading speed, and detect device switches (cursor jumps backward). This is inherent to the long-poll model. |

688−| **CRIME/BREACH surface on profiles** | The CRIME/BREACH side channel (§3, *Length Padding*) extends beyond text messages to `profile` broadcasts: `display_name`, `bio`, and `photo` are compressed together in one zstd frame. If an attacker can influence part of the profile text (e.g., the user sets their display name based on something the attacker controls), the compressed size could leak information about the user's other profile fields. The risk is low in practice — the base64-encoded photo is high-entropy and nearly incompressible, and bucket padding coarsens the granularity — but the spec's claim that "an attacker cannot make the client re-encrypt a chosen variant of a secret on demand" is too strong for profile broadcasts. |

666+| **No forward secrecy** | A captured blob plus a later compromise of the recipient's long-term key **is enough to decrypt that message** — the per-message ephemeral key is the *sender's*, and the recipient's half of the exchange is their long-term identity key, which never rotates. So an adversary who records ciphertext today (a network observer, or any relay it passed through) and obtains the recipient's key at any point in the future can read everything it recorded. There is no ratchet, so there is also no post-compromise recovery: once the key leaks, future messages are readable too until the user rotates identity. Do not read the per-message ephemeral keys as forward secrecy; they are not. |

667+| **Recipient metadata exposure** | Servers see the recipient pubkey and arrival time of every message, plus the rough size of each blob. They do **not** see the sender. |

689668| **Presence gossip leaks location** | Federated peers learn which server a user is currently connected to. A presence row is anchored for up to 90 min (`onlineGossipTtl`), which outlives the 1 h session, so location metadata — and forwards aimed at the user — can linger for up to ~90 min after the user disconnects. |

690669| **No durable delivery** | If the sender's server goes down or all forward retries fail, messages may be lost. |

691−| **Mailbox eviction under flood (DoS)** | The per-recipient mailbox cap (`maxMessagesPerRecipient`, default 10 000) evicts the oldest messages when the cap is reached. An authenticated attacker (pubkeys are free to mint) can flood a victim's mailbox with junk, pushing out genuine undelivered messages. The victim's client only sees junk; the genuine messages are permanently destroyed. At 60 requests/min × 100 messages = 6 000/min, the attacker fills the cap in ~2 minutes (per IP; multiple IPs are faster). This is an accepted design tradeoff of v0.1 — a real fix requires per-sender quotas or pricing. |

692−| **Unbounded mailbox storage** | The per-recipient mailbox cap (`maxMessagesPerRecipient`) bounds each recipient but not the count of distinct recipient keys. An attacker can fill the server's disk by sending messages to many distinct invalid pubkeys, bounded only by the 30-day TTL and rate limits. The reference server now enforces a global `maxMessagesTotal` cap (default 1 000 000) that evicts the globally-oldest rows on overflow, symmetric with the other state refs. |

693−| **CPU amplification via dedup scan** | `appendMessage` performs an O(n) full-scan dedup check on every message (§6). Under a burst of 100-message batches, each message triggers a scan of the entire mailbox. With large mailboxes this is quadratic and amplifies CPU cost per request. Bounded by rate limits (60/min per IP) and the fact that the attacker must be authenticated, but the amplification is real. |

694−| **Clock forward-jump pins the sequence counter** | The `receivedAt` sequence counter is a forward-only ratchet: `max(wall_clock, previous + 1)`. A single NTP forward-jump (server migration, misconfiguration) pins the counter at the jumped value, delaying all TTL pruning until real time catches up. Backward jumps are safe (the counter dominates). |

695−| **Challenge pool floodable (soft DoS)** | The challenge pool is globally capped at `maxChallenges` (default 10 000) with per-IP rate limiting. An attacker with many IPs — or behind a proxy with XFF spoofing when `trustForwardedFor = true` — can fill the pool with challenges for random pubkeys, causing legitimate challenges to be LRU-evicted. Authentication still works but with extra latency (clients retry). This is a soft DoS. |

696−| **Rate limit counts requests, not messages** | The per-IP send rate limit (60/min) counts requests, and each request can carry up to 100 messages. The effective message rate is therefore 60 × 100 = 6 000 messages/min per IP (bounded by the body-size cap), much higher than the per-request limit suggests. An attacker with multiple IPs can send millions of messages per minute. |

697−| **Session pool Sybil-floodable** | The global session pool (`maxSessions`, default 10 000) uses LRU eviction. An attacker with enough IPs can generate thousands of keypairs, authenticate each one, and fill the pool — evicting legitimate users' sessions. Users re-authenticate automatically (they get `401` and retry), so this is a soft DoS adding latency and load. Per-IP session caps were considered and rejected because they collapse behind carrier-grade NAT. |

698−| **Presence table fillable with fake keys** | The presence table (`maxPresence`, default 100 000) can be filled with fake keys via gossip (100 events per request, 60/min per IP). Local rows are exempt from the cap, so local users' presence is never evicted, but legitimate *remote* presence (from honest peers) can be evicted, causing forwards to those peers to fail. Requires federation to be enabled. |

699−| **Gossip amplification** | A single `/federation/gossip` request with 100 `online` events triggers up to 100 mailbox scans and forward-staging operations. The reference server caps the number of newly-online keys that trigger forward sweeps per batch (`maxNewlyOnlineForwards`, default 10), limiting the amplification to 10× per request. An attacker can still send 100 online events per request, but only 10 trigger forward sweeps; the remaining keys are written to `*presence` without a forward sweep. Bounded by the per-IP rate limit (60/min). |

700−| **`fromServer` not verified** | The `fromServer` field in gossip events is self-asserted and not verified against the connecting peer's actual network address — the server has **no mechanism** to verify that the connecting peer is who it claims to be. An attacker can claim `fromServer: "legit-relay.example.com"` from any IP, poisoning the presence table with the legitimate relay's hostname. Forwards go to the legitimate relay (which doesn't have the key online → 404), causing spurious forward requests. This is a variant of the gossip-redirect attack; the intended fix is reverse-DNS verification of the connecting peer, which requires runtime DNS support not currently available. |

701−| **No identity revocation** | There is no in-protocol mechanism to revoke or invalidate a compromised identity key. A stolen key allows full takeover: decrypt all captured messages, send messages as the user, poll their mailbox, and receive their messages via presence redirect. The only defense is out-of-band communication. See §11 (Future Extensions — Key Rotation) for the intended direction. |

702−| **Unauthenticated session relay** (mitigated) | The auth signature is bound to the target server's hostname under a domain-separation tag (§6), so a malicious/relay server can no longer forward another server's challenge and replay the resulting signature to impersonate the client elsewhere. Residual caveat: the binding is to the hostname the client dialed, so it assumes the client reaches each server under its true `serverHost` (DNS/TLS integrity). |

703−| **Same-recipient replay** | Nothing stops a captured blob from being re-delivered to its original recipient. The damage is bounded per payload type: `text` is deduplicated by `id` (the reference client maintains a persistent `seen_ids` set that survives `trim_history`), `delivery.ack` is idempotent, and `profile` is guarded by the per-contact `ts` staleness check of §4. |

704−| **Open federation — gossip redirect** | `/federation/gossip` is unauthenticated; an attacker announces the victim online at a host it controls and origin relays forward the victim's queued ciphertext there. **Active users are also affected**: even when the recipient is locally online and actively polling, a forged remote presence row causes each new incoming message to be duplicated to the attacker's server — the victim receives everything normally but the attacker silently collects ciphertext metadata for the live inbound stream. See *Open federation* below. |

705−| **Open federation — forward injection** | `/federation/forward` is unauthenticated; any host can inject arbitrary blobs into a currently-online recipient's mailbox. See *Open federation* below. |

706−| **Bearer token theft = full impersonation** | Sessions are bearer-token-based: anyone who obtains the token can use it. The token is bound to `(pubkey, ip, expiry)`, but the `pubkey` binding is for authorization (self-send rejection), not for authenticating the request. If an attacker steals a bearer token (e.g., from a compromised proxy's access log), they can poll the victim's mailbox and send messages as the victim — modulo IP binding. Token expiry (1 hour) is the only automatic recovery. Consider shorter token lifetimes or per-request signing. |

707−| **Token entropy depends on runtime CSPRNG** | Session and challenge tokens are generated by the server's runtime random source. Implementations SHOULD verify that their RNG is cryptographically secure (e.g., backed by `/dev/urandom` or an OS-provided CSPRNG). |

708−| **Non-curve-point `to` keys accepted** | The server validates that `to` is 64 lowercase hex chars but does not check that the decoded bytes form a valid Ed25519 curve point. Blobs addressed to non-existent keys are stored and forwarded normally, consuming storage until TTL expiry. |

709−| **No crypto rotation performed** | The wire format carries a version byte (§3, *Cryptographic Versioning*) and a fixed HKDF `info` (`"skrepka-v2"`), so a future revision *can* introduce new AEAD/KDF/curve choices by bumping both. Version 0x02 added AEAD associated data (AAD) to bind envelope fields to the ciphertext. No further rotation has been performed. |

710−| **TOFU only — no verification UI** | A first-time public key is trusted on encounter; users must compare fingerprints out-of-band (e.g., @p syllables in person) to detect MITM at first contact. The reference client does not yet provide a UI for this out-of-band verification. Independent clients SHOULD implement such a UI. |

670+| **Unauthenticated session relay** (mitigated) | The auth signature is bound to the target server's hostname under a domain-separation tag (§6), so a malicious/relay server can no longer forward another server's challenge and replay the resulting signature to impersonate the client elsewhere — the signature commits to the relay's own hostname. Residual caveat: the binding is to the hostname the client dialed, so it assumes the client reaches each server under its true `serverHost` (DNS/TLS integrity); it does not defend against an attacker who fully controls name resolution and the server's certificate. |

671+| **Same-recipient replay** | Nothing stops a captured blob from being re-delivered to its original recipient. The damage is bounded per payload type: `text` is deduplicated by `id`, `delivery.ack` is idempotent, and `profile` — which carries no `id` — is guarded by the per-contact `ts` staleness check of §4, which the reference client enforces, so a replayed stale `profile` is dropped rather than rolling a contact's cached profile back. A client that omits that check is open to profile rollback. |

672+| **Open federation — gossip redirect** | `/federation/gossip` is unauthenticated, and the harm is *active*, not merely passive observation: an attacker announces the victim online at a host it controls and origin relays forward the victim's queued ciphertext there. See *Open federation* below. |

673+| **Open federation — forward injection** | `/federation/forward` is unauthenticated, so any host can inject arbitrary blobs into a currently-online recipient's mailbox. See *Open federation* below. |

674+| **No crypto rotation performed** | The wire format carries a version byte (§3, *Cryptographic Versioning*) and a fixed HKDF `info` (`"skrepka-v1"`), so a future revision *can* introduce new AEAD/KDF/curve choices by bumping both. No such rotation has been performed, and a client that does not recognize the version byte rejects the blob outright — but there is no negotiation, so an old client cannot discover that a new one exists. |

675+| **TOFU only** | A first-time public key is trusted on encounter; users must compare fingerprints out-of-band to detect MITM at first contact. |

711676

712677### Open Federation (accepted limitation of v0.1)

713678

@@ -724,8 +689,6 @@ to every relay it can reach. Each relay holding mail for the victim now forwards

724689

725690**2. Forward injection — spam into an online recipient's mailbox.** `/federation/forward` is unauthenticated, so any host can inject arbitrary blobs into the mailbox of any recipient who is currently locally online. Injected junk is undecryptable, so a client drops it silently on ingest — but it occupies the recipient's poll stream and the relay's mailbox until the cursor advances past it. The only bounds are the per-source-IP rate limit (`forwardLimit`), the SSRF deny-list (which constrains where a relay will *send*, not who may call it), and the `no_presence` gate (which limits injection to online recipients).

726691

727−**3. Forward cancellation — deleting queued mail-in-flight.** The offline-event forward cancellation (§7) **widens** the unauthenticated-gossip blast radius from writing presence to **deleting queued forwards** — an attacker claiming `fromServer: X` can cancel pending forwards to any real relay X by announcing an `offline` event for the relevant key, so mail queued for delivery to X is dropped from the origin's outbox (the message itself stays in `*messages` and is re-forwarded if the key reappears on another peer, so this delays rather than destroys delivery).

728−

729692**Mitigation path.** Both attacks are accepted limitations of v0.1's unauthenticated federation. The intended fix is peer authentication — signed presence gossip and authenticated forward requests — or an explicit peer allow-list gate before `forwardQueuedToServer`. Until then, operators who federate only with trusted peers (or not at all) are unaffected.

730693

731694### Recommendations for Implementers

apple/SkrepkaApp/Core.swift+15−13

@@ -26,17 +26,16 @@ final class Core: ObservableObject {

2626 private let store = KvStore()

2727

2828 private init() {

29− // The FFI's guard returns empty bytes when the core panics; force-try

30− // on empty bytes crashes the app. Fall back to a default ViewModel instead.

31− self.view = (try? ViewModel.bincodeDeserialize(input: [UInt8](core.view()))) ?? ViewModel()

29+ // swiftlint:disable:next force_try

30+ self.view = try! .bincodeDeserialize(input: [UInt8](core.view()))

3231 bootIdentity()

3332 }

3433

3534 // MARK: - Event/effect loop

3635

3736 func update(_ event: Event) {

38− guard let eventData = try? event.bincodeSerialize() else { return }

39− let effects = [UInt8](core.update(data: Data(eventData)))

37+ // swiftlint:disable:next force_try

38+ let effects = [UInt8](core.update(data: Data(try! event.bincodeSerialize())))

4039 dispatch(effects)

4140 }

4241

@@ -46,7 +45,8 @@ final class Core: ObservableObject {

4645 }

4746

4847 private func dispatch(_ effects: [UInt8]) {

49− guard let requests = try? Requests.bincodeDeserialize(input: effects).value else { return }

48+ // swiftlint:disable:next force_try

49+ let requests = try! Requests.bincodeDeserialize(input: effects).value

5050 for request in requests {

5151 process(request)

5252 }

@@ -56,27 +56,29 @@ final class Core: ObservableObject {

5656 let id = request.id

5757 switch request.effect {

5858 case .render:

59− self.view = (try? ViewModel.bincodeDeserialize(input: [UInt8](core.view()))) ?? self.view

59+ // swiftlint:disable:next force_try

60+ self.view = try! .bincodeDeserialize(input: [UInt8](core.view()))

6061

6162 case .http(let req):

6263 Task { [weak self] in

6364 let result = await Http.perform(req)

64− guard let output = try? result.bincodeSerialize() else { return }

65− self?.resolve(id, output)

65+ // swiftlint:disable:next force_try

66+ self?.resolve(id, try! result.bincodeSerialize())

6667 }

6768

6869 case .keyValue(let op):

6970 // The file I/O runs on the store's own serial queue; hop the result back to

7071 // the main actor, because the core is single-threaded and `.render` publishes.

7172 store.handle(op) { [weak self] result in

72− guard let output = try? result.bincodeSerialize() else { return }

73+ // swiftlint:disable:next force_try

74+ let output = try! result.bincodeSerialize()

7375 Task { @MainActor in self?.resolve(id, output) }

7476 }

7577

7678 case .time(let req):

7779 Time.handle(req) { [weak self] response in

78− guard let output = try? response.bincodeSerialize() else { return }

79− self?.resolve(id, output)

80+ // swiftlint:disable:next force_try

81+ self?.resolve(id, try! response.bincodeSerialize())

8082 }

8183 }

8284 }

@@ -95,4 +97,4 @@ final class Core: ObservableObject {

9597 identityError = error.message

9698 }

9799 }

98−}

100+}

apple/SkrepkaApp/Effects.swift+14−80

@@ -5,44 +5,19 @@ import Skrepka

66// MARK: - HTTP

8−/// Hard cap on any HTTP response body we will buffer. A hostile relay

9−/// can answer any endpoint with a multi-gigabyte body; without this cap

10−/// `URLSession.data(for:)` would OOM the app before the core's own

11−/// `MAX_POLL_RESPONSE_BYTES` check (which runs on the wrong side of the

12−/// FFI boundary to prevent the allocation) ever fires.

13−private let maxResponseBytes = 64 * 1024 * 1024 // 64 MiB

14−

15−/// The one session delegate, handling two defenses against an untrusted relay.

8+/// Cancels every HTTP redirect instead of following it.

169///

17−/// **Redirect cancellation.** URLSession replays the original request's headers onto a

18−/// redirect target, including `Authorization: Bearer <session_token>`. A hostile (or

19−/// compromised) relay could answer `/poll` or `/messages` with a 302 to a host it chooses

10+/// URLSession replays the original request's headers onto a redirect target, including

11+/// `Authorization: Bearer <session_token>`. A relay is untrusted infrastructure: a hostile

12+/// (or compromised) one could answer `/poll` or `/messages` with a 302 to a host it chooses

2013/// and harvest the bearer token from the request we would dutifully re-send there. Sessions

2114/// are bound to a single relay by design (§6), so a cross-host redirect is never legitimate

22−/// — refusing it costs nothing and closes the token-exfiltration path. Same-host redirects

23−/// (e.g. HTTP → HTTPS upgrade on the same host) are allowed; the Authorization header stays

24−/// within the relay's own host. Returning `nil` from the completion handler does not error

25−/// the task: it stops the redirect and hands the 3xx response itself back to the caller,

26−/// which the core sees as a non-2xx status and treats as a failed request.

15+/// — refusing it costs nothing and closes the token-exfiltration path.

2716///

28−/// **Response size limiting.** As body chunks arrive we accumulate the byte count per task

29−/// and cancel the task the moment it crosses `maxResponseBytes`, so a multi-gigabyte body

30−/// never fully materializes in memory. Cancelling surfaces to the caller as a `URLError`

31−/// with code `.cancelled`, which `Http.perform` maps to a transport error.

32−private final class HttpSessionDelegate: NSObject, URLSessionTaskDelegate, URLSessionDataDelegate {

33− let maxResponseBytes: Int

34−

35− /// Per-task accumulated byte counts. The delegate is shared across every concurrent

36− /// request, so a single shared counter would conflate their bodies — key by task instead.

37− /// Guarded by `lock` because delegate callbacks arrive on the session's own (non-main)

38− /// queue and may interleave across tasks.

39− private var taskSizes: [URLSessionTask: Int] = [:]

40− private let lock = NSLock()

41−

42− init(maxResponseBytes: Int) {

43− self.maxResponseBytes = maxResponseBytes

44− }

45−

17+/// Returning `nil` from the completion handler does not error the task: it stops the

18+/// redirect and hands the 3xx response itself back to the caller, which the core sees as a

19+/// non-2xx status and treats as a failed request.

20+private final class NoRedirectDelegate: NSObject, URLSessionTaskDelegate {

4621 func urlSession(

4722 _ session: URLSession,

4823 task: URLSessionTask,

@@ -50,55 +25,20 @@ private final class HttpSessionDelegate: NSObject, URLSessionTaskDelegate, URLSe

5025 newRequest request: URLRequest,

5126 completionHandler: @escaping (URLRequest?) -> Void

5227 ) {

53− // Allow same-host redirects (e.g. HTTP → HTTPS upgrade on the same host).

54− // Cancel cross-host redirects — a hostile relay could redirect to an

55− // attacker-controlled host and harvest the Authorization header.

56− if let originalURL = task.currentRequest?.url,

57− let redirectHost = request.url?.host?.lowercased(),

58− let originalHost = originalURL.host?.lowercased(),

59− redirectHost == originalHost {

60− completionHandler(request)

61− } else {

62− completionHandler(nil)

63− }

64− }

65−

66− func urlSession(

67− _ session: URLSession,

68− dataTask: URLSessionDataTask,

69− didReceive data: Data

70− ) {

71− lock.lock()

72− let total = (taskSizes[dataTask] ?? 0) + data.count

73− taskSizes[dataTask] = total

74− let exceeded = total > maxResponseBytes

75− lock.unlock()

76− if exceeded {

77− dataTask.cancel()

78− }

79− }

80−

81− func urlSession(

82− _ session: URLSession,

83− task: URLSessionTask,

84− didCompleteWithError error: Error?

85− ) {

86− lock.lock()

87− taskSizes.removeValue(forKey: task)

88− lock.unlock()

28+ completionHandler(nil)

8929 }

9030}

9131

9232enum Http {

9333 /// Strongly held by `session` for the app's lifetime — the session is never invalidated,

9434 /// so the delegate is never released. That is the intended shape here, not a leak.

95− private static let httpDelegate = HttpSessionDelegate(maxResponseBytes: maxResponseBytes)

35+ private static let redirectDelegate = NoRedirectDelegate()

9636

9737 /// A private, ephemeral session. `URLSession.shared` would hand every relay a

9838 /// persistent cookie jar and an on-disk response cache — a relay is untrusted

9939 /// infrastructure and must not be able to pin a stable identifier on the client

10040 /// or leave polled ciphertext lying around on disk. It would also follow redirects,

101− /// which is what `HttpSessionDelegate` is here to prevent.

41+ /// which is what `NoRedirectDelegate` is here to prevent.

10242 private static let session: URLSession = {

10343 let config = URLSessionConfiguration.ephemeral

10444 config.httpCookieAcceptPolicy = .never

@@ -108,13 +48,11 @@ enum Http {

10848 config.requestCachePolicy = .reloadIgnoringLocalAndRemoteCacheData

10949 config.timeoutIntervalForRequest = 70 // server long-polls for ~25s

11050 config.tlsMinimumSupportedProtocolVersion = .TLSv12

111− return URLSession(configuration: config, delegate: httpDelegate, delegateQueue: nil)

51+ return URLSession(configuration: config, delegate: redirectDelegate, delegateQueue: nil)

11252 }()

11353

11454 static func perform(_ req: HttpRequest) async -> HttpResult {

115− guard let url = URL(string: req.url),

116− let scheme = url.scheme,

117− scheme == "http" || scheme == "https" else {

55+ guard let url = URL(string: req.url) else {

11856 return .err(.url(req.url))

11957 }

12058 var request = URLRequest(url: url)

@@ -134,10 +72,6 @@ enum Http {

13472 headers: headers(of: http),

13573 body: [UInt8](data)

13674 ))

137− } catch let error as URLError where error.code == .cancelled {

138− // The size-limit delegate cancels the task when the body exceeds the cap.

139− // Treat it as a transport error so the core backs off and retries.

140− return .err(.io("response body exceeded \(maxResponseBytes) bytes"))

14175 } catch let error as URLError where error.code == .timedOut {

14276 return .err(.timeout)

14377 } catch {

apple/SkrepkaApp/PhotoPicker.swift+1−23

@@ -62,29 +62,7 @@ struct PhotoPicker: UIViewControllerRepresentable {

6262 guard let source = CGImageSourceCreateWithURL(url as CFURL, nil),

6363 let thumb = CGImageSourceCreateThumbnailAtIndex(source, 0, options as CFDictionary)

6464 else { return nil }

65− let image = UIImage(cgImage: thumb)

66− // Reduce quality until the base64 fits within the protocol cap (MAX_PHOTO_LEN,

67− // 64 KiB). A high-detail 256px frame can exceed the cap even at q0.7; without

68− // this loop `SaveProfile` rejects the whole profile with no recourse for the user.

69− let maxBase64Len = 64 * 1024

70− var quality: CGFloat = 0.7

71− while quality > 0.1 {

72− if let jpegData = image.jpegData(compressionQuality: quality) {

73− let base64 = jpegData.base64EncodedString()

74− if base64.count <= maxBase64Len {

75− return base64

76− }

77− }

78− quality -= 0.1

79− }

80− // Last resort: the smallest quality that still produces something.

81− // If even this exceeds the cap, return nil so onCancel fires rather

82− // than sending an oversized payload the core will reject.

83− let lastResort = image.jpegData(compressionQuality: 0.1)?.base64EncodedString()

84− if let result = lastResort, result.count <= maxBase64Len {

85− return result

86− }

87− return nil

65+ return UIImage(cgImage: thumb).jpegData(compressionQuality: 0.7)?.base64EncodedString()

8866 }

8967 }

9068}

apple/SkrepkaApp/QRView.swift+2−36

@@ -21,9 +21,6 @@ func qrImage(_ string: String) -> UIImage? {

2121/// A QR code carries whatever its author put there. Strip a leading scheme so a share

2222/// link (`skrepka:<key>`, `https://…/<key>`) yields the bare key the core will accept,

2323/// and so the pubkey field never silently fills with an unrelated URL.

24−// NOTE: This URL scheme stripping is arguably business logic that belongs in

25−// the core (see AGENTS.md). It is kept here for now because moving it requires

26−// an FFI change. The core's `try_parse_pubkey` validates the result regardless.

2724func scannedKeyPayload(_ raw: String) -> String {

2825 var value = raw.trimmingCharacters(in: .whitespacesAndNewlines)

2926 let schemes = ["skrepka://", "skrepka:", "https://", "http://"]

@@ -78,24 +75,6 @@ final class ScannerVC: UIViewController {

7875 override func viewDidLoad() {

7976 super.viewDidLoad()

8077 view.backgroundColor = .black

81−

82− let status = AVCaptureDevice.authorizationStatus(for: .video)

83− switch status {

84− case .authorized:

85− startSession()

86− case .notDetermined:

87− AVCaptureDevice.requestAccess(for: .video) { [weak self] granted in

88− DispatchQueue.main.async {

89− if granted { self?.startSession() }

90− else { self?.showPermissionDenied() }

91− }

92− }

93− default:

94− showPermissionDenied()

95− }

96− }

97−

98− private func startSession() {

9978 guard let device = AVCaptureDevice.default(for: .video),

10079 let input = try? AVCaptureDeviceInput(device: device),

10180 session.canAddInput(input) else { return }

@@ -114,19 +93,6 @@ final class ScannerVC: UIViewController {

11493 previewLayer = preview

11594 }

11695

117− private func showPermissionDenied() {

118− let label = UILabel()

119− label.text = "Camera permission required"

120− label.textAlignment = .center

121− label.textColor = .secondaryLabel

122− view.addSubview(label)

123− label.translatesAutoresizingMaskIntoConstraints = false

124− NSLayoutConstraint.activate([

125− label.centerXAnchor.constraint(equalTo: view.centerXAnchor),

126− label.centerYAnchor.constraint(equalTo: view.centerYAnchor),

127− ])

128− }

129−

13096 override func viewDidLayoutSubviews() {

13197 super.viewDidLayoutSubviews()

13298 previewLayer?.frame = view.bounds

@@ -134,7 +100,7 @@ final class ScannerVC: UIViewController {

134100

135101 override func viewWillAppear(_ animated: Bool) {

136102 super.viewWillAppear(animated)

137− if !session.isRunning && !session.inputs.isEmpty {

103+ if !session.isRunning {

138104 DispatchQueue.global(qos: .userInitiated).async { self.session.startRunning() }

139105 }

140106 }

@@ -146,4 +112,4 @@ final class ScannerVC: UIViewController {

146112 DispatchQueue.global(qos: .userInitiated).async { self.session.stopRunning() }

147113 }

148114 }

149−}

115+}

apple/SkrepkaApp/SkrepkaApp.swift+2−4

@@ -151,15 +151,13 @@ enum BackgroundRefresh {

151151 /// Waits for a condition on the view, or for the deadline (or expiry) to overtake it.

152152 ///

153153 /// The core has nothing to await — it publishes a `ViewModel` and that is the whole of

154− /// its output — so the shell watches that. A 500ms tick across the handful of transitions

154+ /// its output — so the shell watches that. A 200ms tick across the handful of transitions

155155 /// this cares about is cheaper than threading a Combine subscription through an actor hop.

156− /// The previous 200ms interval was unnecessarily aggressive for a background task with a

157− /// 25s budget that only cares about a few state transitions.

158156 private static func settle(by deadline: Date, until condition: () -> Bool) async -> Bool {

159157 while !condition() {

160158 guard !Task.isCancelled, Date() < deadline else { return false }

161159 // Cancellation makes this throw at once; the guard above is what breaks the loop.

162− try? await Task.sleep(for: .milliseconds(500))

160+ try? await Task.sleep(for: .milliseconds(200))

163161 }

164162 return true

165163 }

core/Cargo.toml−1

@@ -45,7 +45,6 @@ zstd.workspace = true

4545rand_core.workspace = true

4646uuid.workspace = true

4747hex.workspace = true

48−base64.workspace = true

4948zeroize.workspace = true

5049url.workspace = true

5150

core/src/app.rs+141−512

@@ -9,9 +9,6 @@ use std::collections::{BTreeMap, HashMap, HashSet, VecDeque};

99use std::sync::Arc;

1010use std::time::{Duration, SystemTime, UNIX_EPOCH};

1111

12−use base64::prelude::*;

13−use base64::Engine;

14−

1512use crux_core::{

1613 macros::effect,

1714 render::{render, RenderOperation},

@@ -61,24 +58,6 @@ const MAX_CONTACTS: usize = 500;

6158/// the budget is dropped exactly like an undecryptable blob would be.

6259const MAX_POLL_TOTAL_BYTES: usize = 64 * 1024 * 1024;

6360

64−/// Cap on the number of events we will attempt to decrypt out of a single poll

65−/// page, independent of the byte budget. Minimum-size blobs (173 bytes decoded)

66−/// would otherwise permit ~388K events within the 64 MiB byte budget, each

67−/// costing a full scalar mult + SHA-512 + AEAD pass — enough to freeze the app

68−/// for tens of seconds per poll. An honest relay caps at 50 events

69−/// (`maxPollEvents`); this is a hostile-relay bound. Set above `MAX_ACK_IDS`

70−/// (1024) so a legitimate large page from one sender still fully processes.

71−const MAX_POLL_EVENTS: usize = 2000;

72−

73−/// Upper bound on a poll response body we will buffer and parse, in bytes.

74−///

75−/// Before the per-blob byte/count budgets in `ingest_poll` ever run, the client

76−/// reads the entire response body into a `Vec<u8>` and deserializes it. A

77−/// multi-gigabyte response from a hostile relay would OOM the app before

78−/// `ingest_poll`'s defenses are consulted. This cap (generously above what 50

79−/// max-size blobs + JSON envelope could cost) bounds the allocation.

80−const MAX_POLL_RESPONSE_BYTES: usize = 64 * 1024 * 1024;

81−

8261/// How long a poll may stay in flight before we assume the shell lost it.

8362///

8463/// `polling` gates the whole long-poll loop, and it is only cleared by a

@@ -108,12 +87,6 @@ const POLL_WATCHDOG_MS: u64 = 90_000;

10887/// one costs a redundant request.

10988const FLUSH_WATCHDOG_MS: u64 = 90_000;

11089

111−/// How long an auth round-trip may stay in flight before we assume the

112−/// shell lost it. Same rationale as `POLL_WATCHDOG_MS`: `authenticating`

113−/// gates the whole auth flow, and without a watchdog a dropped effect

114−/// leaves it stuck forever. Kept above the 70 s shell HTTP timeout.

115−const AUTH_WATCHDOG_MS: u64 = 90_000;

116−

11790/// Messages per `/messages` request.

11891///

11992/// The relay rejects a longer batch outright (`413 batch_too_large`,

@@ -147,18 +120,10 @@ const K_PROFILE: &str = "profile";

147120const K_CONTACTS: &str = "contacts";

148121const K_CURSOR: &str = "cursor";

149122const K_OUTBOX: &str = "outbox";

150−const K_SEEN_IDS: &str = "seen_ids";

151123fn k_messages(peer: &str) -> String {

152124 format!("messages:{peer}")

153125}

154126

155−/// N7: Cap on the per-peer `seen_ids` dedup set. Without a cap the set grows

156−/// without bound — a peer who sends thousands of messages accumulates

157−/// thousands of IDs, and the `seen_ids` kv blob is rewritten in full on every

158−/// incoming message. Kept well above `MAX_MESSAGES_PER_PEER` (1000) so a

159−/// trim-and-replay within the conversation window still hits the set.

160−const MAX_SEEN_IDS_PER_PEER: usize = 2000;

161−

162127// ---------------------------------------------------------------------------

163128// Effect

164129// ---------------------------------------------------------------------------

@@ -226,9 +191,6 @@ pub enum Event {

226191 LoadedOutbox(#[facet(opaque)] KvData),

227192 #[serde(skip)]

228193 #[facet(skip)]

229− LoadedSeenIds(#[facet(opaque)] KvData),

230− #[serde(skip)]

231− #[facet(skip)]

232194 LoadedMessages(String, #[facet(opaque)] KvData),

233195 #[serde(skip)]

234196 #[facet(skip)]

@@ -262,17 +224,11 @@ pub enum Event {

262224 #[serde(skip)]

263225 #[facet(skip)]

264226 StartFlush,

265− /// Fires `FLUSH_WATCHDOG_MS` after generation `n`'s flush is issued; a no-op

266− /// unless that exact send is somehow still in flight — same pattern as

267− /// `PollWatchdog`.

268− #[serde(skip)]

269− #[facet(skip)]

270− FlushWatchdog(u64),

271− /// Fires `AUTH_WATCHDOG_MS` after generation `n`'s auth round-trip is

272− /// issued; a no-op unless that exact auth is somehow still in flight.

227+ /// Fires `FLUSH_WATCHDOG_MS` after a flush is issued; a no-op unless the

228+ /// send is somehow still in flight — same pattern as `PollWatchdog`.

273229 #[serde(skip)]

274230 #[facet(skip)]

275− AuthWatchdog(u64),

231+ FlushWatchdog,

276232 #[serde(skip)]

277233 #[facet(skip)]

278234 ChallengeResult(u64, #[facet(opaque)] HttpResult),

@@ -284,7 +240,7 @@ pub enum Event {

284240 PollResult(u64, #[facet(opaque)] HttpResult),

285241 #[serde(skip)]

286242 #[facet(skip)]

287− SendResult(u64, #[facet(opaque)] HttpResult),

243+ SendResult(#[facet(opaque)] HttpResult),

288244}

289245

290246// ---------------------------------------------------------------------------

@@ -310,9 +266,9 @@ pub enum Page {

310266 EditProfile,

311267}

312268

313−/// The six kv keys loaded at startup (`settings`, `profile`, `contacts`,

314−/// `cursor`, `outbox`, `seen_ids`). `Connect` waits for all of them.

315−const STARTUP_LOADS: u8 = 6;

269+/// The five kv keys loaded at startup (`settings`, `profile`, `contacts`,

270+/// `cursor`, `outbox`). `Connect` waits for all of them.

271+const STARTUP_LOADS: u8 = 5;

316272

317273/// The batch a live `/messages` request is carrying: the first `count` items of

318274/// the outbox, all bound for `recipient`.

@@ -338,12 +294,6 @@ pub struct Model {

338294 profile: OwnProfile,

339295 contacts: BTreeMap<String, Contact>,

340296 messages: BTreeMap<String, Vec<StoredMessage>>,

341− /// Q18: Per-peer dedup ID set, independent of the trimmed conversation.

342− /// Without this, a replayed blob whose `id` was aged out by `trim_history`

343− /// (past the 1000-message cap) passes the dedup check and re-enters the

344− /// conversation. This set is loaded from and persisted to kv alongside

345− /// messages, so it survives restarts.

346− seen_ids: BTreeMap<String, HashSet<String>>,

347297 outbox: VecDeque<OutboxItem>,

348298 cursor: i64,

349299 token: Option<String>,

@@ -386,12 +336,6 @@ pub struct Model {

386336 /// items it sent off the head of the outbox, so two overlapping sends would

387337 /// pop each other's messages.

388338 flushing: bool,

389− /// Which flush the in-flight `SendResult` / `FlushWatchdog` is allowed to

390− /// belong to. Same pattern as `poll_gen`: bumped every time a flush is

391− /// issued and every time one is abandoned, so a `SendResult` or watchdog

392− /// from a superseded send cannot clear the guard or pop items belonging to

393− /// the replacement.

394− flush_gen: u64,

395339 /// What the in-flight send will pop off the head of the outbox when it

396340 /// succeeds — see `InFlight`. `None` while nothing is in flight, and also

397341 /// while a send is in flight whose items have since been removed from under

@@ -456,7 +400,6 @@ impl Default for Model {

456400 profile: OwnProfile::default(),

457401 contacts: BTreeMap::new(),

458402 messages: BTreeMap::new(),

459− seen_ids: BTreeMap::new(),

460403 outbox: VecDeque::new(),

461404 cursor: 0,

462405 token: None,

@@ -468,7 +411,6 @@ impl Default for Model {

468411 authenticating: false,

469412 auth_gen: 0,

470413 flushing: false,

471− flush_gen: 0,

472414 in_flight: None,

473415 send_batch_budget: None,

474416 loads_pending: 0,

@@ -520,24 +462,6 @@ impl Model {

520462 self.auth_gen

521463 }

522464

523− /// Open a new flush generation and return it. Same pattern as

524− /// `next_poll_gen`: a `SendResult` or `FlushWatchdog` whose generation no

525− /// longer matches is dropped, so a late result from a superseded send

526− /// cannot clear the guard or pop items belonging to the replacement.

527− fn next_flush_gen(&mut self) -> u64 {

528− self.flush_gen = self.flush_gen.wrapping_add(1);

529− self.flush_gen

530− }

531−

532− /// Abandon the in-flight flush, if any: release the guard and retire the

533− /// generation so a late `SendResult` cannot clear the *replacement* flush's

534− /// guard or pop its items.

535− fn abandon_flush(&mut self) {

536− self.flushing = false;

537− self.in_flight = None;

538− self.flush_gen = self.flush_gen.wrapping_add(1);

539− }

540−

541465 /// Abandon the in-flight auth round-trip (either leg).

542466 fn abandon_auth(&mut self) {

543467 self.authenticating = false;

@@ -584,7 +508,7 @@ fn now_ms() -> i64 {

584508 SystemTime::now()

585509 .duration_since(UNIX_EPOCH)

586510 .map(|d| d.as_millis() as i64)

587− .unwrap_or(1)

511+ .unwrap_or(0)

588512}

589513

590514/// Bare lowercased hostname of a server URL (no scheme/port/trailing dot).

@@ -672,16 +596,6 @@ struct PollEvent {

672596 #[serde(rename = "encryptedBlob")]

673597 encrypted_blob: String,

674598}

675−

676−/// Q17: Deferred delivery-ack accumulator. Collects ack_ids and the max `ts`

677−/// across all `delivery.ack` payloads from one sender in a single poll page,

678−/// so the staleness check and watermark update run once per sender after the

679−/// event loop — immune to relay page ordering.

680−#[derive(Default)]

681−struct PendingAck {

682− ts: i64,

683− ids: HashSet<String>,

684−}

685599#[derive(Serialize)]

686600struct SendBatch {

687601 messages: Vec<Envelope>,

@@ -725,7 +639,6 @@ impl App for Skrepka {

725639 KeyValue::get(K_CONTACTS).then_send(Event::LoadedContacts),

726640 KeyValue::get(K_CURSOR).then_send(Event::LoadedCursor),

727641 KeyValue::get(K_OUTBOX).then_send(Event::LoadedOutbox),

728− KeyValue::get(K_SEEN_IDS).then_send(Event::LoadedSeenIds),

729642 ])

730643 .and(render())

731644 }

@@ -803,51 +716,10 @@ impl App for Skrepka {

803716 }

804717 self.startup_done(model).and(render())

805718 }

806− Event::LoadedSeenIds(res) => {

807− match parse_kv::<BTreeMap<String, HashSet<String>>>(res) {

808− Ok(Some(map)) => model.seen_ids = map,

809− Ok(None) => {}

810− Err(()) => {

811− // Non-fatal: dedup falls back to the conversation-derived

812− // set, which is weaker but functional.

813− model.seen_ids = BTreeMap::new();

814− }

815− }

816− self.startup_done(model).and(render())

817− }

818719 Event::LoadedMessages(peer, res) => {

819720 match parse_kv::<Vec<StoredMessage>>(res) {

820721 Ok(Some(list)) => {

821− // D5: Add on-disk message IDs to seen_ids so future

822− // replays don't pass dedup. Without this, a seen_ids

823− // kv load failure leaves the set empty, and on-disk

824− // messages aren't protected against replay.

825− if let Some(id_set) = model.seen_ids.get_mut(&peer) {

826− id_set.extend(list.iter().map(|m| m.id.clone()));

827− }

828− // Merge: a poll that beat this lazy load may have already

829− // inserted messages for this peer. Overwriting with the

830− // on-disk list (which the GET read before the poll wrote)

831− // would silently destroy the freshly-ingested messages.

832− // Union by id, keeping both the on-disk history and any

833− // in-memory additions.

834− match model.messages.get_mut(&peer) {

835− Some(existing) => {

836− let existing_ids: HashSet<&String> =

837− existing.iter().map(|m| &m.id).collect();

838− let new_msgs: Vec<StoredMessage> = list

839− .into_iter()

840− .filter(|m| !existing_ids.contains(&m.id))

841− .collect();

842− existing.extend(new_msgs);

843− // Re-sort by ts to maintain the invariant.

844− existing.sort_by_key(|m| m.ts);

845− trim_history(existing);

846− }

847− None => {

848− model.messages.insert(peer, list);

849− }

850− }

722+ model.messages.insert(peer, list);

851723 }

852724 Ok(None) => {}

853725 Err(()) => {

@@ -957,20 +829,11 @@ impl App for Skrepka {

957829 // would then ack a sequence number B never issued, and B would

958830 // drop every message waiting for us.

959831 model.abandon_poll();

960− // ...and retire the send that is still in flight *to relay A*,

961− // for the same reason: its `SendResult` carries A's acceptance,

962− // and popping items here would eat whatever the new relay's

963− // send is about to carry. The generation check in `SendResult`

964− // is what makes the late result a no-op.

965− model.abandon_flush();

966832 // The old relay's rate limit was the old relay's opinion. A new one is

967833 // entitled to take our sends immediately, and carrying the pause over

968834 // would park the outbox against a limit that no longer applies.

969835 model.flush_paused_until = 0;

970836 model.send_retries = 0;

971− // D2: Reset poll retries too — the new relay's poll failures

972− // should start fresh, not inherit the old relay's backoff.

973− model.poll_retries = 0;

974837 let writes = if self.refuse_write(model) {

975838 Command::done()

976839 } else {

@@ -1077,7 +940,6 @@ impl App for Skrepka {

1077940 Event::DeleteContact { peer } => {

1078941 model.contacts.remove(&peer);

1079942 model.messages.remove(&peer);

1080− model.seen_ids.remove(&peer);

1081943 model.outbox.retain(|item| item.recipient != peer);

1082944 // The send in flight may be carrying the very items we just

1083945 // dropped; if so its result must pop nothing.

@@ -1094,8 +956,6 @@ impl App for Skrepka {

1094956 // message the user just asked us to forget. Delete the key.

1095957 KeyValue::delete(k_messages(&peer)).then_send(Event::Saved),

1096958 self.persist_outbox(model),

1097− // Q18: persist the seen_ids map without the removed peer.

1098− self.persist_seen_ids(model),

1099959 ])

1100960 .and(render())

1101961 }

@@ -1123,13 +983,6 @@ impl App for Skrepka {

1123983 model.error = Some("photo too large".into());

1124984 return render();

1125985 }

1126− // S6: Validate the photo is valid base64 before broadcasting —

1127− // the recipient's parse_payload rejects invalid base64, so an

1128− // invalid photo would be silently dropped by every recipient.

1129− if photo.as_ref().is_some_and(|p| BASE64_STANDARD.decode(p).is_err()) {

1130− model.error = Some("photo is not valid base64".into());

1131− return render();

1132− }

1133986 model.profile = OwnProfile {

1134987 display_name,

1135988 bio,

@@ -1138,8 +991,8 @@ impl App for Skrepka {

1138991 model.page = Page::Conversations;

1139992 let ts = now_ms();

1140993 let payload = Payload::Profile {

1141− display_name: Some(model.profile.display_name.clone()),

1142− bio: Some(model.profile.bio.clone()),

994+ display_name: model.profile.display_name.clone(),

995+ bio: model.profile.bio.clone(),

1143996 photo: model.profile.photo.clone(),

1144997 };

1145998 // Broadcast the new profile to every contact we haven't blocked.

@@ -1218,11 +1071,6 @@ impl App for Skrepka {

12181071 let gen = model.next_auth_gen();

12191072 req.build()

12201073 .then_send(move |r| Event::ChallengeResult(gen, r))

1221− .and(

1222− Time::notify_after(Duration::from_millis(AUTH_WATCHDOG_MS))

1223− .0

1224− .then_send(move |_| Event::AuthWatchdog(gen)),

1225− )

12261074 .and(render())

12271075 }

12281076 Err(_) => {

@@ -1401,90 +1249,35 @@ impl App for Skrepka {

14011249 return render();

14021250 }

14031251 let bytes = resp.take_body().unwrap_or_default();

1404− // Bound the response before parsing: a hostile relay can return

1405− // a multi-gigabyte body that OOMs the app before `ingest_poll`'s

1406− // per-blob budgets are even consulted.

1407− if bytes.len() > MAX_POLL_RESPONSE_BYTES {

1408− model.error = Some("relay sent an oversized poll response".into());

1409− return self.backoff_poll(model);

1410− }

1411− // Q25: A malformed or unparseable poll response must not be

1412− // treated as an empty page — `unwrap_or_default()` would adopt

1413− // cursor 0, forcing a re-fetch from the beginning and wasting

1414− // bandwidth on already-seen (deduped) messages. Back off instead.

1415− let parsed: PollResp = match serde_json::from_slice(&bytes) {

1416− Ok(p) => p,

1417− Err(_) => {

1418− model.error = Some("relay sent a malformed poll response".into());

1419− return self.backoff_poll(model);

1420− }

1421− };

1422− let cursor_before = model.cursor;

1252+ let parsed: PollResp = serde_json::from_slice(&bytes).unwrap_or_default();

14231253 let cmd = self.ingest_poll(model, parsed);

14241254 // The re-poll hangs off the *cursor write*, not off this event.

14251255 // Polling again is what acks the batch we just took — the server

14261256 // deletes everything up to `cursor` — so it must not happen until

14271257 // the batch is durable on our side. `SavedCursor` re-polls.

1428− //

1429− // Arm a watchdog alongside the cursor write: if the shell ever

1430− // drops the KV effect (suspension, bug), `SavedCursor` never fires,

1431− // `polling` stays `false`, and the loop is dead until the next

1432− // foreground `Connect`. The watchdog fires `Poll` if the loop is

1433− // still idle — same pattern as the poll/send HTTP watchdogs.

1434− //

1435− // Skip the cursor write when the cursor did not advance (an empty

1436− // or fully-deduped page): there is nothing new to persist, so

1437− // re-poll directly. The watchdog is still armed as a fallback.

1438− let cursor_advanced = model.cursor != cursor_before;

1439− cmd.and(if cursor_advanced {

1258+ cmd.and(

14401259 KeyValue::set(K_CURSOR, json_bytes(&model.cursor))

1441− .then_send(Event::SavedCursor)

1442− } else {

1443− Command::event(Event::Poll)

1444− })

1445− .and(

1446− Time::notify_after(Duration::from_millis(POLL_WATCHDOG_MS))

1447− .0

1448− .then_send(|_| Event::Poll),

1260+ .then_send(Event::SavedCursor),

14491261 )

14501262 .and(render())

14511263 }

14521264

14531265 // ---------------- outbox ----------------

14541266 Event::StartFlush => self.flush_next(model),

1455− Event::FlushWatchdog(gen) => {

1456− // Only the flush this watchdog was armed for, and only while it

1457− // is still the current one and still in flight. A watchdog whose

1458− // send already completed (or was superseded) is a stale timer and

1459− // must not touch a healthy successor — same pattern as

1460− // `PollWatchdog`.

1461− if gen != model.flush_gen || !model.flushing {

1267+ Event::FlushWatchdog => {

1268+ // The send request never came back — the shell dropped the HTTP

1269+ // effect (backgrounded app, bug), and `flushing` has been stuck

1270+ // ever since. Release the guard and retry the flush. The late

1271+ // `SendResult`, if it ever arrives, finds `in_flight` already

1272+ // cleared and pops nothing.

1273+ if !model.flushing {

14621274 return Command::done();

14631275 }

1464− // Retire it as we give up on it. The request itself is not

1465− // cancelled, so if it eventually resolves the generation check

1466− // in `SendResult` is what stops it from popping the replacement's

1467− // items.

1468− model.abandon_flush();

1276+ model.flushing = false;

1277+ model.in_flight = None;

14691278 self.flush_next(model)

14701279 }

1471− Event::AuthWatchdog(gen) => {

1472− // Only the auth this watchdog was armed for, and only while it is

1473− // still the current one and still in flight.

1474− if gen != model.auth_gen || !model.authenticating {

1475− return Command::done();

1476− }

1477− model.abandon_auth();

1478− Command::event(Event::Authenticate)

1479− }

1480− Event::SendResult(gen, Ok(resp)) => {

1481− // A result for a send we already abandoned (a watchdog gave up

1482− // on it, or a server change invalidated it). Dropping it is safe

1483− // and required: its items were re-queued, so popping by count

1484− // here would eat whichever messages slid into their place.

1485− if gen != model.flush_gen {

1486− return Command::done();

1487− }

1280+ Event::SendResult(Ok(resp)) => {

14881281 // The in-flight send is over; `flush_next` refuses to run while

14891282 // this is set, so it must be cleared before *any* branch below.

14901283 model.flushing = false;

@@ -1574,24 +1367,16 @@ impl App for Skrepka {

15741367 // later, under load that has nothing to do with this one — starts

15751368 // at whatever height the last one climbed to.

15761369 model.send_retries = 0;

1577− // D3-app: Don't pop if kv is broken — the persist would be

1578− // refused, and the items would be lost from memory but still

1579− // on disk, causing duplicate sends on relaunch.

1580− if !model.kv_load_failed {

1581− for _ in 0..batch.map_or(0, |b| b.count) {

1582− model.outbox.pop_front();

1583− }

1370+ for _ in 0..batch.map_or(0, |b| b.count) {

1371+ model.outbox.pop_front();

15841372 }

15851373 return self.persist_outbox(model).and(self.flush_next(model));

15861374 }

15871375 // A transient failure: a 5xx, a rate limit, a relay restarting.

15881376 self.retry_batch(model, batch)

15891377 }

1590− Event::SendResult(gen, Err(_)) => {

1378+ Event::SendResult(Err(_)) => {

15911379 // A transport error is the same transient failure as a 5xx.

1592− if gen != model.flush_gen {

1593− return Command::done();

1594− }

15951380 model.flushing = false;

15961381 let batch = model.in_flight.take();

15971382 self.retry_batch(model, batch)

@@ -1766,16 +1551,6 @@ impl Skrepka {

17661551 KeyValue::set(k_messages(peer), json_bytes(&list)).then_send(Event::Saved)

17671552 }

17681553

1769− /// Q18: Persist the per-peer dedup ID set. Written alongside messages so

1770− /// the set survives restarts and covers IDs that `trim_history` has aged

1771− /// out of the conversation.

1772− fn persist_seen_ids(&self, model: &mut Model) -> Command<Effect, Event> {

1773− if self.refuse_write(model) {

1774− return Command::done();

1775− }

1776− KeyValue::set(K_SEEN_IDS, json_bytes(&model.seen_ids)).then_send(Event::Saved)

1777− }

1778−

17791554 fn schedule_reconnect(&self, model: &mut Model) -> Command<Effect, Event> {

17801555 let delay = backoff_ms(model.poll_retries);

17811556 model.poll_retries = model.poll_retries.saturating_add(1);

@@ -1874,21 +1649,14 @@ impl Skrepka {

18741649 .insert(peer.clone(), Contact::new(peer.clone(), String::new(), ts));

18751650 }

18761651

1877− let text = Payload::Text { id, body };

1878− model.outbox.push_back(OutboxItem::new(

1879− peer.clone(),

1880− Arc::new(protocol::serialize_payload(&text, ts)),

1881− ));

1882−

1883− // On first contact, share our profile *after* the text. The text

1884− // auto-creates the contact on the recipient's side; the profile that

1885− // follows in the same batch then applies to the now-existing contact.

1886− // (Previously profile was queued before the text, but the recipient's

1887− // ingest drops profiles from non-contacts, so the profile was lost.)

1652+ // On first contact, share our profile *before* the text so the

1653+ // recipient's first impression is a name and avatar, not a truncated

1654+ // @p that gets replaced a moment later. Both are queued behind any

1655+ // in-flight items, so the ordering is preserved through the outbox.

18881656 if was_new {

18891657 let profile = Payload::Profile {

1890− display_name: Some(model.profile.display_name.clone()),

1891− bio: Some(model.profile.bio.clone()),

1658+ display_name: model.profile.display_name.clone(),

1659+ bio: model.profile.bio.clone(),

18921660 photo: model.profile.photo.clone(),

18931661 };

18941662 model.outbox.push_back(OutboxItem::profile(

@@ -1897,6 +1665,12 @@ impl Skrepka {

18971665 ));

18981666 }

18991667

1668+ let text = Payload::Text { id, body };

1669+ model.outbox.push_back(OutboxItem::new(

1670+ peer.clone(),

1671+ Arc::new(protocol::serialize_payload(&text, ts)),

1672+ ));

1673+

19001674 Command::all([

19011675 self.persist_messages(model, &peer),

19021676 self.persist_contacts(model),

@@ -2024,7 +1798,6 @@ impl Skrepka {

20241798 };

20251799

20261800 model.flushing = true;

2027− let gen = model.next_flush_gen();

20281801 model.in_flight = Some(InFlight {

20291802 recipient,

20301803 count: messages.len(),

@@ -2035,11 +1808,11 @@ impl Skrepka {

20351808 .header("authorization", format!("Bearer {token}"))

20361809 .body_json(&SendBatch { messages })

20371810 {

2038− Ok(req) => persist.and(req.build().then_send(move |r| Event::SendResult(gen, r)))

1811+ Ok(req) => persist.and(req.build().then_send(Event::SendResult))

20391812 .and(

20401813 Time::notify_after(Duration::from_millis(FLUSH_WATCHDOG_MS))

20411814 .0

2042− .then_send(move |_| Event::FlushWatchdog(gen)),

1815+ .then_send(|_| Event::FlushWatchdog),

20431816 ),

20441817 Err(_) => {

20451818 // Not a dead loop: the next StartFlush (from a poll page or a

@@ -2110,20 +1883,8 @@ impl Skrepka {

21101883 return Command::done();

21111884 }

21121885 let prev_cursor = model.cursor;

2113− // Clamp the relay-supplied cursor: honest cursors are wall-clock-seeded

2114− // sequence numbers, so anything far in the future is a hostile or buggy

2115− // relay. Adopting `i64::MAX` would ack (delete) all queued mail on the

2116− // next poll and persist that poison across relaunches.

2117− let clamped_cursor = page.cursor.min(now_ms().saturating_add(60_000));

2118− // Q16: Only advance the cursor when the page actually carried events.

2119− // An empty page with a cursor higher than ours is suspicious — a

2120− // compromised relay could poison the cursor to ack (delete) messages

2121− // the client hasn't seen. When there are no events, there is nothing

2122− // to acknowledge, so the cursor should not move. (An honest relay's

2123− // empty-page cursor equals what the client sent, so this is a no-op

2124− // in the normal case.)

2125− if !page.events.is_empty() && clamped_cursor > model.cursor {

2126− model.cursor = clamped_cursor;

1886+ if page.cursor > model.cursor {

1887+ model.cursor = page.cursor;

21271888 }

21281889 let Some(id) = model.identity() else {

21291890 return Command::done();

@@ -2132,24 +1893,12 @@ impl Skrepka {

21321893 let now = now_ms();

21331894 let mut touched_convos: HashSet<String> = HashSet::new();

21341895 let mut contacts_dirty = false;

2135− let mut outbox_dirty = false;

21361896 // sender hex -> message ids needing acks

21371897 let mut ack_targets: BTreeMap<String, Vec<String>> = BTreeMap::new();

2138− // Q17: Per-sender deferred ack accumulation. Collected during the event

2139− // loop, applied after it — so relay page ordering cannot cause an older

2140− // ack to be dropped as stale by a newer one processed first.

2141− let mut pending_acks: HashMap<String, PendingAck> = HashMap::new();

1898+ // Lazily-built per-sender sets of known message IDs for O(1) text dedup.

1899+ let mut seen_ids: HashMap<String, HashSet<String>> = HashMap::new();

21421900

21431901 let mut budget = MAX_POLL_TOTAL_BYTES;

2144− let mut events_processed = 0usize;

2145− // N9: Track whether any event was successfully decrypted and stored.

2146− // When the budget/count is exhausted mid-page, we ack the page (keep

2147− // the advanced cursor) only if at least one event was processed —

2148− // the unprocessed tail is from a hostile/misconfigured relay and

2149− // losing them is better than livelocking. If zero events were

2150− // processed (a completely hostile page), restore the cursor so we

2151− // don't ack mail we never saw.

2152− let mut events_stored = 0usize;

21531902 for ev in page.events {

21541903 // Reject an oversized blob on its hex length, before it costs us a

21551904 // decode. No conforming sender produces one (the relay caps blobs at

@@ -2157,37 +1906,19 @@ impl Skrepka {

21571906 if ev.encrypted_blob.len() > MAX_BLOB_LEN * 2 {

21581907 continue;

21591908 }

2160− // Event count cap: the byte budget alone permits ~388K minimum-size

2161− // events, each costing a full decrypt attempt. A hostile relay can

2162− // freeze the app for tens of seconds per poll with a page of small

2163− // junk blobs. Stop processing past this count.

2164− if events_processed >= MAX_POLL_EVENTS {

2165− // N9: If we stored at least one event, keep the advanced cursor

2166− // to ack the page and avoid a livelock. The unprocessed events

2167− // are hostile junk or beyond our capacity — we can't process

2168− // them anyway, and re-fetching them forever would wedge the

2169− // client.

2170− if events_stored == 0 {

2171− model.cursor = prev_cursor;

2172− }

2173− model.error = Some("relay sent too many poll events".into());

2174− break;

2175− }

2176− events_processed += 1;

21771909 match budget.checked_sub(ev.encrypted_blob.len() / 2) {

21781910 Some(left) => budget = left,

21791911 None => {

2180− // N9: Budget exhausted. If we stored at least one event,

2181− // keep the advanced cursor to ack the page — re-fetching

2182− // an oversized page forever is a livelock. The unprocessed

2183− // events are beyond our capacity and would be re-served

2184− // on every poll, wedging the client. Acking them breaks

2185− // the loop. If zero events were stored (completely hostile

2186− // page), restore the cursor to avoid acking mail we

2187− // never saw.

2188− if events_stored == 0 {

2189− model.cursor = prev_cursor;

2190− }

1912+ // A page this large is a misbehaving relay, not real mail.

1913+ // Stop here; the rest of the page is discarded exactly as an

1914+ // undecryptable blob would be.

1915+ //

1916+ // Restore the cursor: it was advanced to `page.cursor` above,

1917+ // but we have not processed the remaining events. If we keep

1918+ // the advanced cursor, the next poll acks the whole page to

1919+ // the relay — including every event we skipped — and the

1920+ // relay deletes them. Those messages are permanently lost.

1921+ model.cursor = prev_cursor;

21911922 model.error = Some("relay sent an oversized poll page".into());

21921923 break;

21931924 }

@@ -2201,10 +1932,6 @@ impl Skrepka {

22011932 let Some(parsed) = protocol::parse_payload(&dec.plaintext) else {

22021933 continue;

22031934 };

2204− // D1: Any event that was successfully decrypted AND parsed counts

2205− // as "stored" for cursor advancement — the client has processed it

2206− // even if it was a duplicate/stale/stranger that was dropped.

2207− events_stored += 1;

22081935 let sender = dec.sender_hex;

22091936

22101937 // Mail from ourselves. A relay cannot forge this — the sender identity

@@ -2256,35 +1983,12 @@ impl Skrepka {

22561983 Contact::new(sender.clone(), String::new(), ts),

22571984 );

22581985 contacts_dirty = true;

2259− // D6-app: Send our profile to the new contact so they

2260− // see our display name and avatar, not just our @p.

2261− let profile = Payload::Profile {

2262− display_name: Some(model.profile.display_name.clone()),

2263− bio: Some(model.profile.bio.clone()),

2264− photo: model.profile.photo.clone(),

2265− };

2266− model.outbox.push_back(OutboxItem::profile(

2267− sender.clone(),

2268− Arc::new(protocol::serialize_payload(&profile, ts)),

2269− ));

2270− outbox_dirty = true;

22711986 }

22721987 let convo = model.messages.entry(sender.clone()).or_default();

2273− // Q18: Use the persistent per-peer dedup set from

2274− // `model.seen_ids` (loaded from kv at startup) instead of

2275− // deriving it from the trimmed conversation. Without this,

2276− // a replayed blob whose `id` was aged out by `trim_history`

2277− // (past the 1000-message cap) passes the dedup check and

2278− // re-enters the conversation.

2279− let id_set = model

2280− .seen_ids

2281− .entry(sender.clone())

2282− .or_default();

2283− // Also seed from the conversation in case the kv load was

2284− // missing or partial — covers the upgrade path.

2285− if id_set.is_empty() {

2286− id_set.extend(convo.iter().map(|m| m.id.clone()));

2287− }

1988+ // Lazily build the per-sender ID set on first touch.

1989+ let id_set = seen_ids.entry(sender.clone()).or_insert_with(|| {

1990+ convo.iter().map(|m| m.id.clone()).collect()

1991+ });

22881992 // dedup by id — O(1) via HashSet

22891993 if !id_set.contains(&msg_id) {

22901994 // The conversation is *kept* sorted rather than re-sorted:

@@ -2302,29 +2006,6 @@ impl Skrepka {

23022006 },

23032007 );

23042008 id_set.insert(msg_id.clone());

2305− // N7: Cap the dedup set so it doesn't grow without

2306− // bound. The set is rewritten to kv on every message

2307− // receipt, so an unbounded set makes every receipt

2308− // slower. Keep the most recent IDs by draining excess

2309− // from the oldest. `HashSet` has no ordering, so when

2310− // the cap is exceeded we rebuild from the conversation

2311− // (which is trimmed to MAX_MESSAGES_PER_PEER and

2312− // sorted by ts) — the oldest IDs in the set that are

2313− // no longer in the conversation are the ones to drop.

2314− if id_set.len() > MAX_SEEN_IDS_PER_PEER {

2315− let convo_ids: HashSet<&String> =

2316− convo.iter().map(|m| &m.id).collect();

2317− let excess = id_set.len() - MAX_SEEN_IDS_PER_PEER;

2318− let to_remove: Vec<String> = id_set

2319− .iter()

2320− .filter(|id| !convo_ids.contains(*id))

2321− .take(excess)

2322− .cloned()

2323− .collect();

2324− for id in to_remove {

2325− id_set.remove(&id);

2326− }

2327− }

23282009 trim_history(convo);

23292010 touched_convos.insert(sender.clone());

23302011 // Only ack a message we actually stored — a duplicate id

@@ -2333,26 +2014,39 @@ impl Skrepka {

23332014 }

23342015 }

23352016 Payload::DeliveryAck { ack_ids } => {

2336− // Q17: Defer the staleness check until after the event loop.

2337− // Within a single page, a relay can reorder events so that a

2338− // newer ack (higher ts) is processed before an older one. If

2339− // we applied the watermark immediately, the older ack would be

2340− // dropped as stale — even if it acks different message IDs.

2341− // Instead, accumulate all ack_ids per sender and the max ts,

2342− // then apply them in a second pass below the loop.

2343− let prev_ts = pending_acks

2017+ // Staleness check: drop a replayed ack whose ts predates the

2018+ // last one we processed for this contact.

2019+ let stale = model

2020+ .contacts

23442021 .get(&sender)

2345− .map(|p| p.ts)

2346− .unwrap_or(0);

2347− if ts > prev_ts {

2348− let entry = pending_acks.entry(sender.clone()).or_default();

2349− entry.ts = ts;

2022+ .is_some_and(|c| ts < c.last_ack_ts);

2023+ if stale {

2024+ continue;

2025+ }

2026+ // The watermark is clamped to *now*, not merely into the skew

2027+ // window: `ts` is the peer's to choose, and `last_ack_ts` is

2028+ // what every later ack is measured against. A single ack at

2029+ // `ts = i64::MAX` would otherwise park the watermark a minute

2030+ // into the future, and every honest ack that followed — the

2031+ // ones that actually mark our messages delivered — would read

2032+ // as stale and be dropped.

2033+ if let Some(c) = model.contacts.get_mut(&sender) {

2034+ c.last_ack_ts = ts.min(now);

2035+ contacts_dirty = true;

2036+ }

2037+ let ack_set: HashSet<String> = ack_ids.iter().cloned().collect();

2038+ if let Some(convo) = model.messages.get_mut(&sender) {

2039+ let mut changed = false;

2040+ for m in convo.iter_mut() {

2041+ if m.outgoing && ack_set.contains(&m.id) && !m.delivered {

2042+ m.delivered = true;

2043+ changed = true;

2044+ }

2045+ }

2046+ if changed {

2047+ touched_convos.insert(sender);

2048+ }

23502049 }

2351− pending_acks

2352− .entry(sender.clone())

2353− .or_default()

2354− .ids

2355− .extend(ack_ids);

23562050 }

23572051 Payload::Profile {

23582052 display_name,

@@ -2379,17 +2073,9 @@ impl Skrepka {

23792073 // A replayed profile at the same `ts` overwrites with identical

23802074 // content, which is a no-op in practice.

23812075 if ts >= c.last_profile_ts {

2382− // D13: Only update fields that are present (Some).

2383− // An absent field (None) means "don't change".

2384− if let Some(name) = display_name {

2385− c.display_name = name;

2386− }

2387− if let Some(b) = bio {

2388− c.bio = b;

2389− }

2390− if let Some(p) = photo {

2391− c.photo = Some(p);

2392− }

2076+ c.display_name = display_name;

2077+ c.bio = bio;

2078+ c.photo = photo;

23932079 c.last_profile_ts = ts.min(now);

23942080 contacts_dirty = true;

23952081 }

@@ -2397,42 +2083,6 @@ impl Skrepka {

23972083 }

23982084 }

23992085

2400− // Q17: Apply deferred delivery acks. Collected during the event loop

2401− // above, now applied with a single staleness check per sender using the

2402− // highest `ts` seen — so relay page ordering cannot cause an older ack

2403− // to be dropped as stale by a newer one processed first.

2404− for (sender, pending) in &pending_acks {

2405− let stale = model

2406− .contacts

2407− .get(sender)

2408− .is_some_and(|c| pending.ts < c.last_ack_ts);

2409− if stale {

2410− continue;

2411− }

2412− // The watermark is clamped to *now*, not merely into the skew window:

2413− // `ts` is the peer's to choose, and `last_ack_ts` is what every later

2414− // ack is measured against. A single ack at `ts = i64::MAX` would

2415− // otherwise park the watermark a minute into the future, and every

2416− // honest ack that followed — the ones that actually mark our messages

2417− // delivered — would read as stale and be dropped.

2418− if let Some(c) = model.contacts.get_mut(sender) {

2419− c.last_ack_ts = pending.ts.min(now);

2420− contacts_dirty = true;

2421− }

2422− if let Some(convo) = model.messages.get_mut(sender) {

2423− let mut changed = false;

2424− for m in convo.iter_mut() {

2425− if m.outgoing && pending.ids.contains(&m.id) && !m.delivered {

2426− m.delivered = true;

2427− changed = true;

2428− }

2429− }

2430− if changed {

2431− touched_convos.insert(sender.clone());

2432− }

2433− }

2434− }

2435−

24362086 // Queue delivery acks, in batches the recipient will actually accept.

24372087 //

24382088 // `parse_payload` drops a `delivery.ack` carrying more than `MAX_ACK_IDS`

@@ -2455,7 +2105,6 @@ impl Skrepka {

24552105 Arc::new(protocol::serialize_payload(&payload, ack_ts)),

24562106 ));

24572107 }

2458− outbox_dirty = true;

24592108 }

24602109

24612110 // Persist everything touched.

@@ -2463,16 +2112,10 @@ impl Skrepka {

24632112 for peer in &touched_convos {

24642113 cmds.push(self.persist_messages(model, peer));

24652114 }

2466− // Q18: Persist the dedup ID set whenever we touched conversations.

2467− if !touched_convos.is_empty() {

2468− cmds.push(self.persist_seen_ids(model));

2469− }

24702115 if contacts_dirty {

24712116 cmds.push(self.persist_contacts(model));

24722117 }

2473− if outbox_dirty {

2474− cmds.push(self.persist_outbox(model));

2475− }

2118+ cmds.push(self.persist_outbox(model));

24762119 cmds.push(Command::event(Event::StartFlush));

24772120 Command::all(cmds)

24782121 }

@@ -2545,7 +2188,7 @@ mod tests {

25452188 use crate::model::{MAX_OUTBOX_RETRIES, OUTBOX_TTL_MS};

25462189

25472190 fn with_identity() -> Model {

2548− let id = Identity::from_seed(&[3u8; 32]).unwrap();

2191+ let id = Identity::from_seed(&[3u8; 32]);

25492192 Model {

25502193 secret_key: Some(Zeroizing::new(id.secret_key.to_vec())),

25512194 my_pubkey: id.public_key_hex(),

@@ -2554,7 +2197,7 @@ mod tests {

25542197 }

25552198

25562199 fn peer_hex(seed: u8) -> String {

2557− Identity::from_seed(&[seed; 32]).unwrap().public_key_hex()

2200+ Identity::from_seed(&[seed; 32]).public_key_hex()

25582201 }

25592202

25602203 /// `Command::event` *queues* an event; it does not run it. The runtime drains

@@ -2577,7 +2220,7 @@ mod tests {

25772220

25782221 /// A poll page carrying one payload, encrypted from `sender_seed` to `me`.

25792222 fn page_from(sender_seed: u8, me: &Model, payload: &Payload, ts: i64) -> PollResp {

2580− let sender = Identity::from_seed(&[sender_seed; 32]).unwrap();

2223+ let sender = Identity::from_seed(&[sender_seed; 32]);

25812224 let recipient = Identity::from_secret_bytes(me.secret_key.as_ref().unwrap()).unwrap();

25822225 let json = protocol::serialize_payload(payload, ts);

25832226 let blob = crate::crypto::encrypt(

@@ -2666,8 +2309,7 @@ mod tests {

26662309 /// One full send round-trip: flush the outbox, then answer with `status`.

26672310 fn send_and_answer(app: &Skrepka, m: &mut Model, status: u16) {

26682311 let _ = app.update(Event::StartFlush, m);

2669− let gen = m.flush_gen;

2670− let _ = app.update(Event::SendResult(gen, Ok(ok_response(status))), m);

2312+ let _ = app.update(Event::SendResult(Ok(ok_response(status))), m);

26712313 }

26722314

26732315 // -----------------------------------------------------------------------

@@ -2696,7 +2338,7 @@ mod tests {

26962338 // The last one exhausts the budget: the head goes, and what was stuck

26972339 // behind it goes out.

26982340 let _ = app.update(Event::StartFlush, &mut m);

2699− let mut cmd = app.update(Event::SendResult(m.flush_gen, Ok(ok_response(503))), &mut m);

2341+ let mut cmd = app.update(Event::SendResult(Ok(ok_response(503))), &mut m);

27002342

27012343 assert_eq!(m.outbox.len(), 1, "the undeliverable item is dropped");

27022344 assert_eq!(m.outbox[0].recipient, behind, "and the queue moves on");

@@ -2815,7 +2457,7 @@ mod tests {

28152457

28162458 let _ = app.update(Event::StartFlush, &mut m);

28172459 let mut cmd = app.update(

2818− Event::SendResult(m.flush_gen, Ok(response_with_header(429, "retry-after", "2"))),

2460+ Event::SendResult(Ok(response_with_header(429, "retry-after", "2"))),

28192461 &mut m,

28202462 );

28212463

@@ -2846,7 +2488,7 @@ mod tests {

28462488 m.poll_retries = 0;

28472489

28482490 let _ = app.update(Event::StartFlush, &mut m);

2849− let mut cmd = app.update(Event::SendResult(m.flush_gen, Ok(ok_response(429))), &mut m);

2491+ let mut cmd = app.update(Event::SendResult(Ok(ok_response(429))), &mut m);

28502492

28512493 assert_eq!(m.outbox[0].retries, 0, "still not the message's fault");

28522494 assert_eq!(

@@ -2859,7 +2501,7 @@ mod tests {

28592501 // A second 429 climbs, rather than restarting at 3 s.

28602502 m.flush_paused_until = 0;

28612503 let _ = app.update(Event::StartFlush, &mut m);

2862− let mut cmd = app.update(Event::SendResult(m.flush_gen, Ok(ok_response(429))), &mut m);

2504+ let mut cmd = app.update(Event::SendResult(Ok(ok_response(429))), &mut m);

28632505 assert_eq!(scheduled_delays(&mut cmd), vec![backoff_ms(1)], "it climbs");

28642506 assert_eq!(m.send_retries, 2);

28652507 }

@@ -2877,7 +2519,7 @@ mod tests {

28772519

28782520 let _ = app.update(Event::StartFlush, &mut m);

28792521 let _ = app.update(

2880− Event::SendResult(m.flush_gen, Ok(response_with_header(429, "retry-after", "2"))),

2522+ Event::SendResult(Ok(response_with_header(429, "retry-after", "2"))),

28812523 &mut m,

28822524 );

28832525 assert!(

@@ -2933,7 +2575,7 @@ mod tests {

29332575

29342576 let _ = app.update(Event::StartFlush, &mut m);

29352577 let mut cmd = app.update(

2936− Event::SendResult(m.flush_gen, Ok(response_with_header(429, "retry-after", "999999999"))),

2578+ Event::SendResult(Ok(response_with_header(429, "retry-after", "999999999"))),

29372579 &mut m,

29382580 );

29392581

@@ -2968,7 +2610,7 @@ mod tests {

29682610 assert!(batches[0].iter().all(|e| e.to == peer));

29692611

29702612 // ...and its success clears the whole batch, not just the head.

2971− let _ = app.update(Event::SendResult(m.flush_gen, Ok(ok_response(200))), &mut m);

2613+ let _ = app.update(Event::SendResult(Ok(ok_response(200))), &mut m);

29722614 assert!(m.outbox.is_empty());

29732615 }

29742616

@@ -2993,7 +2635,7 @@ mod tests {

29932635 assert_eq!(batches[0].len(), 2, "only the run at the head");

29942636 assert!(batches[0].iter().all(|e| e.to == a));

29952637

2996− let mut cmd = app.update(Event::SendResult(m.flush_gen, Ok(ok_response(200))), &mut m);

2638+ let mut cmd = app.update(Event::SendResult(Ok(ok_response(200))), &mut m);

29972639 assert_eq!(m.outbox.len(), 2);

29982640 let batches = sent_batches(&mut cmd);

29992641 assert_eq!(batches[0].len(), 1, "then b's single message");

@@ -3016,7 +2658,7 @@ mod tests {

30162658 let batches = sent_batches(&mut cmd);

30172659 assert_eq!(batches[0].len(), MAX_SEND_BATCH);

30182660

3019− let _ = app.update(Event::SendResult(m.flush_gen, Ok(ok_response(200))), &mut m);

2661+ let _ = app.update(Event::SendResult(Ok(ok_response(200))), &mut m);

30202662 assert_eq!(m.outbox.len(), 20, "the rest stays queued for the next batch");

30212663 }

30222664

@@ -3078,7 +2720,7 @@ mod tests {

30782720 let sent_bytes: usize = first[0].iter().map(|e| e.encrypted_blob.len()).sum();

30792721

30802722 // ...and the relay says that was too big.

3081− let mut cmd = app.update(Event::SendResult(m.flush_gen, Ok(ok_response(413))), &mut m);

2723+ let mut cmd = app.update(Event::SendResult(Ok(ok_response(413))), &mut m);

30822724

30832725 assert_eq!(

30842726 m.send_batch_budget,

@@ -3099,7 +2741,7 @@ mod tests {

30992741 assert!(shrunk > 0, "but not an empty one");

31002742

31012743 // The relay takes the smaller batch, and exactly it is popped.

3102− let _ = app.update(Event::SendResult(m.flush_gen, Ok(ok_response(200))), &mut m);

2744+ let _ = app.update(Event::SendResult(Ok(ok_response(200))), &mut m);

31032745 assert_eq!(m.outbox.len(), 5 - shrunk, "exactly the batch that landed is gone");

31042746 assert_eq!(

31052747 m.send_batch_budget,

@@ -3204,7 +2846,7 @@ mod tests {

32042846 let parsed = protocol::parse_payload(item.envelope_json.as_bytes()).unwrap();

32052847 match parsed.payload {

32062848 Payload::Profile { display_name, .. } => {

3207− assert_eq!(display_name, Some("Three".to_string()), "and it is the latest one");

2849+ assert_eq!(display_name, "Three", "and it is the latest one");

32082850 }

32092851 _ => panic!("expected a profile"),

32102852 }

@@ -3247,12 +2889,12 @@ mod tests {

32472889 );

32482890 assert_eq!(m.outbox.len(), 2, "the in-flight item is left alone");

32492891

3250− let _ = app.update(Event::SendResult(m.flush_gen, Ok(ok_response(200))), &mut m);

2892+ let _ = app.update(Event::SendResult(Ok(ok_response(200))), &mut m);

32512893 assert_eq!(m.outbox.len(), 1, "the sent one is popped");

32522894 let parsed = protocol::parse_payload(m.outbox[0].envelope_json.as_bytes()).unwrap();

32532895 match parsed.payload {

32542896 Payload::Profile { display_name, .. } => assert_eq!(

3255− display_name, Some("New".to_string()),

2897+ display_name, "New",

32562898 "and the newer profile survives to be sent"

32572899 ),

32582900 _ => panic!("expected a profile"),

@@ -3293,7 +2935,7 @@ mod tests {

32932935 assert_eq!(m.outbox.len(), 1);

32942936

32952937 // The send lands. It must pop nothing.

3296− let _ = app.update(Event::SendResult(m.flush_gen, Ok(ok_response(200))), &mut m);

2938+ let _ = app.update(Event::SendResult(Ok(ok_response(200))), &mut m);

32972939 assert_eq!(m.outbox.len(), 1, "the friend's message is untouched");

32982940 assert_eq!(m.outbox[0].recipient, friend);

32992941 }

@@ -3434,8 +3076,8 @@ mod tests {

34343076 .insert(peer.clone(), Contact::new(peer.clone(), String::new(), 0));

34353077

34363078 let profile = |name: &str| Payload::Profile {

3437− display_name: Some(name.to_string()),

3438− bio: Some(String::new()),

3079+ display_name: name.into(),

3080+ bio: String::new(),

34393081 photo: None,

34403082 };

34413083 let page = page_from(9, &m, &profile("Far"), i64::MAX);

@@ -3532,11 +3174,8 @@ mod tests {

35323174 let (m, peer) = ingest_one_text_from_an_unblocked_peer();

35333175 assert_eq!(m.messages[&peer].len(), 1);

35343176 assert_eq!(m.messages[&peer][0].body, "hi");

3535− // D6-app: A profile broadcast is queued alongside the delivery.ack

3536− // so the new contact sees our display name and avatar.

3537− assert_eq!(m.outbox.len(), 2, "one delivery.ack + one profile queued");

3177+ assert_eq!(m.outbox.len(), 1, "one delivery.ack is queued");

35383178 assert_eq!(m.outbox[0].recipient, peer);

3539− assert_eq!(m.outbox[1].recipient, peer);

35403179 }

35413180

35423181 /// A peer sending `ts = i64::MAX` used to pin itself to the top of the

@@ -3973,7 +3612,7 @@ mod tests {

39733612 assert!(m.flushing);

39743613

39753614 let resp = crux_http::testing::ResponseBuilder::ok().body(Vec::new()).build();

3976− let _ = app.update(Event::SendResult(m.flush_gen, Ok(resp)), &mut m);

3615+ let _ = app.update(Event::SendResult(Ok(resp)), &mut m);

39773616

39783617 assert!(!m.flushing, "flushing must be cleared on the success path");

39793618 assert!(m.outbox.is_empty(), "the sent item is dropped from the outbox");

@@ -3995,7 +3634,7 @@ mod tests {

39953634

39963635 // Its success must both drop the item and let the *next* one go out.

39973636 let resp = crux_http::testing::ResponseBuilder::ok().body(Vec::new()).build();

3998− let _ = app.update(Event::SendResult(m.flush_gen, Ok(resp)), &mut m);

3637+ let _ = app.update(Event::SendResult(Ok(resp)), &mut m);

39993638 assert_eq!(m.outbox.len(), 1);

40003639 assert!(m.flushing, "the second item is now in flight");

40013640 }

@@ -4138,7 +3777,6 @@ mod tests {

41383777 Event::LoadedProfile(Ok(None)),

41393778 Event::LoadedContacts(Ok(None)),

41403779 Event::LoadedCursor(Ok(None)),

4141− Event::LoadedSeenIds(Ok(None)),

41423780 ]

41433781 .into_iter()

41443782 .enumerate()

@@ -4152,7 +3790,7 @@ mod tests {

41523790 assert_eq!(connects(&mut cmd), 0, "and none of them connects");

41533791 }

41543792

4155− // The sixth — and only the sixth — emits Connect.

3793+ // The fifth — and only the fifth — emits Connect.

41563794 let mut cmd = app.update(Event::LoadedOutbox(Ok(None)), &mut m);

41573795 assert_eq!(m.loads_pending, 0);

41583796 assert_eq!(connects(&mut cmd), 1, "the last load connects, exactly once");

@@ -4242,7 +3880,7 @@ mod tests {

42423880 );

42433881

42443882 // The recovery is a relaunch, which re-runs the loads and clears the latch.

4245− let sk = Identity::from_seed(&[3u8; 32]).unwrap().secret_key.to_vec();

3883+ let sk = Identity::from_seed(&[3u8; 32]).secret_key.to_vec();

42463884 let _ = app.update(Event::IdentityLoaded(sk), &mut m);

42473885 assert!(

42483886 !m.kv_load_failed,

@@ -4349,8 +3987,8 @@ mod tests {

43493987 );

43503988

43513989 let profile = Payload::Profile {

4352− display_name: Some("Mallory".into()),

4353− bio: Some("spam".into()),

3990+ display_name: "Mallory".into(),

3991+ bio: "spam".into(),

43543992 photo: Some("aGk=".into()),

43553993 };

43563994 let page = page_from(9, &m, &profile, now_ms());

@@ -4431,8 +4069,8 @@ mod tests {

44314069 let peer = peer_hex(9);

44324070

44334071 let profile = Payload::Profile {

4434− display_name: Some("Mallory".into()),

4435− bio: Some(String::new()),

4072+ display_name: "Mallory".into(),

4073+ bio: String::new(),

44364074 photo: Some("aGk=".into()),

44374075 };

44384076 let page = page_from(9, &m, &profile, now_ms());

@@ -4644,7 +4282,7 @@ mod tests {

46444282

46454283 // One page holding more messages from one sender than fits in a single ack.

46464284 let count = protocol::MAX_ACK_IDS + 5;

4647− let sender = Identity::from_seed(&[9u8; 32]).unwrap();

4285+ let sender = Identity::from_seed(&[9u8; 32]);

46484286 let me = Identity::from_secret_bytes(m.secret_key.as_ref().unwrap()).unwrap();

46494287 let events = (0..count)

46504288 .map(|i| {

@@ -4964,7 +4602,7 @@ mod tests {

49644602

49654603 // The send never comes back. The watchdog fires, clears the stuck guard,

49664604 // and retries the flush — the message goes out again.

4967− let mut cmd = app.update(Event::FlushWatchdog(m.flush_gen), &mut m);

4605+ let mut cmd = app.update(Event::FlushWatchdog, &mut m);

49684606

49694607 assert!(m.flushing, "a fresh send is in flight (the retry)");

49704608 assert!(m.in_flight.is_some(), "in_flight is set for the retry");

@@ -4981,23 +4619,22 @@ mod tests {

49814619 m.outbox.push_back(queued(&peer_hex(9), "hi"));

49824620

49834621 let _ = app.update(Event::StartFlush, &mut m);

4984− let _ = app.update(Event::SendResult(m.flush_gen, Ok(ok_response(200))), &mut m);

4622+ let _ = app.update(Event::SendResult(Ok(ok_response(200))), &mut m);

49854623 assert!(!m.flushing);

49864624 assert!(m.outbox.is_empty());

49874625

49884626 // The watchdog for the completed send fires late.

4989− let _ = app.update(Event::FlushWatchdog(m.flush_gen), &mut m);

4627+ let _ = app.update(Event::FlushWatchdog, &mut m);

49904628 assert!(!m.flushing, "a completed send is not re-armed");

49914629 assert!(m.outbox.is_empty());

49924630 }

49934631

4994− /// A late `SendResult` from a superseded send is dropped by the generation

4995− /// check. The watchdog abandoned the first send and retried under a new

4996− /// generation; the late result's generation no longer matches, so it cannot

4997− /// pop the retry's items or clear its guard. The retry's own `SendResult`

4998− /// is what eventually pops them.

4632+ /// A late `SendResult` after the watchdog has already retried sees the

4633+ /// retry's `in_flight` and pops its items. This is correct: the retry sent

4634+ /// the same items, and a 200 means they were accepted — whether by the

4635+ /// original request or the retry is irrelevant. The items are delivered.

49994636 #[test]

5000− fn a_late_send_result_after_the_watchdog_is_dropped_by_generation() {

4637+ fn a_late_send_result_after_the_watchdog_pops_the_retrys_items() {

50014638 let app = Skrepka;

50024639 let mut m = with_identity();

50034640 m.token = Some("t".into());

@@ -5005,23 +4642,15 @@ mod tests {

50054642 m.outbox.push_back(queued(&peer, "stuck"));

50064643

50074644 let _ = app.update(Event::StartFlush, &mut m);

5008− let first_gen = m.flush_gen;

5009− // The watchdog fires and retries the flush under a new generation.

5010− let _ = app.update(Event::FlushWatchdog(first_gen), &mut m);

4645+ // The watchdog fires and retries the flush.

4646+ let _ = app.update(Event::FlushWatchdog, &mut m);

50114647 assert_eq!(m.outbox.len(), 1, "the item is still queued (re-sent)");

5012− assert_ne!(m.flush_gen, first_gen, "the generation was bumped");

5013− assert!(m.flushing, "the retry is in flight");

5014−

5015− // The original send's result arrives late. Its generation no longer

5016− // matches, so it is dropped — it cannot pop the retry's items or

5017− // clear the retry's guard.

5018− let _ = app.update(Event::SendResult(first_gen, Ok(ok_response(200))), &mut m);

5019− assert!(m.flushing, "the retry's guard is untouched");

5020− assert_eq!(m.outbox.len(), 1, "the late result popped nothing");

5021−

5022− // The retry's own result arrives and pops the items.

5023− let _ = app.update(Event::SendResult(m.flush_gen, Ok(ok_response(200))), &mut m);

5024− assert!(m.outbox.is_empty(), "the retry's result pops the items");

4648+

4649+ // Now the original send's result arrives late. The retry's in_flight is

4650+ // set, so a 200 pops the item — which is correct, the message was

4651+ // accepted by one of the two sends.

4652+ let _ = app.update(Event::SendResult(Ok(ok_response(200))), &mut m);

4653+ assert!(m.outbox.is_empty(), "the late 200 pops the retry's items — the message was accepted");

50254654 assert!(!m.flushing, "and the guard is released");

50264655 }

50274656}

core/src/crypto.rs+64−240

@@ -15,60 +15,28 @@

1515

1616use std::io::Read;

1717

18−use chacha20poly1305::aead::{Aead, Payload as AeadPayload};

18+use chacha20poly1305::aead::Aead;

1919use chacha20poly1305::{Key, KeyInit, XChaCha20Poly1305, XNonce};

2020use curve25519_dalek::edwards::CompressedEdwardsY;

21−use ed25519_dalek::{Signer, SigningKey, VerifyingKey};

21+use ed25519_dalek::{Signer, SigningKey, Verifier, VerifyingKey};

2222use hkdf::Hkdf;

2323use rand_core::{CryptoRng, RngCore};

2424use sha2::{Digest, Sha256, Sha512};

2525use zeroize::{Zeroize, ZeroizeOnDrop, Zeroizing};

2626

27−/// HKDF `info` string (PROTOCOL.md §3). Derived from the wire version so a

28−/// future crypto revision that bumps the version byte also changes the KDF

29−/// label automatically — the two must always move together (N2).

30−const HKDF_INFO: &[u8] = b"skrepka-v2";

27+/// HKDF `info` string (PROTOCOL.md §3 / Constants.hkdfInfo). Fixed.

28+const HKDF_INFO: &[u8] = b"skrepka-v1";

3129/// Domain-separation tag for the auth challenge signature (PROTOCOL.md §6).

3230const AUTH_TAG: &str = "skrepka-auth-v1:";

3331

34−/// Domain-separation tag for per-message signatures (PROTOCOL.md §3).

35−/// Prevents cross-protocol signature reuse: an auth challenge signature

36−/// begins with "skrepka-auth-v1:" while a message signature begins with

37−/// this tag, so the same key cannot sign in one context and have it

38−/// validate in another.

39−const MSG_TAG: &[u8] = b"skrepka-msg-v2:";

40−

4132/// Wire-format version byte prepended to every encrypted blob (PROTOCOL.md §3).

42−///

43−/// Version 0x02 adds AEAD associated data (AAD): the cleartext header

44−/// `version_byte || ephemeral_public || nonce` is authenticated alongside

45−/// the ciphertext, so a relay that tampers with any envelope field —

46−/// including swapping the `to` recipient — causes AEAD decryption to fail

47−/// before the blob is ever acked (N1). The recipient's Ed25519 public key

48−/// is also included in the AAD, binding the envelope `to` field to the

49−/// inner signed recipient, so a `to`-swap is detected as an AEAD failure

50−/// rather than a silent misdelivery.

51−const WIRE_VERSION: u8 = 2;

52−

53−/// Build the AAD for AEAD: `version || ephemeral_pub || nonce || recipient_pub`.

54−/// All envelope-level fields the relay can see are now cryptographically

55−/// bound to the ciphertext (N1).

56−fn aad(version: u8, eph_pub: &[u8; 32], nonce: &[u8; NONCE_LEN], recipient_pub: &[u8; 32]) -> Vec<u8> {

57− let mut aad = Vec::with_capacity(1 + 32 + NONCE_LEN + 32);

58− aad.push(version);

59− aad.extend_from_slice(eph_pub);

60− aad.extend_from_slice(nonce);

61− aad.extend_from_slice(recipient_pub);

62− aad

63−}

33+const WIRE_VERSION: u8 = 1;

6434

6535pub const ED25519_SECRET_LEN: usize = 64;

6636pub const ED25519_PUBLIC_LEN: usize = 32;

6737pub const NONCE_LEN: usize = 24;

68−/// `1+32+24+32+64+4+16` bytes = version, eph pubkey, nonce, sender pub, sig,

69−/// compressed_len, AEAD tag. The 4-byte compressed_len field sits inside the AEAD

70−/// ciphertext. The version byte, ephemeral pubkey, nonce, and recipient pubkey are

71−/// AEAD AAD (v0x02).

38+/// 1 (version) + 32 (eph) + 24 (nonce) + 32 (sender pub) + 64 (sig) + 4 (compressed_len)

39+/// + 16 (AEAD tag). The 4-byte compressed_len field sits inside the AEAD ciphertext.

7240pub const MIN_BLOB_LEN: usize = 1 + 32 + NONCE_LEN + 32 + 64 + 4 + 16;

7341

7442/// Blob sizes are padded up to these boundaries so the on-wire length does not

@@ -90,10 +58,7 @@ fn padded_len(actual: usize) -> usize {

9058 // Above 65536: round to the next multiple of 65536.

9159 let remainder = actual % 65536;

9260 if remainder == 0 {

93− // D6: When actual is an exact multiple of 65536 above 65536,

94− // returning `actual` would give zero padding, revealing the exact

95− // compressed size. Always add at least one bucket of padding.

96− actual + 65536

61+ actual

9762 } else {

9863 actual + 65536 - remainder

9964 }

@@ -162,17 +127,9 @@ impl std::error::Error for CryptoError {}

162127///

163128/// `ZeroizeOnDrop` wipes the seed when the value goes away. `Identity` is cloned

164129/// freely (once per encrypt/decrypt), so each of those copies is wiped too.

165−///

166−/// The derived X25519 keys (`x25519_priv`, `x25519_pub`) are computed once at

167−/// construction and cached: `decrypt` is called per-blob in a poll page, and

168−/// recomputing the SHA-512 + Edwards decompress on every call is a measurable

169−/// CPU multiplier under a flood of small blobs. Both are `Zeroizing` so the

170−/// private half is wiped on drop alongside the seed.

171130#[derive(Clone, ZeroizeOnDrop)]

172131pub struct Identity {

173132 pub secret_key: [u8; ED25519_SECRET_LEN],

174− x25519_priv: [u8; 32],

175− x25519_pub: [u8; 32],

176133}

177134

178135impl Identity {

@@ -197,24 +154,24 @@ impl Identity {

197154 return Err(CryptoError::BadKeyLength);

198155 }

199156

200− Identity::with_x25519(secret_key)

157+ Ok(Identity { secret_key })

201158 }

202159

203160 /// Generate a fresh identity from a CSPRNG.

204− pub fn generate(rng: &mut (impl RngCore + CryptoRng)) -> Result<Self, CryptoError> {

161+ pub fn generate(rng: &mut (impl RngCore + CryptoRng)) -> Self {

205162 let mut seed = Zeroizing::new([0u8; 32]);

206163 rng.fill_bytes(&mut *seed);

207164 Self::from_seed(&seed)

208165 }

209166

210167 /// Build the 64-byte secret key (`seed || pub`) from a 32-byte seed.

211− pub fn from_seed(seed: &[u8; 32]) -> Result<Self, CryptoError> {

168+ pub fn from_seed(seed: &[u8; 32]) -> Self {

212169 let signing = SigningKey::from_bytes(seed);

213170 let public = signing.verifying_key();

214171 let mut secret_key = [0u8; ED25519_SECRET_LEN];

215172 secret_key[..32].copy_from_slice(seed);

216173 secret_key[32..].copy_from_slice(public.as_bytes());

217− Identity::with_x25519(secret_key)

174+ Identity { secret_key }

218175 }

219176

220177 pub fn public_key(&self) -> [u8; ED25519_PUBLIC_LEN] {

@@ -233,46 +190,6 @@ impl Identity {

233190 SigningKey::from_bytes(&seed)

234191 }

235192

236− /// Compute the cached X25519 keys from the Ed25519 secret key.

237− ///

238− /// Q49: Also checks that the derived X25519 public key is not an all-zero

239− /// (low-order) point. The probability of generating such a key is negligible,

240− /// but if it ever happened every encryption to this identity would fail with

241− /// `InvalidEphemeralKey` and the user would be unable to receive messages

242− /// with no indication of why. Catching it at construction time gives a

243− /// clear error instead.

244− fn with_x25519(secret_key: [u8; ED25519_SECRET_LEN]) -> Result<Self, CryptoError> {

245− let x25519_priv = *ed25519_sk_to_x25519(&secret_key);

246− let x25519_pub = x25519_dalek::x25519(x25519_priv, x25519_dalek::X25519_BASEPOINT_BYTES);

247− // D33: Return an error instead of just printing a warning when the

248− // derived X25519 public key is all-zero (low-order point). The

249− // probability of generating such a key is negligible, but if it ever

250− // happened every encryption to this identity would fail with

251− // `InvalidEphemeralKey` and the user would be unable to receive

252− // messages with no indication of why. Catching it at construction time

253− // gives a clear error instead.

254− if x25519_pub.iter().all(|b| *b == 0) {

255− return Err(CryptoError::InvalidPublicKey);

256− }

257− Ok(Identity {

258− secret_key,

259− x25519_priv,

260− x25519_pub,

261− })

262− }

263−

264− /// Cached X25519 private key derived from the Ed25519 seed (libsodium

265− /// `crypto_sign_ed25519_sk_to_curve25519`). Avoids a per-decrypt SHA-512.

266− fn x25519_private(&self) -> &[u8; 32] {

267− &self.x25519_priv

268− }

269−

270− /// Cached X25519 public key derived from the Ed25519 public key (libsodium

271− /// `crypto_sign_ed25519_pk_to_curve25519`). Avoids a per-decrypt decompress.

272− fn x25519_public(&self) -> &[u8; 32] {

273− &self.x25519_pub

274− }

275−

276193 /// Sign the auth challenge: `ed25519(sk, "skrepka-auth-v1:" + host + ":" + challenge)`.

277194 /// `server_host` must already be the bare lowercased hostname.

278195 ///

@@ -294,14 +211,7 @@ fn ed25519_pk_to_x25519(ed_pub: &[u8; 32]) -> Result<[u8; 32], CryptoError> {

294211 let point = compressed

295212 .decompress()

296213 .ok_or(CryptoError::InvalidPublicKey)?;

297− let montgomery = point.to_montgomery().to_bytes();

298− // D3: A 32-byte all-zero input is the Ed25519 identity point, which

299− // produces an all-zero Montgomery u-coordinate — a low-order point.

300− // Reject it explicitly, separate from the x25519 shared-secret check.

301− if montgomery.iter().all(|&b| b == 0) {

302− return Err(CryptoError::InvalidPublicKey);

303− }

304− Ok(montgomery)

214+ Ok(point.to_montgomery().to_bytes())

305215}

306216

307217/// libsodium `crypto_sign_ed25519_sk_to_curve25519`: clamp(SHA-512(seed)[..32]).

@@ -332,7 +242,7 @@ fn x25519(scalar: &[u8; 32], point: &[u8; 32]) -> Result<Zeroizing<[u8; 32]>, Cr

332242 Ok(shared)

333243}

334244

335−/// HKDF-SHA256(ikm=raw_secret, salt=eph_pub || recip_x_pub, info="skrepka-v2", 32).

245+/// HKDF-SHA256(ikm=raw_secret, salt=eph_pub || recip_x_pub, info="skrepka-v1", 32).

336246fn derive_key(

337247 raw_secret: &[u8; 32],

338248 eph_pub: &[u8; 32],

@@ -361,15 +271,7 @@ fn compress(plaintext: &[u8]) -> Vec<u8> {

361271/// *would* overrun is detected rather than silently truncated.

362272fn decompress(data: &[u8]) -> Result<Vec<u8>, CryptoError> {

363273 let mut decoder = zstd::stream::Decoder::new(data).map_err(|_| CryptoError::Decompress)?;

364− // Cap the decoder's window buffer so a crafted frame declaring a huge

365− // windowLog (up to 27 = 128 MiB by default) cannot force a matching

366− // allocation before the output-size cap even applies. 2^21 = 2 MiB is

367− // comfortably above `MAX_PLAINTEXT_LEN` (1 MiB), so every legitimate frame

368− // still decodes; frames declaring a larger window are rejected.

369− decoder

370− .window_log_max(21)

371− .map_err(|_| CryptoError::Decompress)?;

372− let mut out = Vec::with_capacity(4096);

274+ let mut out = Vec::new();

373275 (&mut decoder)

374276 .take(MAX_PLAINTEXT_LEN as u64 + 1)

375277 .read_to_end(&mut out)

@@ -388,12 +290,6 @@ pub fn encrypt(

388290 recipient_ed_pub: &[u8; 32],

389291 plaintext: &[u8],

390292) -> Result<Vec<u8>, CryptoError> {

391− // D28: Reject a plaintext over the cap before compressing and encrypting

392− // — the recipient will reject it on decompression anyway, so the work

393− // is wasted. CryptoError::Encrypt signals an encryption-side failure.

394− if plaintext.len() > MAX_PLAINTEXT_LEN {

395− return Err(CryptoError::Encrypt);

396− }

397293 let sender_pub = sender.public_key();

398294

399295 // Ephemeral raw X25519 keypair (libsodium crypto_box_keypair).

@@ -423,8 +319,7 @@ pub fn encrypt(

423319

424320 // Sign recipient_pub || compressed_len_bytes || compressed || padding

425321 // (i.e. recipient_pub || everything after the 96-byte header in inner).

426− let mut signed = Zeroizing::new(Vec::with_capacity(MSG_TAG.len() + 32 + 4 + compressed.len() + padding.len()));

427− signed.extend_from_slice(MSG_TAG);

322+ let mut signed = Zeroizing::new(Vec::with_capacity(32 + 4 + compressed.len() + padding.len()));

428323 signed.extend_from_slice(recipient_ed_pub);

429324 signed.extend_from_slice(&compressed_len_bytes);

430325 signed.extend_from_slice(&compressed);

@@ -448,18 +343,8 @@ pub fn encrypt(

448343 let mut nonce = [0u8; NONCE_LEN];

449344 rng.fill_bytes(&mut nonce);

450345 let cipher = XChaCha20Poly1305::new(Key::from_slice(&*key));

451− // AAD binds the envelope header (version, ephemeral pubkey, nonce) and

452− // the recipient identity to the ciphertext (N1). A relay that swaps the

453− // `to` field causes the wrong recipient to fail AEAD decryption, and the

454− // original recipient's message stays in the mailbox instead of being

455− // silently misdelivered.

456− let aad_buf = aad(WIRE_VERSION, &eph_pub, &nonce, recipient_ed_pub);

457− let payload = AeadPayload {

458− msg: inner.as_ref(),

459− aad: &aad_buf,

460− };

461346 let ciphertext = cipher

462− .encrypt(XNonce::from_slice(&nonce), payload)

347+ .encrypt(XNonce::from_slice(&nonce), inner.as_ref())

463348 .map_err(|_| CryptoError::Encrypt)?;

464349 inner.zeroize();

465350

@@ -501,22 +386,15 @@ pub fn decrypt(recipient: &Identity, blob: &[u8]) -> Result<Decrypted, CryptoErr

501386 nonce.copy_from_slice(&blob[33..33 + NONCE_LEN]);

502387 let ciphertext = &blob[33 + NONCE_LEN..];

503388

504− let recip_x_priv = recipient.x25519_private();

505− let raw_secret = x25519(recip_x_priv, &eph_pub)?;

506− let recip_x_pub = recipient.x25519_public();

507− let key = derive_key(&raw_secret, &eph_pub, recip_x_pub);

389+ let recip_x_priv = ed25519_sk_to_x25519(&recipient.secret_key);

390+ let raw_secret = x25519(&recip_x_priv, &eph_pub)?;

391+ let recip_x_pub = ed25519_pk_to_x25519(&recipient.public_key())?;

392+ let key = derive_key(&raw_secret, &eph_pub, &recip_x_pub);

508393

509394 let cipher = XChaCha20Poly1305::new(Key::from_slice(&*key));

510− // Reconstruct the same AAD used during encryption: the envelope header

511− // and the recipient identity. This binds the envelope `to` field to the

512− // ciphertext — a relay that swapped `to` causes AEAD failure here, not

513− // a silent misdelivery (N1).

514− let recip_pub = recipient.public_key();

515− let aad_buf = aad(blob[0], &eph_pub, &nonce, &recip_pub);

516− let payload = AeadPayload { msg: ciphertext, aad: &aad_buf };

517395 let mut inner = Zeroizing::new(

518396 cipher

519− .decrypt(XNonce::from_slice(&nonce), payload)

397+ .decrypt(XNonce::from_slice(&nonce), ciphertext)

520398 .map_err(|_| CryptoError::Decrypt)?,

521399 );

522400

@@ -535,7 +413,7 @@ pub fn decrypt(recipient: &Identity, blob: &[u8]) -> Result<Decrypted, CryptoErr

535413 inner[98],

536414 inner[99],

537415 ]) as usize;

538− if compressed_len > inner.len().saturating_sub(100) {

416+ if 100 + compressed_len > inner.len() {

539417 inner.zeroize();

540418 return Err(CryptoError::Decrypt);

541419 }

@@ -545,12 +423,11 @@ pub fn decrypt(recipient: &Identity, blob: &[u8]) -> Result<Decrypted, CryptoErr

545423 // (covers compressed_len_bytes || compressed || padding).

546424 let verifying = VerifyingKey::from_bytes(&sender_pub).map_err(|_| CryptoError::BadSignature)?;

547425 let signature = ed25519_dalek::Signature::from_bytes(&sig_bytes);

548− let mut signed = Zeroizing::new(Vec::with_capacity(MSG_TAG.len() + 32 + (inner.len() - 96)));

549− signed.extend_from_slice(MSG_TAG);

426+ let mut signed = Zeroizing::new(Vec::with_capacity(32 + (inner.len() - 96)));

550427 signed.extend_from_slice(&recipient.public_key());

551428 signed.extend_from_slice(&inner[96..]);

552429 verifying

553− .verify_strict(&signed, &signature)

430+ .verify(&signed, &signature)

554431 .map_err(|_| CryptoError::BadSignature)?;

555432

556433 let plaintext = decompress(compressed)?;

@@ -578,12 +455,12 @@ mod tests {

578455

579456 #[test]

580457 fn identity_pub_is_last_32_bytes_and_consistent() {

581− let id = Identity::generate(&mut rng(1)).unwrap();

458+ let id = Identity::generate(&mut rng(1));

582459 assert_eq!(&id.secret_key[32..], &id.public_key());

583460 // Re-deriving from the seed yields the same public key.

584461 let mut seed = [0u8; 32];

585462 seed.copy_from_slice(&id.secret_key[..32]);

586− let id2 = Identity::from_seed(&seed).unwrap();

463+ let id2 = Identity::from_seed(&seed);

587464 assert_eq!(id.public_key(), id2.public_key());

588465 }

589466

@@ -591,7 +468,7 @@ mod tests {

591468 /// under one identity while claiming another.

592469 #[test]

593470 fn from_secret_bytes_rejects_a_seed_pubkey_mismatch() {

594− let id = Identity::from_seed(&[3u8; 32]).unwrap();

471+ let id = Identity::from_seed(&[3u8; 32]);

595472 assert!(Identity::from_secret_bytes(&id.secret_key).is_ok());

596473

597474 let mut tampered = id.secret_key;

@@ -604,8 +481,8 @@ mod tests {

604481

605482 #[test]

606483 fn round_trip_recovers_plaintext_and_sender() {

607− let alice = Identity::generate(&mut rng(10)).unwrap();

608− let bob = Identity::generate(&mut rng(20)).unwrap();

484+ let alice = Identity::generate(&mut rng(10));

485+ let bob = Identity::generate(&mut rng(20));

609486 let msg = br#"{"type":"text","id":"abc","body":"hello bob","ts":1700000000000}"#;

610487

611488 let blob = encrypt(&mut rng(99), &alice, &bob.public_key(), msg).unwrap();

@@ -618,17 +495,17 @@ mod tests {

618495

619496 #[test]

620497 fn wrong_recipient_cannot_decrypt() {

621− let alice = Identity::generate(&mut rng(1)).unwrap();

622− let bob = Identity::generate(&mut rng(2)).unwrap();

623− let eve = Identity::generate(&mut rng(3)).unwrap();

498+ let alice = Identity::generate(&mut rng(1));

499+ let bob = Identity::generate(&mut rng(2));

500+ let eve = Identity::generate(&mut rng(3));

624501 let blob = encrypt(&mut rng(4), &alice, &bob.public_key(), b"secret").unwrap();

625502 assert_eq!(decrypt(&eve, &blob).unwrap_err(), CryptoError::Decrypt);

626503 }

627504

628505 #[test]

629506 fn tampered_ciphertext_is_rejected() {

630− let alice = Identity::generate(&mut rng(1)).unwrap();

631− let bob = Identity::generate(&mut rng(2)).unwrap();

507+ let alice = Identity::generate(&mut rng(1));

508+ let bob = Identity::generate(&mut rng(2));

632509 let mut blob = encrypt(&mut rng(4), &alice, &bob.public_key(), b"secret").unwrap();

633510 let last = blob.len() - 1;

634511 blob[last] ^= 0xff;

@@ -637,8 +514,8 @@ mod tests {

637514

638515 #[test]

639516 fn blob_layout_offsets() {

640− let alice = Identity::generate(&mut rng(1)).unwrap();

641− let bob = Identity::generate(&mut rng(2)).unwrap();

517+ let alice = Identity::generate(&mut rng(1));

518+ let bob = Identity::generate(&mut rng(2));

642519 let blob = encrypt(&mut rng(7), &alice, &bob.public_key(), b"x").unwrap();

643520 // Version byte at offset 0.

644521 assert_eq!(blob[0], WIRE_VERSION);

@@ -655,7 +532,7 @@ mod tests {

655532

656533 #[test]

657534 fn too_short_blob_errors() {

658− let bob = Identity::generate(&mut rng(2)).unwrap();

535+ let bob = Identity::generate(&mut rng(2));

659536 assert_eq!(

660537 decrypt(&bob, &[0u8; 10]).unwrap_err(),

661538 CryptoError::BlobTooShort

@@ -666,7 +543,7 @@ mod tests {

666543 /// scalar mult, an AEAD pass, or a decompression.

667544 #[test]

668545 fn too_long_blob_errors() {

669− let bob = Identity::generate(&mut rng(2)).unwrap();

546+ let bob = Identity::generate(&mut rng(2));

670547 let huge = vec![0u8; MAX_BLOB_LEN + 1];

671548 assert_eq!(decrypt(&bob, &huge).unwrap_err(), CryptoError::BlobTooLong);

672549 }

@@ -683,27 +560,25 @@ mod tests {

683560 );

684561 assert_eq!(decompress(&bomb).unwrap_err(), CryptoError::Decompress);

685562

686− // ...and the same bomb sent through encrypt is rejected before

687− // compression/encryption work is done (D28).

688− let alice = Identity::generate(&mut rng(1)).unwrap();

689− let bob = Identity::generate(&mut rng(2)).unwrap();

690− assert_eq!(

691− encrypt(

692− &mut rng(3),

693− &alice,

694− &bob.public_key(),

695− &vec![0u8; MAX_PLAINTEXT_LEN + 1],

696− )

697− .unwrap_err(),

698− CryptoError::Encrypt,

699− );

563+ // ...and the same bomb wrapped in a well-formed, correctly signed blob

564+ // (i.e. from a real peer) dies at the same wall.

565+ let alice = Identity::generate(&mut rng(1));

566+ let bob = Identity::generate(&mut rng(2));

567+ let blob = encrypt(

568+ &mut rng(3),

569+ &alice,

570+ &bob.public_key(),

571+ &vec![0u8; MAX_PLAINTEXT_LEN + 1],

572+ )

573+ .unwrap();

574+ assert_eq!(decrypt(&bob, &blob).unwrap_err(), CryptoError::Decompress);

700575 }

701576

702577 /// A plaintext right at the cap still round-trips: the bound is inclusive.

703578 #[test]

704579 fn a_plaintext_at_the_cap_still_round_trips() {

705− let alice = Identity::generate(&mut rng(1)).unwrap();

706− let bob = Identity::generate(&mut rng(2)).unwrap();

580+ let alice = Identity::generate(&mut rng(1));

581+ let bob = Identity::generate(&mut rng(2));

707582 let msg = vec![7u8; MAX_PLAINTEXT_LEN];

708583 let blob = encrypt(&mut rng(3), &alice, &bob.public_key(), &msg).unwrap();

709584 assert_eq!(decrypt(&bob, &blob).unwrap().plaintext.as_slice(), msg.as_slice());

@@ -713,7 +588,7 @@ mod tests {

713588 /// secret, so the sender's "encryption" is forgeable. Reject it.

714589 #[test]

715590 fn a_low_order_ephemeral_point_is_rejected() {

716− let bob = Identity::generate(&mut rng(2)).unwrap();

591+ let bob = Identity::generate(&mut rng(2));

717592 // eph_pub = 0 is the canonical low-order point; x25519 with it yields

718593 // an all-zero shared secret for any scalar.

719594 let mut blob = vec![0u8; MIN_BLOB_LEN + 1];

@@ -728,8 +603,8 @@ mod tests {

728603 /// A short message must be padded so the blob size lands on a bucket boundary.

729604 #[test]

730605 fn blob_is_padded_to_bucket_size() {

731− let alice = Identity::generate(&mut rng(1)).unwrap();

732− let bob = Identity::generate(&mut rng(2)).unwrap();

606+ let alice = Identity::generate(&mut rng(1));

607+ let bob = Identity::generate(&mut rng(2));

733608

734609 // Short message → should round up to the smallest bucket (256).

735610 let blob_small = encrypt(&mut rng(7), &alice, &bob.public_key(), b"x").unwrap();

@@ -754,8 +629,8 @@ mod tests {

754629 /// same blob size (same bucket) but different blob contents (random padding).

755630 #[test]

756631 fn padding_is_random_per_message() {

757− let alice = Identity::generate(&mut rng(1)).unwrap();

758− let bob = Identity::generate(&mut rng(2)).unwrap();

632+ let alice = Identity::generate(&mut rng(1));

633+ let bob = Identity::generate(&mut rng(2));

759634 let msg = b"hello bob, this is a test message";

760635

761636 let blob1 = encrypt(&mut rng(100), &alice, &bob.public_key(), msg).unwrap();

@@ -776,8 +651,8 @@ mod tests {

776651 /// never sees trailing padding bytes.

777652 #[test]

778653 fn compressed_len_field_is_parsed_correctly() {

779− let alice = Identity::generate(&mut rng(1)).unwrap();

780− let bob = Identity::generate(&mut rng(2)).unwrap();

654+ let alice = Identity::generate(&mut rng(1));

655+ let bob = Identity::generate(&mut rng(2));

781656

782657 // Normal round-trip.

783658 let msg = b"round trip test with some content";

@@ -799,7 +674,7 @@ mod tests {

799674 /// error says so rather than blaming decryption.

800675 #[test]

801676 fn encrypting_to_an_off_curve_key_reports_an_invalid_public_key() {

802− let alice = Identity::generate(&mut rng(1)).unwrap();

677+ let alice = Identity::generate(&mut rng(1));

803678 let not_a_point = [0xabu8; 32];

804679 assert_eq!(

805680 encrypt(&mut rng(2), &alice, &not_a_point, b"x").unwrap_err(),

@@ -809,7 +684,7 @@ mod tests {

809684

810685 #[test]

811686 fn sk_to_x25519_clamps() {

812− let id = Identity::generate(&mut rng(5)).unwrap();

687+ let id = Identity::generate(&mut rng(5));

813688 let scalar = ed25519_sk_to_x25519(&id.secret_key);

814689 assert_eq!(scalar[0] & 7, 0);

815690 assert_eq!(scalar[31] & 64, 64);

@@ -818,7 +693,7 @@ mod tests {

818693

819694 #[test]

820695 fn challenge_signature_is_deterministic_and_host_bound() {

821− let id = Identity::from_seed(&[7u8; 32]).unwrap();

696+ let id = Identity::from_seed(&[7u8; 32]);

822697 let a = id.sign_challenge("relay.example.com", "deadbeef").unwrap();

823698 let b = id.sign_challenge("relay.example.com", "deadbeef").unwrap();

824699 let c = id.sign_challenge("other.example.com", "deadbeef").unwrap();

@@ -830,7 +705,7 @@ mod tests {

830705 /// We sign whatever a not-yet-trusted relay hands us, so its size is bounded.

831706 #[test]

832707 fn an_oversized_challenge_is_not_signed() {

833− let id = Identity::from_seed(&[7u8; 32]).unwrap();

708+ let id = Identity::from_seed(&[7u8; 32]);

834709 let huge = "a".repeat(MAX_CHALLENGE_LEN + 1);

835710 assert_eq!(

836711 id.sign_challenge("relay.example.com", &huge).unwrap_err(),

@@ -840,55 +715,4 @@ mod tests {

840715 let at_cap = "a".repeat(MAX_CHALLENGE_LEN);

841716 assert!(id.sign_challenge("relay.example.com", &at_cap).is_ok());

842717 }

843−

844− /// A blob encrypted to Bob cannot be decrypted by Charlie — the key

845− /// derivation itself binds the recipient (the AEAD key is a function

846− /// of the recipient's private key and the ephemeral public key). The

847− /// AAD additionally authenticates the recipient pubkey, but the tag

848− /// check would fail even without it, because Charlie derives a

849− /// different key. The AAD is defense-in-depth: it makes the binding

850− /// explicit rather than implicit in the KDF.

851− #[test]

852− fn wrong_recipient_cannot_decrypt_aead_fails() {

853− let alice = Identity::generate(&mut rng(1)).unwrap();

854− let bob = Identity::generate(&mut rng(2)).unwrap();

855− let charlie = Identity::generate(&mut rng(3)).unwrap();

856−

857− let blob = encrypt(&mut rng(4), &alice, &bob.public_key(), b"hi bob").unwrap();

858− assert_eq!(

859− decrypt(&charlie, &blob).unwrap_err(),

860− CryptoError::Decrypt,

861− "wrong recipient must fail AEAD — key derivation binds the recipient"

862− );

863− }

864−

865− /// Tampering with the version byte causes failure via the explicit

866− /// version check (`blob[0] != WIRE_VERSION`) before the AEAD even runs.

867− /// The AAD includes the version as defense-in-depth, but the explicit

868− /// check fires first.

869− #[test]

870− fn tampered_version_byte_is_rejected() {

871− let alice = Identity::generate(&mut rng(1)).unwrap();

872− let bob = Identity::generate(&mut rng(2)).unwrap();

873− let mut blob = encrypt(&mut rng(3), &alice, &bob.public_key(), b"hi").unwrap();

874− blob[0] ^= 0xff;

875− assert_eq!(

876− decrypt(&bob, &blob).unwrap_err(),

877− CryptoError::Decrypt,

878− "version byte tampering is rejected"

879− );

880− }

881−

882− /// Tampering with the ephemeral pubkey causes key derivation to produce

883− /// a different key, so the AEAD tag check fails. The AAD additionally

884− /// authenticates the eph_pub, but the KDF mismatch is what actually

885− /// catches this.

886− #[test]

887− fn tampered_ephemeral_pubkey_is_rejected() {

888− let alice = Identity::generate(&mut rng(1)).unwrap();

889− let bob = Identity::generate(&mut rng(2)).unwrap();

890− let mut blob = encrypt(&mut rng(3), &alice, &bob.public_key(), b"hi").unwrap();

891− blob[5] ^= 0x01;

892− assert!(decrypt(&bob, &blob).is_err());

893− }

894718}

core/src/ffi.rs−5

@@ -39,11 +39,6 @@ impl Default for CoreFFI {

3939/// `AssertUnwindSafe` is sound here because a poisoned `Bridge` is never read

4040/// again for correctness: the worst case is a dropped effect batch, and the next

4141/// event starts a fresh `update`.

42−///

43−/// NOTE: A panic mid-`update` leaves the `Model` in a partially-mutated state.

44−/// The next `update` call operates on this potentially-corrupted state. A

45−/// proper fix requires snapshotting the Model before `update` and restoring on

46−/// panic, or marking the Bridge as poisoned. This is an accepted limitation.

4742fn guard(f: impl FnOnce() -> Vec<u8>) -> Vec<u8> {

4843 catch_unwind(AssertUnwindSafe(f)).unwrap_or_default()

4944}

core/src/phonemic.rs+3−8

@@ -96,11 +96,6 @@ fn suffix_index(s: &str) -> Option<u8> {

9696/// Keys are always 32 bytes, so no caller is affected — but a display helper

9797/// must not quietly invent a byte.

9898pub fn to_ob(bytes: &[u8]) -> Option<String> {

99− // P1: Empty input produces an empty string, which is a valid but

100− // meaningless @p — return None instead so the round-trip is symmetric.

101− if bytes.is_empty() {

102− return None;

103− }

10499 if !bytes.len().is_multiple_of(2) {

105100 return None;

106101 }

@@ -156,7 +151,7 @@ pub fn try_parse_pubkey(input: &str) -> Option<String> {

156151 if let Some(hex) = from_ob(trimmed).as_deref().and_then(valid_pubkey_hex) {

157152 return Some(hex);

158153 }

159− if let Ok(bytes) = hex::decode(trimmed) {

154+ if let Ok(bytes) = hex::decode(trimmed.to_lowercase()) {

160155 return valid_pubkey_hex(&bytes);

161156 }

162157 None

@@ -212,13 +207,13 @@ mod tests {

212207 fn odd_length_input_has_no_spelling() {

213208 assert_eq!(to_ob(&[7u8]), None);

214209 assert_eq!(to_ob(&[7u8, 0]), Some("hidzod".to_string()));

215− assert_eq!(to_ob(&[]), None);

210+ assert_eq!(to_ob(&[]), Some(String::new()));

216211 }

217212

218213 /// A real Ed25519 public key. `try_parse_pubkey` now checks that a key is a

219214 /// curve point, so tests can't use an arbitrary byte pattern.

220215 fn real_key() -> [u8; 32] {

221− crate::crypto::Identity::from_seed(&[7u8; 32]).unwrap().public_key()

216+ crate::crypto::Identity::from_seed(&[7u8; 32]).public_key()

222217 }

223218

224219 /// 32 bytes that decode fine but are *not* on the curve — the case that used

core/src/protocol.rs+31−72

@@ -4,8 +4,6 @@

44//! millisecond `ts`. Unknown types are ignored (return `None`).

66use serde::{Deserialize, Serialize};

7−use base64::prelude::*;

8−use base64::Engine;

108/// Caps on the attacker-chosen fields of an incoming payload.

119///

@@ -35,8 +33,8 @@ pub enum Payload {

3533 ack_ids: Vec<String>,

3634 },

3735 Profile {

38− display_name: Option<String>,

39− bio: Option<String>,

36+ display_name: String,

37+ bio: String,

4038 photo: Option<String>,

4139 },

4240}

@@ -77,16 +75,10 @@ pub fn serialize_payload(payload: &Payload, ts: i64) -> String {

7775 } => {

7876 let mut obj = serde_json::json!({

7977 "type": "profile",

78+ "display_name": display_name,

79+ "bio": bio,

8080 "ts": ts,

8181 });

82− // D13: Only include the field when present — absent means

83− // "don't change", while present (even empty) means "set to this".

84− if let Some(name) = display_name {

85− obj["display_name"] = serde_json::Value::String(name.clone());

86− }

87− if let Some(b) = bio {

88− obj["bio"] = serde_json::Value::String(b.clone());

89− }

9082 // Omit `photo` entirely when there isn't one, rather than sending an

9183 // explicit null: "no photo" and "field absent" mean the same thing to

9284 // a reader, and the null costs bytes in every broadcast.

@@ -99,38 +91,6 @@ pub fn serialize_payload(payload: &Payload, ts: i64) -> String {

9991 value.to_string()

10092}

10193

102−/// D14: Filter out control characters, bidirectional control characters, and

103−/// zero-width characters from a received string. Applied on the receiving side

104−/// (parse_payload) so the sender's input is preserved as-is on send, but the

105−/// recipient is protected from invisible character tricks.

106−///

107−/// Filters:

108−/// - Control characters U+0000–U+001F (except U+0009 tab, U+000A newline,

109−/// U+000D carriage return)

110−/// - Bidirectional control characters (U+200E LRM, U+200F RLM, U+202A–U+202E,

111−/// U+2066–U+2069)

112−/// - Zero-width characters (U+200B, U+200C, U+200D, U+FEFF)

113−fn sanitize_text(s: &str) -> String {

114− s.chars()

115− .filter(|c| {

116− let cp = *c as u32;

117− // Control characters U+0000–U+001F, except tab/newline/CR

118− if cp <= 0x001F && cp != 0x0009 && cp != 0x000A && cp != 0x000D {

119− return false;

120− }

121− // Bidirectional control characters

122− if matches!(cp, 0x200E | 0x200F | 0x202A..=0x202E | 0x2066..=0x2069) {

123− return false;

124− }

125− // Zero-width characters

126− if matches!(cp, 0x200B | 0x200C | 0x200D | 0xFEFF) {

127− return false;

128− }

129− true

130− })

131− .collect()

132−}

133−

13494/// Parse a plaintext payload. Returns `None` for unknown/malformed types so the

13595/// caller silently ignores them (forward compatibility, PROTOCOL.md §4).

13696pub fn parse_payload(bytes: &[u8]) -> Option<ParsedPayload> {

@@ -140,7 +100,7 @@ pub fn parse_payload(bytes: &[u8]) -> Option<ParsedPayload> {

140100 let payload = match ty {

141101 "text" => {

142102 let id = v.get("id")?.as_str()?.to_string();

143− let body = sanitize_text(v.get("body")?.as_str()?);

103+ let body = v.get("body")?.as_str()?.to_string();

144104 if id.len() > MAX_ID_LEN || body.len() > MAX_BODY_LEN {

145105 return None;

146106 }

@@ -165,24 +125,23 @@ pub fn parse_payload(bytes: &[u8]) -> Option<ParsedPayload> {

165125 Payload::DeliveryAck { ack_ids }

166126 }

167127 "profile" => {

168− // D13: Use Option<String> — None when the field is absent (don't

169− // change the recipient's cached value), Some(value) when present

170− // (even if empty, meaning "set to this value").

171− let display_name = v.get("display_name").and_then(|x| x.as_str()).map(sanitize_text);

172− let bio = v.get("bio").and_then(|x| x.as_str()).map(sanitize_text);

128+ let display_name = v

129+ .get("display_name")

130+ .and_then(|x| x.as_str())

131+ .unwrap_or("")

132+ .to_string();

133+ let bio = v

134+ .get("bio")

135+ .and_then(|x| x.as_str())

136+ .unwrap_or("")

137+ .to_string();

173138 let photo = v

174139 .get("photo")

175140 .and_then(|x| x.as_str())

176141 .map(str::to_string);

177− if display_name.as_ref().is_some_and(|d| d.chars().count() > MAX_DISPLAY_NAME_LEN)

178− || bio.as_ref().is_some_and(|b| b.chars().count() > MAX_BIO_LEN)

142+ if display_name.chars().count() > MAX_DISPLAY_NAME_LEN

143+ || bio.chars().count() > MAX_BIO_LEN

179144 || photo.as_ref().is_some_and(|p| p.len() > MAX_PHOTO_LEN)

180− || photo.as_ref().is_some_and(|p| {

181− // Reject a photo that isn't valid base64 — a peer can put

182− // any string in the field, and the shell attempts to decode

183− // it as an image on every render.

184− BASE64_STANDARD.decode(p).is_err()

185− })

186145 {

187146 return None;

188147 }

@@ -228,14 +187,14 @@ mod tests {

228187 #[test]

229188 fn profile_round_trip_with_and_without_photo() {

230189 let with = Payload::Profile {

231− display_name: Some("Alice".into()),

232− bio: Some("writing".into()),

190+ display_name: "Alice".into(),

191+ bio: "writing".into(),

233192 photo: Some("aGVsbG8=".into()),

234193 };

235194 assert_eq!(reparse(&with, 1).payload, with);

236195 let without = Payload::Profile {

237− display_name: Some("Bob".into()),

238− bio: Some("".into()),

196+ display_name: "Bob".into(),

197+ bio: "".into(),

239198 photo: None,

240199 };

241200 assert_eq!(reparse(&without, 1).payload, without);

@@ -275,8 +234,8 @@ mod tests {

275234

276235 let long_bio = serialize_payload(

277236 &Payload::Profile {

278− display_name: Some("A".into()),

279− bio: Some("b".repeat(MAX_BIO_LEN + 1)),

237+ display_name: "A".into(),

238+ bio: "b".repeat(MAX_BIO_LEN + 1),

280239 photo: None,

281240 },

282241 1,

@@ -285,8 +244,8 @@ mod tests {

285244

286245 let long_name = serialize_payload(

287246 &Payload::Profile {

288− display_name: Some("n".repeat(MAX_DISPLAY_NAME_LEN + 1)),

289− bio: Some(String::new()),

247+ display_name: "n".repeat(MAX_DISPLAY_NAME_LEN + 1),

248+ bio: String::new(),

290249 photo: None,

291250 },

292251 1,

@@ -295,8 +254,8 @@ mod tests {

295254

296255 let big_photo = serialize_payload(

297256 &Payload::Profile {

298− display_name: Some(String::new()),

299− bio: Some(String::new()),

257+ display_name: String::new(),

258+ bio: String::new(),

300259 photo: Some("p".repeat(MAX_PHOTO_LEN + 1)),

301260 },

302261 1,

@@ -330,8 +289,8 @@ mod tests {

330289 fn a_photoless_profile_omits_the_field() {

331290 let json = serialize_payload(

332291 &Payload::Profile {

333− display_name: Some("A".into()),

334− bio: Some("B".into()),

292+ display_name: "A".into(),

293+ bio: "B".into(),

335294 photo: None,

336295 },

337296 1,

@@ -342,8 +301,8 @@ mod tests {

342301 #[test]

343302 fn snake_case_field_names_on_wire() {

344303 let p = Payload::Profile {

345− display_name: Some("A".into()),

346− bio: Some("B".into()),

304+ display_name: "A".into(),

305+ bio: "B".into(),

347306 photo: None,

348307 };

349308 let json = serialize_payload(&p, 1);

install.sh+9−13

@@ -154,21 +154,18 @@ fetch_to "$DOWNLOAD_URL" "$TMP_BIN"

154154# HTTPS, but that authenticates GitHub's CDN, not the artifact — a compromised or

155155# swapped release asset would otherwise be installed and launched unquestioned.

156156#

157−# N15: Verification is mandatory. A missing checksum, a missing sha256sum tool,

158−# or a mismatch are all fatal — the binary is refused.

159−# N15: Checksum verification is mandatory for all installs. A missing

160−# checksum file indicates either a pre-checksum release or a supply-chain

161−# attack that removed the checksum. We refuse to install without verification

162−# rather than silently proceeding.

157+# The check is best-effort by necessity: releases cut before CI began publishing

158+# .sha256 files have no checksum to compare against, and refusing to install from

159+# them would break upgrades from every existing deployment. So a *missing*

160+# checksum warns and proceeds, while a checksum that is present and does *not*

161+# match is fatal — the case that actually indicates tampering.

163162if fetch_to "$CHECKSUM_URL" "$TMP_SUM" 2>/dev/null; then

164163 EXPECTED=$(cut -d' ' -f1 < "$TMP_SUM")

165164 ACTUAL=$(sha256_of "$TMP_BIN")

166165 if [ -z "$ACTUAL" ]; then

167− echo "error: no sha256sum/shasum available; cannot verify binary integrity" >&2

168− exit 1

166+ echo "warning: no sha256sum/shasum available; skipping checksum verification" >&2

169167 elif [ -z "$EXPECTED" ]; then

170− echo "error: checksum file is empty; refusing to install unverified binary" >&2

171− exit 1

168+ echo "warning: checksum file is empty; skipping verification" >&2

172169 elif [ "$EXPECTED" != "$ACTUAL" ]; then

173170 echo "error: checksum verification FAILED for ${ASSET}" >&2

174171 echo " expected: ${EXPECTED}" >&2

@@ -179,9 +176,8 @@ if fetch_to "$CHECKSUM_URL" "$TMP_SUM" 2>/dev/null; then

179176 echo "Checksum verified (${ACTUAL})"

180177 fi

181178else

182− echo "error: no published checksum at ${CHECKSUM_URL}; refusing to install unverified binary" >&2

183− echo " (releases predating checksum publication have none — install from a recent release)" >&2

184− exit 1

179+ echo "warning: no published checksum at ${CHECKSUM_URL}; skipping verification" >&2

180+ echo " (releases predating checksum publication have none)" >&2

185181fi

186182

187183chmod 755 "$TMP_BIN"

server.knot+86−261

@@ -87,29 +87,12 @@ maxBatchSize = 100

8787-- Cap on gossip events accepted or emitted in a single federation exchange.

8888maxGossipEvents : Int

8989maxGossipEvents = 100

90−-- N13: Cap on newly-online keys per gossip batch that trigger forward sweeps.

91−-- Without this, a single gossip request with 100 `online` events triggers 100

92−-- mailbox scans (O(100 × |messages|)). Capping at 10 limits the amplification

93−-- while still allowing reasonable multi-key presence announcements. Remaining

94−-- newly-online keys are still written to `*presence` — only the forward sweep

95−-- is deferred until the next presence re-announce or a poll triggers

96−-- `forwardQueuedToServer` naturally.

97−maxNewlyOnlineForwards : Int

98−maxNewlyOnlineForwards = 10

9990-- Cap on events returned by one long-poll response.

10091maxPollEvents : Int

10192maxPollEvents = 50

10293-- Per-peer ceiling on outstanding forward attempts.

10394maxForwardsPerServer : Int

10495maxForwardsPerServer = 2000

105−-- S9: Cap on distinct remote servers a single message is immediately forwarded

106−-- to at send time. Separate from `maxForwardsPerServer` (which bounds outstanding

107−-- forwards *per peer*), this bounds the fan-out breadth. A recipient is unlikely

108−-- to be visible on more than 100 servers; the previous reuse of

109−-- `maxForwardsPerServer` (2000) for this purpose was an overload that could

110−-- spawn up to 2000 immediate HTTP forwards per message.

111−maxRemoteServersPerMessage : Int

112−maxRemoteServersPerMessage = 100

11396-- Global ceiling on the `*forwards` outbox. `maxForwardsPerServer` bounds any one

11497-- peer, but a recipient gossiped as present on many servers fans one blob out to

11598-- all of them, so the total is bounded only by (peers x per-peer cap). This caps

@@ -197,15 +180,6 @@ maxPresencePerServer = 5000

197180-- the same argument for sessions on `maxSessions`, and PROTOCOL.md §10.

198181maxMessagesPerRecipient : Int

199182maxMessagesPerRecipient = 10000

200−-- Global ceiling on total stored messages across all recipients (S6). Every

201−-- other state ref has a global cap (*sessions, *challenges, *presence,

202−-- *forwards); *messages had only a per-recipient cap, so total storage was

203−-- bounded only by (distinct recipient keys x maxMessagesPerRecipient), and an

204−-- attacker minting fresh invalid pubkeys could fill the disk (bounded only by

205−-- rate limits and the 30-day TTL). On overflow this evicts the globally-oldest

206−-- rows, symmetric with the other refs. See PROTOCOL.md §10.

207−maxMessagesTotal : Int

208−maxMessagesTotal = 1000000

209183-- Validity window for an auth challenge before it must be re-issued (1 min).

210184challengeExpiry : Int<Ms>

211185challengeExpiry = 60000

@@ -544,15 +518,8 @@ capPerServer = \items server maxN -> union (filter (\x -> not (x.server == serve

544518-- no timestamp (the same reason `retryPendingForwards` has to sort on the blob).

545519-- Applied by both writers that grow `*forwards` (`forwardQueuedToServer` and

546520-- `handleSendMessages`); the retry sweep only ever shrinks it.

547−--

548−-- N4: Sort by `(retries, encryptedBlob)` for determinism. Without the secondary

549−-- key, a `sortBy retries` alone is unstable when many entries share `retries: 0`,

550−-- and any of them could be dropped — including a fresh forward for a healthy

551−-- peer. The blob is a unique secondary key (the dedup invariant guarantees

552−-- `(toKey, encryptedBlob, toServer)` uniqueness), so the sort is total and

553−-- deterministic.

554521capForwards : [ForwardEntry] -> [ForwardEntry]

555−capForwards = \fwds -> take maxForwardsTotal (sortBy (\f -> {retries: f.retries, blob: f.encryptedBlob}) fwds)

522+capForwards = \fwds -> take maxForwardsTotal (sortBy (\f -> f.retries) fwds)

556523

557524-- Random hex token: one random hex char per recursive call. `n` is the

558525-- desired length in characters (so n=48 yields 24 random bytes of entropy).

@@ -777,7 +744,7 @@ isBadServerName : Text -> Bool

777744isBadServerName = \raw ->

778745 let sn = stripTrailingDot raw in

779746 let host = beforeColon sn in

780− sn == "" || sn == "localhost" || hasPrefix "localhost:" sn || isNumericHost host || isReservedOctetPrefix host || isReservedIPv4 host || hasLeadingZeroOctet host || hasPrefix "0x" sn || any (\c -> not contains c "0123456789abcdefghijklmnopqrstuvwxyz-.:") (chars sn) || countChar ":" sn > 1 || any (\p -> hasPrefix p sn) [".", ":", "192.0.2.", "198.51.100.", "203.0.113."] || any (\s -> hasSuffix s sn) [".localhost", ".local", ".internal", ".arpa", ".onion"]

747+ sn == "" || sn == "localhost" || hasPrefix "localhost:" sn || isNumericHost host || isReservedOctetPrefix host || isReservedIPv4 host || hasLeadingZeroOctet host || hasPrefix "0x" sn || any (\c -> not contains c "0123456789abcdefghijklmnopqrstuvwxyz-.:") (chars sn) || countChar ":" sn > 1 || any (\p -> hasPrefix p sn) [".", ":", "192.0.2.", "203.0.113."] || any (\s -> hasSuffix s sn) [".localhost", ".local", ".internal", ".arpa", ".onion"]

781748

782749-- ============================================

783750-- Auth helpers

@@ -949,13 +916,6 @@ currentSeq = \rows -> fold (\acc r -> max acc r.value) (0 : Timestamp) rows

949916-- and the fresh `seqTs` below would otherwise make `union` keep both rows and

950917-- double-deliver. Re-reading `*messages` per call also collapses duplicate blobs

951918-- appearing twice within one batch.

952−--

953−-- N3: This O(n) scan is a CPU amplification vector. A batch of 100 identical

954−-- blobs to the same recipient triggers 100 × O(|messages|) comparisons. With

955−-- |messages| = 10000, that's 1M comparisons per request, bounded by the 60/min

956−-- rate limit. A real fix needs an index on (toKey, encryptedBlob) or a

957−-- hash-based dedup set — both require runtime support not available in Knot

958−-- today. Documented as an accepted DoS surface.

959919appendMessage : PubkeyHex -> BlobHex -> Int<Ms> -> IO {rw *messages, rw *seqCounter} {}

960920appendMessage = \toKey encryptedBlob t -> do

961921 msgs <- *messages

@@ -967,32 +927,14 @@ appendMessage = \toKey encryptedBlob t -> do

967927 -- for this recipient so the post-append count lands exactly on the ceiling.

968928 -- `- 1` reserves the slot the new row is about to take.

969929 --

970− -- S4: Instead of building an `evicted` list and checking membership (which

971− -- is O(|messages| × |evicted|)), compute the eviction threshold — the

972− -- receivedAt of the (maxMessagesPerRecipient - 1)th oldest message for this

973− -- recipient — and keep only messages newer than it. This is O(|messages|)

974− -- with no inner scan.

930+ -- Eviction keys on `encryptedBlob` rather than the row itself because

931+ -- (toKey, encryptedBlob) is unique by this function's own dedup invariant

932+ -- (the `when` guard above), so a blob identifies at most one row per key.

975933 let forRecipient = filter (\m -> m.toKey == toKey) msgs

976934 let excess = max 0 (count forRecipient - (maxMessagesPerRecipient - 1))

977− let sortedRecipient = sortBy (\m -> m.receivedAt) forRecipient

978− -- The threshold: the receivedAt of the last row we want to evict.

979− -- Rows with receivedAt <= threshold are evicted; rows > threshold survive.

980− let evictionThreshold = if excess > 0

981− then case take excess sortedRecipient of

982− [] -> 0

983− xs -> case last xs of

984− {receivedAt: r} -> r

985− else 0

986− let kept = filter (\m -> not (m.toKey == toKey && m.receivedAt <= evictionThreshold && excess > 0)) msgs

987− -- Global cap (S6): after the per-recipient eviction, bound the total mailbox

988− -- across all recipients by dropping the globally-oldest rows. Only runs on

989− -- overflow, so the O(n log n) sort is off the hot path. Dropped rows may

990− -- belong to other recipients; their orphaned *forwards are reclaimed by

991− -- `pruneExpired`, and their lost `deliveredTo` is harmless (the blob is gone).

992− let globallyCapped = if count kept > maxMessagesTotal

993− then drop (count kept - maxMessagesTotal) (sortBy (\m -> m.receivedAt) kept)

994− else kept

995− *messages = union globallyCapped [{toKey, encryptedBlob, receivedAt: seqTs, deliveredTo: []}])

935+ let evicted = map (\m -> m.encryptedBlob) (take excess (sortBy (\m -> m.receivedAt) forRecipient))

936+ let kept = filter (\m -> not (m.toKey == toKey && elem m.encryptedBlob evicted)) msgs

937+ *messages = union kept [{toKey, encryptedBlob, receivedAt: seqTs, deliveredTo: []}])

996938

997939-- Record that `server` has accepted a federated forward of this message, so a

998940-- later presence re-announce of `toKey` doesn't re-forward the same blob to a peer

@@ -1046,12 +988,6 @@ pruneExpired = \t -> atomic do

1046988 -- Prune forwards whose message was removed by the TTL sweep above.

1047989 -- ForwardEntry carries no timestamp, so match against the surviving

1048990 -- messages (the post-sweep list, not the pre-sweep snapshot).

1049− --

1050− -- S5: This is O(|forwards| × |surviving|) — a quadratic scan. In practice

1051− -- |forwards| is usually far below maxForwardsTotal (50000) and |surviving|

1052− -- is bounded by maxMessagesTotal (1000000), so the cost is modest. A real

1053− -- fix needs a set/index keyed on (toKey, encryptedBlob), which the Knot

1054− -- runtime does not expose today. Documented as an accepted design tradeoff.

1055991 fw <- *forwards

1056992 *forwards = filter (\f -> any (\m -> m.toKey == f.toKey && m.encryptedBlob == f.encryptedBlob) surviving) fw

1057993 ff <- *forwardFailures

@@ -1114,70 +1050,56 @@ sendBatchedGossip = \peers events -> case localServerName of

11141050-- comes online: any messages already buffered for that pubkey are enqueued

11151051-- as forwards to the newly-known server.

11161052

1117−-- Attempt every forward in `batch` to one peer, in order, and report both whether

1118−-- any attempt was a genuine peer failure (`anyFailed`) and whether any attempt

1119−-- genuinely succeeded (`anySucceeded`). Drops successful entries from `*forwards`

1120−-- and records the peer on the message's `deliveredTo`; every attempt (success,

1121−-- failure, or 404) bumps the retry count and gives up after `maxForwardRetries`.

1053+-- Attempt every forward in `batch` to one peer, in order, and report whether any

1054+-- attempt was a genuine peer failure. Drops successful entries from `*forwards` and

1055+-- records the peer on the message's `deliveredTo`; on failure bumps the retry count

1056+-- and gives up after `maxForwardRetries`.

11221057--

11231058-- INVARIANT — this must not touch `*forwardFailures`. The caller records at most one

1124−-- failure per peer per sweep, from the `anyFailed` flag returned here; recording per

1125−-- failing *message* would let one unreachable peer with N buffered messages take N

1126−-- backoff steps in a single sweep and pin itself at `retryBackoffMax` for

1127−-- `forwardFailureMaxAge`. The counter counts consecutive failed *sweeps*.

1059+-- failure per peer per sweep, from the Bool returned here; recording per failing

1060+-- *message* would let one unreachable peer with N buffered messages take N backoff

1061+-- steps in a single sweep and pin itself at `retryBackoffMax` for `forwardFailureMaxAge`.

1062+-- The counter counts consecutive failed *sweeps*.

11281063--

11291064-- A 404 is NOT a peer failure. `handleForwardMessage` answers 404 `no_presence`

11301065-- whenever the recipient is not *currently* online at that peer, which is an

11311066-- expected, retryable outcome (PROTOCOL.md §7) — the peer is healthy and answering.

1132−-- `fetch` returns `Err` for every status >= 400, so treating any `Err` as a failure

1133−-- would feed a routine 404 into `recordFailure`, and `*forwardFailures` is shared

1134−-- with gossip: one stale-presence 404 would suppress all forwards *and* all gossip to

1135−-- that peer for a full backoff step (30 s–8 min). So a 404 leaves the peer's backoff

1136−-- untouched (`anyFailed` stays false for it) and never clears it (`anySucceeded`

1137−-- stays false too).

1138−--

1139−-- But a 404 DOES bump the forward's retry count now (S1). It previously left the row

1140−-- entirely untouched, so a forward whose recipient never came online at the peer was

1141−-- retried every sweep for the full 30-day message TTL — the counter never advanced,

1142−-- so `maxForwardRetries` was never reached. Counting the attempt (without charging

1143−-- the peer's backoff) lets the forward hit the cap and be dropped after

1144−-- `maxForwardRetries` sweeps while still not penalizing a healthy peer.

1067+-- But `fetch` returns `Err` for every status >= 400, so treating any `Err` as a

1068+-- failure would feed a routine 404 into `recordFailure`, and `*forwardFailures` is

1069+-- shared with gossip: one stale-presence 404 would suppress all forwards *and* all

1070+-- gossip to that peer for a full backoff step (30 s–8 min). So a 404 leaves the peer

1071+-- unpenalized and the forward row untouched — no retry bump either, since the row is

1072+-- waiting on the recipient's presence, not on a delivery that went wrong.

11451073--

11461074-- Recursive rather than `forEach` because the result has to be accumulated across

11471075-- iterations; `sortBy` fixes the iteration order that `head`/`drop 1` then walk.

1148−retryForwardsTo : Text -> [ForwardEntry] -> IO {rw *forwards, rw *messages, network} {anyFailed: Bool, anySucceeded: Bool}

1076+retryForwardsTo : Text -> [ForwardEntry] -> IO {rw *forwards, rw *messages, network} Bool

11491077retryForwardsTo = \server batch -> case head batch of

1150− Nothing {} -> yield {anyFailed: False {}, anySucceeded: False {}}

1078+ Nothing {} -> yield (False {})

11511079 Just {value: f} -> do

11521080 result <- fetch (federationUrl server) (ForwardMessage {f.toKey, f.encryptedBlob})

11531081 let status = case result of

11541082 Err {error: e} -> e.status

11551083 Ok _ -> 200

11561084 let success = status < 400

1157− -- Recipient simply isn't online at the peer yet: hold the peer blameless, but

1158− -- still count the attempt so the row can't outlive the message TTL (S1).

1085+ -- Recipient simply isn't online at the peer yet: hold the row, blame no one.

11591086 let deferred = status == 404

11601087 let isMatch = forwardMatches f.toKey f.encryptedBlob server

11611088 let isDone = \x -> isMatch x && (success || x.retries + 1 >= maxForwardRetries)

11621089 atomic (do

1163− cur <- *forwards

1164− -- Count the attempt regardless of outcome: a 404 still consumes a retry slot

1165− -- so a forward that never finds the recipient online is eventually dropped

1166− -- (S1). On success or after `maxForwardRetries`, `isDone` filters the row out

1167− -- first, so the increment then no-ops on an absent row.

1168− *forwards = map (\x -> if isMatch x

1169− then {x.toServer, x.toKey, x.encryptedBlob, retries: x.retries + 1}

1170− else x) (filter (\x -> not isDone x) cur)

1090+ when (not deferred) (do

1091+ cur <- *forwards

1092+ *forwards = map (\x -> if isMatch x

1093+ then {x.toServer, x.toKey, x.encryptedBlob, retries: x.retries + 1}

1094+ else x) (filter (\x -> not isDone x) cur))

11711095 when success (markDelivered f.toKey f.encryptedBlob server))

1172− rest <- retryForwardsTo server (drop 1 batch)

1173− yield {anyFailed: (not success && not deferred) || rest.anyFailed, anySucceeded: success || rest.anySucceeded}

1096+ restFailed <- retryForwardsTo server (drop 1 batch)

1097+ yield ((not success && not deferred) || restFailed)

11741098

11751099-- Walk pending forwards grouped by destination and retry each peer's backlog (up

11761100-- to maxBatchSize per peer) via `/federation/forward`. One failure record per peer

1177−-- per sweep: a sweep with any genuine failure takes exactly one backoff step; a

1178−-- sweep with at least one genuine success clears the peer's backoff; an all-404

1179−-- sweep leaves the backoff untouched, neither charging nor clearing it (S1). See

1180−-- `retryForwardsTo`.

1101+-- per sweep: a sweep in which every attempt succeeded clears the peer's backoff, a

1102+-- sweep with any failure takes exactly one backoff step (see `retryForwardsTo`).

11811103retryPendingForwards : IO {rw *forwardFailures, rw *forwards, rw *messages, network, clock} {}

11821104retryPendingForwards = do

11831105 t <- now

@@ -1199,17 +1121,13 @@ retryPendingForwards = do

11991121 -- `maxForwardRetries` (dropped). `ForwardEntry` carries no timestamp, so key on

12001122 -- the unique blob.

12011123 let batch = take maxBatchSize (sortBy (\f -> f.encryptedBlob) (filter (\f -> f.toServer == server) fwds))

1202− result <- retryForwardsTo server batch

1203− -- Clear the peer's backoff only on a sweep with at least one genuine success

1204− -- (S1). An all-404 sweep (recipient not online at the peer) is neither a

1205− -- failure nor a success: clearing backoff on it would reset the peer to

1206− -- "fresh" every sweep, firing a retry every `backgroundPruneInterval` for the

1207− -- full 30-day message TTL. `count batch > 0` also guards against reading an

1208− -- empty sweep (possible with a startup-overridden `maxBatchSize` of 0) as

1209− -- meaningful.

1210− if result.anyFailed

1124+ anyFailed <- retryForwardsTo server batch

1125+ -- `count batch > 0` guards the clear: `maxBatchSize` is startup-overridable,

1126+ -- and at 0 every batch is empty — an empty sweep must not be read as a

1127+ -- success and reset a failing peer's backoff.

1128+ if anyFailed

12111129 then recordFailure server t

1212− else when (count batch > 0 && result.anySucceeded) (clearFailure server t)))

1130+ else when (count batch > 0) (clearFailure server t)))

12131131

12141132-- Forward queued messages to a server when a remote key comes online.

12151133-- Skips messages already delivered to `server` (tracked via Message.deliveredTo)

@@ -1232,32 +1150,6 @@ forwardQueuedToServer = \pubkey serverName -> atomic (do

12321150 let newFwds = map (\m -> {toServer: server, m.toKey, m.encryptedBlob, retries: 0}) (take budget (sortBy (\m -> m.receivedAt) candidates))

12331151 *forwards = capForwards (union fwds newFwds))

12341152

1235−-- Batched version of `forwardQueuedToServer`: stage forwards for *all* newly-online

1236−-- keys in a single mailbox scan (S4). Calling `forwardQueuedToServer` per key scans

1237−-- `*messages` once per key, which is why `handleRecvGossip` previously capped the

1238−-- number of keys at `maxNewlyOnlineForwards` (N13) — but that cap silently deferred

1239−-- delivery past the 10th key, and a re-announce within the TTL never recovered it

1240−-- (the `deliveredTo`/presence state made the key look already-handled). A single

1241−-- pass bounds the cost to O(|messages|) regardless of how many keys came online.

1242−--

1243−-- SECURITY: shares `forwardQueuedToServer`'s exposure — it routes on gossip-written

1244−-- presence. The same `deliveredTo` / `notYetForwarded` / per-peer budget guards

1245−-- apply; do not widen them without revisiting the gossip-redirect note above.

1246−forwardQueuedToAll : [PubkeyHex] -> ServerName -> IO {rw *forwards, r *messages} {}

1247−forwardQueuedToAll = \pubkeys serverName -> atomic (do

1248− let server = (serverName : Text)

1249− msgs <- *messages

1250− fwds <- *forwards

1251− let existing = countWhere (\f -> f.toServer == server) fwds

1252− let budget = max 0 (maxForwardsPerServer - existing)

1253− let notYetForwarded = \m -> not any (forwardMatches m.toKey m.encryptedBlob server) fwds

1254− let notYetDelivered = \m -> not any (\d -> d.server == server) m.deliveredTo

1255− -- `elem m.toKey pubkeys` is O(|pubkeys|), but `pubkeys` is bounded by

1256− -- `maxGossipEvents` (100), so the scan stays O(|messages|) overall.

1257− let candidates = filter (\m -> elem m.toKey pubkeys && notYetForwarded m && notYetDelivered m) msgs

1258− let newFwds = map (\m -> {toServer: server, m.toKey, m.encryptedBlob, retries: 0}) (take budget (sortBy (\m -> m.receivedAt) candidates))

1259− *forwards = capForwards (union fwds newFwds))

1260−

12611153-- ============================================

12621154-- Handler: challenge / verify

12631155-- ============================================

@@ -1307,83 +1199,47 @@ handleVerifyAuth = \pubkey challenge signature revokeOthers clientIp -> do

13071199 -- The client signs (target host, challenge) under a domain-separation tag so a

13081200 -- relay server cannot replay the signature to a different server. We verify

13091201 -- against our own configured hostname (port stripped), which a relay cannot forge.

1310− --

1311− -- Signature verification is split out of the session-install transaction (S7).

1312− -- Phase 1 is a cheap read-only atomic that confirms a matching, unexpired,

1313− -- IP-bound challenge exists — the original CPU-DoS guard, which still spends no

1314− -- Ed25519 CPU on /auth/verify calls that have no matching challenge. Phase 2 runs

1315− -- the expensive `verify` *outside* any atomic, so an STM retry on the phase-3

1316− -- install transaction (triggered by concurrent writes to *challenges/*sessions)

1317− -- never re-executes it — previously `verify` sat inside that transaction and every

1318− -- retry re-ran the Ed25519 check. Phase 3 re-checks the challenge before consuming

1319− -- it, closing the TOCTOU window opened between phases 1 and 3.

1202+ -- Computed outside the atomic block: `verify` is not a DB effect, and computing

1203+ -- it here avoids re-running crypto on every STM retry.

13201204 let signedText = "skrepka-auth-v1:" ++ authHost serverHost ++ ":" ++ challenge

1321− challengeOk <- atomic (do

1205+ let sigValid = case bytesFromHex pubkey of

1206+ Just {value: pk} -> case bytesFromHex signature of

1207+ Just {value: sigBytes} -> verify pk (textToBytes signedText) sigBytes

1208+ _ -> False {}

1209+ _ -> False {}

1210+ result <- atomic (do

13221211 ch <- *challenges

13231212 let same = \c -> c.pubkey == pubkey && c.challenge == challenge

1324− case findFirst ch same of

1325− Nothing {} -> yield (False {})

1326− Just {value: c} -> yield (c.expiresAt > t && matchIp clientIp c.ip))

1327− if not challengeOk

1328− then yield (Err {error: {status: 401, message: "invalid"}})

1329− else do

1330− -- Phase 2: verify OUTSIDE any atomic. Expensive, and must not be re-executed on

1331− -- an STM retry of the install transaction below (S7).

1332− let sigValid = case bytesFromHex pubkey of

1333− Just {value: pk} -> case bytesFromHex signature of

1334− Just {value: sigBytes} -> verify pk (textToBytes signedText) sigBytes

1335− _ -> False {}

1336− _ -> False {}

1337− if not sigValid

1338− then yield (Err {error: {status: 401, message: "invalid"}})

1213+ let valid = any (\c -> same c && c.expiresAt > t && matchIp clientIp c.ip) ch && sigValid

1214+ if not valid

1215+ then yield (Nothing {})

13391216 else do

1340− -- Phase 3: re-check the challenge (it may have expired or been consumed by a

1341− -- concurrent verify since phase 1), consume it, and install the session. The

1342− -- body is cheap, so an STM retry here costs almost nothing.

1343− result <- atomic (do

1344− ch <- *challenges

1345− let same = \c -> c.pubkey == pubkey && c.challenge == challenge

1346− let matchingChallenge = findFirst ch same

1347− case matchingChallenge of

1348− Nothing {} -> yield (Nothing {})

1349− Just {value: c} -> do

1350− if not (c.expiresAt > t && matchIp clientIp c.ip)

1351− then yield (Nothing {})

1352− else do

1353− -- Consume the challenge and optionally revoke other sessions + challenges.

1354− -- When `revokeOthers` is set, drop all other sessions AND outstanding

1355− -- challenges for this pubkey, so a captured challenge cannot be

1356− -- redeemed for a new session after revocation (Q35).

1357− *challenges = if revokeOthers

1358− then filter (\x -> not (x.pubkey == pubkey)) ch

1359− else filter (\x -> not same x) ch

1360− ses <- *sessions

1361− let pruned = if revokeOthers

1362− then filter (\s -> s.pubkey != pubkey) ses

1363− else capPerKey ses pubkey maxSessionsPerKey

1364− let newSession = {token, pubkey, expiresAt: expiry, ip: clientIp}

1365− -- LRU-evicts the soonest-to-expire session when the pool is full; this global

1366− -- eviction is Sybil-floodable, see the LIMITATION note on `maxSessions`.

1367− let pooled = union pruned [newSession]

1368− -- Count what `capList` is about to shed, so the handler can warn about it

1369− -- below. That flood has no other observable signature: evicted users just

1370− -- start seeing 401s and silently re-authenticate, which looks like normal

1371− -- traffic in the access log. A sustained nonzero rate here is the alert.

1372− let evicted = max 0 (count pooled - maxSessions)

1373− *sessions = capList pooled maxSessions

1374− peers <- refreshLocalPresence pubkey expiry

1375− yield (Just {value: {peers, evicted}}))

1376− case result of

1377− Nothing {} -> yield (Err {error: {status: 401, message: "invalid"}})

1378− Just {value: r} -> do

1379− -- Warn outside the `atomic` block, never inside: an STM transaction can

1380− -- retry, and a console write is not rolled back with it — logging inside

1381− -- would emit one line per retry attempt rather than one per eviction.

1382− -- Include the requesting pubkey and IP for audit (Q38): an operator

1383− -- investigating a Sybil flood needs to know which identities are responsible.

1384− when (r.evicted > 0) (logWarn ("session pool full: evicted " ++ show r.evicted ++ " session(s) to seat a new login (pubkey=" ++ pubkey ++ ", ip=" ++ clientIp ++ ", maxSessions=" ++ show maxSessions ++ ")"))

1385− when federationEnabled (fork (sendBatchedGossip r.peers [{eventType: "online", pubkey: Just {value: pubkey}}]))

1386− yield (Ok {value: {token, expiresAt: expiry}})

1217+ *challenges = filter (\c -> not same c) ch

1218+ ses <- *sessions

1219+ let pruned = if revokeOthers

1220+ then filter (\s -> s.pubkey != pubkey) ses

1221+ else capPerKey ses pubkey maxSessionsPerKey

1222+ let newSession = {token, pubkey, expiresAt: expiry, ip: clientIp}

1223+ -- LRU-evicts the soonest-to-expire session when the pool is full; this global

1224+ -- eviction is Sybil-floodable, see the LIMITATION note on `maxSessions`.

1225+ let pooled = union pruned [newSession]

1226+ -- Count what `capList` is about to shed, so the handler can warn about it

1227+ -- below. That flood has no other observable signature: evicted users just

1228+ -- start seeing 401s and silently re-authenticate, which looks like normal

1229+ -- traffic in the access log. A sustained nonzero rate here is the alert.

1230+ let evicted = max 0 (count pooled - maxSessions)

1231+ *sessions = capList pooled maxSessions

1232+ peers <- refreshLocalPresence pubkey expiry

1233+ yield (Just {value: {peers, evicted}}))

1234+ case result of

1235+ Nothing {} -> yield (Err {error: {status: 401, message: "invalid"}})

1236+ Just {value: r} -> do

1237+ -- Warn outside the `atomic` block, never inside: an STM transaction can

1238+ -- retry, and a console write is not rolled back with it — logging inside

1239+ -- would emit one line per retry attempt rather than one per eviction.

1240+ when (r.evicted > 0) (logWarn ("session pool full: evicted " ++ show r.evicted ++ " session(s) to seat a new login (maxSessions=" ++ show maxSessions ++ ")"))

1241+ when federationEnabled (fork (sendBatchedGossip r.peers [{eventType: "online", pubkey: Just {value: pubkey}}]))

1242+ yield (Ok {value: {token, expiresAt: expiry}})

13871243

13881244-- ============================================

13891245-- Handler: poll

@@ -1422,16 +1278,11 @@ handlePoll = \cursor authorization clientIp -> do

14221278 -- so peers don't time us out mid-session.

14231279 let stale = not any (\p -> p.pubkey == pubkey && isLocalServer p.server && p.expiresAt - t >= sessionExpiry / 2) pres

14241280 refreshPeers <- if stale then refreshLocalPresence pubkey (t + sessionExpiry) else yield []

1425− -- S3: Track whether we actually refreshed so the gossip line below

1426− -- only fires on a refresh, not on every poll. Without this, every

1427− -- poll gossips to all seed peers via gossipTargets [], creating

1428− -- O(clients × seeds) federation traffic per poll cycle.

1429− yield (Just {value: {pubkey, clampedCursor, refreshPeers, didRefresh: stale}}))

1281+ yield (Just {value: {pubkey, clampedCursor, refreshPeers}}))

14301282 case setup of

14311283 Nothing {} -> yield (Err {error: {status: 401, message: "unauthorized"}})

14321284 Just {value: s} -> do

1433− -- S3: Only gossip when we actually refreshed presence — not on every poll.

1434− when (federationEnabled && s.didRefresh) (fork (sendBatchedGossip s.refreshPeers [{eventType: "online", pubkey: Just {value: s.pubkey}}]))

1285+ when federationEnabled (fork (sendBatchedGossip s.refreshPeers [{eventType: "online", pubkey: Just {value: s.pubkey}}]))

14351286 pollResult <- doPoll s t

14361287 yield (Ok {value: pollResult})

14371288

@@ -1542,15 +1393,10 @@ handleSendMessages = \messages authorization clientIp -> do

15421393 Nothing {} -> do

15431394 committed <- atomic (do

15441395 pres <- *presence

1545− -- S2: cap the immediate fan-out at `maxForwardsPerServer` servers per

1546− -- recipient. The post-commit `forkForwardsTo` fires against this list

1547− -- directly (bypassing the `*forwards` queue and its per-peer cap), so

1548− -- without a bound here a recipient gossiped as present on thousands of

1549− -- servers would spawn one immediate HTTP forward per server per message.

15501396 let staged = map (\m -> {

15511397 m.to,

15521398 m.encryptedBlob,

1553− remoteServers: take maxRemoteServersPerMessage (collectPeers (filter (\p -> p.pubkey == m.to && p.expiresAt > t) pres) (\p -> p.server))

1399+ remoteServers: collectPeers (filter (\p -> p.pubkey == m.to && p.expiresAt > t) pres) (\p -> p.server)

15541400 }) messages

15551401 forEach staged (\c -> do

15561402 -- Read `*messages` *before* the append: `delivered` below must see the

@@ -1655,7 +1501,7 @@ forkForwardsTo = \to encryptedBlob servers -> forEach servers (\server -> when (

16551501-- fromServer) row touched by this batch, then re-adds fresh-TTL rows for

16561502-- pubkeys with an `online` event (so Online wins on collision). For keys

16571503-- that transition offline → online, flushes any locally-buffered messages via

1658−-- `forwardQueuedToAll`. Events with an unrecognized `eventType` or no

1504+-- `forwardQueuedToServer`. Events with an unrecognized `eventType` or no

16591505-- `pubkey` are skipped (forward-compat) rather than rejecting the batch.

16601506--

16611507-- SECURITY: this is the gossip-redirect ingress described in the section header

@@ -1666,7 +1512,7 @@ handleRecvGossip : [GossipEvent] -> ServerName -> IO {r *messages, rw *forwards,

16661512handleRecvGossip = \events fromServer -> do

16671513 t <- now

16681514 -- Widen the peer-supplied `ServerName` once (see `type ServerName`);

1669− -- `forwardQueuedToAll` below still takes the refined name.

1515+ -- `forwardQueuedToServer` below still takes the refined name.

16701516 let from = (fromServer : Text)

16711517 if not federationEnabled

16721518 then yield (Err {error: {status: 403, message: "federation_disabled"}})

@@ -1689,13 +1535,12 @@ handleRecvGossip = \events fromServer -> do

16891535 Ok {value: pk} -> if e.eventType == "online"

16901536 then {

16911537 touched: union acc.touched [pk],

1692− added: union acc.added [{pubkey: pk, server: from, expiresAt: t + onlineGossipTtl}],

1693− offline: acc.offline

1538+ added: union acc.added [{pubkey: pk, server: from, expiresAt: t + onlineGossipTtl}]

16941539 }

16951540 else if e.eventType == "offline"

1696− then {acc.added, touched: union acc.touched [pk], offline: union acc.offline [pk]}

1541+ then {acc.added, touched: union acc.touched [pk]}

16971542 else acc

1698− Nothing {} -> acc) {touched: ([] : [PubkeyHex]), added: ([] : [PresenceEntry]), offline: ([] : [PubkeyHex])} events

1543+ Nothing {} -> acc) {touched: ([] : [PubkeyHex]), added: ([] : [PresenceEntry])} events

16991544 let kept = filter (\p -> p.server != from || not elem p.pubkey collected.touched) pres

17001545 let merged = union kept collected.added

17011546 -- Cap the gossip-learned rows: per-peer first, so one peer cannot crowd every

@@ -1707,28 +1552,8 @@ handleRecvGossip = \events fromServer -> do

17071552 let localRows = filter (\p -> isLocalServer p.server) merged

17081553 let remoteRows = filter (\p -> not isLocalServer p.server) merged

17091554 *presence = union localRows (capList (capPerServer remoteRows from maxPresencePerServer) maxPresence)

1710− -- S8: Make online+offline for the same key mutually exclusive within one

1711− -- batch. If a batch carries both events for a key, online wins — the presence

1712− -- merge above already added the online row — so that key must NOT also travel

1713− -- the offline path and cancel its own freshly-staged forwards.

1714− let onlineKeys = map (\p -> p.pubkey) collected.added

1715− let offlineOnly = filter (\pk -> not elem pk onlineKeys) collected.offline

1716− -- N14: Cancel pending forwards to `from` for offline keys. Without this,

1717− -- forwards to a peer that just went offline retry for up to 80 minutes,

1718− -- wasting maxForwardsPerServer slots and generating failed HTTP requests.

1719− -- The message stays in *messages, so it's re-forwarded if the key

1720− -- re-appears on another peer.

1721− when (count offlineOnly > 0) (do

1722− fwds <- *forwards

1723− *forwards = filter (\f -> not (f.toServer == from && elem f.toKey offlineOnly)) fwds)

17241555 yield (filter (\pk -> not any (\p -> p.pubkey == pk && p.server == from && p.expiresAt > t) pres) (map (\p -> p.pubkey) collected.added)))

1725− -- S4: forward queued mail for ALL newly-online keys in one mailbox pass. The

1726− -- old per-key cap (maxNewlyOnlineForwards, N13) bounded amplification but

1727− -- silently deferred delivery past the 10th key, and a re-announce within the

1728− -- TTL never recovered it (the deliveredTo/presence state made the key look

1729− -- already-handled). `forwardQueuedToAll` bounds the cost to O(|messages|)

1730− -- regardless of how many keys came online.

1731− fork (forwardQueuedToAll newlyOnline fromServer)

1556+ fork (forEach newlyOnline (\pk -> forwardQueuedToServer pk fromServer))

17321557 yield (Ok {value: {}})

17331558

17341559-- POST /federation/forward: receive a single federated message destined for

server.odeleted

Binary file not shown.