Repository navigation
id: next horizons — what comes after Phase 13 (discussion with Drew) #1240
Description
id: next horizons — investigation + discussion with Drew (planning, not a work order)
Drew (2026-10-26): "We need to start preparing for further phases and next steps. Ensure there are designs either built or on the roadmap to be made... Investigate and find things we could do, and then another issue to discuss with me, and we'll come up with a plan." This is that discussion issue. Nothing here starts until we agree a plan in the comments.
Where the design coverage stands today (checked 2026-10-26)
- Phases 0–11: designed and built; validation audits queued (id: validation — Phases 0–8 + platform completion acceptance audit #1075–id: validation — delivered Phase 11 items (claimed-done audit) #1078) to prove it.
- Phase 12: epic id: Phase 12 designs to run through the research workflow #534 runs each F-item through the research/design workflow before implementation; item issues exist for all of F12.1–F12.18. The two that most need design depth first: F12.4 provider registry (id: F12.4 provider registry — capabilities as manifest + provider components #1061 — the registry shape constrains everything) and F12.10 scheduling/quotas (id: F12.10 fair scheduling and per-account quotas #1067 — policy, not just code).
- Phase 13: client shells + capability providers; F13.1/F13.2 done, F13.3–F13.8 filed (id: Phase 13 F13.3 SSH-over-iroh reachability (and iroh-over-SSH fallback) #785–id: Phase 13 F13.8 multi-server, multi-client topology; client-only mode always supported #790). No design docs yet for F13.6 native shells (id: Phase 13 F13.6 native client shells on the shell contract #788) beyond the shell contract.
- Beyond Phase 13: nothing is designed or roadmapped. That's the gap this issue is for.
Candidate directions worth a Phase 14+ (from the current architecture and open threads)
- Hosted worlds / always-on hosting — worlds that live on a host (e.g. the basement cluster) instead of a participant's machine: persistence, backups/snapshot export, world DR, uptime. Builds on F12.11 multi-node and F12.13 replication.
- Discovery & federation — the world directory (id phase-10: the world directory feed was not built — id world list --json is admin-only, has no presence counts, and 'open' means loaded-in-memory #812 feed is the seed), signed catalogs, cross-node invites, popularity/quality signals. Global chat exists; worlds are still islands.
- Program ecosystem — share/fork Roc programs and template worlds, a gallery, one-click install into a world; provenance from F12.17 makes this safe to open up.
- More shells — mobile/PWA shell with offline mode, native apps (id: idea — native GUI client #1072), the ratatui TUI (id: idea — native TUI client (ratatui) on the shell contract #1071), and hardware shells — the ESP32 wing line of work already running in the fleet could become a physical id terminal/input device.
- Agents in worlds — agent participants as first-class programs: MCP bridge so an agent can join a world, read screens, act — id as a place agents and people share, not just people.
- Scale & performance hardening — large-world stress program (entity counts, journal growth, bandwidth budgets), snapshot/compaction policy, chaos tests across nodes.
- Creator tooling & insight — world analytics for authors, in-world search across worlds, moderation tooling for public worlds (needed before any public directory).
Also on the table
- The dashboard build-out (dashboard: full id platform coverage — auto-updated phases, validation, CI and queue panels #1239) — how much of the platform's operational picture belongs there vs in
id world doctor-style CLI surfaces.
Questions for Drew
- Which 1–2 themes feel like the real Phase 14? (My instinct: hosted worlds + discovery, because they turn id from a tool into a place — but agents-in-worlds is the most differentiating.)
- Local-first forever, or is a hosted tier an explicit goal?
- How public should discovery be at first — tailnet friends, invite-only catalogs, or open?
- Anything on your mind that isn't in the candidate list?
When we've talked it through here, the output is: chosen themes → design issues filed → roadmap "Later" section updated. Until then this stays priority/low discussion.
Acceptance criteria
- A discussion with Drew in this issue's comments produces an agreed plan: which post-Phase-13 directions (from the candidate list or new ones) become Phase 14+ design work, and in what order.
- Each agreed direction gets a design/roadmap issue (or an explicit 'not now' record) in the same pass — no agreed direction is left as comment-only text.
- Until that agreement exists, no implementation work starts from this issue (it is a planning/discussion issue, not a work order).
Metadata
Metadata
Assignees
Labels
Package/app: id (pkgs/ or apps/ in this repo)Medium: expected under 1 day of workNew feature or capability requestIntake review done: acceptance criteria, links, and normalized labels addedFully doable remotely: design, config, code, cloudNice to have; do when convenientQueue or user escalation stateHas a queued task in the Supabase agent queueFiled directly by a humanQueue or user escalation state
Activity
developing-today commentedon Oct 27, 2026
CODE-369
dezren39 commentedon Oct 27, 2026
Intake review
Related: #1235 (Path to Phase 12 — the ordered queue this discussion sits behind), epic #534 (Phase 12 design workflow), #1239 (dashboard coverage), validation audits #1075–#1078.
Notes: Drew framed this explicitly as investigation + discussion: 'Nothing here starts until we agree a plan in the comments.' Labels were already normalized by the filer (kind/feature, source/human, priority/low, effort/m); this pass added acceptance criteria,
meta/enriched, anduser/reviewso the discussion reaches the review lane.Risks: The failure mode for discussion issues is silent drift — a rich candidate list that never becomes a decision. The acceptance criteria therefore require the agreed plan and per-direction issues to exist before this can close.
Suggested approach: Muse reviews the candidate directions against current fleet state and posts a recommended Phase 14+ shortlist in the comments for Drew's decision.
dezren39 commentedon Oct 27, 2026
Resurface system is live for this issue (Drew's directive, 2026-10-26): a scheduled check (
id-horizons-resurface, every ~3 days) evaluates the triggers documented on #1295 — the Path-to-Phase-12 queue (#1235) completing, open app/id issues dropping below 25, or 7 days passing without a resurface (then at most weekly). When one fires, a status comment lands here and Drew gets a chat ping with where things stand and the questions most needing his answers. This issue stays do-not-work until Drew engages; the checker never starts work from it.2 remaining items
dezren39 commentedon Oct 28, 2026
🤖 Agent note · escalated
user/reviewlane)Worker review (verified fresh, 2026-10-28): the issue's picture is still accurate, with two updates since it was written (2026-10-26):
My read (for the discussion, not a decision): the body's instinct holds up. Hosted worlds + discovery compound — always-on worlds are what make a directory worth browsing — and both lean on F12.11/F12.13 replication work already in flight. Agents-in-worlds is the most differentiating theme and the cheapest to prototype on top of the shell contract (an agent shell is just another conformance-checked client), so it could run as a small Phase 14 spike alongside hosted-worlds design rather than instead of it.
What is genuinely Drew's (why this escalates): the acceptance criteria require a discussion with Drew producing an agreed plan — which 1–2 themes become Phase 14, whether a hosted tier is an explicit goal vs local-first forever, and how public discovery should be at first. Those are product-direction calls no worker should make. Drew: the four questions are in the issue body above; answering them here is the whole unblock. This task is blocked as
escalated-to-userand the issue is labelleduser/escalateduntil then — no implementation work starts from this issue meanwhile, per its own acceptance item 3.dezren39 commentedon Oct 28, 2026
🤖 Agent note · correction (queue worker, Lane B)
dezren39 commentedon Nov 5, 2026
Resurface check — 2026-11-04
Trigger fired: milestone (also weekly — 8 days since the last resurface on 2026-10-27).
The Path-to-Phase-12 step queue from #1235 is now complete: all 14 step issues are closed.
id world verify) #544 — id(world): F11.16 replay self-check (id world verify)Current open
app/idcount: 404 (well above the <25 running-low threshold, so that trigger did not fire — the queue is not running dry; this resurface is because the milestone completed and the weekly cadence elapsed).Questions in this issue that most need Drew's answers
This remains a do-not-work planning discussion until Drew engages here — no implementation work is being started from this issue.
dezren39 commentedon Nov 5, 2026
all these items are good and should be planned with next steps for first iteration designs and rough outline with followup issues for the v2/v3/V4 steps for each. I agree with your suggestions for first items to impl with phase 14 after you build out research for each of the listed items. local first is always the goal, but we do intend to create a hosted version which can operate as central coordination and support a large graph of objects that are broadly accessible. anything we build should be completely usable by others if they wished to host a small or large server for whatever purpose. ideally p2p hosted worlds and data behaves the same as a large hosted public server, differences mostly in backend elements to support scale and access controls broadly set to public. if we can host most of it but it's built in a way that users can fluidly connect to each other and transfer/interact directly then that will allow us to scale further. whatever can pass off for users to be able to handle directly without needing hosted resources is good, we can support the use cases that need a large central server or understanding of server admin in order to handle, and can make the app in a way where it still doesn't technically need us to function. collaborative / shared / federated /local-first / p2p. we can be the backstop. for our purposes the hosted version essentially public but in other contexts user Controlled, only open as much as they want it to be. they can share broadly to my server or publish on pkarr or host themselves, we can support a registry list, possibly some basic proxy/relay behavior to allow user ip to be less widely visible, all comms through iroh on backend and first class clients. our main endpoint totally public facing , maybe parts of the deeper backend are separate iroh/Id servers that have private tunnel with limited direct/trusted access.
dezren39 commentedon Nov 5, 2026
Decision recorded — this discussion has converted into filed plans (2026-11-05)
Drew's direction (comment above, 2026-11-05): all seven themes are planned. Phase 14's first implementation items are hosted worlds + discovery, with agents-in-worlds as the differentiating spike. Local-first always; a hosted tier is an explicit goal; everything hostable by anyone; p2p behavior identical to hosted behavior; we are the backstop, never a requirement. (Full principles are quoted in the Phase 14 epic and every core topic issue.)
The filed map
Each topic has four further issues: a v1 first-iteration design, and v2/v3/v4 outline issues, all linked from its core issue and prioritized. Design order: F12.4 (#1061) and F12.10 (#1067) designs first, then Phase 14 v1 designs — hosted worlds → discovery → agents spike → ecosystem → shells → scale → creators. Implementation follows Phase 13.
The resurface rule that guarded this issue (#1295) is satisfied by this conversion and is being retired; the roadmap's Later section gains the Phase 14 block in the same pass. This issue stays open as the discussion of record until the epic's first designs land.