moqt-16 vs Cloudflare relays: SUBSCRIBE response fails to decode ('invalid value') — token-in-path + --broadcast otherwise compose end-to-end

[Glenn444]

Summary

Cloudflare's new provisioned relays (dashboard/API, 2026-07-31) authenticate with the JWT in the URL path — https://draft-16.cloudflare.mediaoverquic.com/<token> — and do not read ?jwt=. moq-cli derives the broadcast path from the connect URL path and carries tokens in ?jwt=. Both sides want the same bytes of the URL, so no form composes:

Connect URL	Result
https://draft-16…/<token>	connects, connected version=moq-transport-16, then publish_namespace broadcast= (empty) → session terminated, reconnect loop
https://draft-16…/name?jwt=<token>	webtransport error: closed: code=3 reason=scope resolution failed (relay never sees the token)
https://draft-16…/<token>/name	connects, but the whole path is treated as the request path — still publish_namespace broadcast= (empty) → terminated

On the draft-14 endpoint the rejection is explicit: PublishNamespaceError { request_id: RequestId(0), error_code: 0, reason_phrase: "done" }.

The subscribe side connects and negotiates cleanly in forms 1 and 3 (moq-transport-16 / moq-transport-14), so this is specifically the publisher's namespace naming. Net effect: the README's "moq-lite works with any moq-transport CDN (ex. Cloudflare)" is currently unreachable for publishing with moq import against Cloudflare's tokened relays.

Environment

• moq-cli v0.9.10 (cargo install moq-cli, macOS arm64), 2026-08-13
• Cloudflare provisioned relay (dashboard-created), draft-14 and draft-16 endpoints, publish+subscribe starter token
• Publisher: ffmpeg … -f mpegts - | moq --client-connect <URL> import ts

Relationship to #2730

This is the next layer of the same onion: after #2730 the IETF path announces unasked, but the announce carries an empty namespace whenever the connect path is consumed by auth — which on Cloudflare is always.

Possible directions

• A --broadcast <path> option (or MOQ_BROADCAST env) on import/export, independent of the connect path — mirrors how moq-net's library API can already name broadcasts explicitly.
• Or a URL convention that survives token-in-path, e.g. fragment (https://relay/<token>#name).
• Or, when ?jwt= is present and the scheme is a known token-in-path relay, hoist the token into the dial path and use the remaining path as the broadcast name.

Happy to send a PR for whichever shape maintainers prefer.

(Written by Claude Fable 5)

[coderabbitai]

🔗 Related PRs

#578 - feat(moq-native): support raw QUIC sessions with moql:// URLs [closed]
#1985 - moq-cli: unified endpoint grammar (binary renamed to moq) [merged]
#2572 - fix(native): send the request path and query in the SETUP on every URI-less transport [merged]
#2738 - feat(bindings): expose incoming request path and query [merged]
#2760 - fix(net): accept a self-contained Track Namespace over moq-transport [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[Glenn444]

Correction + much narrower root cause after further testing. The original report missed --broadcast (my error — it does exactly what the issue asked for), so the naming half of this issue is wrong. With --client-connect "https://draft-16.cloudflare.mediaoverquic.com/<token>" --broadcast name.hang, nearly everything composes against Cloudflare's provisioned relays:

• token-in-path auth: ✅ (connected version=moq-transport-16 both sides)
• publisher announce with the named namespace: ✅ (accepted, no more empty PUBLISH_NAMESPACE)
• subscriber discovery: ✅ (subscribe_namespace ok → announce broadcast=name.hang arrives)
• subscribe routed through the relay to the publisher: ✅ (publisher logs subscribe started id=1 broadcast=name.hang track=catalog.json)
• the subscribe response from Cloudflare fails to decode: ❌

Subscriber trace (moq-cli v0.9.10, draft-16 endpoint):

TRACE moq_net::ietf::message: encoding self=SubscribeNamespaceLegacy { request_id: RequestId(0), namespace: Path(""), subscribe_options: 1 }
DEBUG moq_net::ietf::subscriber: subscribe_namespace ok prefix=
DEBUG moq_net::ietf::subscriber: namespace path=demo.hang hops=1 cost=1
DEBUG moq_net::ietf::subscriber: announce broadcast=demo.hang
TRACE moq_net::ietf::message: encoding self=Subscribe { request_id: RequestId(2), track_namespace: Path("demo.hang"), track_name: "catalog.json", subscriber_priority: 155, group_order: Descending, filter_type: LargestObject }
 INFO moq_net::ietf::subscriber: subscribe started broadcast=demo.hang track=catalog.json
DEBUG moq_net::ietf::subscriber: subscribe response error err=invalid value
DEBUG moq_net::model::origin_impl: every source refused track; aborting name=catalog.json err=invalid value
Error: json: invalid value

So the remaining bug is a single message-level decode mismatch on the draft-16 SUBSCRIBE response (SUBSCRIBE_OK or its error variant) as Cloudflare encodes it. Note the client encodes SubscribeNamespaceLegacy — possibly a draft-16 revision skew between moq-net's moqt-16 and Cloudflare's deployment.

Secondary observation: on the draft-14 endpoint the same named-broadcast pair connects cleanly but the subscribe never routes to the publisher at all (no subscribe started, zero bytes) — may be expected if draft-14 discovery semantics differ, mentioned for completeness.

Happy to run any diagnostic build against our provisioned relay — it reproduces in seconds.

(Written by Claude Fable 5)