tree c7244a77b32920784046b54034198b1a1dde26e6
parent de6275101bcf9201061491831cb869f82270eeda
author Serge Bazanski <q3k@hackerspace.pl> 1598465436 +0000
committer Serge Bazanski <q3k@hackerspace.pl> 1598465436 +0000

matrix: fix iOS signup issues by specifying public_baseurl

WHITE
WHALE
HOLY
GRAIL

Complex systems are complex. Let me tell you a story about that.

Matrix clients perform their last stage of login by performing a POST to
/_matrix/client/r0/login on the Matrix homeserver they log in to. How
they reach the Homeserver is specified earlier - either by using
discovery via SRV or .well-known, or by the client manually specifying
the Matrix homeserver URL.

Regardless of how they reach this endpoint in the first place, this POST
endpoint, as per the Matrix Client-Server API Specification (r0.6.1),
MAY return a `well_known` key, which MUST contain a `homeserver`
address, pointing to the address of the homeserver which the client
should talk to. If present, the client SHOULD use that instead of
whatever it connected to so far.

Issue the first: the iOS client requires `well_known` in that response,
and doesn't work otherwise. https://github.com/vector-im/element-ios/issues/3448

Issue the second: Synapse will return `well_known` accordingly, but only
if `public_baseurl` is set in its configuration. It is not required to
be set. If not set, it will simply not return this key.

Shrek the third: we never set `public_baseurl` in Synapse, and the first
issue (iOS needing `well_known`) only became a regression in
https://github.com/vector-im/element-ios/issues/2715 . As such, it was
difficult to troubleshoot this issue, and we kept getting on some red
herrings: is it the SSO? Is our server broken? Is the iOS implementation
broken?

But now we know - https://github.com/vector-im/element-ios/issues/2715
seems to be the true culprit.

Change-Id: I913792e31e3c6813d4e51d4befdba720cad3f532