Self-Hosting di un Server Matrix

Ti metti a fare self-hosting di Matrix per impedire a un'azienda di conservare le tue conversazioni, e su questo punto funziona esattamente come promesso. Quello che sorprende dopo è la forma di ciò che hai installato: un homeserver non è una scatola privata che per caso parla di chat. È un nodo di replica in una rete pubblica, e la federazione si comporta molto più come un protocollo di pubblicazione di quanto la maggior parte dei nuovi amministratori si aspetti.

Niente di tutto ciò è un argomento contro il gestirne uno — è l'argomento per gestirne uno deliberatamente. La privacy che guadagni è reale ma specifica: la custodia passa a te, l'account non può essere chiuso da qualcun altro, e le questioni legali finiscono in una giurisdizione che hai scelto tu, non una scelta fatta da un'azienda. La privacy che non guadagni è altrettanto specifica, e vive quasi tutta nel divario tra "i messaggi sono cifrati" e "nessuno può dire chi sta parlando con chi". Questa guida copre entrambe le metà, poi i dettagli operativi che decidono se il server sarà ancora sano tra un anno.

Cosa cambia davvero gestire il proprio homeserver

Comincia separando le minacce, perché un homeserver ne risolve alcune completamente, altre in parte, altre per niente. La tabella qui sotto è la versione onesta del discorso, e vale la pena leggerla prima di scegliere l'hardware, non dopo.

Leggi con attenzione le ultime due righe, perché è lì che le aspettative si rompono. Se il tuo obiettivo è che nessuno possa stabilire che un servizio esiste, Matrix è lo strumento sbagliato e un servizio onion è più vicino a quello giusto. Se il tuo obiettivo è custodia, controllo e giurisdizione, un homeserver è uno strumento eccellente e il resto di questa guida parla di come gestirlo bene.

La federazione è un protocollo di replica travestito da protocollo di chat

Ecco il meccanismo che spiega la maggior parte delle sorprese. Quando uno dei tuoi utenti entra in una stanza ospitata altrove, il tuo server non recupera i messaggi su richiesta come un client di posta. Entra nella stanza come partecipante in un grafo di eventi distribuito, poi scarica e conserva una copia degli eventi della stanza, della sua composizione e di abbastanza cronologia di stato da convalidare ciò che segue. Da quel momento la tua macchina detiene una replica, e ogni altro server partecipante ne detiene una a sua volta.

Le conseguenze vanno in entrambe le direzioni e nessuna delle due è intuitiva. I dati generati dai tuoi utenti — nome visualizzato, avatar, ingressi e uscite, timestamp, reazioni — vengono copiati su ogni server che ha un membro in quella stanza, e restano nei loro database indipendentemente da cosa elimini in seguito sul tuo. La redazione è una richiesta ai peer, non un comando. Non esiste un "annulla invio" attraverso una federazione di server gestiti indipendentemente, e aspettarselo è il fraintendimento più comune sul protocollo.

Nell'altra direzione, unirsi a grandi stanze pubbliche significa importare sul tuo disco la cronologia di altre persone. Ecco perché un homeserver nuovo di zecca con tre utenti può portarsi dietro decine di gigabyte di database: non perché i tuoi tre utenti abbiano scritto molto, ma perché si sono uniti a stanze con cinquantamila membri e anni di stato. Scegliere le stanze con attenzione è una decisione di capacità tanto quanto di privacy.

Cosa copre la crittografia, e cosa resta in chiaro

Matrix cifra il contenuto dei messaggi con Megolm, e nelle stanze private è attiva per impostazione predefinita. Questo protegge la parte a cui le persone tengono di più e funziona davvero — il tuo server conserva testo cifrato che non può leggere, il che è una proprietà reale e utile quando il server è hardware noleggiato. La busta attorno al messaggio è tutta un'altra storia, e il divario è più ampio di quanto ammettano la maggior parte dei riassunti.

La lettura pratica: la crittografia protegge il cosa, la federazione pubblica il chi, quando e con quale frequenza. Per la maggior parte delle comunità questo compromesso è del tutto accettabile e l'onestà è il punto. Per un modello di minaccia in cui il grafo sociale stesso è la parte sensibile, un protocollo federato è strutturalmente la forma sbagliata, e nessuna opzione di configurazione lo cambia.

Synapse, Dendrite o Conduit: cosa usare davvero

In pratica contano tre implementazioni, e la scelta è soprattutto una decisione di risorse più che filosofica.

• Synapse è il server di riferimento, scritto in Python, e l'unico dove ogni funzione funziona fin dal primo giorno. È anche il più esigente: la memoria cresce con il numero e la dimensione delle stanze a cui si uniscono i tuoi utenti, e un server trafficato prima o poi va diviso in processi worker. Scegli questo quando ti serve che spazi, strumenti di moderazione, bridge e API di amministrazione si comportino esattamente come documentato.
• Dendrite è la riscrittura in Go. Sensibilmente più leggero di Synapse e perfettamente usabile per un piccolo server, al costo di qualche ritardo nelle funzionalità. Un'opzione intermedia ragionevole quando Synapse ti sembra pesante per il numero di persone che hai davvero.
• Conduit e il suo fork attivamente sviluppato conduwuit sono scritti in Rust e distribuiti come un singolo binario con database integrato. Fanno girare un server per una famiglia o una piccola community sul piano più economico che vendiamo senza battere ciglio. Il compromesso è un ecosistema più piccolo: alcuni strumenti di amministrazione e qualche bridge danno per scontato Synapse.

Per un primo server con una manciata di utenti, il software della famiglia Conduit su un piccolo VPS è la strada meno dolorosa verso qualcosa che funziona e resta economico. Per tutto ciò che prevedi possa crescere — una community pubblica, un'azienda, un progetto con bridge — parti direttamente con Synapse e salta la migrazione, perché passare da un'implementazione all'altra in seguito è un esercizio di esportazione e ricostruzione, non una modifica di configurazione.

La configurazione della delega che tutti sbagliano

Matrix separa il nome nei tuoi ID utente dalla macchina che serve il traffico, e invertire questo è l'errore permanente più comune nel self-hosting. Il tuo server_name è il dominio che compare dopo i due punti in ogni ID utente sul tuo server. Diventa parte della tua identità nella federazione nel momento in cui viene firmato il primo evento, e non può essere cambiato in seguito senza abbandonare ogni account e stanza sulla macchina.

La configurazione che quasi sempre vuoi: server_name è il tuo dominio nudo, mentre il software gira su un sottodominio. Colleghi i due con la delega, in uno di due modi. Il più semplice è un file JSON statico servito su /.well-known/matrix/server sul dominio nudo, che indica l'host e la porta reali. L'alternativa è un record DNS, _matrix._tcp, che punta allo stesso posto. Servi anche il file lato client su /.well-known/matrix/client, così le app trovano l'homeserver a partire dal solo indirizzo.

Dimensionarlo onestamente

Matrix in condizioni normali non è vincolato dalla CPU; è vincolato dalla memoria e dal comportamento del database. I dati pubblicati per Synapse sono una base utile: circa 2 GB di RAM per iniziare, circa 4 GB una volta che hai dieci-cinquanta utenti attivi, e 8 GB o più oltre un centinaio. I server della famiglia Conduit restano ben al di sotto. Quello che quei numeri omettono è che il consumo segue le stanze a cui ci si unisce, non le persone registrate — cinque utenti in cento grandi stanze pubbliche costano molto di più di cinquanta utenti in una manciata di stanze private.

Ne seguono due regole pratiche. Metti il database su storage veloce e dagli spazio per crescere, perché il pattern di scrittura è piccolo e costante piuttosto che a raffiche. E non dimensionare in base al numero di utenti di oggi: dimensiona in base alle stanze a cui quegli utenti si uniranno nel primo mese, che di solito è dove si nasconde la sorpresa. Il nostro piano base regge comodamente un piccolo server Conduit o Dendrite, mentre un'istanza Synapse per una community vera appartiene a un piano di fascia media o superiore — la pagina dedicata all'hosting per chat elenca i piani che consigliamo per ciascuno di questi scenari.

Qui l'uptime conta più che per la maggior parte dei carichi di lavoro, perché un server di chat fermo non è solo non disponibile — sta silenziosamente perdendo eventi che i peer ritenteranno per un po' e poi smetteranno di offrire. La federazione perdona i minuti ed è spietata sui giorni.

L'archivio media è una bomba a orologeria per il disco

Ogni immagine, video e file che attraversa una stanza in cui si trovano i tuoi utenti può finire in cache sul tuo disco, compresi i media remoti che i tuoi utenti non hanno mai aperto. La conservazione predefinita in Synapse li mantiene a tempo indeterminato. Il risultato è prevedibile e continua a sorprendere: un server con un database stabile e una cartella media che cresce silenziosamente finché il volume si riempie, e a quel punto il sintomo non è "disco pieno" ma "il server si comporta in modo strano".

Imposta una policy di conservazione per i media remoti fin dal primo giorno, non dopo il primo disservizio. Synapse espone le impostazioni di conservazione in homeserver.yaml, oltre a endpoint di amministrazione per eliminare cronologia vecchia e file in cache; synapse-compress-state recupera una quantità sorprendente di spazio dalle tabelle di stato su un server datato. Tieni d'occhio sia il database sia il percorso dei media, e imposta un avviso sullo spazio libero invece che sul servizio caduto — il secondo sintomo arriva giorni dopo il primo.

Un'impostazione merita una decisione, non un valore predefinito. Le anteprime degli URL fanno sì che il tuo server recuperi qualsiasi link pubblicato in una stanza, il che significa che l'indirizzo IP del tuo server fa una richiesta in uscita verso terzi nell'istante in cui qualcuno incolla un link — incluso un link scelto apposta per vedere chi abbocca. Se il tuo homeserver è dietro un front e il suo indirizzo reale conta, valutalo con attenzione; la nostra guida su come nascondere un indirizzo di origine copre la stessa categoria di fuga di dati in maggior dettaglio.

Registrazione, spam e la reputazione che erediti

La registrazione aperta su un homeserver pubblico è un invito, e non del tipo che vuoi. Le iscrizioni automatiche trasformano un piccolo server in una fonte di spam nel giro di pochi giorni, e la conseguenza non resta locale: altri homeserver aggiungono il tuo dominio a liste di controllo degli accessi, e una volta che il tuo nome compare su abbastanza di esse, i tuoi utenti legittimi smettono di poter partecipare alle stanze altrove. Recuperare una reputazione di dominio bruciata è molto più difficile che evitarlo, esattamente come per la deliverability della posta.

Le impostazioni predefinite difendibili sono semplici. Tieni enable_registration disattivato per un server privato e distribuisci gli account tu stesso. Se vuoi tenere la porta aperta, vincolala: registration_requires_token trasforma la registrazione in un sistema a inviti senza alcun servizio di terze parti, e un captcha aiuta contro la parte più grossolana del problema. Per le stanze che amministri, i bot di moderazione della famiglia Mjolnir e Draupnir ti permettono di applicare liste di ban e ACL delle stanze su un'intera community invece che una stanza alla volta.

Vale la pena saperlo anche al contrario: i nostri intervalli di indirizzi non compaiono nelle blocklist ACL di Matrix che circolano tra gli homeserver, quindi un nuovo server parte da una reputazione pulita. Cosa succede a quella reputazione in seguito dipende da come gestisci la registrazione, non da dove si trova la macchina.

I bridge, e il conto di metadati che portano

I bridge sono il motivo onesto per cui molte persone restano su Matrix: un unico client per stanze che vivono su altre reti. Cambiano anche la posizione di sicurezza del tuo server in un modo facile da trascurare. Un bridge detiene le credenziali dell'account remoto e, al confine dove i protocolli si incontrano, gestisce necessariamente i messaggi in una forma che può convertire — il che significa che il processo del bridge vede in chiaro un traffico che è cifrato end-to-end su entrambi i suoi lati.

Questo non è un motivo per evitare i bridge. È un motivo per trattare l'host del bridge come infrastruttura sensibile: è la macchina che, se compromessa, espone gli account per cui fa da tramite. Ogni bridge raddoppia più o meno l'impronta di memoria di un piccolo server, quindi pianifica la capacità di conseguenza, e dedica alla sua collocazione la stessa attenzione che hai dedicato all'homeserver stesso — il ragionamento della nostra guida alla giurisdizione vale con ancora più forza per una macchina che detiene contemporaneamente le credenziali di più reti.

Tenerlo in vita: chiavi, backup e aggiornamenti

Un server Matrix ha un file la cui perdita è irrecuperabile in un modo che non ha nulla a che vedere con il volume di dati. La chiave di firma — signing.key in Synapse — è ciò che dimostra che gli eventi che dichiarano di provenire dal tuo dominio provengono davvero da lì. Se la perdi non puoi più essere credibilmente il tuo server; i peer rifiuteranno eventi firmati da uno sconosciuto che detiene il tuo nome. Fanne un backup separato da tutto il resto, e tieni quella copia fuori dalla macchina.

Gli aggiornamenti sono ordinaria amministrazione, ma non facoltativi. Le versioni dell'homeserver portano migrazioni dello schema, e saltarne molte trasforma un aggiornamento di cinque minuti in un pomeriggio intero. Leggi le note di rilascio prima di aggiornare, aggiorna con una regolarità tale che ogni passo resti piccolo, e applica l'igiene di base dell'host dalla checklist di hardening della prima ora — un server di chat è un servizio esposto a internet e di lunga durata con un database annesso, e merita lo stesso trattamento.

Dove si trova il server decide ancora il risultato

Tutto quanto sopra è configurazione. La parte che la configurazione non può toccare è quale sistema legale riceve una richiesta sui tuoi utenti, e per un server di comunicazioni questa domanda pesa più che per un sito web. Un homeserver conserva in chiaro registri di appartenenza, timestamp e dati del grafo sociale anche quando i corpi dei messaggi sono cifrati — quindi la giurisdizione che lo ospita è la giurisdizione che governa l'accesso a quel registro.

Questo è l'argomento pratico per scegliere una posizione di proposito e non solo in base alla latenza. Ne gestiamo sette, e i compromessi tra loro sono spiegati nella guida alla giurisdizione e nella pagina delle sedi. L'altra metà della stessa domanda è chi il provider sa che tu sia: un account senza alcuna identità collegata non può produrre documenti d'identità che non ha mai raccolto, ed è proprio per questo che l'hosting no-KYC e le comunicazioni self-hosted continuano a comparire nella stessa conversazione. Nessuna delle due è una difesa contro un tribunale che ha già il tuo nome, e la nostra guida OpSec è schietta su dove si trovi quel limite.

La versione breve

Se porti via sei cose da questa pagina, porta via queste:

• Scegli il server_name prima di installare qualsiasi cosa — è l'unica decisione che non potrai mai rivedere.
• Delega con /.well-known/matrix/server o un record SRV, e mantieni un TLS valido su entrambi i nomi.
• Dimensiona in base alle stanze a cui i tuoi utenti si uniranno, non a quanti utenti hai.
• Imposta la conservazione dei media fin dal primo giorno, e decidi tu sulle anteprime degli URL invece di ereditare il valore predefinito.
• Tieni la registrazione chiusa o vincolata a token; una reputazione di dominio bruciata è costosa da rimediare.
• Fai il backup di signing.key separatamente, e non riportare mai indietro il database lasciando indietro i tuoi peer.

Fai queste cose e il server risulterà poco appariscente, esattamente ciò che un server di chat dovrebbe essere. Quello che ottieni in cambio merita di essere guardato con chiarezza: non l'invisibilità, e non un protocollo che nasconde chi parla con chi, ma conversazioni il cui contenuto è tuo, un account che nessun altro può chiudere, e una macchina sotto un sistema legale che hai scelto deliberatamente. Metti un homeserver dove l'hai scelto tu, e lascia che la federazione arrivi a lui.