Back to Nexus

How It Works

True Peer-to-Peer

Understanding WebRTC & P2P

See exactly how your data travels, what information is exposed, and verify for yourself that Nexus uses genuine peer-to-peer connections.

How WebRTC P2P Works

WebRTC enables direct browser-to-browser communication without media going through servers. Here's the complete flow:

Connection Establishment Flow

1

Signaling (via Server)

Server Involved

Users exchange connection metadata through our signaling server. This includes SDP offers/answers (codec info, media capabilities) and ICE candidates (network addresses).

WebSocket connection to signaling server
Exchange of SDP (Session Description Protocol)
ICE candidate exchange for NAT traversal
Server only sees metadata, not media
2

STUN Discovery

Server Involved

Your browser contacts STUN servers to discover your public IP address and port mappings. This is necessary because most devices are behind NAT.

Discovers public IP address
Identifies NAT type and port mappings
Uses Google STUN servers by default
Only connection metadata is shared
3

ICE Candidate Gathering

Direct P2P

Your browser gathers all possible ways to reach you: local addresses, public addresses (from STUN), and relay addresses (from TURN if configured).

Host candidates: Local network addresses
Server reflexive (srflx): Public NAT addresses
Relay candidates: TURN server fallback
Prioritized by speed and reliability
4

Direct P2P Connection

Direct P2P

Using the gathered candidates, browsers attempt direct connections. The best working path is selected. Media flows directly between peers.

DTLS encryption established
SRTP for secure media transport
DataChannels for P2P chat
No server involvement in media

Through Our Server (Signaling)

  • Room join/leave events
  • User presence information
  • SDP offers/answers (codec negotiation)
  • ICE candidates (connection addresses)
  • Media state changes (muted/camera off)

Note: This is metadata only. The server cannot see or record your video, audio, or chat content.

Direct P2P (Peer-to-Peer)

  • Video streams (encrypted)
  • Audio streams (encrypted)
  • Screen share streams (encrypted)
  • Chat messages (via DataChannel)
  • File transfers (if implemented)

All media is encrypted end-to-end with DTLS/SRTP. Even if intercepted, it cannot be decrypted.

Live WebRTC Demo

Run this demo to see exactly what ICE candidates your browser gathers. This reveals your local and public IP addresses - the same information any WebRTC peer would see.

ICE Candidate Discovery

Activity Log

Click "Start Discovery" to begin...

What This Reveals About You

IP Address Exposure

Any WebRTC peer can see your public and local IP addresses. This is inherent to P2P - you need to know where to send data. VPNs only partially help (local IPs still exposed).

Network Fingerprinting

Your NAT type, number of network interfaces, and IP patterns can be used for fingerprinting. This is a privacy tradeoff for direct P2P communication.

Security Analysis

A honest assessment of Nexus's security model - what's protected, what's exposed, and what you should know.

Media Privacy

A
  • Video/audio encrypted with DTLS-SRTP
  • Media flows directly peer-to-peer
  • Server cannot intercept media streams
  • Chat via encrypted DataChannels

Metadata Privacy

B
  • IP addresses exposed to all peers
  • Server sees room membership
  • No persistent user accounts
  • Rooms auto-delete when empty

Authentication

C
  • No user authentication required
  • Anyone with link can join rooms
  • Session tokens for room access
  • No identity verification

Detailed Security Breakdown

End-to-End Media Encryption

All media (video, audio, screen share) is encrypted using DTLS (Datagram Transport Layer Security) for key exchange and SRTP (Secure Real-time Transport Protocol) for the actual media. This encryption is handled by your browser and cannot be disabled or intercepted by our servers.

P2P Chat via DataChannels

Chat messages are sent directly between peers using WebRTC DataChannels, which are also encrypted with DTLS. Messages never pass through our server - they go directly from your browser to the other participant's browser.

IP Address Exposure

This is the main privacy tradeoff of P2P: other participants can see your IP address. This is technically necessary - you can't send data to someone without knowing their address. Using a VPN can hide your real public IP but local IPs may still be exposed.

Signaling Server Visibility

Our signaling server sees: who joins/leaves rooms, SDP offers/answers (codec info), and ICE candidates (IP addresses). It does NOT see: actual video/audio content, chat messages, or screen share content.

STUN Server Usage

By default, we use Google's public STUN servers for NAT traversal. These servers see connection attempts (your IP) but not media content. For maximum privacy, you can self-host STUN/TURN servers.

Frequently Asked Questions

Common questions about WebRTC, P2P, and Nexus's security model.

Verify For Yourself

Don't trust us - verify these claims yourself using these tools:

Chrome WebRTC Internals

See all active P2P connections

chrome://webrtc-internals

Network DevTools

Monitor WebSocket signaling traffic

F12 → Network → WS

Source Code

Review the implementation

View on GitHub