Short answer: make the server the only issuer of ordered chat state, and make every token prove one room and one action before a change enters the log.
That rule covers typing indicators and read receipts, but the two events should not be treated as equally durable. Typing is a hint with a short lifetime. A read receipt is an assertion tied to a message, an audience session, and a point in the room's history. The security design should preserve that difference instead of forcing both through one permissive endpoint.
Start with a trust boundary, not a transport choice
WebRTC can move media and data between peers, yet its specification does not make a peer an authority for application ordering or authorization. Those decisions belong to the application service (W3C WebRTC Recommendation, in References). A browser may send intent; it must not choose a sequence, room, actor, or receipt timestamp.
I write the boundary down as an architecture decision record before choosing storage. The invariants are deliberately plain: the service assigns a monotonic sequence per room, a read receipt names an existing message in that room, a typing event expires server-side, and a reconnect must pass authorization again. A cursor supplied by a client is a request for replay, never evidence of permission.
One bad assumption is enough to undo the rest. During an early test I accepted a client cursor as if it were harmless UI metadata. A stale cursor from room stage-b then produced a 409 conflict after the room had moved on. The fix was to reject backwards cursors and bind each accepted event to (room_id, actor_id, token_id, sequence). Three identifiers and one sequence. Boring is good here.
Measure twice.
The longer incident path deserves more attention than the happy path. Imagine a viewer changes networks while the headliner starts a new song. The first gateway has accepted a token for stage-a; the reconnect lands on another worker, which sees a valid bearer but has no local cursor state. If that worker trusts the supplied cursor, it can request events from a different room or ask for an unbounded replay. Even when the data itself is not secret, the ordering leaks moderation decisions: a receipt shown before a deletion looks like proof that a message was read. The service should therefore resolve the room from the authenticated token, clamp the cursor to the retained range, and emit an explicit “resync required” result when the gap is too large. That result is safer than silently filling the gap with client-side guesses. Correlate the gateway decision, append record, and replay response by token identifier and server sequence; timestamps from three hosts will disagree, while those identifiers still describe one causal path.
How can ordered realtime changes keep client trust narrow?
Use separate capabilities for chat:typing and chat:read, each scoped to a room and a short expiry. A posting token should not silently gain permission to acknowledge every message a viewer can see. On reconnect, mint or validate a fresh token and compare its room binding with the requested stream; do not inherit trust from a socket that disappeared during a mobile network change.
The critical path can stay small:
from dataclasses import dataclass
from time import time
@dataclass(frozen=True)
class Token:
actor_id: str
room_id: str
scopes: frozenset[str]
expires_at: float
def authorize(token: Token, room_id: str, kind: str, message_id: str | None) -> None:
if token.room_id != room_id or token.expires_at <= time():
raise PermissionError("token is not valid for this room")
required = "chat:typing" if kind == "typing" else "chat:read"
if required not in token.scopes:
raise PermissionError("scope does not permit this event")
if kind == "read" and message_id is None:
raise ValueError("read receipts require a message id")
def append_intent(store, token: Token, room_id: str,
kind: str, message_id: str | None):
authorize(token, room_id, kind, message_id)
sequence = store.next_sequence(room_id)
event = {
"room": room_id,
"actor": token.actor_id,
"kind": kind,
"message": message_id,
"sequence": sequence,
}
store.append_if_absent(room_id, sequence, event)
return event
append_if_absent needs an atomic uniqueness check on (room, sequence). A process-local counter will split history as soon as two workers handle the same concert. If the write store cannot provide that boundary, place sequencing behind one durable log and fan out only after the append is committed.
What does a reconnect prove about ordered state changes?
Treat replay as a new authorization transaction. The client sends the last applied sequence; the service checks room membership, token scope, and a bounded replay window, then returns events in server order. A future cursor is a validation error, not a hint to skip ahead. An old cursor can be replayed safely only if idempotency and retention rules say exactly what “old” means.
The subtle failure is publishing before the authorization record is durable. A fan-out worker can deliver a receipt that the audit stream later rejects, leaving moderators with a plausible but unverifiable history. Record the decision and the sequence in one write boundary, then publish. For retries, deduplicate on a client-provided idempotency key that is still bound to room and actor; the key must never override membership.
Keep logs useful and restrained. Store a hashed token identifier, denial reason, source region, and server sequence. Do not copy message text into security logs; a livestream's audience is large, and logs outlive the performance. I am not sure a single global retention period fits every jurisdiction, so make retention a policy input and test deletion separately from replay.
Which sequencing boundary survives a live show?
The choice is a failure-boundary decision, not a race for the smallest latency.
| Boundary | What it guarantees | Cost or limit | Appropriate use |
|---|---|---|---|
| Per-room sequencer | One authority defines room history | Hot rooms need partitioning and backpressure | Auditable receipts and moderation actions |
| Durable log with consumers | Replay and inspection after reconnect | Consumer lag and duplicate delivery must be handled | Receipts plus moderation pipelines |
| Client merge of signed events | Low-latency cosmetic display | Key rotation and replay protection are complex | Best-effort typing hints |
Client merge is a valid tool for a hint that may vanish. It is a poor authority for a receipt that changes what a user believes happened. Your mileage may vary across regions: wall-clock timestamps can describe when a packet was observed, but they cannot establish which receipt came first.
What should testing and operations observe?
Property tests should generate concurrent typing and receipt intents from two regions, kill a consumer between append and publish, and reconnect with stale, future, and cross-room cursors. The expected result is deterministic replay, explicit denial, and no client-controlled ordering.
During the event, watch sequence gaps, replay latency, duplicate suppression, token-denial rate, and clock skew. Alert on a rising gap rate before viewers report missing receipts. Keep a quarantine queue for validation failures so an operator can inspect metadata without replaying an untrusted payload.
The catch is latency and concentration. A strict per-room sequencer is not suitable for peer-to-peer offline chat, and it is unnecessary when a typing hint can be lost without consequence. In those cases, use a best-effort channel for typing while keeping receipts on the authoritative path. Document that split in the client contract; “pending” should mean pending, not silently accepted.
Top comments (0)