DEV Community

JedidiahRhodes8293
JedidiahRhodes8293

Posted on

How to Moderate Video Room Participants by Muting or Kicking (During Live Polls)

#webrtc #moderation #observability

A shopper removed from a video room must stop receiving its media and must not keep counting as present in the live poll. A muted shopper may still watch and vote. That distinction changes the moderation decision: mute a disruptive audio source; remove a participant whose continued access or presence is the problem. Screen sharing makes the distinction urgent because silencing a microphone does nothing to revoke access to the shared screen.

Short answer: model mute as a permission change on a specific publishing track, and removal as revocation of room membership plus media delivery and poll eligibility. Neither a button click nor a WebRTC track event alone proves that all three effects happened. Observe each effect separately.

What changes when the poll and screen share are live?

Picture a live shopping session: a host shares a product comparison, viewers vote in a poll, and a participant starts talking over the host. Before moderation, that participant can publish audio, receive the screen share, and cast a vote. After a microphone mute, they can still see the comparison and remain eligible to vote. After removal, they should do neither. These are different operations with different blast radii. Imagine a vote request reaching the server while a removal request is still in flight: whichever authorization revision wins must determine both the accepted vote and the presence count. If the vote validator reads old membership but the counter reads new membership, the result can include a vote from someone the interface says is gone. Record the revision with each accepted vote so that discrepancy can be investigated without guessing from client timestamps.

One button, several effects.

There is a subtle failure mode here. A browser's MediaStreamTrack.enabled = false controls that browser's own track; it is not proof that a moderator revoked a remote publisher's permission. Likewise, closing one peer connection is not a durable ban: a client with valid room credentials may reconnect. The room authority needs to record the decision, invalidate or reject further membership attempts as appropriate, and stop forwarding media to an expelled member. The signaling and authorization design is application-specific; WebRTC itself does not define the moderation policy.

For poll accuracy, count authorized room members using server-side membership state, not a sum of connected tracks. One person can have multiple tracks or reconnect, while a participant with no microphone can still be present. Define whether disconnected members have a short reconnect grace period before the poll opens. Pick that policy explicitly; otherwise a network flap can change the displayed denominator while votes arrive.

Tracks are not people.

How do you make a moderation decision observable?

Start with a state transition that the room server owns. The following TypeScript runs with npx tsx moderation.ts; the in-memory maps illustrate the contract, not persistent storage or a distributed lock. In production, serialize updates for each room and participant in the shared store, and gate media forwarding and vote acceptance on the resulting authorization state.

type Member = {
  roomId: string;
  participantId: string;
  present: boolean;
  canPublishAudio: boolean;
  canReceiveShare: boolean;
  canVote: boolean;
  revision: number;
};
type Action = "mute" | "remove";
type AuditEvent = {
  roomId: string;
  participantId: string;
  action: Action;
  revision: number;
  occurredAt: string;
};

const members = new Map<string, Member>();
const audit: AuditEvent[] = [];
const key = (roomId: string, participantId: string) =>
  `${roomId}:${participantId}`;

function moderate(roomId: string, participantId: string, action: Action): Member {
  const id = key(roomId, participantId);
  const current = members.get(id);
  if (!current || !current.present) throw new Error("participant is not present");

  const next: Member = {
    ...current,
    canPublishAudio: false,
    canReceiveShare: action === "remove" ? false : current.canReceiveShare,
    canVote: action === "remove" ? false : current.canVote,
    present: action === "remove" ? false : current.present,
    revision: current.revision + 1,
  };
  members.set(id, next);
  audit.push({ roomId, participantId, action, revision: next.revision,
    occurredAt: new Date().toISOString() });
  return next;
}

members.set(key("sale-42", "viewer-17"), {
  roomId: "sale-42", participantId: "viewer-17", present: true,
  canPublishAudio: true, canReceiveShare: true, canVote: true, revision: 1,
});
console.log(moderate("sale-42", "viewer-17", "mute"));
console.log(moderate("sale-42", "viewer-17", "remove"));
console.log(audit);
Enter fullscreen mode Exit fullscreen mode

The first transition preserves poll participation. The second removes it. A repeated removal returns an error in this small example; a real control plane can instead return the existing final revision for retrying callers. Either way, give the action an idempotency key so a moderator retry cannot produce two conflicting audit entries. Do not put personal data or vote contents in the moderation log.

Instrument intent and enforcement separately. Record the requested action, authorization revision, media-publish rejection, share-delivery stop, membership change, and vote rejection with a common room and participant identifier. A metric for the time between the moderation request and enforced media policy is more useful than a metric for button clicks. Alert on accepted votes from removed participants or on screen-share packets delivered after removal; those are violations of the desired state, even if the UI already displays "removed." Keep identifiers bounded in metric labels and use logs or traces for per-participant correlation.

Should video room moderation mean muting or kicking participants?

Removal is the right answer when access to the session or shared content must end. It is a blunt answer to audio disruption: it also strips poll eligibility, can discard an in-progress vote, and may force a legitimate viewer through re-entry. Mute lets the viewer continue shopping and voting while the host speaks. The trade-off is concrete: if the concern is abusive chat, screen-share access, or repeated unauthorized joins, audio mute leaves the relevant capability intact. Make those separate permissions rather than pretending one mute flag covers the room.

Test the state transitions with two devices logged in as the same participant, an action racing a vote, and a reconnect immediately after removal. Verify the server rejects a post-removal vote and does not forward the screen share after credentials are revoked. Also test a mute with a screen share already active: if the muted participant is the presenter, decide whether publishing the share is a distinct permission, and test that decision. One generic "muted" badge cannot answer it.

Can a disconnected viewer still count as present?

Only if the poll's published presence policy says so. A transient disconnect is different from removal: keep a reconnect grace window if the product needs it, but expire it deterministically and expose the same membership revision to the vote validator and the displayed count. When the host announces results, snapshot the eligible membership set or define a fixed poll-close timestamp; don't recompute yesterday's denominator from today's connections.

Roll out that rule with a small session first. Compare the server's eligible-member count with accepted votes and rejected-vote reasons, inspect a few authorization timelines, and make a rollback plan for policy changes. The operational question is not which moderation button fires fastest. It is whether media access, poll eligibility, and the displayed room state agree after the button fires.

Sources

References

Top comments (0)