What problem are you trying to solve?
I'd like to trigger some custom UI logic when a participant is muted by a moderator, not when they mute themselves. However, using the TRACK_MUTE_CHANGED event alone doesn't give me enough context — it fires for all mute actions, regardless of who triggered the mute.
This makes it hard to distinguish between:
a user muting themselves, and
being muted by a moderator
When I try to hook into TRACK_MUTE_CHANGED for my UI updates, it results in false positives — since it doesn't differentiate the source of the mute action.
Ideally, I’d want to listen to a specific event or metadata that confirms the mute was initiated by a moderator so I can:
trigger secondary API calls
update my custom UI logic (e.g., alerts, overlays, status indicators)
What solution would you like to see?
No response
Is there an alternative?
No response
What problem are you trying to solve?
I'd like to trigger some custom UI logic when a participant is muted by a moderator, not when they mute themselves. However, using the TRACK_MUTE_CHANGED event alone doesn't give me enough context — it fires for all mute actions, regardless of who triggered the mute.
This makes it hard to distinguish between:
a user muting themselves, and
being muted by a moderator
When I try to hook into TRACK_MUTE_CHANGED for my UI updates, it results in false positives — since it doesn't differentiate the source of the mute action.
Ideally, I’d want to listen to a specific event or metadata that confirms the mute was initiated by a moderator so I can:
trigger secondary API calls
update my custom UI logic (e.g., alerts, overlays, status indicators)
What solution would you like to see?
No response
Is there an alternative?
No response