P1. Protocol overview and profile

Work in progress — not audited

Normative protocol documentation for the current implementation. Not independently audited.

P1.0 Notation

Symbol / term	Meaning
Byte string	Uint8Array; on the wire as JSON array of integers 0–255
Concatenation	A || B
Hex	Lowercase hex digits; test vectors omit 0x prefix
Text	UTF-8 unless noted
IK, EK, …	Signal/MLS symbols per upstream specs when cited

Keywords MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are interpreted per RFC 2119 in all P-chapters and appendices.

P1.1 Protocol identifier

This document defines profile:

EnkryptedChat-Profile-v0

Implementations claiming this profile MUST:

1. Use WebRTC data channels as the transport (see P2, ch. 3).
2. Use JSON UTF-8 objects as application PDUs on the data channel (see P4).
3. When application E2EE is enabled, apply cascade layers in order MLS → Signal → ML-KEM → AES on plaintext (see P5).
4. Follow processing rules in P6.

Alternate profiles (non-normative for v0):

Profile	Description
EnkryptedChat-Profile-v0-MLS-fallback	Cascade disabled or failed; MLS-only envelope
EnkryptedChat-Profile-v0-fast-file	Fast file transfer; cascade MAY be bypassed; DTLS only for bulk data

P1.2 Layer stack

Layer	Component	Normative reference
L0	Signaling (PeerJS / WSS)	P2
L1	WebRTC (DTLS, SCTP data channel, SRTP for media)	RFC 8825–8829; ch. 3
L2	Session handshake PDUs	P3
L3	Cascade layer 1 — MLS	RFC 9420
L4	Cascade layer 2 — Signal (X3DH + Double Ratchet)	Signal spec; Appendix B
L5	Cascade layer 3 — ML-KEM-768	FIPS 203 / project quantum doc
L6	Cascade layer 4 — AES-GCM-256	Web Crypto API; password-derived in implementation
L7	Application PDU (type field)	P4

Encrypt direction (plaintext to wire): L7 payload → L3…L6 cascade → wrapped in encryptedMessage → L2 PDU → L1 DTLS.

P1.3 Product configuration (Enkrypted Chat)

Authoritative product settings in glitr-chat:

enableCascadingCipher = true
cipherLayers = ["MLS", "Signal", "ML-KEM", "AES"]
enableSignalProtocol = true

The p2p library defaults enableCascadingCipher = false; the product shell overrides to true.

P1.4 Security properties (normative summary)

Legend: Provides · Partial · Does not provide

Property	Signaling	Handshake	Transport (DTLS/SRTP)	Application message
Confidentiality (content)	N/A	Partial — key material in JSON PDUs	Provides	Provides — cascade + DTLS
Integrity	Provides (TLS)	Partial	Provides	Provides — AEAD per layer
Forward secrecy (message)	Does not provide	Partial	Provides (ephemeral)	Provides — Signal + MLS epochs
Post-quantum confidentiality	Does not provide	Does not provide	Does not provide	Partial — ML-KEM layer only
Authentication (peer identity)	Partial — Peer ID	Partial — in-band keys	Does not provide	Partial — no global PKI
Metadata minimization	Does not provide	Does not provide	Does not provide	Partial
Offline / async delivery	Does not provide	Does not provide	Does not provide	Does not provide

PQ wording: ML-KEM-768 adds post-quantum protection for message content at the cascade layer; transport and handshake are not post-quantum.

At-rest protection for local keys is product-dependent and not claimed by this profile.

P1.5 Explicit non-properties

Implementations of EnkryptedChat-Profile-v0 do not provide:

• Offline / asynchronous message delivery without both peers online
• Global identity or account system
• Guaranteed anonymity (IPs visible to TURN/peers)
• Interoperability with Signal, WhatsApp, or Matrix clients
• Independently audited security (see disclaimers)

P1.6 Formal verification scope

In-house formal work applies to the Rust Signal Protocol core only. It does not cover the browser stack, cascade composition, WebRTC, or JSON PDU layer. See Signal Protocol formal verification.

P1.7 EnkryptedChat-Profile-v1 (future freeze)

EnkryptedChat-Profile-v0 remains unfrozen. Before publishing v1, implementations MUST meet:

1. Frozen PDU schemas (no new required fields without version bump).
2. Mandatory specVersion: "1.0" on every application PDU.
3. Implemented protocol-error PDUs (P8.8).
4. Golden hex vectors in Appendix A.
5. Normative Appendix B.
6. Independent security audit completed or documented waiver.

Until then, receivers SHOULD ignore unknown JSON fields. See CHANGELOG-SPEC.

Optional field in current builds: specVersion (string) MAY appear on PDUs for forward compatibility; MUST NOT be required until v1.

P1.8 Vulnerability disclosure

Report security issues via GitHub Security Advisories on positive-intentions/chat. See SECURITY.md in that repository.

P1.9 Document boundary

In protocol spec (P0, P1–P8, appendices)	In product spec (ch. 1–12)
Data channel PDUs, handshake, cascade	Module federation, UI, OPFS, calendar
WebRTC/signaling profile	Competitive analysis, roadmap
Limits, errors, test vectors	Deployment, CSP/SRI MUSTs
Design rationales (P0)	SFrame UX (informative Appendix D)