The server reference implementation for the [Matrix](../) protocol is [Synapse](https://github.com/element-hq/synapse).
It's a federated homeserver developed by the Matrix Foundation[^1] and has a
stable and full-featured maturity, which can make it quite resource-intensive.
For running a Matrix server on Raspberry Pi[^2], for example, consider a more
lightweight solution such as Conduit or Dendrite[^3]. The source code of Synapse
is written in Python3/Twisted[^4] and can be found at GitHub.
## Basic setup
The [Synapse — UberLab 7 documentation](https://lab.uberspace.de/guide_synapse)
describes the basic setup at my hosting provider. Other [installation instructions](https://matrix-org.github.io/synapse/latest/setup/installation.html)
are found in the project documentation.
## Delegation
As I want a [user ID](../matrix/#user-id) without a subdomain part I need to use
via a .well-known URI[^5] to get a user ID such as `user:example.org` instead of
`user:matrix.example.org`. Thus, I specify `example.org` as `server_name` at the beginning of the configuration file, but set `public_baseurl` to the subdomain `matrix.example.org`.
For the *.well-known announcement* I create `.well-known/matrix/server` in the
Synapse log configuration file is typically named after the server name with the suffix `.log.config` appended. If I need to investigate errors, I change both
`level` parameters in the *synapse.storage.SQL* subsection below *loggers* and
in the *root* section. Allowed values are `CRITICAL`, `ERROR`, `WARNING`,
`INFO`, and `DEBUG`. The default value is `INFO` as shown in the