What WolfP2P's server sees during a transfer

The coordination server processes:

• the temporary tunnel code and tunnel lifecycle state;
• which of the two tunnel roles is occupied;
• server-assigned connection identifiers and short-lived reclaim credentials;
• connection and activity times used to expire abandoned tunnels; and
• the connecting IP address used for tunnel ownership controls, abuse prevention, and rate limiting.

These details let the service limit a tunnel to its intended two roles, reconnect a browser where supported, reject excessive attempts, and remove temporary state after its configured lifetime.

WolfP2P generates each six-character tunnel code with a cryptographically secure random generator using Crockford Base32. The 32-symbol alphabet produces 32⁶, or 1,073,741,824 possible codes (30 bits).

The 30-bit value describes the theoretical code space, not the number of tunnels the service can operate simultaneously. Matching an occupied code does not provide another seat, and terminal or unknown codes are not joinable.

The server limits hub invocations to 250 per second on one connection. A separate admission limit permits 120 requests per minute per trusted client IP address, shared by tunnel creation, joining, and outcome lookup. Requests above those limits are refused until the relevant fixed window resets. Connection establishment also has its own throttling.

These limits constrain one source address; they do not establish a guaranteed time to guess an invitation. Distributed attempts, the number of open invitations, and exposure of the code also matter. Treat the code as an invitation secret and share it only with the intended peer.

The time before the intended peer joins is still important. Every minute an invitation waits with an open seat gives a source address another limited set of guesses. Contact the peer through a separate trusted channel first, create the tunnel only when the peer is ready, share the invitation immediately, and ask the peer to join without unnecessary delay. Once both seats are occupied, another browser cannot enter that live tunnel.

These controls reduce casual and single-source guessing, but the tunnel code remains a human-shareable invitation rather than a high-entropy identity credential. A distributed attacker using many source addresses is not equivalent to one rate-limited browser. Share the invitation privately, confirm the intended peer after joining, and select sensitive files only after that confirmation.

The browsers exchange a WebRTC offer, answer, and Interactive Connectivity Establishment information through the coordination server. The Interactive Connectivity Establishment (ICE) standard uses candidate network addresses to discover a working path between the peers.

The server relays the WebRTC session descriptions and ICE candidates to the other occupied tunnel role. These connection details can expose network-address and transport information required for connection establishment. They do not contain the selected file bytes, but the coordination server remains part of the trust model because WolfP2P does not currently provide an independent, out-of-band fingerprint comparison.

The current WolfP2P deployment passes no ICE-server configuration to the browser peer connection. It therefore does not direct either browser to Google's public STUN service—or another STUN or TURN service—for connection discovery or file relay.

With no ICE server configured, the browsers gather host candidates only. This can establish a direct connection on a shared network where browser and network policy permit it, but it does not provide STUN-based traversal between separate private networks. Guest-network isolation, firewalls, VPNs, browser privacy behavior, or managed policy can still prevent the host candidates from connecting.

The absence of STUN and TURN is a deployment fact, not a general property of WebRTC. If WolfP2P later configures either service, the Security and Privacy disclosures must be reviewed before deployment.

The file-data channel runs between the connected browser peers. WolfP2P's coordination server does not receive file metadata—including filenames, folder names, relative paths, extensions, media types, per-file sizes, manifests, and content-derived verification information—or file bytes from that channel.

Coordination has no transfer-progress heartbeat. Server deadlines use tunnel age, phase entry, and connection attachment. The browsers enforce their own work-silence timers. Optional, consent-controlled volume analytics are a separate data purpose and do not keep a tunnel alive.

The browser protects the data channel using standardized DTLS for WebRTC. Read How WolfP2P Encrypts the Transfer for the protocol and trust boundaries.

Operational and security systems can process ordinary service information such as IP addresses, request times, response status, rate-limit events, connection failures, and service errors. That information is used to operate, secure, and diagnose the service; it is not a copy of the transferred file.

Optional product analytics are consent-controlled. WolfP2P's analytics rules prohibit filenames, folder names, paths, extensions, media types, manifests, file contents, hashes, tunnel codes, reclaim credentials, WebRTC session descriptions, ICE candidates, clipboard contents, and inferred information about the peer from entering behavioral analytics.

External analytics providers are not enabled by default. Current collection choices and the governing personal-data inventory are described in the Privacy Notice and Cookie and Browser Storage Notice.