Matrix Synapse Miscellaneous

Different things, sometimes advanced and some things that just did not fit in the regular guide.

Show the public rooms on the server

Add an SRV Record

To use the domain and still just use instead of we need to set up an SRV record. At first an A (possibly AAAA) record is needed for

After the A record is set up, create a SRV Record that looks like

_matrix._tcp.<> <ttl> IN SRV 10 0 <port> <>

So, for example use 3600 IN SRV 10 0 8448

and when creating the Synapse server use for the servername.


So, when I'm using the domain and want to use for the registration and so on, i should use SRV. If i'm using and making the redirect with nginx, there is no need for a SRV record?


The SRV record is how other servers find your server (and putting matrix federation behind a reverse proxy is a bit fragile)

Mathijs the relevant url is where the federated servers can connect to you


It's so your server_name (what's in MXIDs) doesn't have to be the hostname of the machine synapse is running on.

Example 1 points to the physical machine where synapse is installed and Port 8448 is used.

Example 2 points to the phsycial machine where synapse is installes and port 8448 can not be used.

SRV needed.

Example 3

FIXME point to the physical machine with the URL

SRV needed?


By setting an SRV record in your DNS provider, it is possible to tell other matrix servers where to connect to the server, pointing them to the correct hostname and port, in this example the default port (8448) is still used: 3600 IN SRV 10 5 443

There is still an A record needed, pointing to the IP-addess of synapse on the subdomain ( This way others can add your user with instead of

.well-known section

it's a little early, but you could also add a section about .well-known which just means you have nginx serve a json file on I did it for apache, but it's probably fairly easy for nginx as well

Mathijs if you like reading spec :)

Proper explanation

.well-known will be checked before SRV gets checked.


Coturn is a turn server and it is used for 1:1 voip calls through the client (example: riot).

apt install coturn

Edit Config files

opening ports

Optional Adminshell

If you forgot to write sudo and don't want to rewrite the whole command, just type sudo !! to execute the last command with sudo rights.

There is another way but you should not work like that all the time because its not secure. There is a reason you have to write sudo for a lot of commands. For an initial server setup you may have to type a lot of commands, to avoid typing sudo * all the time, it is possible to type in sudo su. This opens a admin-shell and you should be able to work without typing sudo in. Keep in mind, exit after step 8 and don't use sudo su when you just have to type in some commands.

Synpase maintenance tools

Installing Bots

Matrix Synapse currently does not have a concept of bots, a bot is just a normal user. Usally there is a config and a .py file, download the files, unpack them and run the .py file. Running and downloading things via pip is not recommended.

Install python3

sudo apt install python3

then install pip

sudo apt install python3-pip

then matrix-bot-api from pyp

pip3 install matrix-bot-api

and finally fill out the config and start it


How calls work

Info about WebRTC:
more or less like this? with instead of

more or less, but you can also host your own jitsi server if you want, jitsi is still FOSS and self-hostable

also, it's a bit nitpicky, but if you use turn, you may want to add a turn-server on the left side, because it's not synapse that does the webrtc relay

jitsi is its own thing, riot just allows integrating jitsi in riot

note that you can self-host jitsi, but if you want riot to use your selfhosted jitsi by default when opening conference calls you'll also want to host an integrations server (ie dimension)

everybody assumes it works like this, but it doesn't: assuming both HSs have turn, you actually want red lines via homeserver 1, homeserver 2 and then one going through both ie. the media may go through one or both turn servers (or none, as in your green line) not sure I quite understand the second diagram in the first. media won't always go through both turn servers the key to thinking about turn, I find, is that the TURN server is a thing that essentially pretends to be your client, but somewhere else on the internet and it tunnels the traffic back to you so you have a point of presence with your own internet connection, and then a second point of presence in your turn server once its opened a channel for you and you then present both of those options to ther other side as ways to talk to you equally you can also use your turn server as a route to send packets out to the internet to talk to the other party