2. Architecture and Trust
This chapter is part of an initial draft specification. Enkrypted Chat has not been independently audited. Content may change.
2.1 Design stance
Enkrypted Chat is not “serverless.” It is message-serverless: there is no central service that stores or decrypts conversation content. Limited infrastructure remains for signaling, NAT traversal, and static asset delivery. Honest documentation of those components is required for professional review.
2.2 High-level architecture
2.3 Layered stack (summary)
| Layer | Responsibility |
|---|---|
| Presentation | React UI (ui, app shell) |
| Session / P2P | MLSProvider, PeerJS, WebRTC data channels |
| Application crypto | Cascading cipher + Signal WASM |
| Transport crypto | WebRTC DTLS, SRTP (media) |
| Local persistence | OPFS, IndexedDB (files, keys — at-rest encryption WIP) |
Full encrypt order: Chapter 4. Transport detail: Chapter 3.
2.4 Module federation
Module Federation is central to the architecture. The chat shell dynamically loads:
ui— Components (contacts, chat, QR connect UI, file browser, etc.)p2p—MLSProvider, messaging, calls, file transfercryptography— MLS, Signal WASM, cascading cipher, SFrame managers
Implications:
- Runtime dependency on remote entry URLs (supply-chain risk).
- Version skew between shell and remotes MUST be managed in deployments.
- Self-hosting MUST include all federated entry points, not only the shell bundle.
See Decentralized architecture and Statics as infrastructure.
2.5 Trust boundaries
| Component | Trust level | Rationale |
|---|---|---|
| Remote peer | Untrusted | Malicious peer may send invalid ciphertext; crypto must fail closed. |
| Signaling server | Semi-trusted | Sees peer IDs, SDP, ICE candidates, connection timing; MUST NOT receive message plaintext. |
| TURN relay | Semi-trusted | May see IPs, packet sizes/timing; in relay-mode carries ciphertext blobs only. |
| CDN / static host | Semi-trusted | Can serve trojaned JS if compromised; mitigated by self-host, CSP, SRI (Chapter 8). |
| Federation remotes | Semi-trusted | Same class as CDN for code integrity. |
| Browser / OS | TCB | Executes all crypto; spec assumes non-malicious browser. |
| Local storage (OPFS) | User-trusted | Protected by at-rest encryption when enabled (Chapter 6). |
2.6 Infrastructure truth table
| Component | Used today | Self-hostable | Carries message plaintext? |
|---|---|---|---|
| Signaling (PeerJS broker) | Yes | Yes | No |
| Static hosting (S3/CDN) | Yes | Yes | No (serves code only) |
| STUN/TURN | Yes | Yes (user keys) | No (encrypted payloads) |
| Central message store | No | N/A | N/A |
| Offline message relay | No (planned) | Planned | Future spec |
2.7 Comparison: centralized vs Enkrypted Chat
| Aspect | Centralized (e.g. Signal, WhatsApp) | Enkrypted Chat |
|---|---|---|
| Message routing | Through operator servers | Direct P2P when connected |
| Pre-key / async delivery | Server-backed | Requires both peers online (broker signaling only) |
| Operator metadata | Typically collected | Reduced for content; signaling/TURN metadata remains |
| Account system | Phone/email identity | Peer ID only (no registration server) |
| Video E2EE | Product-dependent | WebRTC + experimental SFrame layer |
Extended comparison tables: Chapter 11 and migrated analysis in project audit materials.
2.8 Multi-device (partial prototype)
Multi-device sync is a partial prototype. The specification documents intended direction in Chapter 11; normative requirements for production multi-device are not defined in this draft.