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
1 file changed
tree: c7244a77b32920784046b54034198b1a1dde26e6
  1. app/
  2. bgpwtf/
  3. bzl/
  4. cluster/
  5. dc/
  6. devtools/
  7. doc/
  8. games/
  9. gcp/
  10. go/
  11. hswaw/
  12. kube/
  13. ops/
  14. personal/
  15. third_party/
  16. tools/
  17. .bazelrc
  18. .gitignore
  19. BUILD
  20. COPYING
  21. env.fish
  22. env.sh
  23. hackdoc.toml
  24. OWNERS
  25. README.md
  26. WORKSPACE
README.md

hscloud is the main monorepo of the Warsaw Hackerspace infrastructure code.

Any time you see a //path/like/this, it refers to the root of hscloud, ie. the path path/like/this in this repository. Perforce and/or Bazel users should feel right at home.

Viewing this documentation

For a pleaseant web viewing experience, see this documentation in hackdoc. This will allow you to read this markdown file (and others) in a pretty, linkable view.

Getting started

See //doc/codelabs for tutorials on how to use hscloud.

If you want to browse the source of hscloud in a web browser, use cs.hackerspace.pl.

If you want some other help, talk to q3k, informatic or your therapist.

Directory Structure

Directories you should care about:

  • app: external services that we host that are somewhat universal: matrix, covid-formity, etc.
  • bgpwtf: code related to our little ISP
  • cluster: code related to our Kubernetes cluster (k0.hswaw.net)
  • dc: code related to datacenter automation
  • devtools: code related to developer tooling, like gerrit or hackdoc
  • doc: high-level documentation that doesn't fit anywhere else, ie. codelabs
  • hswaw: Warsaw Hackerspace specific/internal services. The line between this and app is unfortunately blurry.
  • personal: user's personal (experimental) directories
  • kube, go: code specific to languages but general to the whole of hscloud

Licensing

Unless noted otherwise, code in hscloud is licensed under the BSD 0-clause license - see COPYING.