Matrix-Server selbst hosten

Menschen hosten Matrix selbst, um zu verhindern, dass ein Unternehmen ihre Unterhaltungen verwahrt, und genau das funktioniert wie versprochen. Was sie später überrascht, ist die Form dessen, was sie installiert haben: Ein Homeserver ist keine private Box, die zufällig Chat spricht. Er ist ein Replikationsknoten in einem öffentlichen Netzwerk, und Federation verhält sich weit mehr wie ein Publishing-Protokoll, als die meisten neuen Administratoren erwarten.

Das alles ist kein Argument gegen den Betrieb eines eigenen Servers – es ist das Argument dafür, ihn bewusst zu betreiben. Der Zugewinn an Privatsphäre ist real, aber spezifisch: Die Verwahrung geht auf Sie über, Ihr Konto kann nicht von jemand anderem geschlossen werden, und rechtliche Anfragen landen in einer Rechtsordnung, die Sie gewählt haben, statt in einer, die ein Unternehmen gewählt hat. Was Sie nicht gewinnen, ist ebenso spezifisch, und fast alles davon liegt in der Lücke zwischen „die Nachrichten sind verschlüsselt“ und „niemand kann erkennen, wer mit wem spricht“. Dieser Leitfaden behandelt beide Hälften und dann die betrieblichen Details, die entscheiden, ob der Server auch in einem Jahr noch gesund ist.

Was der Betrieb eines eigenen Homeservers wirklich verändert

Trennen Sie zunächst die Bedrohungen, denn ein Homeserver beantwortet manche davon vollständig, manche teilweise und manche gar nicht. Die folgende Tabelle ist die ehrliche Version des Verkaufsarguments, und es lohnt sich, sie zu lesen, bevor Sie die Hardware auswählen, nicht danach.

Lesen Sie die letzten beiden Zeilen aufmerksam, denn dort brechen Erwartungen. Wenn Ihr Ziel ist, dass niemand feststellen können soll, dass ein Dienst überhaupt existiert, ist Matrix das falsche Werkzeug, und ein Onion-Dienst kommt dem richtigen näher. Wenn Ihr Ziel Verwahrung, Kontrolle und Rechtsordnung ist, ist ein Homeserver ein hervorragendes Instrument, und der Rest dieses Leitfadens handelt davon, ihn gut zu betreiben.

Federation ist ein Replikationsprotokoll im Gewand eines Chat-Protokolls

Hier ist der Mechanismus, der die meisten Überraschungen erklärt. Wenn einer Ihrer Nutzer einem Raum beitritt, der anderswo gehostet wird, ruft Ihr Server keine Nachrichten auf Abruf ab wie ein Mail-Client. Er tritt dem Raum als Teilnehmer in einem verteilten Ereignisgraphen bei und zieht sich eine Kopie der Ereignisse des Raums, seiner Mitgliedschaft und genug Statushistorie, um zu validieren, was als Nächstes kommt, und speichert sie. Von diesem Moment an hält Ihre Maschine eine Replik, und jeder andere teilnehmende Server hält ebenfalls eine.

Die Folgen wirken in beide Richtungen, und keine davon ist intuitiv. Daten, die Ihre Nutzer erzeugen – Anzeigename, Avatar, Beitritte und Austritte, Zeitstempel, Reaktionen – werden auf jeden Server kopiert, der ein Mitglied in diesem Raum hat, und bleiben in dessen Datenbank, unabhängig davon, was Sie später bei sich löschen. Eine Löschanfrage ist eine Bitte an die Peers, kein Befehl. Es gibt kein Zurückholen einer Nachricht über eine Federation unabhängig betriebener Server hinweg, und genau das zu erwarten ist das häufigste Missverständnis über das Protokoll.

In die andere Richtung bedeutet der Beitritt zu großen öffentlichen Räumen, dass Sie die Geschichte anderer Leute auf Ihre Festplatte importieren. Deshalb kann ein brandneuer Homeserver mit drei Nutzern zig Gigabyte an Datenbank tragen: nicht weil Ihre drei Nutzer viel geschrieben hätten, sondern weil sie Räumen mit fünfzigtausend Mitgliedern und jahrelanger Historie beigetreten sind. Bewusste Raumauswahl ist ebenso eine Kapazitätsentscheidung wie eine Frage der Privatsphäre.

Was die Verschlüsselung abdeckt, und was im Klaren bleibt

Matrix verschlüsselt Nachrichteninhalte mit Megolm, und in privaten Räumen ist das standardmäßig aktiv. Das schützt den Teil, der den Menschen am wichtigsten ist, und es funktioniert tatsächlich – Ihr Server speichert Chiffretext, den er nicht lesen kann, was eine reale und nützliche Eigenschaft ist, wenn der Server gemietete Hardware ist. Der Umschlag um die Nachricht ist eine andere Geschichte, und die Lücke ist größer, als die meisten Zusammenfassungen zugeben.

Die praktische Lesart: Verschlüsselung schützt das Was, Federation veröffentlicht das Wer, Wann und Wie oft. Für die meisten Communitys ist dieser Tausch vollkommen akzeptabel, und die Ehrlichkeit ist der Punkt. Für ein Bedrohungsmodell, in dem der soziale Graph selbst der sensible Teil ist, hat ein föderiertes Protokoll strukturell die falsche Form, und keine Konfigurationsoption ändert das.

Synapse, Dendrite oder Conduit – was Sie tatsächlich betreiben sollten

In der Praxis zählen drei Implementierungen, und die Wahl ist eher eine Ressourcenfrage als eine philosophische.

• Synapse ist der Referenzserver, geschrieben in Python, und der einzige, bei dem am ersten Tag jede Funktion läuft. Er ist auch der hungrigste: Der Speicherbedarf wächst mit Anzahl und Größe der Räume, denen Ihre Nutzer beitreten, und ein stark genutzter Server will irgendwann in Worker-Prozesse aufgeteilt werden. Wählen Sie ihn, wenn Spaces, Moderationswerkzeuge, Bridges und Admin-APIs sich exakt wie dokumentiert verhalten müssen.
• Dendrite ist die Neufassung in Go. Merklich leichter als Synapse und für einen kleinen Server durchaus brauchbar, auf Kosten eines gewissen Funktionsrückstands. Eine vernünftige Mittelposition, wenn Ihnen Synapse für die Zahl der tatsächlich vorhandenen Nutzer zu schwer vorkommt.
• Conduit und sein aktiv weiterentwickelter Fork conduwuit sind in Rust geschrieben und kommen als einzelne Binärdatei mit eingebetteter Datenbank. Sie betreiben einen Familien- oder kleinen Community-Server auf dem kleinsten Plan, den wir verkaufen, ohne zu murren. Der Preis dafür ist ein kleineres Ökosystem: Manche Admin-Werkzeuge und einige Bridges setzen Synapse voraus.

Für einen ersten Server mit einer Handvoll Nutzer ist Software aus der Conduit-Familie auf einem kleinen VPS der schmerzloseste Weg zu etwas, das funktioniert und günstig bleibt. Für alles, wovon Sie Wachstum erwarten – eine öffentliche Community, ein Unternehmen, ein Projekt mit Bridges – starten Sie mit Synapse und sparen sich die Migration, denn der spätere Wechsel zwischen Implementierungen ist eher eine Export-und-Neuaufbau-Übung als eine Konfigurationsänderung.

Die Delegation, bei der fast jeder etwas falsch macht

Matrix trennt den Namen in Ihren Nutzer-IDs von der Maschine, die den Datenverkehr bedient, und diese Trennung falsch herum aufzusetzen ist der häufigste dauerhafte Fehler beim Self-Hosting. Ihr server_name ist die Domain, die nach dem Doppelpunkt in jeder Nutzer-ID auf Ihrem Server erscheint. Er wird in dem Moment Teil Ihrer Identität in der Federation, in dem das erste Ereignis signiert wird, und er kann danach nicht mehr geändert werden, ohne jedes Konto und jeden Raum auf der Maschine aufzugeben.

Das Setup, das Sie fast immer wollen: server_name ist Ihre nackte Domain, während die Software auf einer Subdomain läuft. Sie verbinden beide durch Delegation, auf eine von zwei Arten. Die einfache ist eine statische JSON-Datei unter /.well-known/matrix/server auf der nackten Domain, die den echten Host und Port nennt. Die Alternative ist ein DNS-Eintrag, _matrix._tcp, der auf denselben Ort zeigt. Stellen Sie auch die clientseitige Datei unter /.well-known/matrix/client bereit, damit Apps den Homeserver allein anhand einer Adresse finden.

Realistisch dimensionieren

Matrix ist im Normalbetrieb nicht CPU-gebunden; es wird durch Arbeitsspeicher und Datenbankverhalten begrenzt. Die veröffentlichten Zahlen für Synapse sind ein brauchbarer Boden: grob 2 GB RAM zum Start, etwa 4 GB sobald Sie zehn bis fünfzig aktive Nutzer haben, und 8 GB oder mehr jenseits von hundert. Server der Conduit-Familie liegen weit darunter. Was diese Zahlen auslassen: Der Verbrauch folgt den beigetretenen Räumen, nicht den registrierten Personen – fünf Nutzer in hundert großen öffentlichen Räumen kosten weit mehr als fünfzig Nutzer in einer Handvoll privater.

Daraus folgen zwei praktische Regeln. Legen Sie die Datenbank auf schnellen Speicher und geben Sie ihr Raum zum Wachsen, denn das Schreibmuster ist klein und konstant statt stoßweise. Und dimensionieren Sie nicht für die heutige Nutzerzahl: Dimensionieren Sie für die Räume, denen diese Nutzer im ersten Monat beitreten werden, denn dort liegt gewöhnlich die Überraschung. Unser Einstiegsplan trägt einen kleinen Conduit- oder Dendrite-Server bequem, während eine Synapse-Instanz für eine echte Community auf einem Plan der mittleren Stufe oder höher zu Hause ist – die Seite zum Chat-Hosting listet die Stufen auf, die wir für jede dieser Formen empfehlen.

Verfügbarkeit zählt hier mehr als bei den meisten Workloads, denn ein Chatserver, der ausfällt, ist nicht bloß nicht erreichbar – er verpasst lautlos Ereignisse, die Peers eine Weile erneut zustellen und dann aufhören anzubieten. Federation verzeiht Minuten und ist unerbittlich bei Tagen.

Der Medienspeicher ist eine Festplattenbombe in Zeitlupe

Jedes Bild, Video und jede Datei, die einen Raum durchläuft, in dem Ihre Nutzer sind, kann auf Ihrer Festplatte landen – auch fremde Medien, die Ihre eigenen Nutzer nie geöffnet haben. Die Standardaufbewahrung in Synapse hält das unbegrenzt vor. Das Ergebnis ist vorhersehbar und erwischt trotzdem immer wieder Leute: ein Server, dessen Datenbank stabil ist und dessen Medienverzeichnis still vor sich hin wächst, bis der Datenträger voll ist – und dann ist das Symptom nicht „Festplatte voll“, sondern „der Server verhält sich seltsam“.

Legen Sie eine Aufbewahrungsrichtlinie für fremde Medien am ersten Tag fest, nicht erst nach dem ersten Ausfall. Synapse bietet Aufbewahrungseinstellungen in homeserver.yaml sowie Admin-Endpunkte zum Bereinigen alter Historie und zwischengespeicherter Dateien; synapse-compress-state gewinnt auf einem älteren Server überraschend viel aus den Statustabellen zurück. Behalten Sie sowohl Datenbank als auch Medienpfad im Auge, und alarmieren Sie beim freien Speicherplatz, nicht erst wenn der Dienst ausfällt – das zweite Symptom kommt Tage nach dem ersten.

Eine Einstellung verdient eine bewusste Entscheidung statt eines Standardwerts. URL-Vorschauen lassen Ihren Server jeden in einem Raum geposteten Link abrufen, was bedeutet, dass die IP-Adresse Ihres Servers in dem Moment eine ausgehende Anfrage an Dritte stellt, in dem jemand einen Link einfügt – auch einen Link, der gezielt gewählt wurde, um zu sehen, wer anbeißt. Wenn Ihr Homeserver hinter einem Frontend sitzt und seine echte Adresse eine Rolle spielt, wägen Sie das sorgfältig ab; unser Leitfaden zum Verbergen einer Ursprungsadresse behandelt dieselbe Art von Leck ausführlicher.

Registrierung, Spam und der Ruf, den Sie erben

Offene Registrierung auf einem öffentlichen Homeserver ist eine Einladung, und nicht die Art, die Sie wollen. Automatisierte Anmeldungen machen einen kleinen Server binnen Tagen zu einer Spam-Quelle, und die Folge bleibt nicht lokal: Andere Homeserver setzen Ihre Domain auf Zugriffskontrolllisten, und sobald Ihr Name auf genug davon steht, können Ihre legitimen Nutzer nicht mehr an Räumen anderswo teilnehmen. Einen verbrannten Domain-Ruf wiederherzustellen ist weit schwerer, als ihn zu vermeiden – genau wie bei der Zustellbarkeit von E-Mail.

Die vertretbaren Standardeinstellungen sind einfach. Lassen Sie enable_registration für einen privaten Server ausgeschaltet und legen Sie Konten selbst an. Wenn Sie die Tür offen halten wollen, schützen Sie sie: registration_requires_token macht aus der Registrierung ein Einladungssystem ganz ohne Drittanbieterdienst, und ein Captcha hilft gegen die groben Fälle des Problems. Für Räume, die Sie verwalten, lassen Sie Moderationsbots aus der Familie Mjolnir und Draupnir Bannlisten und Raum-ACLs für eine ganze Community anwenden statt Raum für Raum.

Wissenswert in die andere Richtung: Unsere Adressbereiche stehen nicht auf den Matrix-ACL-Sperrlisten, die zwischen Homeservern kursieren, sodass ein neuer Server mit einem sauberen Ruf startet. Was danach mit diesem Ruf geschieht, bestimmt, wie Sie die Registrierung führen, nicht wo die Maschine steht.

Bridges, und die Metadaten-Rechnung, die dazugehört

Bridges sind der ehrliche Grund, warum viele Menschen bei Matrix bleiben: ein Client für Räume, die auf anderen Netzwerken leben. Sie verändern auch die Sicherheitsposition Ihres Servers auf eine Weise, die man leicht übersieht. Eine Bridge hält Zugangsdaten für das entfernte Konto, und an der Stelle, wo Protokolle aufeinandertreffen, verarbeitet sie Nachrichten zwangsläufig in lesbarer Form – was bedeutet, dass der Bridge-Prozess Klartext für Verkehr sieht, der auf beiden Seiten Ende-zu-Ende-verschlüsselt ist.

Das ist kein Grund, Bridges zu vermeiden. Es ist ein Grund, den Bridge-Host als sensible Infrastruktur zu behandeln: Es ist die Maschine, die bei einer Kompromittierung die Konten offenlegt, für die sie spricht. Jede Bridge verdoppelt in etwa den Speicherbedarf eines kleinen Servers, planen Sie die Kapazität also entsprechend, und schenken Sie ihrem Standort dieselbe Überlegung wie dem Homeserver selbst – die Argumentation in unserem Leitfaden zur Rechtsordnung gilt mit noch mehr Gewicht für eine Box, die Zugangsdaten mehrerer Netzwerke gleichzeitig hält.

Am Leben halten: Schlüssel, Backups und Upgrades

Ein Matrix-Server hat eine Datei, deren Verlust auf eine Weise unwiederbringlich ist, die nichts mit dem Datenvolumen zu tun hat. Der Signaturschlüssel – signing.key in Synapse – ist, wie Ihr Server beweist, dass Ereignisse, die vorgeben, von Ihrer Domain zu stammen, das auch wirklich tun. Verlieren Sie ihn, können Sie glaubwürdig nicht mehr Ihr eigener Server sein; Peers werden Ereignisse zurückweisen, die von einem Fremden signiert wurden, der Ihren Namen trägt. Sichern Sie ihn getrennt von allem anderen, und bewahren Sie diese Kopie abseits der Maschine auf.

Upgrades sind gewöhnlich, aber nicht optional. Homeserver-Releases bringen Schema-Migrationen mit sich, und viele Versionen zu überspringen macht aus einem Fünf-Minuten-Upgrade einen Nachmittag. Lesen Sie die Release Notes, bevor Sie springen, aktualisieren Sie regelmäßig genug, dass jeder Schritt klein bleibt, und erledigen Sie die grundlegende Host-Hygiene aus der Checkliste für die erste Stunde – ein Chatserver ist ein langlebiger, aus dem Internet erreichbarer Dienst mit angeschlossener Datenbank, und er verdient dieselbe Behandlung wie einer.

Wo der Server steht, entscheidet immer noch über das Ergebnis

Alles bisher Genannte ist Konfiguration. Der Teil, den Konfiguration nicht berühren kann, ist, welches Rechtssystem eine Anfrage zu Ihren Nutzern erhält, und bei einem Kommunikationsserver wiegt diese Frage schwerer als bei einer Website. Ein Homeserver hält Mitgliedschaftsdatensätze, Zeitstempel und Daten des sozialen Graphen im Klartext, selbst wenn Nachrichteninhalte verschlüsselt sind – die Rechtsordnung, die ihn hostet, ist also die Rechtsordnung, die den Zugriff auf diesen Datensatz regelt.

Das ist das praktische Argument dafür, einen Standort bewusst zu wählen statt allein nach Latenz. Wir betreiben sieben, und die Abwägungen zwischen ihnen stehen im Leitfaden zur Rechtsordnung und auf der Standorte-Seite. Die andere Hälfte derselben Frage ist, wen der Anbieter als Sie kennt: Ein Konto ohne hinterlegte Identität kann keine Ausweisdokumente herausgeben, die es nie erfasst hat, was der schlichte Grund ist, warum No-KYC-Hosting und selbstgehostete Kommunikation immer wieder im selben Gespräch auftauchen. Keins von beiden ist eine Verteidigung gegen ein Gericht, das Ihren Namen bereits hat, und unser OpSec-Leitfaden spricht unverblümt darüber, wo diese Grenze liegt.

Die Kurzfassung

Wenn Sie sechs Dinge von dieser Seite mitnehmen, nehmen Sie diese:

• Legen Sie den server_name fest, bevor Sie irgendetwas installieren – es ist die eine Entscheidung, die Sie nie revidieren können.
• Delegieren Sie mit /.well-known/matrix/server oder einem SRV-Eintrag, und halten Sie gültiges TLS auf beiden Namen aufrecht.
• Dimensionieren Sie für die Räume, denen Ihre Nutzer beitreten werden, nicht für die Anzahl Ihrer Nutzer.
• Legen Sie die Medienaufbewahrung am ersten Tag fest, und entscheiden Sie bewusst über URL-Vorschauen, statt den Standard einfach zu übernehmen.
• Halten Sie die Registrierung geschlossen oder tokengeschützt; ein verbrannter Domain-Ruf ist teuer rückgängig zu machen.
• Sichern Sie signing.key getrennt, und rollen Sie die Datenbank niemals hinter Ihre Peers zurück.

Tun Sie das, und der Server wird unauffällig sein, was genau das ist, was ein Chatserver sein sollte. Was Sie im Gegenzug bekommen, ist es wert, klar benannt zu werden: keine Unsichtbarkeit und kein Protokoll, das verbirgt, wer mit wem spricht, sondern Unterhaltungen, deren Inhalte Ihnen gehören, ein Konto, das niemand sonst schließen kann, und eine Maschine unter einem Rechtssystem, das Sie bewusst gewählt haben. Stellen Sie einen Homeserver dorthin, wo Sie ihn gewählt haben, und lassen Sie die Federation zu ihm kommen.