Rooms

Activate intentional group membership without an extra discovery avenue

Rooms connect peers that intentionally share a session identifier. Joining a room activates one avenue; it does not create or retain a separate space or user-scope connection.

Ephemeral room

const room = await rtc.rooms.join('support-7f3a', {
  access: 'capability',
  membership: 'ephemeral',
});

// room.peers, room.channels, room.diagnostics
await room.leave();

This is the default for games, calls, temporary collaboration, and public prototypes.

Authenticated room

const room = await rtc.rooms.join('team-roadmap', {
  access: 'authenticated',
  membership: 'ephemeral',
  auth,
});

Use the authenticated path when the room policy depends on your product user. OpenRTC consumes a registered assertion; it does not own your product authorization model.

Durable membership

const room = await rtc.rooms.join('team-roadmap', {
  access: 'authenticated',
  membership: 'durable',
  auth,
});

Durable membership is a portal-enabled advanced capability. It incurs durable control-plane operations and should be reserved for teams or memberships that must survive everyone leaving.

Capacity is always server-admitted. A client maxPeers can lower its desired capacity but cannot increase the manifest, budget, fan-out, or technical ceiling.

Rooms that grow

Leave the architecture on auto when a room may grow beyond a small group:

const room = await rtc.rooms.join('community-stage', {
  access: 'authenticated',
  auth,
  architecture: 'auto',
  payload: 'reliable',
});

const chat = room.channel<{ text: string }>('chat');
await chat.send({ text: 'Hello everyone' });

OpenRTC keeps automatic reliable groups of eight or fewer as a direct full mesh. Fixed reliable mesh is reviewed through 16 members. Managed fan-out is not available in 2.5, so reliable rooms above those safe limits fail with room-architecture-unavailable instead of changing semantics or selecting a hidden hosted path. Rooms that declare payload: 'latest-state' may use a small authenticated sparse graph through 50 members. Your app still uses the same channel API. It does not pick peers, carriers, retries, or relay routes.

The current release rejects member 51. Larger logical rooms remain on the sharded-cell roadmap and are not enabled by choosing a fixed architecture.

During a membership change, OpenRTC may briefly keep displaced active routes as overlap. The shared Rust owner removes them only after the new active routes are connected and admitted. Steady topologies use active routes only.

Sparse forwarding is for room-wide, short-lived updates. sendTo() uses a direct authorized connection and never forwards a private targeted payload through other members. The current API fails closed when that direct route is not already available; automatic direct-route requests are not shipped yet. Durable business actions still need the app's normal idempotency, acknowledgement, and storage rules.

Usage is reported as customer credits. Direct peer payload does not use relay credits; any measured relay traffic is shown through the existing relay credit meter. Internal provider rates and operator costs are not part of the public API.

See Adaptive large rooms for automatic selection, diagnostics, quotes, fixed-mode limits, native Rust, and hosted rollout gates.