Private — Encrypted in Transit
All sensitive message content is AES-256 encrypted on your WordPress server before transmission through the WebSocket infrastructure. The relay server only handles encrypted data and cannot read message content. Decryption happens in the authorized user's browser using keys only available to the conversation's participants.
This is a WebSocket-version feature. The free version uses AJAX polling against your own WordPress server, so no third-party relay is involved.
What it adds#
- AES-256 encryption of all message content on your WordPress server before send
- WebSocket relay server cannot decrypt or read messages
- Decryption only in the authorized recipient's browser
- No plaintext message data ever leaves your server
- Identical encryption applied to private DMs, group chats, and chat rooms
- Same protection covers attachments, voice messages, and other content payloads
How it works#
When a user sends a message, your WordPress server encrypts the content with AES-256 using a per-conversation key before pushing it to the WebSocket relay. The relay then forwards the encrypted payload to all conversation participants' open connections. Each participant's browser decrypts using the same per-conversation key, retrieved securely from your server.
| Stage | What's visible |
|---|---|
| Sender's browser → your server | Plaintext over HTTPS |
| Your server encrypts → relay | Encrypted ciphertext only |
| Relay → recipient's browser | Encrypted ciphertext only |
| Recipient decrypts | Plaintext locally |
The relay's role is purely to route encrypted bytes between participants — it has no key, no inspection capability, no ability to comprehend what it's forwarding.
Frequently asked questions#
Is this the same as end-to-end encryption?#
No — this is transit encryption. The WordPress server has the key. For true end-to-end encryption (where only the participants — not even your server — can decrypt), use the optional end-to-end encryption (E2EE) per-thread feature.
Does this require any setup?#
No — encryption is automatic on the WebSocket version. There's no key management, no user-facing setup.
Does this apply to file attachments?#
File attachments are stored on your server. Their URLs are encrypted in the message payload but the files themselves are accessed via your WordPress media library security model.
Are voice / video call streams encrypted?#
Yes — WebRTC uses DTLS/SRTP encryption for all media streams. See Secure for the connection-layer details.
Can attackers intercept messages over the WebSocket?#
The WebSocket connection is itself TLS-encrypted (WSS). Even before AES-256 content encryption, the transport layer is secure. Combined, an attacker would need to break BOTH TLS AND AES-256 — neither is feasible with current technology.
See also#
- End-to-end encryption (E2EE) — optional per-thread true end-to-end encryption
- Secure (WSS) — transport-layer security
- Local browser encryption — encrypt cached data on the user's device
- Your data is yours — what's stored where
- Privacy & GDPR — full privacy picture