Let call member events expire#3831
Conversation
proposals/3401-group-voip.md
Outdated
| `m.call.member` state events must be ignored if their user's `m.room.member` event's membership field is not `join`. | ||
| When sending an `m.call.member` event, clients should set the `m.expires_ts` value to one hour in the future. If the user stays connected for longer than an hour, the client must actively update the state event with a new expiration timestamp (for example, every 45 minutes to allow for some amount of clock desync between participants). | ||
|
|
||
| `m.call.member` state events must be ignored if the `m.expires_ts` field indicates they have expired, or if their user's `m.room.member` event's membership field is not `join`. They must also be ignored if the `m.expires_ts` value is more than 75 minutes in the future, to prevent uncooperative clients from getting themselves permanently shown as 'connected' by setting the expiration date to way in the future. |
There was a problem hiding this comment.
Oh, also: worth noting that call invites have a 'lifetime' field which is a duration for which it's valid after the "time of the event", the idea being that you can work that out by using the age field you get from the homeserver and then it doesn't rely on your clients' clocks being synced. This approach is much simpler and avoids using the (slightly contentious and difficult to use) age field but obviously relies on time being correct (ish) on clients. I think this is probably the right approach because 1) almost all user devices automatically NTP sync nowadays and 2) we're dealing with a much longer span of time than the amount of time a call rings for, so if a clock is off by a couple of minutes, it won't make much difference here (whereas for a call invite, it could mean the call would never ring at all).
In other words, I think this is correct, but could be worth noting in case we come back in several years and wonder why event expiry is handled differently between invites & group call member events.
robintown
changed the title
|
I'd say this is OK to go ahead & merge into Matthew's branch |
2 participants
This is to combat stale device data so clients can show an accurate view of who's actively participating in the call at all times. See matrix-org/matrix-react-sdk#8776 for a similar PoC implementation of this for Element Web's video rooms.