MSC4018: Reliable call membership

[robintown]

Rendered

[dbkr]

Seems nice & simple. Could potentially mention that homeservers would have a delay of presumably a few seconds of not having a stream for a device before deleting that device's member state, since it will just be one sync request followed by another rather than, for example, a websocket connection.

[toger5]

This is a list of questions that were not immediately clear to me while reading the msc:
Who would be the sender in the m.call.member state event?
Would it still be possible to update the state event using the regular room state event PUT endpoint?
Can there be any conflicts between manual updates from clients and updating the room state using the proposed endpoint. If so would it make sense to mention, that the homeserver has to reject any manual state update using m.call.member ?

[axelsimon]

This looks straightforward enough, but we might want to consider more in detail what happens if a homeserver goes offline, as this could easily become a large issue in P2P Matrix.

[toger5]

Reding through this again I think the scope of this MSC should be bigger.
Introducing new endpoints for updating the membership, allows us to never grant any user permission to update m.call.member state events. Instead the HS will update those using the additional endpoints.
This frees us from the necassity of using the key = user_id permission system.

We could use keys of the format: $user_id/$device_id which are all handled by the HS.
This would make things much more efficient/simple (especially considering aggreagting sessions), since we dont update the whole state event with multiple memberships anymore but instead only update the data that is actually assocaited with the membership.

[toger5]

Even closer would be the SFU itself.
What do you think about the following idea:
The homeserver issues a token to update the memberships for one membership id. The client can then share this token with the SFU or hold it to itself.
In case its shared with the sfu, the sfu will update the homeserver on any membership changes (disconnects).

For the fullmesh case the client keeps the token to itself and uses it directly to disconnect.

If the client disconnects from the homeserver directly the homeserver will disconnect this participant independent of whether an explicit disconnect was sent.
(With the rational that a matrixRTC session only works if the user is also connected to matrix: for crypto and other matrixRTC applications that rely on both: matrix + matrixRTC updates at to work properly)

[anoadragon453]

This may have implications for anyone hoping to run a matrix homeserver in a "serverless" configuration.

[robintown]

This MSC has been replaced by MSC4140: Cancellable delayed events!