id(web): a hosted world can't be viewed without an interactive guest join — add a host view

From the 2026-10-29 screenshot walkthrough of id serve --web:

A hosted world cannot actually be viewed from the web UI without interactive choreography. The /world page renders a pre-join lobby shell ("Not connected"): viewing anything requires pasting a guest capability into the join form interactively, and the Records panel reads {} unless a world program (Roc/Wasm module) has been installed into the world and a guest session has joined and written records. There is no host-side view of a world this node is already serving.

Gaps to close:

A node that hosts a world (serve --world, optionally --world-module) should be able to display that world's live view and records in its own web UI without minting and pasting a guest capability by hand — the host is already trusted locally.
Installing a world program into a world should have a discoverable path (CLI at minimum, documented; web UI ideally), so "the world is empty" is a state a user can act on rather than a dead end.

Design questions to answer in triage:

What is the intended viewing model for a hosted world — is the guest-join flow meant to be the only door, with the host view a convenience, or should a hosted world render server-side by default?
What does the world program's output surface look like when rendered for the host (same program view as guests see, plus host-only panels)?

Related: #2057 (world-VM Wasm portability audit) touches the runtime, not this serving/viewing gap. Walkthrough notes: ~/workspace/id-walkthrough/NOTES.md (screenshot 07-world.png shows the pre-join shell).

CODE-1041

🤖 Agent note · picked up

Agent: repo worker (repo-worker-code, OpenChamber scheduled lane)
Session / ID: queue task 3154
Found via: atomic claim from repo-health-code-pilot
Task: Triage host/owner viewing of a running world and discoverable program installation for id(web): a hosted world can't be viewed without an interactive guest join — add a host view #2144.
Revalidation: id(web): a hosted world can't be viewed without an interactive guest join — add a host view #2144 is open; no matching PR found. Related design id(serve): design — how does a program appear as a website? (program-only ports, mixed ports, path mounts) #2146 is open and defines the program-as-website model; checking the current implementation and design scope before routing.
Next: establish host-vs-guest viewing model, scope both follow-ups, and route them without implementing them in this triage.

Triage verdict (verified against current main `e6577a96d`)

Viewing model: keep capability-gated guest join as the external guest path, and add an explicit authenticated host/owner view as a convenience for the operator. Do not make /world visitors hosts by default or mint/use a guest capability to render the host's own world. Start with a read-only host view of authoritative program output and records; the host should not appear as a guest participant.

Evidence: web/src/world.ts:288-314,606 only connects with a stored/pasted guest capability and sends a join frame; src/world_session/mod.rs:1058-1067 validates that join through the guest capability.

Program installation: the requested path already exists: id world install is a CLI subcommand (src/cli.rs:1434-1454), documented in examples/roc-counter/README.md:33-43, and the web UI has Wasm/Roc install controls (src/web/templates.rs:806-823). The web controls are tucked under “Host: create a guest invite,” so the follow-up will give them a distinct install/update section and an actionable no-program state rather than create another install mechanism.

Scoped implementation follow-up: #3378. It keeps listener/bindings (#2145), program-as-website routing (#2146), and dynamic publish (#2147) out of scope.

🤖 Agent note · triaged — host/guest model answered and follow-up scoped

Agent: repo worker (repo-worker-code, OpenChamber scheduled lane)
Session / ID: queue task 3154
Disposition: Host view is explicit and authenticated; guest join remains capability-gated. Existing CLI/web install paths are verified; improve their discoverability within id(web): explicit host view and actionable program-install state #3378.
Follow-up: id(web): explicit host view and actionable program-install state #3378

🤖 Agent note · handed off

Agent: repo worker (repo-worker-code, OpenChamber scheduled lane)
Session / ID: queue task 3154 → follow-up issue id(web): explicit host view and actionable program-install state #3378 / task 5190
Handoff: Host-view and install-discoverability scope is recorded in id(web): explicit host view and actionable program-install state #3378; the packet preserves guest capability checks and excludes the separate serving/bindings design work.

🤖 Agent note · done

Agent: repo worker (repo-worker-code, OpenChamber scheduled lane)
Session / ID: queue task 3154
Outcome: Triage complete. id(web): a hosted world can't be viewed without an interactive guest join — add a host view #2144 remains open; implementation follow-up id(web): explicit host view and actionable program-install state #3378 is queued as task 5190.
Verification: host join restriction and existing CLI/web install paths verified against current main; parent no longer has in-flight labels.

agent-note:v1
state: triaged → closed (superseded by its own implementation issue)
Agent: queue worker (repo-worker-code), OpenChamber scheduled lane 02cafe76
Found via: queue claim (task 7847, triage)

The 2026-11-01 triage of this issue answered its design questions and handed the implementation to #3378 (id(web): explicit host view and actionable program-install state). That follow-up is live and still open, so this origin issue no longer needs to be the tracker.

Fresh evidence (2026-11-03):

Host view landed: PR feat(id): authenticated read-only world host view (#3378) #4104 feat(id): authenticated read-only world host view (#3378) MERGED 2026-11-02T15:41:11Z, merge commit 0dfe5f19 (pkgs/id/src/world_ws.rs, web/src/world.ts, rejoin tests, templates/actor/handle).
Remaining install-discoverability work is scoped in id(web): explicit host view and actionable program-install state #3378, which is OPEN (updated 2026-11-02T15:47Z) — implementation continues there, not here.
No competing PR or open task names this issue; nothing here is lost by closing it.

Closing as superseded by #3378. Reopen only if the remaining install path needs the broader design discussion from this body.

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 40 (priority/normal). 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

Navigation Menu

Repository navigation

id(web): a hosted world can't be viewed without an interactive guest join — add a host view #2144

Triage verdict (verified against current main `e6577a96d`)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

id(web): a hosted world can't be viewed without an interactive guest join — add a host view #2144

Description

Activity

developing-today commented on Oct 29, 2026

dezren39 commented on Nov 1, 2026

dezren39 commented on Nov 1, 2026

Triage verdict (verified against current main e6577a96d)

dezren39 commented on Nov 1, 2026

dezren39 commented on Nov 1, 2026

dezren39 commented on Nov 3, 2026

developing-today commented on Nov 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Triage verdict (verified against current main `e6577a96d`)