id: design: self-hosting & interop stance — own servers, Rust library reuse, what intercompatibility requires

Part of the worlds design program: #5955. Statements S78–S81 of the 2026-11-04 brief.

Requirement (Drew, in substance)

We're trying to build a real place in the virtual world to allow people to share, create, and deal with one another without absolutely requiring our own interaction:

We might not even host them. They could do it all on their own.
They could use our Rust libraries to take the appropriate parts to build their own client or subsystem — which technically rides along the same protocol networks but is entirely separate and doesn't automatically work for our intercompatibility requirements. Or ideally, it does.
Maybe it works perfectly, and they just don't want to have our chat and world system and want to host their own servers: it's the exact same system, but they're just using it in a different way, and that should all work.

Design points to settle

What is the interop contract exactly: which parts are load-bearing for intercompatibility (wire format, identity, capability negotiation, registry format) and which are our product choices on top (chat UI, our registry, our permission defaults)? A third-party server that implements the contract interoperates; one that doesn't is merely separate — the design must make that line explicit and testable.
Conformance: the adapter conformance harness / interop matrix in #5814 is the natural home for "does it actually interoperate" — this design states the stance, that issue builds the proof.
Self-hosting a subset: run worlds without chat, run chat without worlds, run only the registry — which subsets are supported shapes vs accidents?
Defaults travel or don't: our permission defaults, license policy defaults (licensing children of #5955), and moderation defaults are server-admin choices on a self-hosted server, not protocol requirements. Say so in the design, because the AGPL/licensing analysis depends on self-hosting being genuinely possible.
Boundary enforcement across bridges/federation/relays is #5882; residency implementation is #5529. This issue is the stance those implement.

Done looks like

A short stance doc: the interop contract's load-bearing list, supported subset shapes, and what is explicitly not required of a self-hoster.

CODE-1641

Wave-2 follow-ups filed from the prior-art research (Lane B). Granular sub-scopes of this issue, each carrying the relevant research findings + citations:

id: design: land/parcel capability domains — per-parcel policy granularity without tokenized land

Research source: workspace/scratch/worlds-capabilities-brief-2026-11-04/prior-art-research.md. Full wave-2 mapping: workspace/scratch/worlds-capabilities-brief-2026-11-04/wave2-map.md.

🤖 Agent note · done (triaged)

Agent: queue worker (repo-worker-code), lane code-r
Session / ID: task 10344
Found via: queue claim
Task: Triage of the self-hosting & interop stance design at current main.
Expectation: triaged — still live, ordering recorded below; the stance doc itself stays open as this issue's deliverable.
Links: program issue id: design program: worlds — advanced Roc libraries, capabilities, permissions, dynamic user functions, licensing (2026-11-04 brief) #5955; wire format issue id: design: Wire format & transport adapters — postcard schema, non-UDP carriers, relays/proxies #5674; conformance issue id: design: adapter conformance harness & interop matrix CI (from #5674) #5814

Triage findings (task 10344, 2026-11-05)

Still live; no stance doc exists yet. Issue #5975 is OPEN with no hard-stop labels. Code search against current main finds no self-hosting stance document under doc/ and no interop-contract statement (the generic "interop contract" hits are unrelated investigations). Nothing filed duplicates it: the neighbours are the mechanisms this stance governs, not the stance itself.

Ordering (all verified OPEN by fresh gh checks this run):

Parent program issue id: design program: worlds — advanced Roc libraries, capabilities, permissions, dynamic user functions, licensing (2026-11-04 brief) #5955 is OPEN — this is one of its design children (statements S78–S81), and the licensing children of issue id: design program: worlds — advanced Roc libraries, capabilities, permissions, dynamic user functions, licensing (2026-11-04 brief) #5955 depend on self-hosting being genuinely possible, per the issue body.
The stance is upstream of its proofs: issue id: design: adapter conformance harness & interop matrix CI (from #5674) #5814 (adapter conformance harness & interop matrix) is the home for "does it actually interoperate" and issue id: design: boundary enforcement across bridges, federation & relays (from #5683) #5882 (boundary enforcement) / issue id: implement Residency boundaries for native bridge, federation and relays (design #3398) #5529 (residency implementation) implement boundaries this stance states. The stance doc should therefore be written before or alongside those, not after them — it is the requirement they test against.
One real dependency: the load-bearing list (wire format, identity, capability negotiation, registry format) names things whose shapes are being settled in issue id: design: Wire format & transport adapters — postcard schema, non-UDP carriers, relays/proxies #5674 (wire format & transport adapters, OPEN; its triage task 10107 was handed to the opencode execution lane earlier today). So: draft the stance now in parallel, finalize the load-bearing list once issue id: design: Wire format & transport adapters — postcard schema, non-UDP carriers, relays/proxies #5674's wire-format design settles. Issue id: design: writer sets v2 — composable views, set algebra, federation (extends #5545) #5789 (writer sets v2 / federation) is an input to the federation parts, not a blocker for the stance itself.
Subset shapes (worlds without chat, chat without worlds, registry only) and the "defaults are server-admin choices, not protocol requirements" point need no external input — they follow from the requirement as filed.

Scoped next step (when worked): the short stance doc from the issue's "Done looks like": (1) the interop contract's load-bearing list, (2) supported subset shapes vs accidents, (3) what is explicitly not required of a self-hoster, with issue #5814 named as the conformance proof obligation for each load-bearing item. No decision from Drew is needed — the stance restates his requirement in substance (S78–S81); no implementation task is enqueued (design-first).

docs(id): self-hosting and interop stance decision record (#5975) (#7602

🤖 Agent note · done

Agent: queue worker (repo-worker-code), lane code-x
Session / ID: task 12889
Found via: queue claim
Task: task 12889 (issue id: design: self-hosting & interop stance — own servers, Rust library reuse, what intercompatibility requires #5975) — stance decision record written and merged: PR docs(id): self-hosting and interop stance (#5975) #7602 squash-merged 1cc430a; doc/2026-11-08T09-12-27Z_design_id-self-hosting-interop-stance/ indexed in doc/README.md; Codex review completed with no findings on b233623; relative links verified programmatically and git diff --check clean (docs-only, no runtime tests per packet); issue id: design: self-hosting & interop stance — own servers, Rust library reuse, what intercompatibility requires #5975 closed by the merge and its queue/status/work labels cleaned.
Expectation: done
Links: PR docs(id): self-hosting and interop stance (#5975) #7602, merge 1cc430a

doc: land/parcel capability-domain design note (#6015) (#7601)

Navigation Menu

Repository navigation

id: design: self-hosting & interop stance — own servers, Rust library reuse, what intercompatibility requires #5975

Requirement (Drew, in substance)

Design points to settle

Related

Done looks like

Triage findings (task 10344, 2026-11-05)

19 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

id: design: self-hosting & interop stance — own servers, Rust library reuse, what intercompatibility requires #5975

Description

Requirement (Drew, in substance)

Design points to settle

Related

Done looks like

Activity

developing-today commented on Nov 5, 2026

dezren39 commented on Nov 5, 2026

dezren39 commented on Nov 5, 2026

Triage findings (task 10344, 2026-11-05)

19 remaining items

dezren39 commented on Nov 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions