From 1e80e88521eaffd518bfa77f2dcff33072314b43 Mon Sep 17 00:00:00 2001 From: Luke Curley Date: Tue, 29 Sep 2026 15:41:46 -0700 Subject: [PATCH 1/5] quest(archive): DVR resolves the live-end handover through the wildcard claim Co-Authored-By: Claude Opus 5.5 --- quest/m1/archive/dvr.md | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/quest/m1/archive/dvr.md b/quest/m1/archive/dvr.md index e379b55192..a58861ea52 100644 --- a/quest/m1/archive/dvr.md +++ b/quest/m1/archive/dvr.md @@ -27,9 +27,18 @@ served stays in `moq_net`'s track cache until the pool reclaims it. Decide whether expiry during a seek needs a group eviction API in `moq-net`. `moq-hls` reads a timeline from the catalog's own broadcast, and an -`archive.replay` path only marks it non-durable. Decide whether a live -broadcast's exporter follows `replay` to the recording for rewind, or whether -viewers address the replay broadcast directly. +`archive.replay` path only marks it non-durable. Decided (09-29): the exporter +does not follow `replay`, and viewers don't address a separate replay +broadcast. A recording is the broadcast. Under the +[wildcard](/quest/m0/wildcard/README.md) plan the archive serves the source +path through the root claim, and a live announcement shadows it. So when live +ends, `moq-hls` resolves the same name and falls through to the recording: +playlists keep serving for rewind and for players finishing the last +segments. `moq-hls` gains no linger (the `hls-linger` quest was dropped, +because an unannounced broadcast can't be FETCHed and a linger would only +serve the cache). Test the handover: a live HLS session keeps its playlist +URIs and media sequence numbers when the name moves from the live publisher to +the archive. ## Required From 2c29bdd6cf6b8fbcd81747024b52a8ceec61959f Mon Sep 17 00:00:00 2001 From: Luke Curley Date: Tue, 29 Sep 2026 15:56:29 -0700 Subject: [PATCH 2/5] quest(archive): DVR handover requires the replay catalog Co-Authored-By: Claude Opus 5.5 --- quest/m1/archive/dvr.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/quest/m1/archive/dvr.md b/quest/m1/archive/dvr.md index a58861ea52..eacb06a8ff 100644 --- a/quest/m1/archive/dvr.md +++ b/quest/m1/archive/dvr.md @@ -34,15 +34,17 @@ broadcast. A recording is the broadcast. Under the path through the root claim, and a live announcement shadows it. So when live ends, `moq-hls` resolves the same name and falls through to the recording: playlists keep serving for rewind and for players finishing the last -segments. `moq-hls` gains no linger (the `hls-linger` quest was dropped, -because an unannounced broadcast can't be FETCHed and a linger would only -serve the cache). Test the handover: a live HLS session keeps its playlist -URIs and media sequence numbers when the name moves from the live publisher to -the archive. +segments. The fall-through needs the recording to publish its catalog live, +since `moq-hls` subscribes to it rather than FETCHing it. `moq-hls` gains +no linger (the `hls-linger` quest was dropped, because an unannounced +broadcast can't be FETCHed and a linger would only serve the cache). Test +the handover: a live HLS session keeps its playlist URIs and media sequence +numbers when the name moves from the live publisher to the archive. ## Required - [Per-track timelines](/quest/m1/archive/track-timeline/README.md) - seeks through per-track timelines +- [Replay catalog](/quest/m1/archive/replay-catalog.md) - the recording publishes its catalog live, so `moq-hls` finds it after the handover ## Closes From 4005e0bdb2281e66abc1a6cbab3be48930e95d2e Mon Sep 17 00:00:00 2001 From: Luke Curley Date: Tue, 29 Sep 2026 16:22:28 -0700 Subject: [PATCH 3/5] quest(archive): DVR handover requires wildcard routing Co-Authored-By: Claude Opus 5.5 --- quest/m1/archive/dvr.md | 1 + 1 file changed, 1 insertion(+) diff --git a/quest/m1/archive/dvr.md b/quest/m1/archive/dvr.md index eacb06a8ff..373feb14f6 100644 --- a/quest/m1/archive/dvr.md +++ b/quest/m1/archive/dvr.md @@ -45,6 +45,7 @@ numbers when the name moves from the live publisher to the archive. - [Per-track timelines](/quest/m1/archive/track-timeline/README.md) - seeks through per-track timelines - [Replay catalog](/quest/m1/archive/replay-catalog.md) - the recording publishes its catalog live, so `moq-hls` finds it after the handover +- [Wildcard](/quest/m0/wildcard/README.md) - the archive's root claim serves the source path once the live announcement ends ## Closes From dc935499261f9b84b16d0ad15cd6f996a36905c9 Mon Sep 17 00:00:00 2001 From: Luke Curley Date: Tue, 29 Sep 2026 16:54:13 -0700 Subject: [PATCH 4/5] quest(archive): note who republishes the catalog behind the root claim Co-Authored-By: Claude Opus 5.5 --- quest/m1/archive/dvr.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/quest/m1/archive/dvr.md b/quest/m1/archive/dvr.md index 373feb14f6..c3bccaef8b 100644 --- a/quest/m1/archive/dvr.md +++ b/quest/m1/archive/dvr.md @@ -35,7 +35,10 @@ path through the root claim, and a live announcement shadows it. So when live ends, `moq-hls` resolves the same name and falls through to the recording: playlists keep serving for rewind and for players finishing the last segments. The fall-through needs the recording to publish its catalog live, -since `moq-hls` subscribes to it rather than FETCHing it. `moq-hls` gains +since `moq-hls` subscribes to it rather than FETCHing it. Open: [Replay +catalog](/quest/m1/archive/replay-catalog.md) keeps that republishing in +`moq-cli`, so decide whether the archive service behind the root claim is a +`moq-cli` owner or the logic moves into `moq-archive`. `moq-hls` gains no linger (the `hls-linger` quest was dropped, because an unannounced broadcast can't be FETCHed and a linger would only serve the cache). Test the handover: a live HLS session keeps its playlist URIs and media sequence From 4aa7062bd9f71efc4a3ae93c163b5232fded5bed Mon Sep 17 00:00:00 2001 From: Luke Curley Date: Tue, 29 Sep 2026 19:24:15 -0700 Subject: [PATCH 5/5] quest(archive): DVR rewinds through the durable live timeline; moq-archive republishes the catalog Co-Authored-By: Claude Opus 5.5 --- quest/m1/archive/dvr.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/quest/m1/archive/dvr.md b/quest/m1/archive/dvr.md index c3bccaef8b..7d498d84ba 100644 --- a/quest/m1/archive/dvr.md +++ b/quest/m1/archive/dvr.md @@ -35,10 +35,15 @@ path through the root claim, and a live announcement shadows it. So when live ends, `moq-hls` resolves the same name and falls through to the recording: playlists keep serving for rewind and for players finishing the last segments. The fall-through needs the recording to publish its catalog live, -since `moq-hls` subscribes to it rather than FETCHing it. Open: [Replay -catalog](/quest/m1/archive/replay-catalog.md) keeps that republishing in -`moq-cli`, so decide whether the archive service behind the root claim is a -`moq-cli` owner or the logic moves into `moq-archive`. `moq-hls` gains +since `moq-hls` subscribes to it rather than FETCHing it. Decided (09-29): +that republishing moves into `moq-archive`, so any host of the archive +behind the root claim does it, not only `moq-cli`; update [Replay +catalog](/quest/m1/archive/replay-catalog.md) to match. + +During live, rewind needs no handover: a recorded broadcast's live timeline +is durable, and every group it lists is promised available, so a seek past +the live window FETCHes old groups through the normal miss chain down to the +archive. `moq-hls` needs no special path. `moq-hls` gains no linger (the `hls-linger` quest was dropped, because an unannounced broadcast can't be FETCHed and a linger would only serve the cache). Test the handover: a live HLS session keeps its playlist URIs and media sequence