|
|
|
@ -1,6 +1,6 @@
|
|
|
|
|
# MSC4140: Expiring events with keep alive endpoint
|
|
|
|
|
|
|
|
|
|
Currently there is not mechanism for a client to provide a reliable way of
|
|
|
|
|
Currently there is no mechanism for a client to provide a reliable way of
|
|
|
|
|
communicating that an event is still valid. The best expiration method is to post
|
|
|
|
|
another event that is stores that it is expired.
|
|
|
|
|
In some situations the client just looses connection or fails to sent the expired
|
|
|
|
@ -121,8 +121,29 @@ the `"will_expire":"running"` events for a specific event type but render the
|
|
|
|
|
|
|
|
|
|
## Alternatives
|
|
|
|
|
|
|
|
|
|
[MSC4018](https://github.com/matrix-org/matrix-spec-proposals/pull/4018) also
|
|
|
|
|
proposes a way to make call memberships reliable. It uses the client sync loop as
|
|
|
|
|
an indicator to determine if the event is expired. Instead of letting the SFU
|
|
|
|
|
inform about the call termination or using the call app ping loop like we propose
|
|
|
|
|
here.
|
|
|
|
|
|
|
|
|
|
## Security considerations
|
|
|
|
|
|
|
|
|
|
We are using unauthenticated endpoint to refresh the expirations. Since we use
|
|
|
|
|
the token it is hard to guess a correct endpoint and randomly end `will_expire`
|
|
|
|
|
events.
|
|
|
|
|
|
|
|
|
|
It is an intentional decision to not provide an endpoint like
|
|
|
|
|
`PUT /_matrix/client/v3/expiration/room/{roomId}/event/{eventId}`
|
|
|
|
|
where any client with access to the room could also `end` or `refresh`
|
|
|
|
|
the expiration. With the token the client sending the event has ownership
|
|
|
|
|
over the expiration and only intentional delegation of that ownership
|
|
|
|
|
(sharing the token) is possible.
|
|
|
|
|
|
|
|
|
|
On the other hand the token makes sure that the instance gets as little
|
|
|
|
|
information about the matrix metadata of the associated `will_expire` event.
|
|
|
|
|
|
|
|
|
|
## Unstable prefix
|
|
|
|
|
|
|
|
|
|
## Dependencies
|
|
|
|
|
|
|
|
|
|