You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hide ghost participants by default, and show them only if a developer flag is enabled.
Why would you like to do it?
Ghosts can show up in normal usage of the app whenever there is a delay between someone leaving the call in Matrix and leaving the call in LiveKit. This is not great, as people will generally not know or care about what the 👻 icon means. I contend that ghost participants are really meant to be a developer feature used for load testing.
How would you like to achieve it?
Wait until we get an E2EE system which selectively shares keys with connected participants via a private channel (i.e. to-device messages). We need to wait for this because currently, showing ghost participants is how we prevent eavesdropping.
Have you considered any alternatives?
No response
Additional context
No response
The text was updated successfully, but these errors were encountered:
it would be great to have some kind of allowlist for livekit identities.
because the cool thing now is, you can send media to element call rooms (of course only if you have api access to your livekit server) e.g. with the livekit-cli .
these participants are currently also marked as [👻]. i assume these would also be hidden then?
maybe we can define an allowlist in the EC config.json?
Your use case
What would you like to do?
Hide ghost participants by default, and show them only if a developer flag is enabled.
Why would you like to do it?
Ghosts can show up in normal usage of the app whenever there is a delay between someone leaving the call in Matrix and leaving the call in LiveKit. This is not great, as people will generally not know or care about what the 👻 icon means. I contend that ghost participants are really meant to be a developer feature used for load testing.
How would you like to achieve it?
Wait until we get an E2EE system which selectively shares keys with connected participants via a private channel (i.e. to-device messages). We need to wait for this because currently, showing ghost participants is how we prevent eavesdropping.
Have you considered any alternatives?
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: