Repository navigation
id: design: rendezvous & discovery for UDP-denied clients (from #5671) #5793
Description
Summary
Follow-on design ticket from #5671 — its decomposition sketch names this as a separate design, and the parent's acceptance requires these tickets to be filed and linked. Filed in the 2026-11-04 gap pass (WS-F) so the design work exists and can be prioritised on its own merits; implementation timing is a separate decision, possibly months out.
What this design must settle
Signed transport advertisements and substrate selection: how a client that cannot use UDP finds and authenticates the rendezvous point it can use.
Context from the parent
The parent design fixes how ID clients and servers stay reachable when UDP is denied — fallback order, broker shapes, trust model, and the E2E boundary. The parent issue carries the surrounding decisions this ticket must not re-decide; where this ticket's answer would change a parent decision, record that explicitly rather than silently forking it.
Decision record expected
Close this design with a recorded decision (on this issue or in a doc/ record linked from it): the chosen shape, the alternatives rejected and why, and the invariants implementation must hold. If the design splits further, file the splits and link them here rather than growing this issue.
Relations
Parent: #5671. Programme: epic #2056. Filed by WS-F (2026-11-04 ID design gap & expansion pass).
Activity
developing-today commentedon Nov 5, 2026
CODE-1476
developing-today commentedon Nov 5, 2026
Triage — task 10196 (lane code-s)
Verdict: live follow-on design issue, correctly filed as a separate ticket from parent #5671; explicitly deferred timing. Stays OPEN.
Evidence checked fresh 2026-11-05 (via the developing.today app token — the user token is currently primary-rate-limited; see infra note on the task):
task/triage,queue/queued,app/id— no status/priority labels; the claim/terminal label sync in this triage normalises that.Ordering recorded: #5793 is strictly downstream of #5671 — its design space is bounded by the parent's fallback/trust decisions, so it should be worked after (or jointly with) the parent's v1 decisions. The filing itself notes implementation timing is a separate decision, possibly months out; nothing here is blocked on Drew today.
No follow-up task enqueued — this issue is itself the design work item, already in the queue system. Task 10196 completes as
triaged.