1. Goals and Terminology
Work in progress — not audited
This chapter is part of an initial draft specification. Enkrypted Chat has not been independently audited. Content may change.
1.1 Goals
Enkrypted Chat aims to provide:
- Direct peer messaging — Browser-to-browser communication over WebRTC without a central message store.
- Layered end-to-end encryption — Application-level cascade (MLS, Signal, ML-KEM, AES) on top of WebRTC transport cryptography.
- User-controlled keys — Keys generated and held on the client; no registration server for identity.
- Modular delivery — Shared cryptography, P2P, and UI logic via Module Federation across apps (chat, files, calls).
- Self-hostable infrastructure — Signaling broker, static bundles, and TURN/STUN can be operated by the user or third parties.
1.2 Non-goals (v1 specification scope)
The following are out of scope for this specification version unless noted as future work:
- QR / offline manual signaling — Connection establishment via broker only (see Chapter 3).
- Interoperability with Signal, Matrix, or other clients — single implementation only.
- Formal compliance certification — No HIPAA/GDPR certification claims; privacy-by-design goals only (Chapter 7).
- Tor-native routing — WebRTC is not documented for Tor; see Chapter 11.
- Monetization or business model — Product FAQ covers project economics separately.
1.3 Product scope
This specification covers the Enkrypted Chat product surface, including features present in code (some experimental):
| Feature area | Specification treatment |
|---|---|
| 1:1 messaging | Core, normative |
| Group chat | Documented; partial / experimental |
| File sharing & OPFS | Documented; encryption at rest WIP |
| Document editor & calendar | Documented at architecture level |
| Voice/video calls | Documented; SFrame E2EE experimental |
| PWA / browser deployment | In scope |
| Tauri Android / desktop | Out of scope for current deployment |
1.4 Terminology
| Term | Definition |
|---|---|
| Peer | A browser instance identified by a peer ID and participating in WebRTC. |
| Peer ID | Opaque client-generated identifier used for signaling and routing; not a long-term cryptographic identity by itself. |
| Signaling server | PeerJS-compatible broker; relays SDP/ICE for connection setup only. |
| TURN relay | Relay server used when direct P2P fails; may see encrypted traffic and metadata. |
| Application ciphertext | Payload after cascading cipher encryption, before WebRTC framing. |
| Cascade / cascading cipher | Sequential application of multiple cipher layers (see Chapter 4). |
| MLS | Message Layer Security (RFC 9420); group-oriented protocol used as a cascade layer. |
| Signal Protocol | X3DH key agreement + Double Ratchet; implemented in Rust/WASM. |
| ML-KEM | Module-lattice KEM (post-quantum layer in cascade). |
| Semi-trusted | Infrastructure that must not learn plaintext but may learn metadata or deliver untrusted code if compromised. |
| TCB | Trusted computing base — here, the user’s browser/OS assumed for crypto execution. |
1.5 Normative language
When this specification uses MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT, they are to be interpreted as described in RFC 2119.
1.6 Privacy-by-design principles
Positive Intentions designs Enkrypted Chat toward:
- Data minimization — No central archive of message plaintext.
- Purpose limitation — Infrastructure components used only for connectivity and static delivery, not analytics on message content.
- User control — Local storage, optional relay/TURN configuration, disablement of metadata-heavy features where implemented.
- Transparency — Open documentation of trust boundaries and known limitations.
These are design goals, not regulatory certifications.