Repository navigation
id(phase-14): Discovery, registry & federation — core topic (research + design) #6277
Description
Discovery, registry & federation — Phase 14 core topic (research + design)
Filed from the next-horizons discussion #1240, decided by Drew on 2026-11-05: all themes are planned. This issue is the core topic for Discovery, registry & federation. Its job is research and design — broaden the idea beyond what is already understood, set up multiple next steps, and produce implementation plans. No implementation starts here; the output is design documents and implementation issues.
Drew's principles for everything in Phase 14 (from #1240, 2026-11-05)
- Local-first is always the goal, AND a hosted version is intended: central coordination supporting a large graph of broadly accessible objects.
- Anything built must be completely usable by others hosting a small or large server themselves. P2P-hosted worlds and data behave the same as a large hosted public server; differences live in backend scale elements and access controls.
- Users connect to each other and transfer/interact directly wherever possible, so hosted resources are an offloadable backstop, not a requirement. The app must not technically need us to function. Collaborative / shared / federated / local-first / p2p.
- Our hosted instance is essentially public; other operators open theirs only as much as they want. Publishing paths: share to a big server, publish on pkarr, or self-host. All comms through iroh on the backend; first-class clients.
The idea, broadened
Worlds are islands: you join what you already know. Discovery asks how a world becomes findable without becoming exposed. Broaden beyond a directory page: signed world announcements, who vouches for a listing, visibility scopes (private, unlisted, registry-listed, public), pkarr as a serverless publishing path, registries anyone can run and mirror, and privacy — a listing must not leak member IPs, which is where relay/proxy behavior comes in. The world-directory feed (#812) is the seed, not the design.
Research questions (first pass)
- Announcement format: what a world publishes (name, description, host endpoint, public key, capacity, tags) and its signature/provenance (F12.17)
- pkarr publishing for worlds and programs: update cadence, key custody, what a pkarr record can and cannot carry
- Registry trust model: curated list, operator-run registries, mirroring and disagreement between registries
- Privacy: relay/proxy options through iroh so joining a public world does not broadcast a home IP
Dependencies and existing pieces
Seed: world directory feed #812. Builds on F12.14 portals (#1068), F12.17 trust/provenance (#1069), Phase 10 roles. First Phase 14 implementation theme (with hosted worlds).
Next steps — the version ladder
- v1 — first-iteration design — its own issue, filed in the same pass and linked in the first comment below
- v2 — outline: the public registry — its own issue, filed in the same pass and linked in the first comment below
- v3 — outline: federation — its own issue, filed in the same pass and linked in the first comment below
- v4 — outline: open discovery at scale — its own issue, filed in the same pass and linked in the first comment below
Plus a standing rule for this topic: anything the research surfaces that doesn't fit v1–v4 gets its own issue (Drew's rule: every feature, concept, or idea gets an issue), and future investigations are listed as comments here rather than lost.
Sequencing
Design queue order: F12.4 provider registry (#1061) and F12.10 scheduling/quotas (#1067) designs land first; Phase 14 v1 designs then run hosted worlds → discovery → agents spike → the rest. Implementation follows Phase 13. The drop rule applies throughout: anything that proves blocked, wrong, or superseded gets parked or closed with a note — never a silent stall.
Acceptance criteria
- A research + design output exists for Discovery, registry & federation: design documents broadening the topic beyond the current understanding, per the Phase 14 principles in the body (local-first plus hosted coordination, self-hostable at any scale, publish via share/pkarr/self-host, iroh transport).
- Multiple concrete next steps are produced as implementation plans / implementation issues filed from this topic.
- No implementation starts under this issue itself (per its own charter).
Activity
developing-today commentedon Nov 5, 2026
CODE-1843
dezren39 commentedon Nov 5, 2026
Version ladder for this topic (filed in the same pass, 2026-11-05):
Phase 14 plan of record: #6312. Discussion of record: #1240.
dezren39 commentedon Nov 6, 2026
🤖 Agent note · picked up
dezren39 commentedon Nov 6, 2026
🤖 Agent note · done
Triage findings (task 11049)
Verdict: valid Phase 14 core topic, ladder complete and linked, correctly gated — no new work to file. The topic's first actionable step is v1 (issue #6287), which waits on the design gates named in this issue's own sequencing.
Evidence, verified fresh 2026-11-06 ~12:33–12:39 UTC:
priority/normal,effort/l, no hard-stop labels (held,user/owned,do-not-merge,do-not-auto-editall absent). It had no intake review yet — only the Kaneo link and the ladder comment from filing.status/needs-triage, queued) → issue id(phase-14): Discovery, registry & federation — v2 — outline: the public registry #6288 (v2 public registry outline,status/needs-triage, queued) → issue id(phase-14): Discovery, registry & federation — v3 — outline: federation #6289 (v3 federation outline, triaged today as task 11061: blocked-by issue id(phase-14): Discovery, registry & federation — v2 — outline: the public registry #6288) → issue id(phase-14): Discovery, registry & federation — v4 — outline: open discovery at scale #6290 (v4 open discovery at scale,queue/parked+work/assigned— held by another lane). The ladder matches the "Next steps" in this issue's body exactly; nothing is missing and nothing needs duplicating.status/needs-triage) precedes issue id(phase-14): Discovery, registry & federation — v1 — first-iteration design #6287 as well.Routing: triage complete. Issue #6277 stays open as the topic umbrella; it closes when its ladder completes or the drop rule is invoked on it. No follow-up task is enqueued — the ladder issues already carry their own queued tasks, and v1 (issue #6287) is next once issue #1061 and issue #1067 land.
dezren39 commentedon Nov 6, 2026
Intake review
🤖 Fleet monitor intake (repo-fleet-monitor), 2026-11-06.