Skip to main content

11. Limitations and Roadmap

Work in progress — not audited

This chapter is part of an initial draft specification. Enkrypted Chat has not been independently audited. Content may change.

11.1 Mandatory limitations (read before use)

The following MUST be understood by any professional evaluator:

  1. No independent security audit of the full product stack.
  2. Experimental / WIP software — not a replacement for Signal, WhatsApp, or enterprise messengers.
  3. No offline messaging — both peers must be online for delivery (relay planned, not specified).
  4. Broker dependency for v1 — QR/offline signaling not in this spec.
  5. Group chat partial — do not rely on group security guarantees.
  6. Browser JS trust model — hosted bundle compromise equals full compromise.
  7. Metadata remains — peer IDs, timing, TURN/signaling exposure (Chapter 7).
  8. Cascading cipher controversy — defense-in-depth intent vs expert caution (Chapter 4).
  9. Fast file transfer — optional reduced protection path.
  10. At-rest encryption — not complete.
  11. SFrame video E2EE — experimental, not audit-backed.
  12. No interoperability with other clients.
  13. Tor unsupported for WebRTC.

11.2 Use cases (from product vision)

Enkrypted Chat is intended for:

  • Privacy-conscious individuals exploring P2P messaging
  • Researchers studying P2P + Signal adaptations
  • Developers evaluating modular federated architecture
  • Organizations prototyping self-hosted secure comms (with their own legal/security review)

It is not positioned today for regulated healthcare, government classified comms, or high-risk journalism without additional review.

11.3 Competitive positioning (summary)

PlatformArchitectureE2EE messagingTrue P2P payload pathNotes
Enkrypted ChatP2P + broker + static CDNCascade + WebRTCYes (when connected)Experimental, unaudited
SignalCentralized serverSignal ProtocolNo (server relay)Mature audit culture
Matrix/ElementFederated homeserversOlm/MegolmNoServer stores ciphertext
Briar/SessionP2P / onion variantsVariousStrong P2P focusDifferent stack
WhatsAppCentralizedSignal-derivedNoMetadata to Meta
Zoom/MeetCentralized SFUVariableNoEnterprise focus

Strategic tradeoff: Enkrypted Chat sacrifices convenience (online-only, setup complexity) for reduced central message custody.

11.4 Thematic roadmap (not dated)

Future work themes (no commitment dates):

  • Independent security audit
  • Offline / self-hosted message relay
  • Multi-device decentralized profile
  • Encryption at rest (passkey/passcode/password wrapping DEK)
  • Self-destructing messages
  • Improved group messaging
  • Multicloud static redundancy
  • Service worker static pinning
  • Onion routing investigation (non-Tor WebRTC constraints)
  • Expanded formal verification coverage

11.5 Vision

Long-term direction: a browser-based, user-sovereign communication suite (messaging, files, documents, calendar) with minimal central custody of content, transparent security documentation, and optional self-hosting at every infrastructure tier.

Progress is incremental; this specification will be revised as implementations mature and audits complete.

11.6 Profile-v1 protocol checklist (next implementation steps)

Before labeling EnkryptedChat-Profile-v1, the project MUST complete:

StepDeliverableStatus
1Golden hex test vectors (handshake, cascade mock, MLS fallback, chunk math)DoneAppendix A; golden-vectors.test.js, protocol-golden-vectors.test.js
2Live MLS+Signal+ML-KEM+AES hex (V8)Deferred — Profile-v1
3Implement type: "protocol-error" on decrypt/oversize/unknown-type pathsDonep2p/src/utils/protocolError.ts
4Mandatory specVersion: "1.0" on all PDUsPending
5Freeze PDU schemas (no breaking required fields)Pending
6Independent security audit or documented waiverPending

Completed in documentation pass (v0): P0 rationales, Appendix B/C, full PDU field reference in P4.13, formal security matrix, broker compromise list, recommended timeouts.

Not planned near-term (per product decision): Broker token/mTLS signaling auth — roadmap only (P2.9).