Show an error screen when the homeserver is missing MSC4140 support
We could do this to (rather forcefully) nudge homeserver admins to turn on support for delayed events.
This is scoped only to MSC4140, since it is possible to infer via the /versions response whether the homeserver supports this. Detecting support for the other MSCs is not a priority right now because MSC3266 is actively being merged to the spec, and we want to try to push MSC4222 in this same direction as well (too much effort to just detect support for it).
Re MSC4222: making element-call incompatible with spec-compliant homeservers seems like a regrettable choice: are you sure this is the right thing to do, rather than getting the MSC merged? It looks pretty much ready to go to me, other than a couple of minor edits.
Making element-call incompatible with spec-compliant homeservers seems like a regrettable choice: are you sure this is the right thing to do, rather than getting the MSC merged? It looks pretty much ready to go to me, other than a couple of minor edits.
That's a valid point rich. In that context. @erikjohnston what is the status of the state_after MSC?
From a product perspective that feedback is needed to manage expectations. We already get a lot of "bug" reports pointing to stuck-calls.
As for MSC3266, that should already have passed FCP so I think probably all that needs to happen is a PR to synapse to enable it by default?
Previous description with some open questions:
MSCs we do care about are:
experimental_features: # MSC3266: Room summary API. Used for knocking over federation msc3266_enabled: true # MSC4222 needed for syncv2 state_after. This allow clients to # correctly track the state of the room. msc4222_enabled: true # The maximum allowed duration by which sent events can be delayed, as # per MSC4140. max_event_delay_duration: 24hQuestions to answer:
- Given a mismatch in required enabled MSCs do we soft-fail or hard-fail? (thinking of delayed events)
- soft-fail candidates
- For msc3266 this would only affect SPA guest user access.
- hard-fail candidates
- msc4222: hard fail since we can't guarantee proper operation
- btw. can we also check rate limiting client side? or only in case we are running into it?
(Pasting this as I'm going to edit the description now)