The domain part of all Matrix user IDs at Librem Chat’s homeserver is librem.one, but the actual hostname of the homeserver is chat.librem.one instead. Therefore, the “Server Discovery” feature of Matrix is necessary for both clients and other homeservers to be able to find the correct hostname of any Librem Chat user’s homeserver.
Currently, there is an SRV record named _matrix._tcp.librem.one present in the DNS, and its target is chat.librem.one. This makes the Server Discovery feature work correctly for other homeservers federating with Librem Chat’s homeserver, according to the “Resolving server names” section (i.e. section 2.1) of Matrix’s Server-Server API specification.
By contrast with the Server-Server API, though, the “Server Discovery” section (i.e. section 3) of Matrix’s Client-Server API specification does not say that Matrix clients should use DNS SRV records for server-discovery purposes. (In fact, the Client-Server API specification doesn’t mention SRV records at all.) Instead, it says that the /.well-known/matrix/client Well-Known URI should be used for client-to-server Server Discovery instead.
However, the web server at librem.one isn’t hosting anything at its /.well-known/matrix/client URL – i.e. you’ll currently get a 404 Not Found error if you try to retrieve that URL. Consequently, it’s not possible for a Librem Chat user to log in using many/most Matrix client apps unless they manually enter in both their user ID (whose domain part is librem.one) and the chat.librem.one hostname separately; otherwise, they’ll get an error message, because the client will try to use librem.one (instead of chat.librem.one) as the hostname of the homeserver.
(For example, nheko will give an error message that says "The required endpoints were not found. Possibly not a Matrix server. in this scenario, and then will need to manually enter chat.librem.one into the “Hostname” field on the login screen in order to log in successfully. Similarly, in SchildiChat, the user will not be able to log in to Librem Chat using the “Sign in with Matrix ID” option on the login screen; they’ll need to use the “Custom server” option instead.)
Also, the web server at librem.one isn’t hosting anything at its /.well-known/matrix/server Well-Known URI for server-discovery by other homeservers that’s specified in the aforementioned part of Matrix’s Server-Server API specification as an alternative to the use of a DNS SRV record. This currently doesn’t cause any problems (because in the absence of that Well-Known URI, homeservers will “fall back” to using the DNS SRV record for server-discovery instead), but someone in nheko’s issue tracker warned that “Matrix Spec may be removing the entire SRV support” in the future (see MSC3922 – i.e. pull-request 3922 in the matrix-org/matrix-spec-proposals repo on GitHub – for more details about this).
(Incidentally, the webserver at chat.librem.one actually does host the correct JSON data for server discovery at its /.well-known/matrix/client URL. But, because the domain part of all Matrix user IDs at Librem Chat’s homeserver is librem.one rather than chat.librem.one, that URL won’t be used by a Matrix client when a user whose user ID’s domain is librem.one tries to log in.)