Participants · RMC Docs

A participant is an identity inside a room with a role, grants, and a bearer credential. It can represent a browser user or an embedded agent. Your product authenticates the person; RMC authorizes the participant's operations.

Bind product identity to room authority

Your backend creates or locates the room, determines the user's access, and issues a participant token. Keep that mapping in your application. A user ID from your identity system is not automatically an RMC participant ID, and a supplied participant ID is not proof of authentication.

Your backend authenticates a product user and issues a scoped room token. Delivery requires a current action grant, matching event visibility, and a matching subscription selector. Revocation ends further access but cannot recall already delivered data. — Current grants, visibility, and selectors answer three different questions.Open SVG ↗Excalidraw source ↓

TypeScript

// Trusted backend: owner is a provisioned room's owner RoomClient.
const invited = await owner.invite("customer", [
  {action: "event:publish", resource: "chat"},
  {action: "event:subscribe", resource: "chat"},
]);

Return owner.roomId, invited.participant.id, and invited.token through your authenticated application endpoint. Keep the owner credential on the backend.

This customer can publish and read eligible chat events. The role string does not supply those permissions; the grants do. Invitation is privileged: RMC accepts the grants an authorized inviter supplies, so your backend must decide their scope.

Keep three questions separate

Question	Mechanism	Example
Who is acting?	Participant credential	Customer participant in this room
May they perform the operation?	Action/resource grant	`event:publish` on `chat`
Is this record intended for them?	Visibility, followed by selection	A specialist-only note remains hidden from the customer

An event records the authenticated actor. A subscription uses that participant's current authority as it reads. Multiple subscriptions on one room handle therefore share an identity even though they keep separate progress.

End access deliberately

Revoking a participant blocks future authorized use and ends existing stream access. It cannot recall data already received or undo an application callback's side effects. Provider cleanup follows the separate live media boundary.

Read authorization and revocation for the grant table, visibility rules, and revoke request. The enforcement lives in session.go and auth.go; session tests document the boundary.