Skip to content

Let call member events expire #3831

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
robintown merged 2 commits into from
Jun 16, 2022
Merged

Let call member events expire #3831

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
52e9c8c
Expire m.call.member events after 1 hour
robintown Jun 7, 2022
3f6ed5f
Allow clients to choose their own timeouts
robintown Jun 10, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Next Next commit
Expire m.call.member events after 1 hour
  • Loading branch information
@robintown
robintown committed Jun 7, 2022
commit 52e9c8c1365196e73ef1041a1cb67dcb461663c9
9 changes: 6 additions & 3 deletions proposals/3401-group-voip.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -99,9 +99,11 @@ We mandate at most one call per room at any given point to avoid UX nightmares -

### Call participation

Users who want to participate in the call declare this by publishing a `m.call.member` state event using their matrix ID as the state key (thus ensuring other users cannot edit it). The event contains an array of `m.calls` object describing which calls the user is participating in within that room. This array must contain one item (for now).
Users who want to participate in the call declare this by publishing a `m.call.member` state event using their matrix ID as the state key (thus ensuring other users cannot edit it). The event contains a timestamp named `m.expires_ts` describing when this data should be considered stale, and an array `m.calls` of objects describing which calls the user is participating in within that room. This array must contain one item (for now).

`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.
Copy link
Member

@dbkr dbkr Jun 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


The fields within the item in the `m.calls` contents are:

Expand Down Expand Up @@ -183,7 +185,8 @@ For instance:
}
]
}
]
],
"m.expires_ts": 1654616071686
}
}
```
Expand Down