RoomHubSeam

Server-side hub Seam for one named room — the structural per-room isolation primitive.

A RoomHubSeam is the server's view of a single room. A frame broadcast here reaches only the connections that have been admitted to this room; a non-member is never in the fanout list, so a cross-room leak is structurally unrepresentable — isolation by construction, not by guard.

Deterministic delivery

Frames are pushed into the room by MuxServerLoom, which performs a single collection of each connection's underlying seam and demultiplexes by channel name inline. A room never collects a per-channel flow itself — so registration and forwarding do not depend on the replay-0 subscription timing of a NamedMux channel view. Inbound frames land in a bounded Spool (a buffered channel), so a frame delivered before the room's consumer subscribes is retained rather than dropped. This is what makes the path deterministic under virtual time.

Membership / registration

A connection joins a room via two gates, both applied by deliver on the first frame:

1. Authorization — authorizer is invoked with the peer's id and this room's channelName. A false return structurally excludes the connection: it is never added to peers, the fanout, or the inbound stream.

2. First-frame admission — only if the authorizer returns true is the connection registered. All subsequent frames from that connection on this channel are then forwarded to incoming and the connection appears in peers.

A connection is deregistered via deregister when its underlying link tears.

Reconnect / resume

Registration is keyed by PeerId. A returning peer (same id, fresh connection) replaces the stale entry; the stale connection's later deregister is a no-op because its OutboundSender is no longer the registered one — the resumed membership survives the old connection's teardown.

The one replacement that is refused is an unattested link claiming an id whose live link the host verified (#2357) — a peer id is self-asserted and public, so without that guard anyone could take both the roster entry and the unicast route of a verified peer, presenting no credential. See principals. Attested → attested replacement is unaffected, and so is a deployment that attests nothing at all.

Thread safety

All mutable state (registered and the attestedPrincipals roster) is guarded by a reentrant lock. Suspend calls (authorizer, sends, spool delivery) are always performed outside the lock. The terminal lifecycle runs through a SeamStateGate: close latches Torn single-shot (no more non-CAS if (_state is Torn) return), and the roster-resurrection hazard — an in-flight deliver re-registering a peer after close() collapsed the roster — is closed by folding the closed check into the same critical section that mutates registered/_peers/principals, so a post-close deliver can never republish membership. The check is that marker and not a read of state because Seam.peers requires the roster collapse to be published before the Torn latch, so mid-close there is an instant at which the roster is collapsed and state is not yet terminal.

Parameters