SimpleX-SMP-Server auf einem VPS selbst hosten

Was ein selbst gehosteter SimpleX-Chatserver tut

Für den Betrieb eines selbst gehosteten SimpleX-Chatservers führen Sie einen Daemon auf einem VPS aus: smp-server, das Relay für SMP (simplex messaging protocol). Es verwaltet die Nachrichtenwarteschlangen, in die Ihre Kontakte schreiben und aus denen sie lesen. Ein zweiter, optionaler Daemon namens xftp-server leitet Dateiübertragungen weiter. Beide stammen aus demselben Projekt, simplexmq, und bestehen jeweils aus einer einzelnen Binärdatei, einer Konfigurationsdatei und einem Log im Append-only-Verfahren.

Dieser Text richtet sich an den Betreiber, nicht an den App-Benutzer. Das Relay verwaltet keine Konten, keine Kontaktlisten und keinen Chatverlauf. Es enthält Warteschlangen, einige nicht zugestellte Chiffretexte und ein Zertifikat, das es identifiziert. Sie übernehmen damit die Verantwortung für Verfügbarkeit, etwas Speicherplatz und die Metadaten, die Ihren Server passieren.

Alle folgenden Befehle, Pfade, Ports und Flags stammen aus der Dokumentation des Projekts: der SMP-Server-Hosting-Seite, der XFTP-Server-Seite und dem Dokument zur Protokollsicherheit. Wenn eine Zahl relevant ist, wird die Seite, aus der sie stammt, direkt daneben genannt.

Warum ein Netzwerk ohne Benutzerkennungen weiterhin Relays benötigt

SimpleX hat keine Benutzernamen, keine Telefonnummern und keine Konto-IDs. Ein Kontakt ist eine unidirektionale Warteschlange: eine Adresse auf einem Relay, in die eine Seite schreibt und aus der die andere Seite liest. Zwei Ihrer Kontakte verwenden keine gemeinsame Kennung, anhand derer ein Server sie zusammenführen könnte.

Diese Warteschlangen müssen dennoch irgendwo gespeichert werden. Der Grund ist einfach: Zwei Telefone sind nur selten gleichzeitig online. Etwas muss eine Nachricht jetzt annehmen und sie speichern, bis das andere Gerät sie abruft. Das ist die gesamte Aufgabe eines SMP-Relays. Dadurch verbinden sich die beiden Geräte auch nie direkt miteinander, sodass keines die IP-Adresse (Internet Protocol) des anderen erfährt. Stattdessen übernimmt das Relay diese Gefährdung.

Der Hostname des Relays ist Bestandteil der Warteschlangenadresse und steht daher in jedem Einladungslink, den Sie darüber weitergeben. Berücksichtigen Sie das, wenn Sie weiter unten das Bedrohungsmodell lesen.

Was ein Relay sehen kann und was nicht

Das Projekt beschreibt dies in protocol/security.md als Bedrohungsmodell. Sie sollten es lesen, bevor Sie etwas installieren. Nach dieser Anleitung gehört das Relay Ihnen. Ein Relay, auch wenn es vollständig von einem Angreifer kontrolliert wird, kann weder die Inhalte noch den Typ der Nachrichten erfahren. Es kann einzelne Nachrichten nicht unbemerkt hinzufügen, duplizieren oder beschädigen. Durch einen aktiven Angriff kann es die Ende-zu-Ende-Verschlüsselung nicht brechen.

Auf derselben Seite wird aufgeführt, was ein Relay kann. Es kann erkennen, wann ein Empfänger einer Queue online ist. Es kann zählen, wie viele Nachrichten eine Queue passieren. Es kann die IP-Adresse eines Empfängers erfahren. Es kann jede zukünftige Nachricht in einer Queue verwerfen oder den Status dieser Queue fälschen.

Die Zuständigkeiten sind daher klar getrennt. Für die Vertraulichkeit ist der Client verantwortlich. Self-Hosting ändert daran nichts. Für Metadaten und Verfügbarkeit ist der Relay-Betreiber verantwortlich. Durch Self-Hosting übernehmen Sie beides.

Was Sie vor dem Start benötigen

• Einen VPS mit Ubuntu 22.04 oder 24.04. Das Projekt veröffentlicht Release-Binärdateien, die genau für diese beiden Versionen in x86-64 und aarch64 erstellt wurden.
• Einen Domainnamen mit einem auf den VPS zeigenden A-Record sowie einem AAAA-Record, falls Sie IPv6 verwenden. In der Dokumentation wird smp1.example.com als Beispiel verwendet.
• Root- oder sudo-Zugriff sowie eine zweite geöffnete SSH-Sitzung, während Sie die Firewall ändern.
• Einen Speicherort außerhalb des Servers für ein Backup, da das Konfigurationsverzeichnis die Identität des Servers enthält.

Auf einer ARM-Instanz verwenden Sie das aarch64-Asset anstelle von x86-64. Ansonsten ändert sich in dieser Anleitung nichts. Die Wahl zwischen ARM- und x86-VPS-Tarifen hängt vom Preis und der Geschwindigkeit pro Kern ab, nicht davon, ob diese Software ausgeführt werden kann.

Eine festgelegte Version installieren, nicht „latest“

Das Projekt stellt ein Installationsskript bereit, das die aktuelle Version herunterlädt und einen Befehl simplex-servers-update registriert. Das funktioniert. Legen Sie die Version trotzdem fest: Wenn sich die Binärdatei eines Relays unbemerkt ändert, können Sie bei einem Fehler nicht mehr nachvollziehen, was passiert.

Im August 2026 ist v6.5.0 die aktuelle Version von simplexmq. Sie wurde am 29 April 2026 veröffentlicht. Prüfen Sie auf der Versionsseite das gewünschte Tag. Verwenden Sie dieses Tag anschließend überall weiter unten.

sudo useradd -m smp
sudo install -d -o smp -g smp -m 755 /etc/opt/simplex /var/opt/simplex

useradd -m smp legt kein Passwort fest. Daher meldet sich niemand direkt als smp an. Erstellen Sie die beiden Verzeichnisse selbst, bevor Sie weitere Befehle ausführen. /etc/opt gehört root und hat den Modus 755. Dadurch hat der Benutzer smp keinen Ort, an dem er sein eigenes Konfigurationsverzeichnis schreiben kann.

VER=v6.5.0
curl -fL "https://github.com/simplex-chat/simplexmq/releases/download/$VER/smp-server-ubuntu-24_04-x86-64" -o /tmp/smp-server
sha256sum /tmp/smp-server

Vergleichen Sie diesen Hash mit den SHA2-256-Prüfsummen, die in den Release Notes für dasselbe Tag veröffentlicht sind. Das Projekt signiert die Release-Prüfsummen außerdem mit dem SimpleX Chat-Schlüssel FB44AF81A45BDE327319797C85107E357D4A17FC. Dieser ist auf der Serverseite dokumentiert. Sie können damit die Signatur prüfen, anstatt der Seite zu vertrauen, von der Sie den Hash übernommen haben.

sudo install -m 755 -o root -g root /tmp/smp-server /usr/local/bin/smp-server

Installieren Sie die Datei absichtlich mit root als Besitzer. Der Dienst läuft als smp. Wenn der Dienst kompromittiert wird, kann er dadurch die Binärdatei, von der er gestartet wurde, nicht überschreiben.

Server und die beiden ausgegebenen Geheimnisse initialisieren

sudo su smp -c "smp-server init --yes --store-log --daily-stats --no-password --fqdn=smp1.example.com"

• --store-log (-l) schreibt ein Append-only-Protokoll der Queues nach /var/opt/simplex/smp-server-store.log, damit der Relay einen Neustart übersteht. Ohne diese Option verwirft ein Neustart jede Queue. Dadurch funktioniert jeder über Sie geroutete Kontakt nicht mehr.
• --daily-stats (-s) schreibt Zähler im CSV-Format nach /var/opt/simplex/smp-server-stats.daily.log.
• --fqdn nimmt Ihre Domain in das generierte Zertifikat auf. Verwenden Sie stattdessen --ip, wenn Sie keine Domain haben.
• --no-password erlaubt jedem, eine Queue auf Ihrem Relay anzulegen. Damit der Relay privat bleibt, setzen Sie nach der Initialisierung create_password unter [AUTH] in /etc/opt/simplex/smp-server.ini, statt hier --password zu übergeben. Eine Befehlszeile ist während der Ausführung in Ihrer Shell-History und in der Prozessliste sichtbar.

Init generiert ein Zertifikat und gibt die beiden Werte aus, die Sie aufbewahren müssen. Der erste Wert ist der Fingerabdruck. Er ist eine Base64-Zeichenfolge und wird außerdem nach /etc/opt/simplex/fingerprint geschrieben. Der zweite Wert ist die vollständige Serveradresse. Sie besteht aus dem Fingerabdruck und Ihrem Hostnamen. Kopieren Sie beide Werte jetzt.

Init erstellt außerdem /etc/opt/simplex/ca.key. In der Dokumentation wird empfohlen, diese Datei in einen Offline-Speicher zu verschieben. Der Grund ist wichtig: Clients pinnen den Fingerabdruck dieser Zertifizierungsstelle. Jeder, der über ca.key verfügt, kann daher ein neues Serverzertifikat ausstellen, das Ihre Clients als Ihr Zertifikat akzeptieren. Sie benötigen die Datei nur später zurück, um das Serverzertifikat mit smp-server cert zu erneuern.

Behandeln Sie Init als einmaligen Schritt. Der Fingerabdruck in Ihrer Adresse stammt von der generierten Zertifizierungsstelle. Wenn Sie diese Zertifizierungsstelle neu generieren, erhalten Sie eine andere Adresse. Die bisher verteilte Adresse ist dann nicht mehr gültig.

Führen Sie den Dienst unter systemd mit einem nicht privilegierten Benutzer aus

Schreiben Sie /etc/systemd/system/smp-server.service genau so, wie es in der Dokumentation angegeben ist:

[Unit]
Description=SMP server systemd service

[Service]
User=smp
Group=smp
Type=simple
ExecStart=/usr/local/bin/smp-server start +RTS -N -RTS
ExecStopPost=/usr/bin/env sh -c '[ -e "/var/opt/simplex/smp-server-store.log" ] && cp "/var/opt/simplex/smp-server-store.log" "/var/opt/simplex/smp-server-store.log.bak"'
LimitNOFILE=65535
KillSignal=SIGINT
TimeoutStopSec=infinity

[Install]
WantedBy=multi-user.target

Die Upstream-Unit enthält außerdem AmbientCapabilities=CAP_NET_BIND_SERVICE. Diese Zeile ist erforderlich, weil der Prozess als smp ausgeführt wird und Ports unter 1024 für einen Nicht-root-Prozess nicht geöffnet werden können. Ohne diese Zeile kann der Daemon daher nicht an Port 80 oder 443 binden. Fügen Sie sie hinzu, wenn Sie diese Ports bereitstellen. LimitNOFILE=65535 ist wichtig, weil jeder abonnierte Client eine offene TCP-Verbindung aufrechterhält und das Standardlimit für ein stark ausgelastetes Relay deutlich zu niedrig ist. ExecStopPost kopiert bei jedem Stop den Store-Log in eine .bak-Datei. Dadurch steht Ihnen ein kostenloser Rollback-Punkt zur Verfügung.

sudo systemctl daemon-reload
sudo systemctl enable --now smp-server
sudo systemctl status smp-server
sudo journalctl -fu smp-server

Ein erfolgreicher Start protokolliert die Serveradresse. Prüfen Sie anschließend, ob die Sockets tatsächlich geöffnet sind:

sudo ss -tlnp | grep -E ':(443|5223)'

Beide Zeilen sollten smp-server nennen. Den Daemon unter einem eigenen Konto ohne sudo-Rechte auszuführen, entspricht dem in dienstbezogene Konten auf einem VPS beschriebenen Vorgehen. Dadurch kann ein Fehler in einem Netzwerk-Daemon nicht zu einer Root-Shell führen.

Welche Ports geöffnet werden sollen und welcher geschlossen bleiben muss

Die Dokumentation führt drei Ports auf: 5223/tcp, 443/tcp und 80/tcp. Port 5223 ist der SMP-Transport. Die mitgelieferte Konfiguration setzt port: 5223,443 unter [TRANSPORT], sodass dasselbe Protokoll auch auf 443 antwortet. Das ist wichtig, weil viele restriktive Netzwerke ausgehend nur 443 und keine anderen Ports zulassen. Port 80 wird nur für die optionale Informationsseite und deren Weiterleitung zu HTTPS benötigt.

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 5223/tcp
sudo ufw enable

Öffnen Sie 5224 nicht. Das ist der Steuerungsport. Die Dokumentation greift mit nc 127.0.0.1 5224 vom Server selbst darauf zu. Der Port zeigt den Serverstatus an und löscht Warteschlangen. Er sollte daher auf Loopback beschränkt werden. Legen Sie außerdem die Admin- und Benutzerpasswörter unter [AUTH] fest. Wenn Sie das Tool noch nicht kennen, erklärt die Grundlagen von ufw auf einem VPS die Reihenfolge von Regeln und wie Sie vermeiden, sich selbst auszusperren.

Eine weitere Firewall wird häufig übersehen. Die meisten Anbieter betreiben im Control Panel eine Netzwerk-Firewall, die von ufw auf dem Server getrennt ist. Ein Port kann in ufw geöffnet sein und trotzdem verworfen werden, bevor der Datenverkehr Sie erreicht.

Die Serveradresse, die Ihre Clients benötigen

smp://<fingerprint>[:<password>]@<public_hostname>[,<onion_hostname>]

Diese Zeichenfolge ist die vollständige clientseitige Konfiguration. Fügen Sie sie in den Servereinstellungen der Anwendung ein, oder lassen Sie sie von jemandem über den QR-Code scannen, den die Anwendung dafür anzeigt. Die Dokumentation weist darauf hin, dass der QR-Code das Passwort enthält. Eine Person, die ihn scannt, kann dadurch ebenfalls Nachrichten über Ihren Server empfangen.

Ein dokumentiertes Verhalten überrascht viele Anwender. Wenn Sie Ihren Server in der Anwendung hinzufügen, betrifft das nur Kontakte, die Sie ab diesem Zeitpunkt erstellen. Bestehende Kontakte bleiben auf den Relays, auf denen ihre Queues erstellt wurden, und werden nicht migriert. Deshalb können Sie ein Relay auch nicht am Tag nach seinem Austausch abschalten.

Hinzufügen eines XFTP-Dateirelays

XFTP (SimpleX file transfer protocol) ist der Dateiteil des Netzwerks. Es läuft als separater Daemon mit einer eigenen Adresse. Laut der XFTP-Ankündigung enthalten Relays keinerlei Dateimetadaten. Sie sehen nur einzelne Chunks mit jeweils 256kb, 1mb oder 4mb, deren Zugriff durch anonyme Zugangsdaten autorisiert wird. Ein Absender kann die Chunks einer Datei auf mehrere Relays verteilen. Ihr Server enthält daher nur Teile und keine vollständigen Dateien.

sudo useradd -m xftp
sudo install -d -o xftp -g xftp -m 755 /etc/opt/simplex-xftp /var/opt/simplex-xftp /srv/xftp
curl -fL "https://github.com/simplex-chat/simplexmq/releases/download/$VER/xftp-server-ubuntu-24_04-x86-64" -o /tmp/xftp-server
sudo install -m 755 -o root -g root /tmp/xftp-server /usr/local/bin/xftp-server
sudo su xftp -c "xftp-server init -l --fqdn=xftp1.example.com -q '20gb' -p /srv/xftp/"

Die Konfiguration befindet sich in /etc/opt/simplex-xftp/, der Status in /var/opt/simplex-xftp/ und die Datei-Chunks in dem Verzeichnis, das -p angibt. Die systemd-Unit hat denselben Aufbau mit User=xftp und ExecStart=/usr/local/bin/xftp-server start +RTS -N -RTS. Init gibt eine xftp://-Adresse im selben Format wie die SMP-Adresse aus, mit einem eigenen Fingerabdruck in /etc/opt/simplex-xftp/fingerprint.

Das müssen Sie bei der Planung berücksichtigen. Der dokumentierte Port des XFTP-Servers ist 443, und auch die SMP-Konfiguration führt 443 auf. Zwei Prozesse können nicht denselben Port an derselben Adresse binden. Auf einem VPS muss daher eine Anpassung erfolgen. Am einfachsten setzen Sie port: 5223 im Abschnitt [TRANSPORT] der SMP-Konfiguration und überlassen Port 443 dem Dateirelay. Dadurch entfällt jedoch der 443-Fallback für Clients in restriktiven Netzwerken. Alternativ können Sie eine zweite IP-Adresse auf demselben VPS oder einen zweiten VPS verwenden.

Legen Sie das Kontingent realistisch fest. -q '20gb' ist eine Zusage über den verfügbaren Speicherplatz. Das Dateirelay benötigt den größten Teil des Speicherplatzes und der Bandbreite. Das Nachrichtenrelay beansprucht beides kaum.

Was auf dem Datenträger liegt und was ein Backup wiederherstellt

Zwei Verzeichnisse sind wichtig. /etc/opt/simplex/ enthält die Identität: smp-server.ini, das Serverzertifikat und den Schlüssel, ca.key sowie fingerprint. /var/opt/simplex/ enthält den Status: smp-server-store.log enthält die Warteschlangen und, wenn restore_messages: on, die nicht zugestellten Nachrichten sowie die tägliche Statistikdatei.

sudo systemctl stop smp-server
sudo tar czf /root/simplex-backup.tgz -C / etc/opt/simplex var/opt/simplex
sudo chmod 600 /root/simplex-backup.tgz
sudo systemctl start smp-server

Machen Sie sich klar, was dieses Archiv enthält. Es ist kein Nachrichtenarchiv: Die Elemente in der Warteschlange sind Chiffretext für Schlüssel, die das Relay nie besessen hat, und die mitgelieferte [STORE_LOG]-Konfiguration lässt Nachrichten ohnehin nach 21 Tagen ablaufen. Es handelt sich um eine Kopie der Identität des Servers, einschließlich ca.key. Wer die Datei erhält, kann sich gegenüber Ihren Kontakten als Ihr Relay ausgeben. Verschlüsseln Sie die Datei und bewahren Sie sie außerhalb des Servers auf.

Der Nutzen zeigt sich bei der Wiederherstellung. Stellen Sie /etc/opt/simplex auf einem frischen VPS wieder her, verweisen Sie denselben DNS-Namen darauf, und der Fingerabdruck bleibt unverändert. Dadurch funktionieren alle Adressen, die Sie ausgegeben haben, weiterhin. Wenn Sie dieses Verzeichnis verlieren, gibt es keine Wiederherstellung: Eine neue Installation erzeugt einen neuen Fingerabdruck. Das bedeutet eine neue Adresse und damit den Verlust aller Kontakte, die über Ihr Relay geroutet wurden.

TLS: zwei Zertifikate mit unterschiedlichen Aufgaben

Der SMP-Transport verwendet keine öffentliche Zertifizierungsstelle. Init erzeugt eine private Zertifizierungsstelle und ein Serverzertifikat. Der Fingerabdruck dieser Zertifizierungsstelle ist Bestandteil der Serveradresse. Der Client vergleicht die vom Server präsentierten Daten mit diesem festgelegten Fingerabdruck. Damit schützt das Projekt die Verbindung zwischen Client und Server vor Machine-in-the-Middle-Angriffen. Für diesen Port muss kein ACME-Client (Automatic Certificate Management Environment) ausgeführt werden. Die Erneuerung erfolgt manuell mit smp-server cert, wobei SMP_SERVER_CFG_PATH gesetzt sein muss.

Das optionale Informationsportal verwendet das andere Zertifikat. In seinem Abschnitt [WEB] werden static_path, https: 443, cert: /etc/opt/simplex/web.crt und key: /etc/opt/simplex/web.key angegeben. Ein Browser kennt Ihre private Zertifizierungsstelle nicht. Deshalb ist dies die Stelle, an der ein öffentlich vertrauenswürdiges Zertifikat verwendet wird. Der Docker-Schnellstart der Dokumentation setzt genau dafür Caddy vor den Server und stellt das Zertifikat automatisch aus.

Über das Tor-Netzwerk den Relay erreichen

Die Dokumentation enthält einen Tor-Abschnitt. Dort wird Tor aus dem Repository des Tor Project installiert und ein Hidden Service in /etc/tor/torrc hinzugefügt:

SOCKSPort 0
HiddenServiceNonAnonymousMode 1
HiddenServiceSingleHopMode 1
HiddenServiceDir /var/lib/tor/simplex-smp/
HiddenServicePort 5223 localhost:5223
HiddenServicePort 443 localhost:443

Lesen Sie die beiden Moduszeilen sorgfältig. Single Hop und Non-Anonymous bedeuten, dass der eigene Standort des Relays nicht verborgen wird. Die Onion-Adresse ist schnell und ermöglicht Clients einen Zugriff, bei dem ihre IP-Adresse niemals an Sie übermittelt wird. Der Server selbst bleibt jedoch über seine öffentliche IP-Adresse auffindbar. Der Onion-Hostname aus /var/lib/tor/simplex-smp/hostname wird nach einem Komma an das Ende der Serveradresse gesetzt. Wenn auch der Standort des Servers verborgen werden soll, ist dafür eine andere Konfiguration erforderlich. Ein echter Onion Service auf einem VPS erläutert diesen Zielkonflikt. Der Unterschied zwischen den Informationen, die die jeweiligen Tools verbergen, ist das Thema von Tor im Vergleich zu einem VPN. Das gilt hier direkt.

Bedrohungsmodell: Was Self-Hosting ändert

Was Sie dadurch gewinnen. Die Metadaten – welche Warteschlangen existieren, wann sie gelesen werden und welche Adressen eine Verbindung herstellen – liegen auf einer von Ihnen kontrollierten Maschine. Sie legen fest, wie lange diese Daten gespeichert werden. Außerdem gehören Sie nicht zu einem großen Pool, dessen Daten gesammelt angefordert werden können.

Was Sie dadurch nicht gewinnen, klar gesagt:

• Die Verschlüsselung bleibt unverändert. Die Nachrichten waren bereits vor dem Aufbau dieses Systems Ende-zu-Ende-verschlüsselt und sind es danach weiterhin. Self-Hosting ist eine Entscheidung über Metadaten, nicht über Kryptografie.
• Ihr VPS-Provider sieht den Netzwerkverkehr zu Ihrer IP-Adresse und speichert Ihre Abrechnungsdaten. Sie verlagern das Vertrauen von einem Messaging-Betreiber zu einem Hosting-Betreiber. Sie entfernen es nicht.
• Ihr Relay bildet eine kleine Gruppe. Wenn es nur von einem Haushalt genutzt wird, identifiziert die Verbindung diesen Haushalt. Außerdem steht sein Hostname in jedem Einladungslink, den Sie darüber senden. Ein stark frequentiertes öffentliches Relay schützt Ihre Identität in diesem einen Punkt besser. Genau darin besteht der tatsächliche Kompromiss. Bei einem privaten Suchserver gilt dasselbe. Deshalb hängt was SearXNG auf Ihrem eigenen VPS tatsächlich verbirgt davon ab, wie viele Personen die Instanz mit Ihnen gemeinsam nutzen.
• Die Verfügbarkeit liegt jetzt in Ihrer Verantwortung. Eine volle Festplatte oder ein ausgefallener Rechner führt dazu, dass Nachrichten nicht mehr zugestellt werden. Ihre Kontakte können die Verbindung nicht über einen anderen Weg herstellen.

Dasselbe gilt für jeden privaten Dienst, den Sie auf einer eigenen Maschine betreiben, unabhängig davon, ob es sich um dieses Relay oder ein WireGuard-VPN auf Ihrem eigenen VPS handelt. Sie entscheiden, welche Partei die Metadaten sieht. Sie lassen die Metadaten nicht verschwinden.

Wenn es nicht funktioniert

Der Dienst startet und wird sofort beendet. Lesen Sie sudo journalctl -u smp-server -n 50. Ein Bind-Fehler nennt den Port, den der Dienst nicht belegen konnte. Führen Sie anschließend sudo ss -tlnp | grep :443 aus, um zu sehen, welcher Prozess den Port bereits verwendet. Auf einem frisch eingerichteten System ist das normalerweise nginx, Caddy oder der XFTP-Server, den Sie vor einer Stunde installiert haben.

Init kann seine Konfiguration nicht schreiben. Wenn Sie smp-server init als Benutzer smp ausführen, bevor /etc/opt/simplex vorhanden ist, wird ein Berechtigungsfehler ausgegeben, weil /etc/opt root gehört. Erstellen Sie das Verzeichnis zuerst mit dem richtigen Eigentümer und führen Sie init anschließend erneut aus.

Clients können das Relay nicht erreichen. Prüfen Sie mit dig +short smp1.example.com, ob der Name zur richtigen Adresse aufgelöst wird. Testen Sie den Port anschließend von Ihrem Laptop aus, nicht vom Server: nc -vz smp1.example.com 5223. Wenn die Verbindung von außen fehlschlägt, während ss den offenen Socket auf dem System anzeigt, liegt die Ursache wahrscheinlich in der Netzwerk-Firewall des Providers. Diese ist eine separate Kontrolle neben ufw.

Ein Kontakt kann über Ihr Relay keine Verbindung herstellen. Der Fingerabdruck in der von Ihnen freigegebenen Adresse muss mit dem aktuellen Inhalt von /etc/opt/simplex/fingerprint übereinstimmen. Wenn Sie create_password unter [AUTH] festgelegt haben, muss die Adresse dieses Passwort ebenfalls enthalten. Andernfalls darf der Client keine Warteschlange erstellen.

Nach dem Hinzufügen des Servers in der Anwendung wurde nichts übertragen. Das ist beabsichtigt. Nur neue Kontakte verwenden das neu hinzugefügte Relay. Bestehende Kontakte behalten ihre bereits vorhandenen Warteschlangen.

FAQ

Macht Self-Hosting eines SimpleX-Servers meine Nachrichten sicherer?

Nein, und das ist beabsichtigt. SimpleX verschlüsselt Nachrichten Ende-zu-Ende zwischen den Geräten, sodass das Relay niemals über die Schlüssel verfügt, unabhängig davon, wer es betreibt. Self-Hosting ändert, wer die Metadaten zu diesen Nachrichten beobachten kann: welche Warteschlangen existieren, wann sie gelesen werden und welche IP-Adressen eine Verbindung herstellen. Es handelt sich um eine Metadatenentscheidung. Wenn der Grund für Self-Hosting eine stärkere Verschlüsselung ist, war die Verschlüsselung bereits vorhanden.

Was kann ein Betreiber eines SimpleX-Relays tatsächlich sehen?

Das Projekt beschreibt dies in protocol/security.md. Ein Relay kann weder Nachrichteninhalte noch Nachrichtentypen lesen, einzelne Nachrichten nicht unbemerkt verändern und die Ende-zu-Ende-Verschlüsselung nicht durch einen aktiven Angriff brechen. Es kann sehen, wann der Empfänger einer Warteschlange online ist, die über eine Warteschlange übertragenen Nachrichten zählen, die IP-Adresse eines Empfängers erfahren, zukünftige Nachrichten in einer Warteschlange verwerfen oder über den Zustand dieser Warteschlange lügen. Über diese Möglichkeiten verfügen Sie, sobald das Relay Ihnen gehört.

Benötige ich einen Domainnamen und ein TLS-Zertifikat?

Für eine nutzbare Einrichtung benötigen Sie eine Domain. smp-server init akzeptiert --ip, wenn Sie tatsächlich keine Domain haben. Für den Messaging-Port benötigen Sie kein Zertifikat einer öffentlichen Zertifizierungsstelle: init erzeugt seine eigene Zertifizierungsstelle, und der Client pinnt den Fingerabdruck, der in Ihrer smp://-Adresse erscheint. Ein öffentlich vertrauenswürdiges Zertifikat ist nur für die optionale Web-Informationsseite erforderlich. Diese wird in smp-server.ini im Abschnitt [WEB] als cert und key konfiguriert.

Was geschieht, wenn ich /etc/opt/simplex verliere?

Jede von Ihnen verteilte Adresse funktioniert dann nicht mehr. Dieses Verzeichnis enthält die Zertifizierungsstelle, deren Fingerabdruck in Ihrer Serveradresse eingebettet ist. Ein Neuaufbau erzeugt daher einen anderen Fingerabdruck und damit einen anderen Server. Kontakte, deren Warteschlangen auf diesem Relay liegen, können nicht clientseitig repariert werden. Sichern Sie das Verzeichnis verschlüsselt außerhalb des Servers und bewahren Sie ca.key offline auf, wie es die Dokumentation vorgibt. Wer darüber verfügt, kann sich als Ihr Relay ausgeben.

Kann ich das SMP-Relay und das XFTP-Dateirelay auf demselben VPS betreiben?

Ja, wobei ein Konflikt gelöst werden muss. Der dokumentierte Port des XFTP-Servers ist 443, und die Standardkonfiguration von SMP enthält port: 5223,443. Beide benötigen daher denselben Socket. Weisen Sie Port 443 einem der beiden Dienste zu: Setzen Sie port: 5223 für den SMP-Server, oder verschieben Sie das Dateirelay auf eine zweite IP-Adresse beziehungsweise einen zweiten VPS. Dimensionieren Sie außerdem das Speicherkontingent nach dem tatsächlich verfügbaren Speicherplatz. Das Dateirelay verbraucht den Speicherplatz und die Bandbreite.