Come gestire Matrix Synapse su un VPS

Cosa serve per mantenere operativo un homeserver Matrix Synapse

Matrix Synapse è facile da installare e altrettanto facile da trascurare. L’installazione richiede un repository apt, un file di configurazione, un blocco del reverse proxy e un record DNS. Mantenere integro l’homeserver per un anno richiede attività diverse: un database reale, un media store sottoposto a pruning, una registrazione che gli utenti estranei non possano utilizzare e un backup che includa entrambe le componenti del server.

Questa guida è rivolta a Ubuntu 24.04 LTS e installa Synapse dal repository apt di matrix.org, ovvero la sorgente dei pacchetti gestita dal progetto Synapse per Debian e Ubuntu. Le versioni dei pacchetti cambiano ogni poche settimane, quindi qui non viene indicato alcun numero di versione. Tutti i percorsi e le opzioni riportati di seguito provengono dalla documentazione Synapse corrente.

Dimensionamento: cosa offrono realmente 1 vCPU e 2 GB di RAM

Le pagine di dimensionamento pubblicate, ad agosto 2026, indicano comunemente 1 vCPU e 2 GB di RAM per un homeserver Synapse. Questa configurazione è adeguata in un caso specifico: un server privato, pochi utenti, stanze di piccole dimensioni e nessuna stanza pubblica molto frequentata. La documentazione di Synapse è chiara sull'altro caso. Richiede «almeno 1GB di RAM libera se si vogliono aggiungere stanze pubbliche di grandi dimensioni come #matrix:matrix.org». Si tratta di RAM libera oltre a quella utilizzata da Python, Postgres e dal kernel.

Una singola stanza può modificare il dimensionamento, a causa del funzionamento dell'ingresso nelle stanze. Quando un utente locale entra in una stanza, l'homeserver diventa un partecipante completo di quella stanza. Riceve ogni evento dagli altri server presenti, ne verifica la firma e salva localmente lo stato della stanza. Una stanza pubblica di grandi dimensioni può avere migliaia di membri distribuiti su centinaia di server. Il server esegue quindi continuamente questo lavoro, anche se l'utente non apre più la stanza. Uscire in seguito dalla stanza non elimina la cronologia già salvata.

Gran parte della RAM utilizzata da Synapse è destinata alle cache. La sezione caches contiene un global_factor che ridimensiona tutte le cache contemporaneamente, mentre la variabile d'ambiente SYNAPSE_CACHE_FACTOR imposta lo stesso valore. Aumentare questo valore utilizza più RAM per ridurre le query al database. Ridurlo utilizza più CPU e più risorse di Postgres per risparmiare RAM. Postgres richiede memoria propria, quindi su un server con 2 GB i due componenti competono per gli stessi megabyte.

Per un piano di piccole dimensioni valgono due regole pratiche. Aggiungete lo swap: non renderà Synapse più veloce, ma impedisce al kernel di terminare il processo durante l'ingresso in una stanza di grandi dimensioni. Monitorate il disco fin dalla prima settimana, perché i due elementi che crescono senza un limite sono il media store e le tabelle dello stato delle stanze, ed entrambi risiedono sul disco.

Perché Postgres e perché SQLite non è più un'opzione

Il pacchetto Debian si avvia usando SQLite. Per il primo avvio va bene, ma non è adatto a un server utilizzato da altre persone. SQLite consente un solo writer alla volta. Il traffico di federazione e le richieste dei client scrivono nello stesso momento, quindi una richiesta semplice resta in attesa dietro a un'operazione lenta. Il sintomo segnalato dagli utenti è che l'applicazione si blocca per alcuni secondi, apparentemente in modo casuale.

Il secondo motivo è strutturale. I processi worker di Synapse sono il metodo supportato per utilizzare più di un core della CPU e richiedono Postgres. Restare su SQLite significa rinunciare sia alle prestazioni sia al percorso di aggiornamento.

La migrazione successiva è supportata, ma richiede un periodo di inattività. Eseguila quindi prima di avere utenti. Synapse include synapse_port_db, che copia un database SQLite in un database Postgres preparato:

synapse_port_db --sqlite-database homeserver.db --postgres-config homeserver-postgres.yaml

Se preferisci eseguire il database in un container accanto a Synapse, trovi i relativi compromessi nella configurazione del database in Docker o sull'host.

Installare Synapse su Ubuntu 24.04

sudo apt install -y lsb-release wget apt-transport-https
sudo wget -O /usr/share/keyrings/matrix-org-archive-keyring.gpg https://packages.matrix.org/debian/matrix-org-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/matrix-org-archive-keyring.gpg] https://packages.matrix.org/debian/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/matrix-org.list
sudo apt update
sudo apt install matrix-synapse-py3

Su Ubuntu 24.04 lsb_release -cs restituisce noble e il repository matrix.org pubblica una suite noble. Non usare il pacchetto matrix-synapse dell'archivio Ubuntu. Il progetto Synapse lo sconsiglia perché queste build sono in ritardo rispetto alle sue release e contengono vulnerabilità di sicurezza note.

L'installer chiede il nome del server e scrive la risposta in /etc/matrix-synapse/conf.d/server_name.yaml. Inseriscila con attenzione. server_name è la parte successiva ai due punti in ogni ID utente (@alice:example.com) ed è incorporata in ogni stanza creata dal server. Modificarla in seguito non sposta alcun contenuto: crea un homeserver diverso. Usa il dominio senza sottodominio, example.com, anche quando Synapse viene eseguito su matrix.example.com. La delega collega i due nomi; questo è l'argomento della sezione successiva.

Il pacchetto esegue Synapse con l'utente matrix-synapse, conserva i dati in /var/lib/matrix-synapse e legge /etc/matrix-synapse/homeserver.yaml, seguito da ogni file in /etc/matrix-synapse/conf.d/. Inserisci le tue impostazioni in file di piccole dimensioni in conf.d. Gli aggiornamenti del pacchetto non li modificano.

sudo systemctl restart matrix-synapse
systemctl status matrix-synapse
sudo journalctl -u matrix-synapse -n 100 --no-pager

Un avvio corretto attiva i listener, quindi il servizio non produce più output. L'unità systemd riavvia il servizio alcuni secondi dopo ogni uscita, quindi una configurazione rifiutata da Synapse si manifesta come un'unità che si avvia e termina in un ciclo continuo. Le ultime righe del journal indicano la chiave rifiutata.

Punta Synapse a Postgres

sudo apt install -y postgresql
sudo -u postgres createuser --pwprompt synapse_user
sudo -u postgres createdb --encoding=UTF8 --locale=C --template=template0 --owner=synapse_user synapse

La localizzazione non è un dettaglio estetico. Synapse rifiuta di avviarsi con un database creato usando valori COLLATE e CTYPE diversi, a meno che non si imposti allow_unsafe_locale nella configurazione del database. La procedura di riparazione documentata consiste poi nell'eseguire un dump e ricaricarlo in un database creato correttamente. Crealo correttamente fin dall'inizio.

database:
  name: psycopg2
  txn_limit: 10000
  args:
    user: synapse_user
    password: secretpassword
    dbname: synapse
    host: localhost
    port: 5432
    cp_min: 5
    cp_max: 10

Mantieni esattamente una chiave database: in tutti i file di configurazione. Sostituisci il blocco SQLite all'interno di homeserver.yaml invece di aggiungere una seconda copia sotto conf.d, così non ci saranno dubbi su quale configurazione sia attiva. Riavvia, quindi verifica che Synapse stia realmente usando Postgres:

sudo -u postgres psql synapse -c "SELECT count(*) FROM users;"

Un numero indica che Synapse ha creato lo schema in questo database. Un errore relativo a una relazione mancante indica che sta ancora scrivendo nel file SQLite; quindi la configurazione modificata non è quella che viene letta.

Reverse proxy, TLS e i file .well-known necessari alla federazione

Synapse è in ascolto su HTTP semplice sulla porta 8008, associato a localhost. TLS e la porta pubblica appartengono al reverse proxy che lo precede.

listeners:
- port: 8008
  tls: false
  type: http
  x_forwarded: true
  bind_addresses:
  - '::1'
  - '127.0.0.1'
  resources:
  - names:
    - client
    - federation
    compress: false

x_forwarded: true indica a Synapse di considerare attendibile l'header X-Forwarded-For impostato dal proxy. Senza questa impostazione, ogni client sembra provenire da 127.0.0.1. Il rate limiting rileva quindi un unico utente locale estremamente attivo e applica il throttling a tutti nello stesso modo.

location ~ ^(/_matrix|/_synapse/client) {
    proxy_pass http://localhost:8008;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $host:$server_port;
    client_max_body_size 50M;
    proxy_http_version 1.1;
}

La documentazione di Synapse contiene un'avvertenza su questo blocco che può costare giorni di lavoro. Non aggiungere un percorso, nemmeno un singolo /, dopo la porta in proxy_pass. nginx rende quindi canonico l'URI. Questo modifica i byte firmati dal server mittente e le richieste di federazione non superano la verifica della firma, mentre le normali richieste dei client continuano a funzionare.

client_max_body_size deve essere almeno pari a max_upload_size di Synapse. Se nginx imposta un valore più piccolo, i caricamenti che lo superano vengono rifiutati da nginx con 413 Request Entity Too Large prima che Synapse possa riceverli. Nei log di Synapse non comparirà quindi alcuna riga utile a spiegare il problema.

Per il certificato, segui Certbot e Let's Encrypt su Ubuntu 24.04. Se non hai ancora scelto il proxy, il confronto tra reverse proxy spiega quale soluzione può gestire TLS al posto tuo.

La delega consente a server_name di restare example.com mentre Synapse è in esecuzione su matrix.example.com. Pubblica due file dal dominio principale:

location /.well-known/matrix/server {
    default_type application/json;
    return 200 '{"m.server": "matrix.example.com:443"}';
}

location /.well-known/matrix/client {
    default_type application/json;
    add_header Access-Control-Allow-Origin '*';
    return 200 '{"m.homeserver": {"base_url": "https://matrix.example.com"}}';
}

Il file per i server indica agli altri homeserver dove inviare il traffico di federazione. In questo modo la federazione usa la porta 443 invece della porta predefinita 8448. Il file per i client indica ai client Matrix quale URL gestisce @alice:example.com. L'header Access-Control-Allow-Origin è importante nel file per i client perché i client basati su browser lo recuperano cross-origin. Senza questo header, il browser blocca la risposta e il client segnala di non riuscire a trovare il tuo homeserver.

Entrambi i file devono essere pubblicati tramite TLS valido direttamente da example.com. Verificali, quindi controlla ciò che vede l'esterno:

curl -s https://example.com/.well-known/matrix/server
curl -s https://matrix.example.com/_matrix/federation/v1/version

Il primo comando restituisce il JSON che hai scritto. Il secondo restituisce un oggetto JSON con il nome dell'implementazione del server e la relativa versione. Questo dimostra che il proxy raggiunge Synapse sul percorso di federazione. Infine, verifica il dominio con il Matrix federation tester all'indirizzo https://federationtester.matrix.org, che segue lo stesso percorso usato da un server remoto reale.

Federare o non federare: decidi consapevolmente

La federazione è il motivo per cui esiste Matrix, ma rappresenta anche la maggior parte dei costi. Un homeserver federato accetta connessioni da server che non hai mai sentito nominare, riceve i loro eventi, memorizza nella cache i relativi contenuti multimediali e conserva lo stato di ogni stanza utilizzata dagli utenti. Questa è una decisione relativa al modello di minaccia, non un comportamento predefinito.

Abilita la federazione quando gli utenti devono raggiungere persone su altri homeserver oppure quando l'identità portabile è il motivo per cui hai scelto Matrix. Non abilitarla quando il server serve un solo team e tutti gli account presenti appartengono alla tua organizzazione. Un server chiuso memorizza meno dati, ne riceve meno e risulta molto meno interessante per gli abusi.

Per limitare la federazione invece di disabilitarla, Synapse utilizza una lista di autorizzazione:

federation_domain_whitelist:
- lon.example.com
- nyc.example.com

La documentazione consiglia inoltre di filtrare tramite firewall il listener della federazione, in modo che il traffico indesiderato venga bloccato a livello di rete anziché all'interno di Python. Per disabilitare completamente la federazione, rimuovi federation dall'elenco resources del listener, non pubblicare /.well-known/matrix/server e lascia chiusa la porta 8448.

Se il motivo per cui esegui Matrix era la chat privata del team e la federazione non ne ha mai fatto parte, confronta i costi operativi con le altre alternative self-hosted a Slack prima di scegliere Synapse. Rocket.Chat con Docker Compose gestisce la chat del team su una macchina più piccola, perché non deve mai memorizzare lo stato delle stanze di un'altra organizzazione.

Il repository multimediale riempie il disco senza attirare l'attenzione

I file caricati dai propri utenti restano permanentemente sul disco. I file pubblicati dagli utenti di altri homeserver vengono scaricati e memorizzati nella cache del disco non appena uno dei propri client li visualizza. Synapse genera inoltre miniature per le immagini, quindi una foto diventa più file. Per impostazione predefinita, nessuno di questi file scade.

Individuare il percorso e misurarne l'utilizzo:

grep media_store_path /etc/matrix-synapse/homeserver.yaml
sudo du -sh /var/lib/matrix-synapse/media_store

Misurare il percorso stampato dalla propria configurazione. Il pacchetto Debian mantiene i dati di Synapse in /var/lib/matrix-synapse, quindi normalmente il repository si trova lì. Impostare quindi una policy di conservazione in conf.d:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

Leggere attentamente queste due righe, perché non definiscono lo stesso tipo di impostazione. remote_media_lifetime applica una scadenza alla cache. I file eliminati possono essere scaricati di nuovo dal server che li gestisce. local_media_lifetime elimina definitivamente i caricamenti dei propri utenti quando raggiungono quell'età. Un team che condivide documenti nella chat e si aspetta di ritrovarli l'anno successivo li perderà. Molti server impostano soltanto il valore relativo ai contenuti remoti.

Per una pulizia una tantum, l'API di amministrazione richiede un timestamp Unix espresso in millisecondi:

BEFORE_TS=$(date -d '30 days ago' +%s%3N)
curl -X POST -H "Authorization: Bearer $ADMIN_TOKEN" \
  "https://matrix.example.com/_synapse/admin/v1/purge_media_cache?before_ts=$BEFORE_TS"

POST /_synapse/admin/v1/purge_media_cache elimina i contenuti multimediali remoti memorizzati nella cache e consultati l'ultima volta prima di quel timestamp. POST /_synapse/admin/v1/media/delete?before_ts=<ms> elimina i contenuti multimediali locali secondo la stessa regola. Eseguire prima la pulizia dei contenuti remoti e misurare di nuovo, perché su un server federato la cache remota è solitamente la parte più grande.

Due impostazioni contribuiscono allo stesso consumo di disco. max_upload_size limita la dimensione di un singolo caricamento e deve essere coerente con client_max_body_size in nginx. url_preview_enabled: true fa sì che il server scarichi le pagine remote per consentire ai client di visualizzare le anteprime dei collegamenti. Questo consuma banda e memorizza miniature di contenuti che nessuno ha caricato sul server.

Chiudi la registrazione prima che qualcuno trovi il tuo homeserver

Gli scanner individuano un homeserver aperto nel giro di pochi giorni. Quando la creazione degli account è libera, il server diventa una fonte di spam in ogni stanza con cui effettua la federazione e gli amministratori dall'altra parte bloccano l'intero dominio. Questo danno alla reputazione persiste anche dopo la bonifica, perché le blocklist vengono gestite manualmente.

Synapse viene distribuito con la registrazione disabilitata. enable_registration è impostato per impostazione predefinita su false e registration_requires_token è impostato per impostazione predefinita su false. Synapse rifiuta inoltre di avviarsi con la registrazione abilitata e senza una procedura di verifica, a meno che non si imposti anche enable_registration_without_verification: true. Questo rifiuto è intenzionale, quindi non abilitarla soltanto per eliminare un errore di avvio.

Crea manualmente gli account desiderati:

sudo register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml http://localhost:8008

Il comando richiede il nome utente, la password e l'indicazione che specifica se l'account è un amministratore del server. Legge registration_shared_secret dalla configurazione passata con -c. Se segnala di non trovare un secret condiviso, indica con -c il file che lo contiene.

Quando la creazione manuale degli account non è più scalabile, i token di registrazione rappresentano una soluzione intermedia. Un token è una stringa che il nuovo utente deve presentare durante la registrazione. Ogni token può includere un limite al numero di utilizzi:

enable_registration: true
registration_requires_token: true

curl -X POST -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"uses_allowed": 1}' \
  https://matrix.example.com/_synapse/admin/v1/registration_tokens/new

Se ometti token dal corpo della richiesta, Synapse ne genera uno e lo restituisce. GET /_synapse/admin/v1/registration_tokens elenca i token ancora attivi. Entrambe le chiamate richiedono l'access token di un account amministratore del server, ottenuto effettuando l'accesso con l'utente amministratore creato in precedenza.

Un'organizzazione che gestisce già gli account altrove può evitare del tutto le password locali, perché Synapse può delegare l'accesso a un provider OIDC (OpenID Connect), ad esempio Authentik come provider SSO self-hosted. La gestione degli ingressi e delle uscite avviene quindi in un unico punto.

Un backup che può ricostruire davvero il server

Un backup di Synapse ha tre componenti. Se ne manca anche solo una, il ripristino produce un server che nessuno può utilizzare.

• Il database PostgreSQL, che contiene ogni evento, account e stanza.
• La directory del media store, che contiene ogni file caricato.
• /etc/matrix-synapse, che contiene la configurazione e la signing key del server.

La signing key è l'elemento che viene dimenticato più spesso. È la chiave privata con cui il homeserver firma gli eventi. I server remoti verificano gli eventi usando la chiave pubblica corrispondente. Esegui grep signing_key_path /etc/matrix-synapse/homeserver.yaml per vedere dove si trova la tua. Se la perdi, ripristini un server che non può dimostrare di essere lo stesso server già noto alle tue stanze.

sudo -u postgres pg_dump --format=custom --file=/var/backups/synapse-$(date +%F).dump synapse
sudo tar czf /var/backups/synapse-etc-$(date +%F).tgz -C /etc matrix-synapse

Scarica prima il database, quindi copia il media store. I file multimediali vengono scritti una sola volta e referenziati tramite ID. Una copia del media store eseguita dopo il dump può quindi contenere soltanto file aggiuntivi, mai file mancanti. Con l'ordine inverso, il database ripristinato potrebbe puntare a un file che il backup non ha acquisito.

Trasferisci tutte e tre le componenti fuori dal VPS. snapshot off-site con restic è adatto a questo scenario, perché il media store è la parte più grande e cambia poco tra un'esecuzione e l'altra. La deduplicazione mantiene quindi ridotte le dimensioni di ogni snapshot.

Poi prova il ripristino, perché un backup che non hai mai ripristinato è soltanto un'ipotesi. Crea un secondo VPS, installa lo stesso pacchetto, ripristina la configurazione, crea il database con la stessa codifica e la stessa locale, pg_restore il dump al suo interno, ricopia il media store e accedi. Annota il tempo impiegato. Questo è il tuo tempo effettivo di ripristino.

Quando le tabelle dello stato crescono: compattazione

Synapse memorizza lo stato delle room come gruppi di stato e, su un server federato, state_groups_state diventa spesso l'oggetto più grande del database. Misura prima di modificare qualsiasi cosa:

sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_database_size('synapse'));"
sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_total_relation_size('state_groups_state'));"

Se questa tabella rappresenta la maggior parte del database, il progetto mette a disposizione un compressore per questa tabella, rust-synapse-compress-state, che riscrive la gerarchia dei gruppi di stato in un numero inferiore di righe senza modificare il significato dello stato di alcuna room. È realizzato in Rust:

sudo apt install -y build-essential libssl-dev pkg-config git
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
git clone https://github.com/matrix-org/rust-synapse-compress-state.git
cd rust-synapse-compress-state/synapse_auto_compressor
cargo build --release

./target/release/synapse_auto_compressor -p postgresql://synapse_user:secretpassword@localhost/synapse -c 500 -n 100

-c indica il numero di gruppi di stato elaborati contemporaneamente e -n indica quanti di questi blocchi vengono elaborati da questa esecuzione. Il compressore automatico registra il punto raggiunto, quindi l'esecuzione successiva riprende da lì. Per questo può essere pianificato in modo sicuro. La documentazione specifica che le modifiche vengono applicate all'interno di transazioni sulle tabelle append-only, quindi il compressore può essere eseguito mentre Synapse è attivo. Esegui comunque un backup del database prima della prima esecuzione.

Un dettaglio di Postgres sorprende spesso. L'eliminazione delle righe restituisce lo spazio a Postgres per il riutilizzo, non al file system. Per questo df potrebbe non ridursi affatto dopo una compattazione significativa. VACUUM FULL restituisce lo spazio al file system e richiede un lock esclusivo sulla tabella, oltre a spazio libero su disco all'incirca pari alle dimensioni della tabella. Pianificalo quindi come attività di manutenzione, invece di eseguirlo senza una pianificazione.

Controlli che indicano che il server è integro

systemctl status matrix-synapse
curl -s https://example.com/.well-known/matrix/server
curl -s https://matrix.example.com/_matrix/federation/v1/version
sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_database_size('synapse'));"
sudo du -sh /var/lib/matrix-synapse/media_store

Un server è integro quando l'unità è attiva e non viene riavviata, il file di delega restituisce il valore m.server, l'endpoint della versione della federazione restituisce JSON e i due valori delle dimensioni possono essere confrontati con quelli del mese scorso. I controlli sulle dimensioni sono quelli che spesso vengono saltati. Lo spazio su disco è la causa di un arresto di Synapse senza preavviso: quando un volume è pieno, PostgreSQL non può più scrivere e Synapse fallisce ogni richiesta che accede al database.

FAQ

Quanta RAM richiede un server Matrix Synapse?

Per un homeserver privato con pochi utenti, stanze di piccole dimensioni e nessuna stanza pubblica molto grande, 2 GB sono sufficienti. È la dimensione consigliata dalla maggior parte delle guide pubblicate ad agosto 2026. La documentazione di Synapse richiede almeno 1 GB di RAM libera aggiuntiva se gli utenti devono partecipare a stanze pubbliche grandi come #matrix:matrix.org, perché il server memorizza lo stato della stanza ed elabora continuamente il relativo traffico. Aggiungi lo swap con un piano da 2 GB, in modo che una singola partecipazione a una stanza grande non faccia terminare il processo dal kernel.

Devo usare PostgreSQL invece di SQLite?

Oltre pochi utenti, sì. SQLite consente un solo writer alla volta, quindi sotto carico il traffico di federazione e le richieste dei client si bloccano a vicenda e le richieste rimangono in attesa per diversi secondi. I processi worker di Synapse, il metodo supportato per utilizzare più di un core della CPU, richiedono Postgres. La migrazione successiva è possibile con synapse_port_db e richiede un periodo di inattività, quindi crea il database con --encoding=UTF8 --locale=C --template=template0 prima di aggiungere utenti.

Perché l'uso del disco di Synapse continua a crescere?

Una directory e una tabella. Il media store conserva ogni file caricato nelle stanze in cui è presente il server, comprese le copie memorizzate nella cache dei media degli utenti remoti e le anteprime generate. Nulla scade finché non imposti media_retention. La tabella state_groups_state cresce con lo stato delle stanze su un server federato, mentre rust-synapse-compress-state ne riduce le dimensioni. Misura entrambi con du -sh sul tuo media_store_path e con SELECT pg_size_pretty(pg_total_relation_size('state_groups_state'));, prima di decidere su quale intervenire.

Come impedisco a utenti sconosciuti di registrarsi sul mio homeserver?

Lascia enable_registration al valore predefinito false e crea gli account con register_new_matrix_user. Quando questo metodo non sarà più sufficiente, imposta enable_registration: true insieme a registration_requires_token: true e distribuisci i token creati tramite POST /_synapse/admin/v1/registration_tokens/new. Non impostare enable_registration_without_verification: true soltanto per evitare il rifiuto dell'avvio da parte di Synapse, perché un homeserver aperto diventa una fonte di spam e gli altri amministratori reagiscono bloccando l'intero dominio.

Il mio homeserver deve federarsi?

La federazione è una scelta relativa all'esposizione del server, non un'impostazione predefinita. Abilita la federazione se gli utenti devono raggiungere persone su altri homeserver. Disabilitala se il server serve un solo team, perché un server non federato memorizza meno dati, riceve meno traffico e attira molti meno abusi. In una situazione intermedia, federation_domain_whitelist limita la federazione ai domini partner indicati. La documentazione di Synapse consiglia inoltre di filtrare con il firewall il listener della federazione, invece di affidarsi soltanto a questo controllo a livello applicativo.