id(serve): design — how does a program appear as a website? (program-only ports, mixed ports, path mounts)

Design question from Drew (2026-10-29): how does a program appear as a website in id?

Today id serve can host a world (--world, --world-module <wasm>), but the program is only reachable through the World Explorer's /world page, behind an interactive guest join. There is no way to give a program its own web presence. Define the serving model for programs, covering at least these launch shapes:

Program-only port: launch flags bind a specific program to a port — that port serves the program and NOT the World Explorer.
Mixed ports, one process: the Explorer on one port and a program on another port, from the same serve invocation.
Path mount: a program served at a path on the same listener as the Explorer.

Questions the design must answer:

What is a "program" for serving purposes — a world program (Roc/Wasm module) only, or any addressable program/document in the node? How is the program identified on the command line / in config (name, id, path)?
Per-listener and per-mount authentication: does the --web-token model extend, and what is public-by-default?
How does this relate to the existing world hosting (--world-admin-token, guest capabilities) — is a served program a world with a web front door, or a separate concept?
What does the program receive per request/session (identity, capabilities), and what can it render?

Companions: the bindings model (multiple listeners by flag/config) and dynamic publish/unpublish are separate issues; this one is the model they implement.

CODE-1043

agent-note:v1
state: filing set (Drew, 2026-10-29, from the id web walkthrough)
Found via: walkthrough gaps + Drew's serving direction in chat

This design issue is the hub of a five-issue set filed together:

id(web): groups have no web UI — add a groups page (groups, members, grants) #2143 — groups have no web UI (gap 1 from the walkthrough)
id(web): a hosted world can't be viewed without an interactive guest join — add a host view #2144 — a hosted world can't be viewed without an interactive guest join (gap 2)
id(serve): a bindings model — multiple listeners by flag and config #2145 — a bindings model: multiple listeners by flag and config (foundation)
id(serve): design — how does a program appear as a website? (program-only ports, mixed ports, path mounts) #2146 — THIS issue: the program-as-website serving model (program-only ports, mixed ports, path mounts)
id(serve): dynamic publish/unpublish — bind and unbind programs and pages to ports, interfaces, and paths at runtime #2147 — dynamic publish/unpublish at runtime, incl. path overrides of Explorer routes with a warning unless acknowledged

Suggested order: #2146 (model) and #2145 (bindings) first; #2147 builds on both. #2143 and #2144 are independent.

docs(id): design program web serving (#2146)

Design decision record is ready: PR #3836.

Summary

V1 targets a hosted world by WorldName, not arbitrary documents or guest-authored HTML.
The website uses the trusted text/screen presenter; the program remains host-run.
Bindings select Explorer or Program(WorldName): program-only root, mixed listeners in one process, or a canonical path mount.
Web-token auth stays listener-wide; mounts inherit it. World sessions separately require guest capabilities; admin and web tokens grant no guest authority.
Explorer route collisions fail by default; mounts must scope paths, assets, and WebSockets.
The note records invariants, implementation acceptance criteria, and source-line evidence.

Phases: (1) surface/target contract after #2145, (2) program-only listener, (3) mixed listeners, (4) canonical path mounts and conflict checks, (5) publication integration with #2147.

Question for Drew: Should a later explicit public mode mint anonymous, least-privilege guest sessions, or should every visitor always need an invite capability? Recommendation: invite-capability gated for v1; consider public access only as an explicit opt-in with a configured capability ceiling and rate/session limits. This does not block the initial serving model.

Merge pull request #3836 from developing-today/design/id-2146

agent-note:v1 — picked up triage task 3156 (worker repo-worker-code, lane aea12c82, origin openchamber-scheduled-lane) at 2026-11-02T23:07:45Z.

Triage verdict: already done — design delivered by merged PR #3836.

Drew's own comment on this issue records the design decision as ready in PR design(id): #2146 program websites #3836 (summary: V1 targets hosted world by WorldName, trusted text/screen presenter, bindings select Explorer or Program(WorldName), listener-wide web-token auth, route-collision rules, invariants + implementation acceptance criteria, 5 phases).
PR design(id): #2146 program websites #3836 (design(id): id(serve): design — how does a program appear as a website? (program-only ports, mixed ports, path mounts) #2146 program websites) merged 2026-11-02T15:50:44Z; doc/2026-11-01_design_id2146.md on main covers all four design questions (sections: publishable program, listeners/mounts composition, auth/public-by-default, program input/rendering) plus invariants, implementation acceptance criteria, and the phased plan. Verified headings on current main.
Implementation phases live with id(serve): a bindings model — multiple listeners by flag and config #2145 (bindings) / id(serve): dynamic publish/unpublish — bind and unbind programs and pages to ports, interfaces, and paths at runtime #2147 (publish/unpublish) per the filing-set note; no new packet needed from this triage — the design ask is answered. Closing as completed.

Merge pull request #5590 from developing-today/queue/9604-5537-progra…

Merge pull request #5606 from developing-today/queue/9681-5537-progra…

Ruling (Drew, 2026-11-04): anonymous public program sessions are the norm AND invite-gating gets built — both modes. Anonymous still requires an iroh ID at minimum; there is no zero-identity access. The generic invite/delegation design (iroh tickets + links, worlds and groups, one-time and bearer forms, delegation provenance) is filed as its own issue extending this one.

Navigation Menu

Repository navigation

id(serve): design — how does a program appear as a website? (program-only ports, mixed ports, path mounts) #2146

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

id(serve): design — how does a program appear as a website? (program-only ports, mixed ports, path mounts) #2146

Description

Activity

developing-today commented on Oct 29, 2026

dezren39 commented on Oct 29, 2026

dezren39 commented on Nov 1, 2026

dezren39 commented on Nov 2, 2026

dezren39 commented on Nov 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions