content/posts/matrix-delegation/index.md

   1 ---
   2 title: "Matrix delegation and how it may bite you"
   3 date: 2024-01-14T11:19:48+01:00
   4 ---
   5 For those who don't know, delegation in Matrix is used in server-to-server
   6 communication to figure out which server serves a given domain. As an example,
   7 if my own Matrix homeserver was running on `matrix.dujemihanovic.xyz` instead of
   8 `dujemihanovic.xyz`, I could delegate the latter to the former to save anyone
   9 wanting to contact me from having to type out the `matrix.`.
  10
  11 Besides domain name, delegation can also be used to specify which port to use
  12 for server-to-server communication. The default is `8448`, and if it's blocked
  13 you can use delegation to use `443` for server-to-server as client-to-server
  14 does by default. However, if you can, **I'd strongly suggest using `8448`!** I had
  15 been delegating S2S to `443` almost the whole time I have had this server for no
  16 reason and it seems that this caused an extremely weird issue with a certain
  17 room:
  18
  19 ## What happened?
  20
  21 Message fetching kept breaking **constantly**. What I mean by that is that when
  22 I joined the room everything would work fine the first few messages, but at some
  23 point I would start getting notifications without any new message being present
  24 in that room. I have noticed that logging out and back in would get the missing
  25 messages in my client, but then the forementioned cycle would repeat again no
  26 matter how many times I logged out and back in *(this also happened on other
  27 clients besides Element desktop)*. To confirm my homeserver was the issue, I
  28 joined the room with my old matrix.org account and sure enough that worked just
  29 fine.
  30
  31 I tried the usual things such as restarting Dendrite and the whole VPS, but to
  32 no avail. I was pretty insistent that the issue was not with my homeserver but
  33 the main server hosting the room *(which, unsurprisingly, turned out to be
  34 false)* and so I gave up on that. The eyeopening moment was me reading the
  35 [conduit
  36 documentation](https://gitlab.com/famedly/conduit/-/blob/next/DEPLOY.md) *(I had
  37 considered migrating to it)*, specifically this:
  38
  39 > If Conduit runs behind Cloudflare reverse proxy, which doesn't support port
  40 > 8448 on free plans,
  41
  42 This implies that routing server-to-server traffic to `443` should only be done
  43 if it's **absolutely impossible** to use `8448` for this, and the [Synapse
  44 documentation](https://matrix-org.github.io/synapse/latest/delegate.html#when-do-i-need-delegation)
  45 said something similar:
  46
  47 > **However**, if your homeserver's APIs aren't accessible on port 8448 and on
  48 > the domain server_name points to, you will need to let other servers know how
  49 > to find it using delegation.
  50
  51 ## Fixing the issue
  52
  53 Encouraged by this, I fixed up my server:
  54
  55 * allow port `8448` in `ufw`
  56 * add something like this to `Caddyfile`:
  57 ```
  58 dujemihanovic.xyz:8448 {
  59         reverse_proxy /_matrix/* localhost:8008
  60 }
  61 ```
  62 * change `/.well-known/matrix/server` to point to `dujemihanovic.xyz:8448` *(in
  63   theory, I could have gotten rid of that `return` directive altogether as
  64   `8448` is default anyway, but I still chose to specify it just to be safe)*
  65 * reload `caddy` and restart `dendrite` *(the latter is, again, just to be
  66   safe)*
  67
  68 Once all this was done, the room finally started acting normally.
  69
  70 ## Small sidenote
  71
  72 I must note that delegating federation to `443` **should not cause breakage like
  73 this**. Despite this, it still did so in my case and for that reason I wrote
  74 about it anyway. It's very unlikely that you will be affected by this issue, but
  75 I still believe it should be pointed out in the event that it does.