Skip to content

id: Phase 13 F13.8 multi-server, multi-client topology; client-only mode always supported #790

New issue
New issue
Closed
Closed
id: Phase 13 F13.8 multi-server, multi-client topology; client-only mode always supported#790
Assignees
dezren39
Labels
app/idPackage/app: id (pkgs/ or apps/ in this repo)effort/lLarge: multi-day or open-ended; expect staged check-insenhancementNew feature or requestkind/featureNew feature or capability requestmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedmode/onlineFully doable remotely: design, config, code, cloudpriority/lowNice to have; do when convenientqueue/queuedHas a queued task in the Supabase agent queuesource/humanFiled directly by a humanstatus/needs-triageNot yet triaged; needs a first looktask/triageQueue packet kind: verify, reproduce, and route this item

Description

@dezren39
dezren39
opened on Oct 24, 2026

What and why

Clients connect to several worlds and servers and to other clients at once, and id is often client and server simultaneously. A client-only mode must always exist (cheap web load, SSH-only clients); SSH servers in id stay rare and opt-in.

Source

Current status

Partial. id world join/stats/logs/record/replay already act as remote iroh clients (pkgs/id/src/world_net.rs WorldClient), and one serve process hosts many worlds (pkgs/id/src/world_hub.rs). Simultaneous multi-world client sessions and a documented client-only mode were not found.

Acceptance criteria

  • One client holds live sessions to two worlds at once
  • The client-only flag boundary is documented and tested to add no authority (a client never silently becomes a server)
  • A world's journal is unchanged by a second client joining it

Size

L

Prerequisites

Activity

  1. dezren39
    added
    enhancementNew feature or request
    on Oct 24, 2026
  2. github-actions
    assigned
    dezren39
    on Oct 24, 2026

  3. developing-today commented on Oct 24, 2026

    @developing-today
    developing-todayBot
    on Oct 24, 2026 – with developing.today
    Contributor

    CODE-118

  4. dezren39
    added a commit that references this issue on Oct 24, 2026

    docs(id): Phase 13 plan — client shells and capability providers

    d21f364
  5. dezren39
    added
    kind/featureNew feature or capability request
    status/needs-triageNot yet triaged; needs a first look
    priority/lowNice to have; do when convenient
    effort/lLarge: multi-day or open-ended; expect staged check-ins
    app/idPackage/app: id (pkgs/ or apps/ in this repo)
    meta/enrichedIntake review done: acceptance criteria, links, and normalized labels added
    source/humanFiled directly by a human
    on Oct 26, 2026

  6. dezren39 commented on Oct 26, 2026

    @dezren39
    dezren39
    on Oct 26, 2026
    MemberAuthor

    Intake review

    Fleet monitor intake pass (protocol §5).

    Related: Phase 13 sibling set — #785 (F13.3), #786 (F13.4), #787 (F13.5), #788 (F13.6), #789 (F13.7), #790 (F13.8); this issue is F13.8 multi-server, multi-client topology; client-only mode. It is a forward roadmap/spec item, not a reported fixed bug; nothing in the issue or its comments indicates it has been implemented.

    Notes / risks: acceptance criteria were already present in the body; none appended. Phase-13 items are large, interdependent platform work (effort/l, priority/low as roadmap items): the set should be sequenced deliberately rather than picked up piecemeal by a worker, and earlier-phase dependencies should be confirmed before implementation starts.

    Suggested approach: keep in the Phase 13 backlog until its phase dependencies land; when scheduled, split into a design pass plus implementation slices rather than a single change.

    Labels normalized by the monitor.

  7. dezren39
    added
    work/assignedQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    and removed
    status/needs-triageNot yet triaged; needs a first look
    on Oct 28, 2026

  8. 12 remaining items

  9. dezren39 commented on Nov 1, 2026

    @dezren39
    dezren39
    on Nov 1, 2026
    MemberAuthor

    Decision-ready F13.8 design: doc/2026-11-01_design_id790.md.
    The current client can open sequential world sessions on one connection, but its existing test does not hold two worlds live concurrently.
    The server's WorldHub is per-server; multi-server routing needs a client-side coordinator with a distinct connection per endpoint.
    I recommend independent session handles and origin-session capability routing, preserving the existing one-shot CLI.
    The client-only boundary is already documented and regression-tested by #3862; no --client-only flag is needed.
    Only explicit id serve hosts a world; the SSH tunnel and mirror listener exceptions do not grant world authority.
    Journal caveat: a first/last participant-presence transition can intentionally append a players System event.
    PR: #3907

    Phased plan: (0, complete) client-only boundary in #3862; (1) standalone journal/presence characterization; (2) concurrent worlds on one endpoint; (3) extend to multiple endpoints with isolation tests.

    Question for Drew: Should “journal unchanged by a second client joining” include an intentional presence System event for a newly present participant?

    • A — strict neutrality: no join may add any journal entry, including presence events; this requires changing/relocating current durable presence behavior.
    • B — preserve presence semantics (recommended): test join neutrality when no presence transition occurs, and separately pin the existing event when players is granted and subscribed. This preserves current replay behavior.
  10. dezren39
    added
    mode/onlineFully doable remotely: design, config, code, cloud
    on Nov 1, 2026

  11. dezren39 commented on Nov 2, 2026

    @dezren39
    dezren39
    on Nov 2, 2026
    MemberAuthor

    🤖 Agent note · check-in

    • Agent: fleet monitor (repo-fleet-monitor)
    • Session / ID: repo-fleet-monitor run 2026-11-02 04:12 CST
    • Found via: monitor reconciliation (in-progress tracker, Duty 3)
    • Task: Check-in on this item. It carries queue/claimed + work/assigned + status/in-progress (effort/l; latest holder note 2026-10-28T20:04Z, last issue activity 2026-11-01T21:17Z) but there is NO live queue task for it in repo-health-code-pilot — the claim it mirrors no longer exists. It is now past ~1.5× its 72h deadline with no checkpoint note from the holder. Holder: please checkpoint, park, or hand off — or, if this item is being worked outside the queue, post a fresh agent note saying so and correct the labels; if it is not being worked, say so and the monitor will requeue it next run.
    • Expectation: a checkpoint / park / handoff note from the holder, or a monitor requeue next run.
  12. dezren39
    added a commit that references this issue on Nov 2, 2026

    Merge pull request #3907 from developing-today/design/id-790

    112baa3
  13. dezren39
    added
    user/reviewNeeds a user-look: Muse reviews first and handles what it can
    and removed
    status/in-progressQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    on Nov 3, 2026

  14. dezren39 commented on Nov 3, 2026

    @dezren39
    dezren39
    on Nov 3, 2026
    MemberAuthor

    🤖 Agent note · done

    Verdict: implemented and merged — closing as complete

    F13.8 landed after this issue's last triage. Verified against origin/main (1e3763faf) on 2026-11-03:

    Acceptance criteria → evidence at main

    Criterion Evidence
    One client holds live sessions to two worlds at once coordinator_holds_two_worlds_on_one_endpoint_concurrently (two live sessions, no cross-talk, hub.open_count()==2) and coordinator_spans_distinct_server_endpoints (two endpoints, two roots, no cross-server bleed)
    Client-only flag boundary documented and tested to add no authority #3862: CLI/README documentation + parser regression test proving client ops never dispatch serve
    A world's journal is unchanged by a second client joining second_join_through_coordinator_does_not_mutate_the_journal — committed seq and records generation identical across a second join

    Notes

    • §7 of the design (does "journal unchanged" include an intentional players presence System event?) was implemented as the recommended Option B: joining itself appends nothing; the pre-existing first/last presence event is preserved and tested separately. If strict neutrality (Option A) is ever wanted, that is a separate scope expansion — reopen or file a follow-up; it is not a defect in this implementation.
    • id(world): input carries no session identity (prerequisite for F13.7 routing and F13.8) #840 (WorldCommand::Input carries no session identity) remains open as an independent prerequisite for actor-side attribution; F13.8's client-side routing criteria do not depend on it, so it is not a blocker here.

    Closing as complete. No follow-up queue task is needed.

  15. dezren39
    closed this as completedon Nov 3, 2026
  16. dezren39
    added
    queue/queuedHas a queued task in the Supabase agent queue
    status/needs-triageNot yet triaged; needs a first look
    task/triageQueue packet kind: verify, reproduce, and route this item
    and removed
    user/reviewNeeds a user-look: Muse reviews first and handles what it can
    on Nov 3, 2026

  17. dezren39 commented on Nov 3, 2026

    @dezren39
    dezren39
    on Nov 3, 2026
    MemberAuthor

    agent-note:v1
    state: triaged (coverage pass)
    Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 30 (priority/low). If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
    Found via: coverage pass 2026-11-03

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

app/idPackage/app: id (pkgs/ or apps/ in this repo)effort/lLarge: multi-day or open-ended; expect staged check-insenhancementNew feature or requestkind/featureNew feature or capability requestmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedmode/onlineFully doable remotely: design, config, code, cloudpriority/lowNice to have; do when convenientqueue/queuedHas a queued task in the Supabase agent queuesource/humanFiled directly by a humanstatus/needs-triageNot yet triaged; needs a first looktask/triageQueue packet kind: verify, reproduce, and route this item

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions