Skip to content

docs(quest): settle 0.0.x package APIs before release - #3801

Open
kixelated wants to merge 2 commits into
mainfrom
codex/api-release-audit
Open

kixelated wants to merge 2 commits into
mainfrom
codex/api-release-audit

Conversation

@kixelated

@kixelated kixelated commented Sep 20, 2026

Copy link
Copy Markdown
Collaborator

Problem

The imminent release would expose inconsistent archive range and listing contracts, E2EE entry points that bypass nonce and epoch ownership, and socket/io_uring construction that permits mismatched owners. Existing quests deferred these API corrections until later work or proposed cosmetic renames that do not make invalid ownership combinations unrepresentable.

The shared m0 questline now contains independent Pronto GPU work, and PR #3803 will add the media API stabilization track before this PR lands. The release gate must add these four-package audits without replacing either track or making all of m0 a release prerequisite.

Approach

Add six m0 release API quests for E2EE path/profile alignment, E2EE ownership, completed socket-group formation, io_uring worker/shard identity, archive inclusive ranges, and recording-scoped archive listing. Keep the existing Pronto quests. After #3803 lands, rebase this PR onto its m0: immediate media graph and use the combined m0: immediate priorities scope for all three independent tracks.

Move existing plans rather than duplicate them, retire the conflicting cosmetic naming quest, and update backlog dependencies. The release quest depends on these six API quests individually, not the entire m0 questline, so Pronto and the media stabilization plan are not accidental release blockers.

Public API impact by package

This PR is planning-only and changes no executable API today. The quests plan these 0.0.1 Rust changes:

  • moq-archive: replace reversed integer-pair group bounds with validated finite RangeInclusive<u64> inputs and outputs; unify streaming and paginated listing under archive-owned store::list::Query and Entry types with recording-relative prefixes, offsets, opaque continuation tokens, and only supported pagination controls; make duplicate path helpers such as check_id crate-private. Keep the generic Store and its object_store escape hatch.
  • moq-e2ee: replace Credential::new(profile, context, generation, kid, secret) with config-based construction around an application-owned 32-byte secret; remove hidden secret generation and raw crypto/HKDF helpers; add epoch-free credential path derivation plus epoch-scoped Generation, Epoch, Name, and track producer/consumer handles; replace process-global publication claims with generation-owned per-track claims; keep sequence allocation, nonce reuse protection, receive windows, and public payload limits inside the supported handles. Catalog policy and producer retransmission internals leave the public surface.
  • moq-sock: make shard::Group yield no usable socket until every declared member has bound and steering is attached; return claims during formation; retain every member socket for the served group's lifetime so an individual early close cannot invalidate steering indices.
  • moq-uring: derive worker ownership and reuseport steering identity from the owned socket or connection; remove independently supplied handle/shard combinations from endpoint and WebTransport construction; preserve unsharded sockets, weak worker lifetimes, root Config, and TxBuf.
  • moq-tokio 0.19.11: preserve its public worker signatures and bind re-export while adapting internal plumbing to the moq-sock ownership model. No rename or compatibility shim is planned.

Wire and storage impact

  • MoQ protocol: no framing, message, authentication, or version-negotiation change.
  • Archive storage: no persisted path or byte-format change. Largest-first filename serialization remains private while public ranges become standard inclusive Rust ranges.
  • E2EE application interoperability: changes if implementation proceeds. The currently implemented moq-e2ee-01 numeric generation and HKDF labels are replaced by the draft's epoch-based moq-e2ee-00 derivation. Opaque broadcast paths, derived names, keys, and ciphertext compatibility change. Publication status must be checked before implementation; any actually published profile must remain compatible under the repository's wire rules.
  • Socket and io_uring traffic: no on-wire format change; only construction, ownership, and lifecycle contracts change.

Alternatives

  • Keep the current APIs and strengthen documentation. That leaves invalid ranges and mismatched ownership representable.
  • Invent a custom archive bounds type. Standard RangeInclusive<u64> matches existing Rust and moq-net range conventions.
  • Rename moq-tokio::bind, io_uring Config, or TxBuf. Their names do not cause the ownership bugs, and changing published moq-tokio exports would expand the break unnecessarily.
  • Make the whole m0 questline a release dependency. Explicitly requiring only these six quests prevents unrelated Pronto and media work from blocking the release.

Follow-ups

  • Merge PR docs(quest): plan media API stabilization before 0.1 #3803 first, then rebase this branch onto its combined m0 graph and preserve every track under m0: immediate priorities.
  • Implement the six API quests and report the E2EE profile interoperability change in release notes.
  • Keep E2EE receive-failure accounting, io_uring handshake cancellation, archive/replay proof, browser E2EE, TypeScript parity, and transport performance in their existing follow-up quests.

Validation: nix develop --command just check passed after rebasing and reconciling the current m0 graph, including all 397 quest documents and repository Markdown checks. Scoped nix develop --command just test passed with no runtime suites selected for this planning-only diff.

(written by GPT-5)

kixelated and others added 2 commits September 20, 2026 06:32
Co-Authored-By: Codex <noreply@openai.com>
Co-Authored-By: Codex <noreply@openai.com>
@kixelated kixelated changed the title quest: record package API audit follow-ups quest: settle 0.0.x package APIs before release Sep 20, 2026
@kixelated
kixelated marked this pull request as ready for review September 20, 2026 17:46
@coderabbitai

coderabbitai Bot commented Sep 20, 2026

Copy link
Copy Markdown
Contributor

Warning

Review limit reached

Next included review available in 58 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used all 4 included reviews currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: df9ef51c-f3a2-4f57-93e9-996666620eed

📥 Commits

Reviewing files that changed from the base of the PR and between b2ef453 and 9667012.

📒 Files selected for processing (20)
  • quest/README.md
  • quest/m0/README.md
  • quest/m0/archive-listing.md
  • quest/m0/archive-ranges.md
  • quest/m0/e2ee-api.md
  • quest/m0/e2ee-path.md
  • quest/m0/sock-group.md
  • quest/m0/uring-identity.md
  • quest/m1/README.md
  • quest/m1/release.md
  • quest/m2/2964-quic-workers-dropping-one-split-server-resizes-the.md
  • quest/m2/README.md
  • quest/m2/api-unreleased-crate-names.md
  • quest/m2/archive/proof.md
  • quest/m2/e2ee/README.md
  • quest/m2/e2ee/receiver-failure.md
  • quest/m2/e2ee/rust.md
  • quest/m2/e2ee/typescript.md
  • quest/m2/one-port/README.md
  • quest/m2/uring-handshake-cancel.md

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@kixelated kixelated changed the title quest: settle 0.0.x package APIs before release docs(quest): settle 0.0.x package APIs before release Sep 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant