Website/content/docs/infrastructure/matrix/synapse.md

---
title: 'Synapse'
date: 2024-02-25T11:55:11+01:00
draft: true
---

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.

[^1]: [About Matrix](https://matrix.org/foundation) website
[^2]: [Raspberry Pi](https://en.wikipedia.org/wiki/Raspberry_Pi) in the
Wikipedia
[^3]: [Conduit](https://conduit.rs) and [Dendrite](https://github.com/matrix-org/dendrite) projects
[^4]: [Twisted](https://en.wikipedia.org/wiki/Twisted_(software)) in the
Wikipedia

## 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
[delegation](https://github.com/matrix-org/synapse/blob/master/docs/delegate.md)
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 
[Document_Root](https://httpd.apache.org/docs/trunk/mod/core.html#documentroot)
of my webserver containing:

```json {filename="server"}
{
    "m.server": "matrix.example.org:443"
}
```

[^5]: [Well-known URI](https://spec.matrix.org/latest/client-server-api/#well-known-uri)
in the Matrix specification

{{< callout type="info" >}}
  If you're running [Nextcloud](../../nextcloud) in the Document_Root, its
  `.htaccess` file needs editing for proper [redirection](#nextcloud_redirects).
{{< /callout >}}

Ultimately, I use the [federation tester](https://federationtester.matrix.org/)
to check my instance.

## Privacy

The default configuration of Synapse isn't aligned to be privacy respecting as
researched by [Libre Monde ASBL](https://github.com/libremonde-org/paper-research-privacy-matrix.org/tree/master/part1),
but there are means to opt-out of statistics and metrics, for example. I refer
to the [config documentation]([documentation](https://matrix-org.github.io/synapse/latest/usage/configuration/config_documentation.html))
and edit the main configuration file `homeserver.yaml` as follows.

### Metrics and stats

I opt-out of metrics and statistics data collection by using the following configuration settings:

```yaml
enable_metrics: false
report_stats: false
```

### Push

When using Push notifications[^6], the message content isn't encrypted. For this 
reason, I create a push section and set `include_content` to `false`.

[^6]: [Push notifications](https://en.wikipedia.org/wiki/Push_technology#Push_notification)
in the Wikipedia

### Profile data

As I don't want my profile information to be visible to the public and shared in
rooms I am invited to before joining them, I change the following settings:

```yaml
require_auth_for_profile_requests: true
limit_profile_requests_to_users_who_share_rooms: true
include_profile_data_on_invite: false
```

## Logging

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
[sample config](https://matrix-org.github.io/synapse/latest/usage/configuration/logging_sample_config.html).

## Known issues

This section is about issues I came accross in relation to the interaction with
other services of my [infrastructure](../../) and documents  **quick and dirty** 
solutions rather than implementing secure and clean code.

### Nextcloud redirects

When using [delegation](#delegation) and running [Nextcloud](../../nextcloud) at
the top-level domain, URL rewriting in `.htaccess` redirects all the traffic for 
documents in the `.well-known` directory to Nextcloud. A solution is to add the 
following [rewrite condition](https://httpd.apache.org/docs/trunk/mod/mod_rewrite.html#rewritecond)
inside the `.htaccess` file in both sections before the rewrite rules:

```
RewriteCond %{REQUEST_URI} !^/\.well-known/matrix/server
```