Version 2.
Live-first und Privacy-Tunnel.

1. Die festgehaltene Richtung

Sieben Leitplanken bilden den Ausgangspunkt. Jede davon muss noch gegen reale Clients, Ausfälle, Plattformgrenzen und das gemeinsame Threat Model geprüft werden.

1. Die Absender-Outbox bleibt bis zu einem authentisierten E2E-Empfangsnachweis die autoritative Kopie einer Sendung.
2. Das Relay versucht zuerst eine flüchtige Live-Weiterleitung und persistiert im erfolgreichen Live-Pfad keinen Nachrichtenpayload.
3. Ist Live-Zustellung nicht möglich, darf ein optionaler Offline-Fallback den E2E-Ciphertext höchstens 24 Stunden halten.
4. Nach dem E2E-ACK oder spätestens nach 24 Stunden löscht das Relay seine Payloadkopie. Die Absender-Outbox bleibt bis zum echten ACK zuständig.
5. Mehrere Smart-HR-Instanzen dürfen eine Firmen-Outbox nur mit expliziter, atomarer Ownership teilen. Mobile Companion-Geräte werden nie Cache oder Transportpeer für fremde Mitarbeiterdaten.
6. Ein Full-Device-VPN ist keine Relay-Voraussetzung. Bevorzugt wird ein kurzer, app-spezifischer Privacy-Tunnel ausschliesslich für Swiftli-Verkehr.
7. Der Tunnel startet nur für ein Sende-/Empfangs-Sync-Fenster und läuft nicht permanent.

2. Kandidaten-Datenfluss

1. 01Absender-OutboxHält den E2E-Ciphertext, bis der wirkliche Empfänger den Empfang bestätigt.
2. 02On-Demand Privacy-TunnelTransportiert nur Swiftli-Verkehr. Ein stiller ungetunnelter Direkt-Fallback ist ausgeschlossen.
3. 03Getrennter Privacy-IngressPoolt Verbindungen vieler Clients und besitzt keine Kenntnis des inneren Mailboxinhalts.
4. 04Live-Rendezvous RelayLeitet bei erreichbarem Empfänger flüchtig weiter; andernfalls greift optional der zeitlich begrenzte Ciphertext-Fallback.

   Online: flüchtig weiterleiten → authentisiertes E2E-ACK.
   Offline: optional höchstens 24 Stunden E2E-Ciphertext.

Entscheidend: Ein E2E-ACK stammt vom wirklichen Empfänger. Eine Relay-Annahme oder ein HTTP-Status 202 allein darf niemals die Löschung der Absender-Outbox autorisieren.

3. Grenzen des Privacy-Tunnels

Der Tunnel ergänzt die innere Ende-zu-Ende-Verschlüsselung und ersetzt sie nie. VPN-, Ingress-, Relay- und E2E-Schlüssel sowie stabile Identifikatoren werden nicht zusammengelegt.

Für den Zielzustand gelten diese Anforderungen:

• ausschliesslich Relay-Traffic im Tunnel;
• DNS, IPv4 und IPv6 ohne ungetunnelten Leak;
• fail-closed bei Tunnelaufbau oder Tunnelverlust;
• kurzlebige Tunnel-Capabilities, die weder Tenant noch Mitarbeitende lesbar identifizieren;
• keine persistierten Access-, DNS-, Flow- oder individuellen Trafficlogs;
• nur flüchtiger Connection- und Rate-Limit-Zustand im Ingress;
• gepoolte Ingress-zu-Relay-Verbindungen vieler Clients;
• getrennte Infrastruktur, Schlüssel, Administration und Observability von Ingress und Relay;
• ein einziges geschlossenes Relay-Ziel statt eines allgemeinen offenen Proxys.

Vollständig unsichtbar wird der Verkehr dadurch nicht: Der Internetanbieter des Clients sieht weiterhin die Ingress-IP, Dauer und das Gesamtvolumen eines Sync-Fensters. Der Ingress sieht die Client-IP vorübergehend. Das Relay soll dagegen nur gepoolte Ingress-Adressen sehen. Kein einzelner Hop soll Client-IP, innere Mailbox und E2E-Klartext zusammenführen können.

Als Kandidat prüfen wir einen standardisierten MASQUE-/CONNECT-UDP-Pfad nach RFC 9298 und den HTTP-Datagram-/Capsule-Unterbau aus RFC 9297. Ein vorhandener Swiftli-VPN käme erst nach einem Audit von Protokoll, Peer-Identitäten, Logs, DNS-Pfaden, Schlüsselrotation und Betreibertrennung infrage. Eigene VPN-Kryptografie ist ausgeschlossen.

MASQUE und Oblivious HTTP sind dabei Referenzmodelle für standardisierte Transport- beziehungsweise Rollentrennung — kein bereits fertiger Swiftli-Tunnel und keine Aussage, dass eines der Protokolle unverändert passt.

4. On-Demand-Sync

Ein Sync-Fenster kann beginnen, wenn die lokale Outbox eine sendbare Sendung enthält, die App online beziehungsweise aktiv wird und ihren Eingang abfragt oder ein zulässiger Betriebssystem-Hintergrundlauf beginnt.

Im Fenster werden Senden, Empfangen und E2E-ACKs gebündelt. Danach endet der Tunnel ohne permanenten Keepalive. Dauer, Paddingklasse und Jitterverteilung sind bewusst noch offen: Ein exakt pro Nachricht gestarteter Tunnel würde dem Internetanbieter ein zu präzises Zeitmuster liefern. Stromverbrauch, Latenz und Metadatenschutz müssen deshalb gemeinsam gemessen werden.

5. Persistenz- und Löschgrenze

Im Zielbild hält der Live-Pfad Nachrichtenbytes nur flüchtig und begrenzt im Arbeitsspeicher. Der optionale Offline-Fallback darf ausschliesslich die geschlossene Feld-Allowlist eines opaken E2E-Ciphertexts sowie die für Zustellung, Ablauf und Löschung unvermeidbaren pseudonymen Werte persistieren.

Historische Payloadbackups, ein append-only Journal pro Sendung und ein 30-tägiger Relay-Zustellverlauf sind für diesen Kandidaten ausgeschlossen.

6. Was die Transportidee nicht ersetzt

Weniger serverseitige Persistenz nimmt der Protokollsicherheit keine Arbeit ab. Für v2 bleiben insbesondere:

• explizites v2-Re-Pairing und strikte Trennung von v1 und v2;
• E2E-Key-Agreement, Ratchet, Forward Secrecy und Post-Compromise Security;
• Forschung an ML-KEM-basierten hybriden Verfahren, ohne bereits gewählte oder implementierte Suite;
• kanonische Bytes, Domain Separation, AAD und Anti-Downgrade;
• Testvektoren, vollständige Zustandsmodelle und unabhängige Audits.

Voraussichtlich entfallen Teile der serverseitigen Queue-, Receipt-, Recovery- und Crypto-Erasure-Zustände. Gleichzeitig werden Endpoint-Outbox, E2E-ACK, Deduplizierung und Multi-Instanz-Ownership sicherheitskritischer.

FIPS 203 standardisiert ML-KEM, und NIST SP 800-227 gibt KEM-Empfehlungen. RFC 9954 und RFC 10024 betreffen hybride Verfahren in TLS 1.3. Deren Sicherheitsanalyse lässt sich nicht einfach auf das Swiftli-E2E-Protokoll übertragen. Auch das stabile HPKE aus RFC 9180 macht eine Post-Quantum-E2E-Konstruktion nicht automatisch fertig.

7. Erforderliche Read-only-Audits

Smart HR

Wann wird heute eine Outboxzeile gelöscht, und teilen mehrere Instanzen eine atomar geschützte Firmen-Outbox?

Mobile Companion

Wie verhalten sich lokale Outbox, At-rest-Schutz, Deduplizierung und Löschauthority nach Neustart oder Geräteverlust?

Gemeinsamer E2E-ACK

Wer erzeugt, authentisiert, persistiert und bestätigt ihn? Kann ein Relay-Status heute fälschlich als Empfänger-ACK wirken?

Swiftli-VPN

Protokoll, stabile Peerkennungen, DNS/IPv6, Logs, Hosterpfade, Schlüsselrotation, Plattformintegration und Stromprofil.

Relay

Welche heutigen Tabellen und Automaten entfallen im Live-first-Kandidaten, und welcher minimale Auth-/Revoke-Zustand bleibt nötig?

Plattformen

iOS-/Android-Hintergrundfenster, VPN-Konflikte, Kill-Switch sowie Leak- und Abbruchverhalten.

8. Freigabesperre

Dieser Entwurf ist weder Source of Truth noch Protokollfreigabe. Vor jeder Umsetzung folgen ein gemeinsamer Cross-App-Anforderungsabgleich, ein Threat Model, ein Dateninventar, der exakte Vertragsdiff, ein Testplan und die ausdrückliche Produktfreigabe. Erst nach messbaren Plattformtests und unabhängigen Prüfungen kann aus dem Zielbild ein produktiver Vertrag werden.

Primärquellen für die weitere Forschung

• RFC 9297 und RFC 9298 — HTTP Datagrams, Capsule Protocol und CONNECT-UDP/MASQUE.
• RFC 9458 — Oblivious HTTP als Modell für begrenztes Vertrauen und getrennte Rollen.
• RFC 9180 — Hybrid Public Key Encryption (HPKE).
• NIST FIPS 203 und NIST SP 800-227 — ML-KEM und Empfehlungen für Key-Encapsulation-Mechanismen.
• RFC 9954 und RFC 10024 — hybride Schlüsselvereinbarung in TLS 1.3, nur als abgegrenzte Referenz.