Multi-user avatar turn ownership: the room needs an authority

A model to inspect

The room owns attribution; the actor owns permission

01Identify room and participant
02Resolve the addressed turn
03Check action authority
04Render attributed response

Floor control, transport identity and permission are distinct. Late events remain bound to their originating turn.

Original conceptual diagram · not a live trace or measured result.

Make the room the primary scope

A shared avatar experience needs a room record before it needs expressive animation. Every input, caption, audio packet, tool proposal, moderation event, and presentation cue should name a room ID, participant ID, source device or channel where relevant, and sequence or receipt order. The avatar is a renderer of authorized room state; it must not infer who owns a turn from volume, gaze, or whichever packet arrived first.

Define admission and departure explicitly. A participant who leaves loses the right to start new actions, but a pending action should retain enough attribution to be cancelled or reconciled. A reconnection creates a new transport attachment, not permission to inherit another participant’s unfinished turn.

Separate floor control from authority

Floor control answers who may speak, interrupt, or receive the next prompt. Action authority answers who may confirm a booking, share a document, change a room setting, or moderate another participant. They can overlap but should not be assumed to be the same. A facilitator may own the floor while another participant alone has authority to approve an expense. Store both decisions as server-side room state.

Hypothetical example: two participants speak over one another while the avatar asks a choice. The room service can mark both inputs as overlapping and request addressed clarification. It must not attribute the louder speaker’s answer to the other participant or execute a shared action without the configured authorized participant’s confirmation.

Addressed speech needs an explicit rule

Write the routing rule for “yes,” names, wake words, direct mentions, text replies, and nonverbal controls. If the system cannot establish addressee and turn owner, it should ask a short disambiguating question or expose a participant selector. Do not make an avatar’s gaze a hidden routing signal; show the current addressed participant in captions and accessible text.

Counterexample: a delayed transcription packet says “cancel” after another user’s tool confirmation is displayed. Without participant and turn identifiers, a global stop could cancel the wrong operation. With them, the system can apply the participant-owned stop or request moderator authority for a room-wide intervention.

Handle late and duplicated media safely

Media transport can reorder, duplicate, or arrive after a room state changed. Keep a bounded event ledger that records the originating participant, turn, media sequence where available, receipt time, and whether the event was accepted, superseded, or ignored. Do not replay late audio into a new turn merely because its words still parse. The action layer checks current room authority again at execution time.

The W3C WebRTC identity document concerns identity assertions and media visibility; it does not define room ownership or conversation protocol. Its relevant limit is a reminder not to borrow transport identity as a complete product authorization model. Define your own policy and test it against reconnect and cross-device scenarios.

Test room conflicts visibly

Use fixtures for concurrent replies, a moderator joining mid-turn, participant departure during confirmation, reconnection with an old packet, text and voice disagreement, caption delay, and an avatar fallback that removes visual cues. Assert participant attribution in the visible transcript, server event record, and action request. Ensure the text-only route can express who the system believes owns the turn and offers a correction mechanism.

Acceptance checks: every consequential room event has participant and room scope; floor and permission states are distinct; late packets cannot change an unrelated turn; and moderator powers are explicit and audited. A correct ownership model reduces confusion, but it cannot infer social intent perfectly; maintain a clarification path.

Keep presence cues subordinate

Avatar motion, gaze, speaking indicators, and captions should consume the room authority record rather than create it. If visual state falls behind, the accessible transcript and action controls remain authoritative. Offer a way to correct attribution without requiring a participant to interrupt the group verbally. Record the correction as a room event so a late renderer cannot immediately restore the disputed cue or confuse participants again visibly.

This protects people using text, captions, reduced motion, or a fallback interface. It also prevents an appealing animation from making an unverified assumption about who was addressed, heard, or authorized.

Take it into the review

Shared-room event authority

Room event	Participant scope	Floor state	Action authority	Late-event handling	Visible correction
voice reply	participant-a	owns current turn	none	drop if superseded	show addressee
booking confirm	participant-b	may speak	approver	recheck on execute	ask named confirmer
moderator stop	moderator	room interrupt	moderation only	apply current sequence	announce scope
late transcript	participant-a	expired turn	none	store inert	offer clarification

A starting artifact to adapt to your service—not a ready-made policy, compliance certificate or test result.

Primary reading

Sources and limits

These links support the architecture, policy, or product behavior discussed above. Vendor documentation describes vendor features; it is not independent proof of performance. Current details should be rechecked before a production decision.

What the sources establish

WebRTC Identity for WebRTC 1.0

The WebRTC identity document describes identity assertions and marking media streams viewable by another identity.

Limits: It does not define shared-room floor control or application authorization.

Checked 2026-09-19 · W3C · source publication date not established.

Open original source ↗

W3C Trace Context

Trace Context standardizes propagation of a trace identity between services.

Limits: It does not define shared-room ownership, floor control, or action authority.