Seal

Peer-to-Peer-Chat mit Ende-zu-Ende-Verschlüsselung.
Kein Posteingang. Kein Konto, das wiederhergestellt werden müsste. Niemand hört mit — nicht einmal wir.

github.com/Emn4tor/Seal

Nachrichten werden direkt zwischen Peers über libp2p übertragen und mit den Signal-artigen Olm/Megolm-Protokollen verschlüsselt (über vodozemac), bevor sie dein Gerät verlassen. Der einzige beteiligte Server ist ein kleines Verzeichnis, das Peers dabei hilft, die aktuelle Adresse des jeweils anderen zu finden. Es sieht nie Nachrichteninhalte und kann mit einem einzigen Befehl gelöscht werden.

Siehe docs/THREAT_MODEL.md und docs/SECURITY.md für Details dazu, wogegen tatsächlich geschützt wird und wie.

Inhalt

Screenshots
Funktionen
So funktioniert es
Projektstruktur
1. Voraussetzungen
2. Kompilieren
3. Im Entwicklermodus ausführen
4. Testen
5. Backend-(Verzeichnisserver-)Einrichtung
6. Die App verwenden

Screenshots

Erster Start — Namen wählen; sonst ist nichts einzurichten.

Seals Erster-Start-Bildschirm: eine Erklärung des Verschlüsselungsmodells neben einem Anzeigenamen-Formular, mit einem Anmelden-bei-Start-Schalter

Unterhaltungen — die Gruppenleiste, Kontaktliste und ein Ende-zu-Ende-verschlüsselter Chat-Bereich.

Eine Direktnachrichten-Unterhaltung in Seal mit Gruppenleiste, Kontaktliste und Ende-zu-Ende-verschlüsseltem Chat-Bereich

Einstellungen — Mikrofonempfindlichkeit, Push-to-Talk, Anmelden bei Start, Netzwerkerreichbarkeit.

Seals Einstellungsbereich: Mikrofonempfindlichkeit, Push-to-Talk, Anmelden bei Start und Netzwerkerreichbarkeit

Funktionen

Immer Ende-zu-Ende-verschlüsselt — jede Nachricht wird mit Olm (1:1) oder Megolm (Gruppen) versiegelt, bevor sie dein Gerät verlässt, und zwar mithilfe von vodozemacs Double-Ratchet-artigem Schema: Jede Nachricht erhält ihren eigenen Schlüssel.
Nie ein Posteingang — Nachrichten werden über eine direkte Peer-to-Peer-Verbindung übertragen (libp2p: QUIC/TCP + Noise, mit Relay und Hole-Punching für NATs). Ist der Empfänger offline, wartet die Nachricht lokal und versucht es erneut — sie wird nie in der Infrastruktur anderer in eine Warteschlange gestellt.
Ein Verzeichnis, keine Datenbank — der eine beteiligte Server (crates/directory-server) bildet eine Benutzer-ID auf eine aktuelle Netzwerkadresse ab und sonst nichts. Er ist strukturell nicht in der Lage, Nachrichteninhalte zu lesen: Seine Cargo.toml hängt nicht einmal von den Crates ab, die dafür nötig wären.
Mehrere Konten auf einem Gerät — vollständig getrennte Identitäten (Schlüssel, Kontakte, Nachrichten), zwischen denen du ohne Neustart wechseln kannst.
Gruppen mit echten Mitgliedschaftsänderungen — Text- und Sprachkanäle pro Gruppe; das Entfernen einer Person rotiert den Gruppen- schlüssel, sodass sie nichts mehr lesen kann, was danach gesendet wird.
Integrierte Sprachfunktion — Push-to-Talk über einen systemweiten Shortcut (funktioniert aus jeder App, nicht nur aus Seal), einstellbare Mikrofonempfindlichkeit und ein optionaler Stimmverzerrer.
Anhänge ohne Metadaten — EXIF-Daten (GPS-Standort, Kamera-/ Geräteinformationen) werden standardmäßig aus Bildern entfernt, bevor sie gesendet werden.
Ein echter Panikknopf — Einstellungen → Daten & Datenschutz löscht sofort und unwiderruflich jeden Schlüssel, Kontakt und jede Nachricht auf diesem Gerät — ohne jede Auswirkung auf Personen, mit denen du gesprochen hast.
Anmelden bei Start, falls gewünscht — standardmäßig aktiviert, in den Einstellungen per Schalter deaktivierbar.
Eine Codebasis, drei Plattformen — native Fenster auf macOS, Windows und Linux, über Tauri.

So funktioniert es

Es gibt zwei Arten von Identitäten in dieser App, die bewusst getrennt gehalten werden:

Deine Chat-Identität ist ein lokal erzeugtes Ed25519/Curve25519- Schlüsselpaar von vodozemac beim ersten Öffnen der App (identity::Identity). Deine öffentliche „Benutzer-ID“ ist lediglich der Fingerabdruck dieses Schlüssels (wire_proto::user_id_from_ed25519). Sie kann von keinem Server ausgestellt oder widerrufen werden, weil kein Server an ihrer Erstellung beteiligt ist.
Deine Netzwerk-Identität ist ein separates libp2p-Schlüsselpaar (PeerId), das nur für die Transportschicht verwendet wird. Es kann sich bei Neustarts ändern, ohne deine Chat-Identität im Geringsten zu beeinträchtigen; die beiden sind nur durch einen Presence-Datensatz verbunden, den du selbst signierst.

Jemanden zu finden und tatsächlich mit ihm zu sprechen, sind zwei verschiedene Schritte:``` ┌────────────────────────┐ │ directory server │ │ (axum + one SQLite │ │ file: users, │ │ presence, group │ │ rosters. Never │ │ message content.) │ └─────────┬───────────────┘ 1. "where is bob │ 2. "here's my current right now?" │ address" (signed, │ expires in minutes) ┌─────────┴───────────────┐ ▼ ▼ ┌───────┐ 3. direct libp2p ┌───────┐ │ alice │◄──── connection ────►│ bob │ └───────┘ (Noise + Olm/ └───────┘ Megolm encrypted)

1. Alice schlägt Bob im Verzeichnis über seine Benutzer-ID nach. Das liefert seine
   öffentlichen Schlüssel und seine zuletzt bekannt gegebene Netzwerkadresse. Das ist der gesamte
   Inhalt des Verzeichnisses: öffentliche Schlüssel, Anzeigenamen,
   Gruppenmitgliedschaftslisten und kurzlebige Adressankündigungen
   (`crates/directory-server`).
2. Alice verbindet sich direkt mit Bob über libp2p (QUIC oder TCP+Noise, mit Relay +
   Hole-Punching für Peers hinter NATs; siehe `crates/net`). Das Verzeichnis ist
   von hier an komplett aus dem Spiel.
3. Die eigentliche Nachricht wird mit **Olm** für einen 1:1-Chat oder
   **Megolm** für eine Gruppe (`crates/crypto-session`), einem Schema im Double-Ratchet-Stil,
   bei dem jede Nachricht ihren eigenen Schlüssel erhält, bevor sie jemals auf
   die libp2p-Verbindung gelegt wird. Es gibt keine serverseitige Inbox: Wenn Bob offline ist,
   wartet die Nachricht lokal und wird erneut gesendet, statt auf der Infrastruktur anderer
   gespeichert zu werden.

Alles oben Genannte wird von `crates/core`'s `AppService` orchestriert, auf den
das Rust-Backend der Tauri-App (`apps/desktop/src-tauri`) tatsächlich zugreift;
die UI spricht nie direkt mit dem Netzwerk.

## Projektstruktur```
crates/
  wire-proto        shared signed-request types for the directory API
  identity          vodozemac identity, OS-keychain key management
  storage           local encrypted store (contacts, messages, groups)
  net               libp2p transport + directory HTTP client
  crypto-session    Olm (1:1) / Megolm (group) session management
  core              orchestrates the above into `AppService` / `ChatNode`
  directory-server  the one server component (axum + SQLite)
apps/desktop         the Tauri + React app
scripts/             build + backend-deployment scripts (§2, §5)

1. Voraussetzungen

Auf jeder Plattform benötigst du Rust und Node.js sowie eine plattformspezifische Toolchain, die Tauri zum Erstellen eines nativen Fensters benötigt. storage und directory-server kompilieren SQLite außerdem gebündelt aus dem Quellcode, was einen einfachen C-Compiler benötigt (kein OpenSSL oder andere native Kryptobibliothek wird irgendwo in diesem Projekt benötigt).

Für alle Plattformen gemeinsam:

Rust (stabiler Kanal; Installation über rustup, nicht über den Paketmanager deines Betriebssystems)
Node.js 20+ und npm

macOS

```sh xcode-select --install ``` Das war's. Die Xcode Command Line Tools stellen sowohl den C-Compiler als auch die Frameworks bereit, die Tauris macOS-Backend (WKWebView-basiert) benötigt.

Linux

Installiere einen C-Compiler, pkg-config und die WebKitGTK/AppIndicator-Entwicklungspakete, gegen die Tauris Linux-Backend linkt.

Debian/Ubuntu:```sh sudo apt update sudo apt install libwebkit2gtk-4.1-dev build-essential curl wget file
libxdo-dev libssl-dev libayatana-appindicator3-dev librsvg2-dev pkg-config

Fedora:```sh
sudo dnf install webkit2gtk4.1-devel openssl-devel curl wget file \
  libappindicator-gtk3-devel librsvg2-devel pkgconf-pkg-config
sudo dnf group install "C Development Tools and Libraries"

Arch:```sh sudo pacman -S --needed webkit2gtk-4.1 base-devel curl wget file openssl
appmenu-gtk-module libappindicator-gtk3 librsvg pkgconf

(Paketnamen ändern sich zwischen Tauri-Releases: Wenn ein Build fehlschlägt, weil eine
`.pc`-Datei fehlt, prüfe die
[aktuellen Tauri-Linux-Voraussetzungen](https://v2.tauri.app/start/prerequisites/)
für deine Distribution.)

</details>

<details>
<summary><strong>Windows</strong></summary>

1. Installiere die **Microsoft C++ Build Tools** (Visual Studio Installer →
   Workload „Desktopentwicklung mit C++"), die sowohl für die native Tauri-Shell
   als auch zum Kompilieren des gebündelten SQLite benötigt werden.
2. Installiere die **MSVC**-Rust-Toolchain: `rustup default stable-msvc`.
3. **WebView2**: bereits auf Windows 11 und den meisten aktuellen Windows-
   10-Installationen vorhanden; falls nicht, wirst du vom Tauri-Build aufgefordert,
   die Evergreen-Runtime zu installieren.

</details>

---

## 2. Erstellen

Vom Repository-Stammverzeichnis aus:```sh
# Rust workspace (backend crates + the directory server)
cargo build --workspace --release

# Frontend + the actual desktop app bundle (installer/.app/.exe)
cd apps/desktop
npm install
npm run tauri build

Sandboxing: this process needs almost nothing

ProtectSystem=strict ProtectHome=true PrivateTmp=true NoNewPrivileges=true ReadWritePaths=/var/lib/seal-directory

[Install] WantedBy=multi-user.target

Hinweise:

- `DIRECTORY_PUBLIC_ADDR` ist hier absichtlich an **Loopback** gebunden; setzen Sie für TLS einen Reverse-Proxy davor (weiter unten), anstatt axum direkt dem Internet auszusetzen.
- Erstellen Sie zuerst das Systembenutzer/-gruppenkonto `seal-directory` und `/var/lib/seal-directory` (`useradd --system --no-create-home seal-directory && install -d -o seal-directory -g seal-directory /var/lib/seal-directory`), und kopieren Sie die gebaute `directory-server`-Binärdatei (aus `target/release/`) nach `/usr/local/bin/`.
- Legen Sie das Admin-Token in eine nur für Root lesbare `EnvironmentFile`, nicht direkt in die Unit-Datei (Unit-Dateien sind oft für alle Benutzer lesbar).

</details>

### TLS über einen Reverse-Proxy

<details>
<summary>Caddy-/nginx-Konfiguration anzeigen</summary>

[Caddy](https://caddyserver.com) liefert automatisches HTTPS mit dem geringsten Konfigurationsaufwand:```
# /etc/caddy/Caddyfile
directory.example.com {
    reverse_proxy 127.0.0.1:8080
}

caddy run (oder systemctl enable --now caddy) übernimmt die Ausstellung/Erneuerung von Zertifikaten von selbst. Wenn Sie lieber nginx verwenden möchten, beenden Sie TLS dort und proxy_pass http://127.0.0.1:8080;, da die App aus Sicht des Proxys nur einfaches HTTP benötigt.

Was die Firewall betrifft: Nur der öffentliche Port muss von außen erreichbar sein (8080 in den obigen Beispielen, über den Proxy durch 443 abgesichert). Der Admin-Port sollte niemals von außen erreichbar sein; erreichen Sie ihn über SSH-Portweiterleitung (ssh -L 8090:127.0.0.1:8090 your-server), wenn Sie eine Bereinigung remote ausführen müssen.

Dies löscht die SQLite-Datei und erstellt ein leeres Schema neu: keine `DELETE`-Anweisungen, kein teilweiser Zustand. Es kann gefahrlos ausgeführt werden, ohne vorher jemanden zu warnen: Jeder Datensatz darin ist ein Cache von Daten, die jeder Client bereits lokal besitzt (seine eigene Registrierung, Präsenz und alle Gruppen-Roster, in denen er Mitglied ist), sodass Clients sie innerhalb von Augenblicken nach ihrer nächsten Aktion wieder neu befüllen. Es gibt bewusst keine Backup-Strategie für diese Datenbank; siehe [`docs/SECURITY.md`](https://github.com/emn4tor/seal/blob/HEAD/docs/SECURITY.md) für den Grund, warum ein Backup den ganzen Zweck untergraben würde. --- ## 6. Verwendung der App 1. **Erster Start, erste Frage**: Welcher Verzeichnisserver verwendet werden soll (§3). Der Standardwert ist das, was in den Build fest eingebaut ist, den du ausführst (ein lokaler Testserver, sofern derjenige, der ihn gebaut hat, keinen offiziellen konfiguriert hat); wähle „Benutzerdefinierter Server", um auf einen zu zeigen, den du oder jemand, dem du vertraust, hostet. 2. **Wähle einen Anzeigenamen.** Dadurch wird auf deinem Gerät ein privates Schlüsselpaar erzeugt (nichts zum Merken und nichts Wiederherstellbares, falls es verloren geht: das ist beabsichtigt) und du wirst durch eine kurze In-App-Erklärung geführt, wie die Verschlüsselung tatsächlich funktioniert. Du kannst sie jederzeit über die Einstellungen erneut ansehen. Bei jedem späteren Start geht es ohne Aufforderung direkt weiter; dies geschieht nur einmal pro Konto. Füge weitere Konten (vollständig getrennte Identitäten) über Einstellungen → Konten auf diesem Gerät hinzu und wechsle ohne Neustart zwischen ihnen. 3. **Jemanden hinzufügen**: Klicke auf **+** neben „Direktnachrichten" und gib deren ID ein (zu finden in *deren* Einstellungen → Meine Identität). Es gibt bewusst kein Verzeichnis zum Durchsuchen; du verbindest dich auf dieselbe Weise, wie du eine Telefonnummer teilen würdest. 4. **Nachricht senden**: Wähle den Namen der Person aus der Liste und tippe. Die erste Nachricht an jemanden richtet automatisch eine verschlüsselte Sitzung ein. 5. **Eine Gruppe starten**: Klicke in der Symbolleiste auf **+**, gib ihr einen Namen und lade dann auf dieselbe Weise Leute per ID ein. Das Entfernen einer Person rotiert den Gruppenschlüssel, sodass diese Person nichts lesen kann, was danach gesendet wird. 6. **Alles löschen**: Einstellungen → Daten & Datenschutz. Dies ist sofortig, nur lokal und unumkehrbar: Es zerstört deine Schlüssel, Kontakte und den Verlauf auf *diesem Gerät* und hat keinerlei Auswirkung auf Personen, mit denen du gesprochen hast.

Skript	Erzeugt
`scripts/build-mac-dmg.sh`	macOS `.dmg`-Installer
`scripts/build-mac-app.sh`	Rohes `.app`-Bundle für macOS, kein Installer
`scripts/build-linux.sh`	Linux `.AppImage` + `.deb`
`scripts/build-windows.ps1`	Windows `.msi` + `.exe` (NSIS)

Seal

Beliebteste

Oder verwende die Skripte

Ein eigenes "Seal"-Netzwerk einbauen

Einen Server auswählen (erster Start)

Testen gegen einen echten Build (nicht Dev-Modus)```sh

5. Einrichtung des Backends (Verzeichnisservers)

Schnellster Weg: das Setup-Skript```sh

Schneller lokaler Start```sh

Als echten Dienst betreiben (systemd)

Sandboxing: this process needs almost nothing

Bereinigen```sh