"Your server lacks native support" for Sliding Sync, even though it's supported

[spantaleev]

Steps to reproduce

1. Go to Settings -> Labs and try to enable Sliding Sync

Outcome

What did you expect?

I expected that Element would read my /.well-known/matrix/client file, would inspect org.matrix.msc3575.proxy (which is currently pointed to sliding-sync at https://matrix.DOMAIN/sliding-sync) and would autoconfigure the Proxy URL.

Sliding-sync works and Element X (iOS) has no problem with it.

What happened instead?

It seems like Element made a POST request to /_matrix/client/unstable/org.matrix.msc3575/sync and hit a 404 not found error.

The "Sliding Sync configuration" modal told me:

Your server lacks native support.

If "native support" means natively supported by the homeserver (Synapse), then.. I don't have that. Only Conduit seems to supports it natively (at least to some extent). From that standpoint, I suppose the "Your server lacks native support" message is correct - it's not natively supported.

Still, my server advertises a Proxy URL via org.matrix.msc3575.proxy in /.well-known/matrix/client. An HTTP request for /.well-known/matrix/client is made initially (when element-web loads for the first time), but never again later. The org.matrix.msc3575.proxy information it found there was up-to-date even during initial-page-load, so should it wish to use it, it's valid.

Trying to enter the URL manually (https://matrix.DOMAIN/sliding-sync) shows another error message:

proxyCheckFailed: client using https://matrix.DOMAIN but server is as http://matrix-synapse-reverse-proxy-companion:8008

Yes, indeed https://matrix.DOMAIN/sliding-sync/client/server.json says:

{"server":"http://matrix-synapse-reverse-proxy-companion:8008","version":"0.99.15 (bbb886e)"}

.. because, for efficiency reasons, sliding-sync communicates with the homeserver over the local container network for this matrix-docker-ansible-deploy setup.

In matrix-org/sliding-sync#386, I aimed to introduce one more environment variable to sliding-sync, so that the server URL that it uses internally and the server URL it reports in the server field at /sliding-sync/client/server.json can be different.

The sliding-sync PR got rejected, stating that Element web shouldn't be hitting /sliding-sync/client/server.json at all and that Element-web is now fixed. I (and others affected by this problem) were wondering which PR/commit in element-web/matrix-react-sdk fixed it, but never found it. Judging by my experience with the brand new Element-web 1.11.57, it seems like the issue is not fixed. Element-web is still hitting /sliding-sync/client/server.json and complaining about the server URL mismatch.

I'm also observing that Element-web is hitting /sliding-sync/client/server.json twice - once after pasting the URL into the textbox and once again onBlur, even though the value remains the same. This minor inefficiency probably doesn't matter though and I suppose element-web should indeed never even try to make that network request and should just configure itself with the value I pasted, instead of trying to be smart.

Moreover, it should read org.matrix.msc3575.proxy from the /.well-known/matrix/client file like it claims it does in #22264 (and possibly in matrix-org/matrix-react-sdk#8328) and should not even ask me to configure the Proxy URL manually.

Operating system

No response

Browser information

No response

URL for webapp

No response

Application version

Element version: 1.11.57, Crypto version: Olm 3.2.15

Homeserver

Synapse 1.100

Will you send logs?

No

[t3chguy]

#22264 tracks the need to read the well-known. Closing in favour of that, same as #26807

The sliding-sync PR got rejected, stating that Element web shouldn't be hitting /sliding-sync/client/server.json at all and that Element-web is now fixed.

The config check was written by the guy who maintains the proxy 🤷

[morguldir]

I don't think they meant it had been fixed in Element Web, just that it isn't necessary to check anymore, since you go from server well-known -> client.json. Since Element Web doesn't support well-known, it goes from user -> sliding-sync/server.json -> homeserver, as you can see there is one stage for the server, and one stage for the proxy here.

Element Web shouldn't simply remove the server check, as that would probably lead to other issues like it sending secrets to whatever you enter into the text box. I would suggest using a public url for SYNCV3_SERVER for now and make the public url go through the container network instead (host file, dns, etc), as it's hard to tell when the well-known check will be added in Element Web