WebRTC P2P NAT Traversal, STUN/TURN, & Client-Side E2EE
Centralized messaging platforms store your chat logs on database servers, exposing your private communications to security breaches, profiling, and server-side analysis. Quick Private Chat by SHADER7 is an experimental peer-to-peer (P2P) messaging application that establishes a direct cryptographic connection between browsers using the WebRTC protocol, completely bypassing external database storage.
Unlike standard apps that use REST APIs or WebSockets to route messages through databases, WebRTC's RTCDataChannel allows browsers to stream encrypted bytes directly to one another. The signaling server is only utilized during the first 10 seconds to help the browsers locate one another. Once the P2P channel is active, the signaling server is disconnected, leaving zero logs or footprints on the web.
WebRTC Protocol Stack: SDP, ICE, & Signaling Handshakes
WebRTC (Web Real-Time Communication) is an open-source framework that enables real-time communication of audio, video, and data in web browsers. Before two browsers can transmit data directly, they must coordinate their network configurations. This process is called **Signaling** and is coordinated using three key protocols:
- SDP (Session Description Protocol): A text-based format that describes the connection parameters of the browser. This includes media formats (codecs), cryptographic fingerprints (DTLS certificates), and data channel options. One browser generates an "SDP Offer", and the receiving browser responds with an "SDP Answer".
- Signaling Sockets: Because browsers cannot locate each other on the open web without assistance, a signaling broker routes the SDP offers and answers. Once the network mappings are established, the signaling server is fully disconnected from the message route.
- ICE Candidates: Interactive Connectivity Establishment (ICE) is a framework used to find all possible network paths (candidates) between the two browsers. These candidates consist of local IP addresses, public reflexive IP addresses, and relay coordinates.
STUN, TURN, & NAT Traversal Mechanics
Most internet-connected devices do not have a public IPv4 address; they reside behind routers utilizing **Network Address Translation (NAT)**. NAT maps multiple private local IP addresses to a single public IP. To traverse NAT routers and establish direct connections, WebRTC relies on STUN and TURN server architectures:
| Server Type |
Protocol Function |
Data Handling |
Bandwidth Cost |
| STUN (Session Traversal Utilities for NAT) |
Helps a browser discover its own public IP address and port binding behind a router. |
Does not touch message payload. Only aids in mapping coordinates. |
Extremely low. Active only during the initial 2-second setup. |
| TURN (Traversal Using Relays around NAT) |
Acts as a secure, high-speed relay server when direct P2P connection paths are blocked by strict firewalls. |
Routes end-to-end encrypted packet blocks. Cannot read the message payload. |
High. Active throughout the entire duration of the connection. |
The success of a direct P2P connection depends heavily on the **NAT Type** of the two router networks:
- Full Cone NAT: Unrestricted. Any external host can send packets to the internal device once a mapping is established. Perfect for high-speed P2P connections.
- Restricted Cone NAT: External hosts can only send data if the internal device has previously sent a packet to their specific IP address.
- Port-Restricted Cone NAT: Strict. External hosts must match both the specific IP address and the specific port used by the internal device.
- Symmetric NAT: Extremely strict. The router allocates a brand-new public port for every single unique destination. In this state, direct P2P mapping is mathematically impossible, and the application must fallback to a **TURN relay** server to forward the traffic securely.
Client-Side Cryptography & Ephemeral Key Derivations
Security is the cornerstone of Quick Private Chat. Even if your traffic is routed through a TURN relay server, your messages remain completely private. WebRTC enforces mandatory, browser-level encryption on all data channels using a dual cryptographic protocol stack:
1. DTLS (Datagram Transport Layer Security): During the connection handshake, the two browsers perform a secure cryptographic handshake. This is modeled on TLS (the protocol that secures HTTPS) but runs over UDP. The browsers negotiate a shared secret session key using a **Diffie-Hellman (DH)** exchange.
The mathematical formulation of the Diffie-Hellman key exchange is represented as:
A = ga mod p (Alice's Public Value)
B = gb mod p (Bob's Public Value)
Once values are exchanged over the public signaling socket, each browser calculates the shared secret key S independently:
S = Ba mod p = Ab mod p
Because the private keys a and b are never transmitted over the network, an eavesdropper intercepting the traffic cannot calculate S, resolving the key distribution problem.
2. AES-256-GCM Encryption: The derived session key S is immediately used to initialize an **AES-256-GCM** (Advanced Encryption Standard in Galois/Counter Mode) block cipher. Every text packet and media stream is encrypted client-side inside the browser before transmission, ensuring that only the target peer can decrypt the payload.
WebRTC Leak Prevention & Local Metadata Security
While WebRTC is exceptional for privacy, it introduces a subtle vulnerability known as the **WebRTC IP Leak**. By default, WebRTC gathers all local ICE candidates (including your private Wi-Fi IP address, e.g. 192.168.1.50, and your local subnet coordinates) to establish the fastest local connection if peers reside on the same network.
To eliminate this threat vector, Quick Private Chat includes a custom **Hide My IP** toggle. When checked, the application filters out local ICE candidates and forces the network adapter to exclusively route WebRTC packets through external relay nodes (TURN servers). This masks your actual WAN IP from the peer browser, presenting only the TURN server's IP address instead.
Peer Connection Troubleshooting Matrix
Because P2P networks rely on user-managed local routers and ISP configurations, connection errors can sometimes occur. Refer to our diagnostic troubleshooting matrix below for common network errors and fixes:
| Error State |
Root Cause |
Technical Resolution |
| ICE Connection Failed |
Symmetric NAT on both endpoints or blockages by local corporate firewalls. |
Enable the 'Hide My IP' toggle or connect to a standard mobile data network to bypass corporate UDP blocks. |
| DTLS Handshake Timeout |
High latency packet loss or router discarding UDP DTLS packets. |
Ensure you have a stable network connection. Re-generate the room code to negotiate a fresh handshake. |
| Media Permission Error |
Browser or operating system blocking camera/microphone access. |
Go to browser settings, select 'Site Permissions', and allow camera/mic access for shader7.com. |
| Room Code Mismatch |
Typographical error or host went offline before client joined. |
Verify the exact 6-character room code. Rooms work only while the active host remains connected. |
Quick Private Chat Frequently Asked Questions (FAQ)
Q: What is a TURN server and can it intercept my chat history?
A: A TURN (Traversal Using Relays around NAT) server is used as a backup to route traffic when firewalls block direct connections. However, because messages are encrypted inside your browser using end-to-end symmetric keys, the TURN server only passes unreadable binary blocks, keeping your chat history completely private.
Q: Why does my chat fail to connect on certain cellular networks?
A: Some cellular providers enforce strict "Symmetric NAT" routing configurations that block standard peer connections. If direct STUN discovery fails, the application automatically fallbacks to TURN servers to establish the connection.
Q: Is my chat history lost when I close the browser window?
A: Yes. Quick Private Chat stores your messages locally in volatile browser memory. Closing the tab immediately destroys the cryptographic keys and chat history, leaving absolutely no digital trace on your device.
Q: Does this app store any cookies or tracking scripts?
A: Absolutely not. Quick Private Chat does not use any tracking scripts, tracking cookies, or analytics packages. Your session preferences (such as your display name or privacy toggle choices) are stored strictly on your device using HTML5 LocalStorage, which never leaves your machine.
Q: Can I share files or images through the chat?
A: File sharing is disabled in this experimental version to maintain maximum throughput and avoid local memory constraints. The focus is entirely on providing an ultra-secure text, voice, and video messaging pipeline.
Q: How does the age check work? Is my Date of Birth stored?
A: The age verification check is processed entirely locally inside your browser using standard client-side JavaScript. The app compares the current date with your input to confirm you are 19+ and saves only a simple binary consent flag (e.g. qpc_tos_accepted = true) in your local browser storage. Your actual birthdate is never transmitted or stored anywhere.
Q: Why does the voice/video call feature require special permissions?
A: The WebRTC framework requires explicit access to your camera and microphone APIs to capture real-time media streams. These streams are converted to encrypted packets and sent directly to the other peer. No media is recorded, cached, or saved by the application.
Q: What is the maximum number of users that can join a single room?
A: To ensure high performance, low latency, and stable peer connectivity, rooms are strictly limited to a maximum of 4 concurrent users. Adding more users exponentially increases the P2P connection mesh complexity, causing network degradation on mobile devices.