Complexity Eater

Proposal, not a service

Hosted rooms

Room-launch contract version 1 has a hosted mode with status not_implemented. This page is the comparison a later provider would have to satisfy. Nothing here provisions a room.

Recommendation

The smallest next step is a remote instance of the existing ce binary, one room process per isolated host, reached through the Tailcat plugin or another transport that publishes only the session ingress. The engine, the invitation codec, and the owner/agent split stay as they are. A shared supervisor is a later step. A Cloudflare Workers and Durable Objects port of the room is the wrong first host: it would reimplement the Rust core to fit a platform.

Three ways to host a room later
Option Idle cost Fit
1. One remote ce process per room The virtual machine stays up for the life of the room. Budget a small always-on machine, commonly a few dollars to a few tens of dollars per month at small-VM prices, and confirm the current rate. Scale to zero is not a property of ce serve. Reuses the binary, the protocol, and the security model. Isolation is the process boundary. This is the preferred first experiment, and it is operator-started, not a button on this website.
2. A shared host with one process per room One machine's floor, divided across rooms. The container profile uses 512 MB for one room, so concurrency is a memory budget. Eight rooms want several gigabytes plus overhead. Still the Rust binary. New code is a supervisor beside the engine. A bug in the supervisor can cross rooms, which the single process does not do today.
3. Workers and Durable Objects Duration billing can be cheaper for idle rooms only after a rewrite. A Worker that proxies to option 1 still pays for the Rust process. The current process is Axum, Tokio, SQLite, and two loopback listeners. Workers cannot run that binary. A Durable Object would be a second implementation of protocol version 1. Do not port the core to satisfy the platform.

Room creation and ownership

An operator starts ce serve on loopback inside the host. The host session holds capability *. There is no account row in this phase. The marketing site and the room origin stay separate so a page view cannot become a session.

Invitations and sessions

Keep commonroom://join/ and protocol version 1. A default invitation lasts 60 minutes, at most 7 days, and spends one use. A failed dial does not spend it. Redeeming it creates a session. The invitation secret is not the bearer token for later calls. Sessions default to 8 hours and last at most 24 hours. Short-lived, single-use grants stay the default.

Owner and agent permissions

The owner cookie stays on the owner port, which the transport does not publish. Agents present bearers on the ingress. POST /mcp stays on the ingress. A default grant remains read, observe, propose, checkout, and commit. approve, invite, and admin stay off that grant. Every mutating route checks the session again. A task id is not a credential.

Transport and failure

Remote participants use a plugin that publishes the ingress. The owner port stays on loopback. If the plugin is missing or crashes, the result is transport_unavailable. The process must not open a public listener as a fallback. A hosted host that cannot bring the plugin up should fail the start and leave no reachable ingress.

Expiration, revocation, and destruction

Invitations and sessions expire on their own. ce remove-participant ends a session. Destroying a room is stopping the process and deleting its volume, and that operation must be safe to repeat. Destroying the process invalidates every session because the sidecar is gone. Keep the markdown file if it is evidence. Do not reuse a leaked invitation; create a new one, or destroy the room.

Persistence and retention

The markdown file remains the artifact. The sidecar holds participants, sessions, invitations, leases, proposals, events, and versions. The event table is a ring of the newest 2000 rows, not a bus another host can tail. Hosted v1 should not add a second store. Retention is the life of the volume. --ephemeral is the wrong mode for a room someone expects to find later: it deletes the temporary sidecar directory on exit and leaves the markdown file. That deletion does not promise a cryptographic wipe of disk blocks.

Quotas and abuse

Keep the current limits: 1 MiB request bodies, 256 KiB proposals, 32 active sessions, 32 active tasks, and 600 authenticated requests per minute per bearer. Add a supervisor cap on restarts and on simultaneous connections per room. Unauthenticated entry is invitation redeem, which stays single-use. Without accounts, a public "create room" control on this website would be an unauthenticated provisioning API. Do not add one. The first hosted rooms are created by an operator who already has the host.

Audit and incidents

Logs keep the path, status, and duration. They omit the Authorization header, the body, invitation secrets, and session ids. A hosted operator can ship those redacted lines to their own store. On a suspected leak, stop the process, preserve the markdown file, and treat every invitation from that sidecar as gone. There is no central account to disable in this phase.

Version compatibility

Invitation version 1 and MCP revision 2026-07-28 are the only accepted pair. A hosted build must serve that pair and return unsupported_version for anything else. The room-launch contract version is independent: it describes how a website asks a person to start a room. Contract version 1 does not add a provider endpoint. A later contract version can name a provider only after that provider exists and has been reviewed. Old invitations keep working until they expire; they are not migrated in place.

Unresolved assumptions