The Discord SDK seam used only to actuate MuteParticipant — all perception is
fed in by the driver via the Ingest* methods so the SDK keeps a single subscriber per event.
ReadonlyCapabilitiesDiscord supports member mute (bot needs "Mute Members"), so the facilitator MuteParticipant tool is offered.
Replaces the roster with a fresh snapshot from the driver and emits it to the channel. Called by the driver after the initial join and on every member join/leave.
The full current Discord voice-channel roster.
Forwards a diarized speaking-set change from the driver to the channel.
The ids currently speaking.
Mutes a participant on the platform (the actuation behind the agent's MuteParticipant tool).
Capability-gated by Capabilities; the channel checks the capability before calling this.
The participant to mute.
A promise resolving once the mute request has been issued.
Convenience alias for IngestSpeaking, kept because "notify" reads naturally at the driver's inbound-audio call site.
The ids currently speaking.
Registers a handler for roster changes. Fired with the FULL current roster on every change.
Invoked with the full current roster on every change.
Registers a handler for diarized speaking changes — the set of participant ids currently speaking.
Invoked with the speaking participant ids on every change.
Discord's adapter to the Meeting Controls channel's event source. It maintains a live roster and mirrors diarized speaking signals, and actuates mute through the SDK.
The driver owns the SDK subscriptions (the SDK seam is "latest handler wins", so it can have only one subscriber per event) and feeds this source imperatively via IngestRoster / IngestSpeaking. This source only needs the SDK for the one action it actuates — MuteParticipant. The Meeting Controls channel subscribes the
On*streams in turn.Note the absence of a hand-raise ingest method: Discord surfaces no hand-raise signal, so unlike the Zoom source there is nothing for the driver to feed. OnHandRaiseChange is implemented (the contract requires it) but its handler is never invoked. See the file-level note.
The driver constructs ONE of these per session (only when the provider has
SpeakerDiarization, i.e. there is a roster to facilitate) and returns it fromDiscordBridge.GetMeetingControlsEventSource.