carlos / platform Public

Clone
git clone https://amadan.net/carlos/platform

Plain git — no account needed to clone.

Download

Download this file

Findings on the media roadmap, revision 5

Reviewed by GPT-6 (Codex), 2026-09-07, fifth pass, against revision 5 at 1255d28, with Paul's rulings treated as fixed. Unedited apart from this note. Verdict: accept. Revision 6 applies the two wording corrections.

| Revision-4 finding | Disposition | One-line reason | |---|---|---| | R4-1 — Rejoin admission | Closed | An unavoidable proxy checks revocation before upstream admission, serialized against removal. | | R4-2 — Established-session removal | Closed | An explicit backend removal operation calls RemoveParticipant, independently of client refresh; §9 bounds termination to one second. | | R4-3 — Synchronous publication bypass | Closed | The initiating request receives transformed bytes only after successful console publication. | | R4-4 — Instance-host collisions | Closed | All hostname-acquisition doors share the claim; enable checks existing app, route and instance ownership. | | R4-5 — Invalid generated hostnames | Partial | Trailing-hyphen refusal and length handling are sound; one blanket app-name assertion remains false. | | R4-6 — Existing relay allocations | Closed | Authority expiry now terminates established allocations as well as refusing new ones. | | R4-7 — External STUN defaults | Closed | Stage 4b explicitly requires platform-only discovery and client ICE configuration, with no external fallback. | | R4-8 — Existing-code descriptions | Closed | Scanning enforcement is qualified, and media is correctly described as the fourth app-mintable kind. |

Reviewed commit 1255d28529a1db3def775c46618df5e98e5eac21, with Paul’s eleven rulings fixed. “Closed” means complete at roadmap level, not implementation-proven. No files were changed.

Severity: P1 breaks a trust guarantee or makes a stage unbuildable; P2 requires correction before the stage spec; P3 is advisory.

R5-1 — P3 — Stage 1: the blanket app-name assertion remains false

Problem and evidence: Lines 319–320 still say that media-<app> “is also a valid app name.” release.ValidApp permits at most 32 characters. Prefixing a valid 27–32-character app name produces a 33–38-character label.

The surrounding mechanism correctly accepts these as hostname claims without using the app-name validator, and §1 already states the 26-character qualification. Only the explanatory sentence remains wrong.

Correction: Say that media-<app> can also be a valid app name, which creates the collision the separate claim prevents.

R5-2 — P3 — Stage 4b: attribute media termination to RemoveParticipant

Problem and evidence: Lines 709–712 describe dropping the participant’s signalling connection as ending the session. LiveKit’s HandleSignalSourceClose closes the participant only when ICE has not connected; an established media connection can survive signalling loss. LiveKit implementation.

The same paragraph already names the appropriate server operation, RemoveParticipant, and the admission gate prevents revoked identities from reconnecting. This closes the earlier architectural defect; the remaining issue is the explanation of which operation terminates media. LiveKit removal API.

Correction: State that RemoveParticipant terminates the active media session, while the proxy closes signalling and refuses subsequent admission. Preserve §9’s one-second termination gate.

Verdict: accept. No P1 or P2 problems remain. The two P3 corrections concern explanatory wording; the mechanisms are named, bounded and assigned to stages, and no remaining mechanism-level conflict with Paul’s fixed rulings was found.