Seal

Chat peer-to-peer, cifrata end-to-end.
Niente inbox. Nessun account da recuperare. Nessuno ascolta — nemmeno noi.

I messaggi viaggiano direttamente tra i peer tramite libp2p e vengono cifrati con i protocolli Olm/Megolm in stile Signal (via vodozemac) prima ancora di lasciare il tuo dispositivo. L'unico server coinvolto è una piccola directory che aiuta i peer a trovare l'indirizzo attuale degli altri. Non vede mai il contenuto dei messaggi e può essere eliminata con un solo comando.

Consulta docs/THREAT_MODEL.md e docs/SECURITY.md per sapere cosa è realmente protetto e come.

Contenuti

Schermate
Funzionalità
Come funziona
Struttura del progetto
1. Prerequisiti
2. Compilazione
3. Esecuzione in modalità di sviluppo
4. Test
5. Configurazione del backend (directory server)
6. Utilizzo dell'app

Schermate

Prima esecuzione — scegli un nome; non c'è altro da configurare.

Schermata di primo avvio di Seal: una spiegazione del modello di cifratura accanto a un modulo per il nome visualizzato, con un'opzione di avvio al login

Conversazioni — la barra dei gruppi, l'elenco dei contatti e un pannello di chat cifrata end-to-end.

Una conversazione diretta in Seal, con la barra dei gruppi, l'elenco dei contatti e il pannello di chat cifrata end-to-end

Impostazioni — sensibilità del microfono, push-to-talk, avvio al login, raggiungibilità di rete.

Pannello impostazioni di Seal: sensibilità del microfono, push-to-talk, avvio al login e raggiungibilità di rete

Funzionalità

Cifratura end-to-end, sempre — ogni messaggio viene sigillato con Olm (1:1) o Megolm (gruppi) prima ancora di lasciare il tuo dispositivo, usando lo schema in stile Double Ratchet di vodozemac: ogni messaggio ha la propria chiave.
Niente inbox, mai — i messaggi viaggiano su una connessione peer-to-peer diretta (libp2p: QUIC/TCP + Noise, con relay e hole-punching per i NAT). Se il destinatario è offline, il messaggio resta in attesa in locale e riprova: non viene mai accodato sull'infrastruttura di altri.
Una directory, non un database — l'unico server coinvolto (crates/directory-server) associa un ID utente a un indirizzo di rete corrente e nient'altro. È strutturalmente incapace di leggere il contenuto dei messaggi: il suo Cargo.toml non dipende nemmeno dai crate che saprebbero come farlo.
Più account, un solo dispositivo — identità completamente separate (chiavi, contatti, messaggi) tra cui puoi passare senza riavviare.
Gruppi con modifiche reali dei membri — canali di testo e voce per gruppo; rimuovere qualcuno ruota la chiave del gruppo così non può leggere nulla inviato in seguito.
Voce integrata — push-to-talk con una scorciatoia di sistema (funziona da qualsiasi app, non solo da Seal), sensibilità del microfono regolabile e un voice changer opzionale.
Allegati senza metadati — i dati EXIF (posizione GPS, informazioni su fotocamera/dispositivo) vengono rimossi dalle immagini prima dell'invio, attivo per impostazione predefinita.
Un vero pulsante di emergenza — Impostazioni → Dati e privacy elimina istantaneamente e irreversibilmente ogni chiave, contatto e messaggio su questo dispositivo, senza alcun effetto su chiunque tu abbia contattato.
Avvio al login, se lo desideri — attivo per impostazione predefinita, a un interruttore di distanza nelle Impostazioni.
Un'unica codebase, tre piattaforme — finestre native su macOS, Windows e Linux, tramite Tauri.

Come funziona

In questa app esistono due tipi di identità, e sono tenuti volutamente separati:

La tua identità di chat è una coppia di chiavi Ed25519/Curve25519 generata localmente da vodozemac la prima volta che apri l'app (identity::Identity). Il tuo "user ID" pubblico è semplicemente l'impronta di quella chiave (wire_proto::user_id_from_ed25519). Non può essere emesso o revocato da alcun server, perché nessun server è coinvolto nella sua creazione.
La tua identità di rete è una coppia di chiavi libp2p separata (PeerId), usata solo per il livello di trasporto. Può cambiare tra un riavvio e l'altro senza influire affatto sulla tua identità di chat; le due sono legate solo da un record di presenza che firmi tu stesso.

Trovare qualcuno e parlarci davvero sono due passaggi diversi:``` ┌────────────────────────┐ │ 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 cerca Bob nella directory tramite il suo ID utente. Questo restituisce
   le sue chiavi pubbliche e il suo ultimo indirizzo di rete annunciato. È tutto
   ciò che la directory contiene: chiavi pubbliche, nomi di visualizzazione,
   liste di appartenenza ai gruppi e annunci di indirizzo di breve durata
   (`crates/directory-server`).
2. Alice contatta Bob direttamente tramite libp2p (QUIC o TCP+Noise, con relay +
   hole-punching per i peer dietro NAT; vedi `crates/net`). La directory è
   completamente fuori gioco da qui in poi.
3. Il messaggio vero e proprio è cifrato con **Olm** per una chat 1:1, o
   **Megolm** per un gruppo (`crates/crypto-session`), uno schema in stile Double-Ratchet
   in cui ogni messaggio ha la propria chiave, prima di essere messo su
   quella connessione libp2p. Non esiste una casella di posta lato server: se Bob è offline,
   il messaggio attende in locale e viene ritentato, non viene memorizzato su infrastruttura
   di nessun altro.

Tutto quanto sopra è orchestrato dall'`AppService` di `crates/core`, che è
ciò che il backend Rust dell'app Tauri (`apps/desktop/src-tauri`) richiama effettivamente;
la UI non comunica mai direttamente con la rete.

## Struttura del progetto```
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. Prerequisiti

Hai bisogno di Rust e Node.js su ogni piattaforma, oltre a una toolchain specifica per piattaforma di cui Tauri ha bisogno per creare una finestra nativa. storage e directory-server compilano anche SQLite dal sorgente in bundle, il che richiede un semplice compilatore C (non è richiesta OpenSSL né alcuna altra libreria crittografica nativa in questo progetto).

Comune a tutte le piattaforme:

Rust (canale stabile; installa tramite rustup, non tramite il gestore pacchetti del tuo sistema operativo)
Node.js 20+ e npm

macOS

```sh xcode-select --install ``` Tutto qui. Gli Xcode Command Line Tools forniscono sia il compilatore C che i framework necessari al backend macOS di Tauri (basato su WKWebView).

Linux

Installa un compilatore C, pkg-config, e i pacchetti di sviluppo WebKitGTK/AppIndicator a cui il backend Linux di Tauri si collega.

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"

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

(I nomi dei pacchetti cambiano tra le release di Tauri: se una build fallisce cercando un
file `.pc` mancante, controlla i
[prerequisiti Tauri Linux attuali](https://v2.tauri.app/start/prerequisites/)
per la tua distribuzione.)

</details>

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

1. Installa il **Microsoft C++ Build Tools** (Visual Studio Installer →
   carico di lavoro "Sviluppo desktop con C++"), necessario sia per la shell
   nativa di Tauri sia per compilare il SQLite incluso.
2. Installa il toolchain Rust **MSVC**: `rustup default stable-msvc`.
3. **WebView2**: già presente su Windows 11 e sulla maggior parte delle installazioni
   Windows 10 aggiornate; in caso contrario, la build di Tauri ti chiederà di installare
   il runtime Evergreen.

</details>

---

## 2. Build

Dalla radice del repository:```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

Note:

- `DIRECTORY_PUBLIC_ADDR` è volutamente associato a **loopback**; metti un
  reverse proxy davanti per TLS (vedi sotto) invece di esporre axum direttamente
  a internet.
- Crea prima l'utente/gruppo di sistema `seal-directory` e
  `/var/lib/seal-directory` (`useradd --system --no-create-home
  seal-directory && install -d -o seal-directory -g seal-directory
  /var/lib/seal-directory`), poi copia il binario `directory-server` compilato
  (da `target/release/`) in `/usr/local/bin/`.
- Metti il token admin in un `EnvironmentFile` leggibile solo da root, non direttamente
  nel file unit (i file unit sono spesso leggibili da tutti).

</details>

### TLS tramite un reverse proxy

<details>
<summary>Mostra la configurazione di Caddy / nginx</summary>

[Caddy](https://caddyserver.com) ti offre HTTPS automatico con il minimo
di configurazione:```
# /etc/caddy/Caddyfile
directory.example.com {
    reverse_proxy 127.0.0.1:8080
}

caddy run (o systemctl enable --now caddy) gestisce l'emissione e il rinnovo dei certificati autonomamente. Se preferisci usare nginx, termina la TLS lì e usa proxy_pass http://127.0.0.1:8080;, poiché l'app ha bisogno solo di HTTP semplice dal punto di vista del proxy.

Per quanto riguarda il firewall: solo la porta pubblica deve essere raggiungibile dall'esterno (8080 negli esempi precedenti, con la 443 come front-end tramite il proxy). La porta di amministrazione non dovrebbe mai essere raggiungibile dall'esterno; raggiungila tramite port-forwarding SSH (ssh -L 8090:127.0.0.1:8090 your-server) quando devi eseguire una pulizia da remoto.

Questo elimina il file SQLite e ricrea uno schema vuoto: nessuna istruzione `DELETE`, nessuno stato parziale. È sicuro eseguirlo senza avvisare prima nessuno: ogni record in esso è una cache di dati che ciascun client possiede già localmente (la propria registrazione, presenza e qualsiasi elenco di gruppo di cui è membro), quindi i client lo ripopolano entro pochi istanti dalla loro azione successiva. Non esiste deliberatamente alcuna policy di backup per questo database; vedi [`docs/SECURITY.md`](https://github.com/emn4tor/seal/blob/HEAD/docs/SECURITY.md) per capire perché mantenerne una minerebbe l'intero scopo. --- ## 6. Usare l'app 1. **Primo avvio, prima domanda**: quale server di directory usare (§3). Il predefinito è ciò che è incorporato nella build in esecuzione (un server di test locale, a meno che chi l'ha creata non ne abbia configurato uno ufficiale); scegli "Server personalizzato" per puntare a uno ospitato da te o da qualcuno di cui ti fidi. 2. **Scegli un nome visualizzato.** Questo genera una coppia di chiavi private sul tuo dispositivo (niente da ricordare, e nulla di recuperabile se perso: è intenzionale) e ti guida attraverso una breve spiegazione in-app di come la crittografia funziona davvero. Puoi rivederla in qualsiasi momento dalle Impostazioni. Ogni successivo avvio torna direttamente all'app senza alcun prompt; questo accade solo una volta per account. Aggiungi altri account (identità completamente separate) da Impostazioni → Account su questo dispositivo e passa dall'uno all'altro senza riavviare. 3. **Aggiungi qualcuno**: clicca su **+** accanto a "Direct messages" e inserisci il suo ID (trovato nelle *sue* Impostazioni → La mia identità). Non c'è una directory da consultare, per scelta progettuale; ti connetti allo stesso modo in cui condivideresti un numero di telefono. 4. **Scrivi loro**: scegli il loro nome dall'elenco e digita. Il primo messaggio a qualcuno stabilisce automaticamente una sessione crittografata. 5. **Crea un gruppo**: clicca su **+** nella barra delle icone, dagli un nome, poi invita le persone tramite ID allo stesso modo. Rimuovere qualcuno ruota la chiave del gruppo così non possono leggere nulla inviato in seguito. 6. **Elimina tutto**: Impostazioni → Dati e privacy. Questa azione è immediata, solo locale e irreversibile: distrugge le tue chiavi, i contatti e la cronologia su *questo dispositivo* e non ha alcun effetto su nessuno con cui hai parlato.

Script	Produce
`scripts/build-mac-dmg.sh`	Installer macOS `.dmg`
`scripts/build-mac-app.sh`	Bundle macOS `.app` grezzo, senza installer
`scripts/build-linux.sh`	Linux `.AppImage` + `.deb`
`scripts/build-windows.ps1`	Windows `.msi` + `.exe` (NSIS)

Seal

Più Popolari

Oppure usa gli script

Integrare la propria rete "Seal"

Scelta del server (primo avvio)

Testare con una build reale (non in modalità dev)```sh

5. Configurazione del backend (directory server)

Percorso più rapido: lo script di setup```sh

Esecuzione locale rapida```sh

Eseguirlo come un vero servizio (systemd)

Sandboxing: this process needs almost nothing

Come eseguire la pulizia```sh