| 1 | # Findings on the relay spec, revision 4 |
| 2 | |
| 3 | Reviewed by **GPT-6 (Codex), 2026-09-07**, fourth pass, against revision 4 at `ee4b78a`, with Paul's rulings treated as fixed. Unedited apart from this note. Revision 5 records how each finding was taken. |
| 4 | |
| 5 | | Revision-3 finding | Disposition | Reason | |
| 6 | |---|---|---| |
| 7 | | R3-1 — Interrupted deletion | Closed | Unconditional aggregate rebuilds recover deletion even after its source record disappears. | |
| 8 | | R3-2 — Stale config publication | Partial | The lock prevents in-process interleaving; cross-process repair still permits old-key delivery after the rotation cutoff. | |
| 9 | | R3-3 — Allocation cleanup | Closed | Wrapper-owned cleanup has the identity needed to preserve a replacement binding. | |
| 10 | | R3-4 — Config adoption and retirement | Partial | Per-route acknowledgements improve granularity, but omit incarnation; the retirement formula also omits the manual cutover time. | |
| 11 | | R3-5 — Premature key issuance | Closed | Every derivation path uses the gated issuer pointer; staging a master alone issues nothing. | |
| 12 | | R3-6 — Rolling-window recovery | Closed | Recovery explicitly reads every hourly object intersecting the window. | |
| 13 | | R3-7 — Memory-pressure behavior | Closed | The OOM claim is narrowed and host-pressure shedding has an explicit trigger. | |
| 14 | | R3-8 — Roadmap contradictions | Closed | The amended passages agree with the fixed rulings and stage contract. | |
| 15 | |
| 16 | Reviewed commit `ee4b78ab3956800448d4df47d87749340133b6b4`, treating Paul’s six rulings as fixed. The cryptographic vector reproduces. Pion v4.1.4’s [documented API](https://pkg.go.dev/github.com/pion/turn/v4) and local source were checked. No files were changed; no live TURN or EC2 tests were run. |
| 17 | |
| 18 | ## R4-1 — P2 — Eventual config repair cannot establish the rotation cutoff |
| 19 | |
| 20 | **Sections:** §2, credential lifetime; §5, reconciliation and rotation. |
| 21 | |
| 22 | The revised mechanism explicitly permits stale config writes across console processes and repairs them within five minutes. That bounds config inconsistency, but does not preserve the promised lifetime of credentials minted during it. |
| 23 | |
| 24 | A permitted sequence is: |
| 25 | |
| 26 | 1. An operation reads the old issuer and derives its config, then pauses. |
| 27 | 2. Another console process rotates, delivers the new key, and obtains every required adoption acknowledgement. |
| 28 | 3. The old operation resumes shortly before the scheduled retirement and publishes its old-key config. A route adopts it and mints a four-hour credential. |
| 29 | 4. Retirement ends that credential’s allocation early. Subsequent reconciliation cannot restore the interrupted call. |
| 30 | |
| 31 | This requires a delayed writer, not force-retirement by the operator: the operator can follow the stated retirement procedure throughout. |
| 32 | |
| 33 | **Evidence:** [The reconciliation mechanism](/home/paulca/amadan.net/carlos/platform/.claude/worktrees/media-roadmap-spec/docs/superpowers/specs/2026-09-07-relay-stun-turn-design.md:408) expressly allows cross-process stale publication. [Rotation](/home/paulca/amadan.net/carlos/platform/.claude/worktrees/media-roadmap-spec/docs/superpowers/specs/2026-09-07-relay-stun-turn-design.md:536) treats migration acknowledgements as establishing when old issuance has stopped. |
| 34 | |
| 35 | **Correction:** Require a publication fence that prevents superseded key selections from reaching config after migration, or establish an enforceable single-writer model covering takeover between console processes. Keep reconciliation for recovery, but do not use eventual repair as the fence. Test a delayed old-key publisher resuming after the migration acknowledgements. |
| 36 | |
| 37 | ## R4-2 — P2 — Acknowledgements cannot distinguish credentials before and after re-enable |
| 38 | |
| 39 | **Sections:** §2, incarnation and key changes; §5, config adoption and status. |
| 40 | |
| 41 | The acknowledgement records only the `kid` per region. A disable followed by re-enable changes the incarnation and derived key while retaining the same regional master and `kid`. |
| 42 | |
| 43 | If both operations finish before the host’s next config sync, its previous successful acknowledgement still names all the newly issued kids. The prescribed status comparison therefore reports “adopted” while the process holds the previous incarnation’s credentials, which the relay rejects. |
| 44 | |
| 45 | **Evidence:** [The re-enable transition](/home/paulca/amadan.net/carlos/platform/.claude/worktrees/media-roadmap-spec/docs/superpowers/specs/2026-09-07-relay-stun-turn-design.md:450) creates a new incarnation. [The acknowledgement and status rules](/home/paulca/amadan.net/carlos/platform/.claude/worktrees/media-roadmap-spec/docs/superpowers/specs/2026-09-07-relay-stun-turn-design.md:482) identify and compare credentials using kids alone. |
| 46 | |
| 47 | **Correction:** Record and compare the complete derived-key identity, including account, app, incarnation, region and kid. The delivered `username_suffix` already supplies most of it. Test disable/re-enable between host syncs: the previous acknowledgement must not establish adoption. |
| 48 | |
| 49 | ## R4-3 — P2 — Retirement does not explicitly allow four hours after manual cutover |
| 50 | |
| 51 | **Sections:** §2, credential lifetime; §5, rotation step 5. |
| 52 | |
| 53 | The retirement formula uses the later of 28 hours after rotation and four hours after the last **observed route acknowledgement**, with unobservable routes restarted by hand. It does not include those manual restart times in the four-hour calculation. |
| 54 | |
| 55 | Suppose observed routes acknowledge at hour 1, while a TCP exec route continues minting from its old in-memory key until its manual restart at hour 28. The written formula permits retirement at hour 28. A credential minted just before that restart can consequently lose almost its entire four-hour lifetime. |
| 56 | |
| 57 | **Evidence:** [Step 5’s formula](/home/paulca/amadan.net/carlos/platform/.claude/worktrees/media-roadmap-spec/docs/superpowers/specs/2026-09-07-relay-stun-turn-design.md:542) names only the observed acknowledgement as the grace-period clock, whereas [§2’s guarantee](/home/paulca/amadan.net/carlos/platform/.claude/worktrees/media-roadmap-spec/docs/superpowers/specs/2026-09-07-relay-stun-turn-design.md:121) requires four hours after the last instance stops minting from the old key. |
| 58 | |
| 59 | **Correction:** Define retirement as no earlier than `max(rotation time + 28h, latest issuer cutover + 4h)`, where the latest cutover includes manually verified adoption. Restarting an unobservable route must establish that it actually loaded the new key. Include a manual cutover after hour 28 in the rotation test. |
| 60 | |
| 61 | **Verdict: request changes.** No P1 remains. Three P2 defects remain in publication fencing, adoption identity and the retirement rule. |
amadan