Skip to main content

Use Cases

The same protocol handles all five of these. The differences are in how you model channels, what you put in peerMetadata, and whether you lean on direct messages or broadcast publishes.

1. WebRTC Signalling​

Exchange WebRTC SDP offer/answer and ICE candidates between peers. Pair with Metered TURN for the media relay.

  • Channel model — One channel per call/room (call-${roomId}). Peers subscribe to coordinate.
  • Messaging pattern — Mostly direct messages (SDP/ICE go between two specific peers, not the whole room). Presence is used to detect new joiners and trigger offer-creation.
  • peerMetadata — Display name, avatar URL, role (presenter / participant).
  • TURN integration — Your /v1/tokens mint puts a fresh, time-bounded ICE-server array in the token's iceServers claim. The peer receives it in the welcome message and feeds it to new RTCPeerConnection({ iceServers }). No separate TURN-credential request from the browser.

Guides:

2. AI Agent Communication​

Multi-agent coordination. Agents subscribe to shared task channels; humans stream interventions or follow-up prompts to specific agents.

  • Channel model — One channel per running workflow (workflow-${runId}), one per role (agents/researchers), plus direct messages for tool-call relays.
  • Messaging pattern — Mix of broadcast ("planner emits a subtask") and direct ("researcher returns a finding to the planner specifically"). Long-lived connections so agents stay reachable while idle.
  • peerMetadata — Agent name, model name, capabilities tag, owner user ID.
  • Why not just HTTP? — Agents need to receive without polling, multi-cast progress updates, and tolerate long idle periods. WebSocket + channels handles all three; HTTP doesn't.

Guide: AI Agent Communication

3. Live Presence & Chat​

Classroom moderation, proctoring, livestream chat, dashboard "who's online" indicators.

  • Channel model — One channel per room (room-${classId}). Everyone subscribes; messages broadcast.
  • Messaging pattern — Almost entirely broadcast publishes. Presence is the headline feature — peer-joined / peer-left events drive the participant list.
  • peerMetadata — userId, username, profilePic, role (student / teacher / moderator). Use the includeSenderMetadata flag on subscribe so every message arrives stamped with the sender's identity, not just presence events.

Guide: Live Presence & Chat

4. IoT Telemetry & Device Control​

AI cameras streaming detection events, fleet vehicles posting telematics, smart-home devices receiving commands.

  • Channel model — Per-device channel for telemetry (devices/${deviceId}/events), per-fleet channel for commands (fleets/${fleetId}/commands).
  • Messaging pattern — Devices publish to their own telemetry channel; control plane publishes commands via the REST API (POST /v1/channels/fleets/abc/commands/publish from your backend — no need to open a WebSocket from your control-plane service).
  • peerMetadata — Device ID, firmware version, location, last-seen timestamp.
  • Why this fits — MQTT-style pub/sub semantics over WebSocket. Server-side publish via REST is the typical pattern when one side is your backend and the other is a fleet of devices.

Guide: IoT Telemetry & Device Control

5. Collaborative Apps​

Cursors / selections, live dashboards, shared document state, multiplayer mini-games.

  • Channel model — One channel per document/board (doc-${docId}). Everyone subscribes.
  • Messaging pattern — Very high publish rate per peer (cursor updates can be 60Hz). Lean on the per-connection token bucket to clamp accidental runaway publishers; sample down on the client side if you're sending pixel-positions.
  • peerMetadata — User ID, display name, cursor color, current view/page.

Guide: Collaborative Apps

Which one is your app?​

If you're unsure, start with WebRTC Signalling if you're a TURN customer, or AI Agent Communication if you're building agent infrastructure. The other three are variations on the same patterns.