Stop using .well-known/matrix/client for client-side configuration settings #2228
Description
Some clients currently use the .well-known/matrix/client file to allow homeserver admins to set certain client-side options. For example, Element Web exposes a number of configuration options: https://github.com/element-hq/element-meta/blob/develop/docs/client_well_known.md.
This is problematic, for a couple of reasons:
- In practice, the people running the Matrix server and the people running the frontend domain may be entirely different; in many organisations, getting a file hosted on the top-level domain to be updated can be prohibitively difficult or even impossible.
- Even if it is organisationally possible, it makes deployment unnecessarily complicated/difficult by separating configuration that would naturally be part of the homeserver to a completely different server.
- The need to serve a file on the MXID domain may require a web server to be hosted on a domain that would not otherwise need one (thanks to SRV delegation). Deploying a web server can be surprisingly onerous in configurations such as Kubernetes clusters.
- It leads to considerable confusion about how best to implement this in clients, particularly if the user logs in by providing the CS-API address rather than a complete MXID. Specifically, should the client look up the .well-known file on the CS-API or on the MXID domain? Presumably, on the MXID domain, but that's not specified. Essentially, the spec doesn't allow for any use of
.well-known/matrix/clientexcept for endpoint discovery before login.
We should stop doing this, and instead provide a mechanism by which clients can discover configuration information via the C-S API.