What WolfP2P's server sees during a transfer

For:Advanced users and digital professionals

Assumes familiarity with files, browsers, and common computer workflows.

WolfP2P's server is the coordination server: it coordinates a temporary connection between two browser clients and helps them become browser peers. It processes the coordination data needed to create, join, protect, maintain, and observe that connection, but it does not receive file bytes or file metadata.

This page explains the complete coordination-data boundary, then separates it from browser-local data, file metadata, file bytes, third-party network-request data, and optional analytics.

The server helps the browsers connect; the browsers read, transfer, write, and verify the files directly. Coordination receives the final outcome, not file contents or a transfer-progress heartbeat.

Transfer sequence

Your WolfP2P browser client asks the coordination server to create a temporary tunnel and receives its code.
You share the code with the intended peer outside WolfP2P. The peer's browser joins using that code.
The coordination server relays connection signaling, and the two browser clients establish an encrypted WebRTC connection as browser peers.
Your browser reads the selected files locally and sends their details and contents directly to the peer's browser, which writes and verifies them locally. The server is outside this file-data path.
A browser with durable completion evidence reports the outcome to coordination. Both browsers keep their own local transfer records.

Data processed by transfer stage

When a tunnel is created or joined

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.

How WolfP2P limits tunnel-code guessing

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.

While the browsers establish WebRTC

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.

Cloudflare connection discovery, without a TURN relay

To find a direct route, each browser may contact Cloudflare's STUN service and exchange candidate network addresses through WolfP2P's coordination service. The discovery service sees the requesting browser's public IP address and port. Candidate connection information is available to the coordination service and the other participant as part of connection setup. STUN does not carry the transferred files. A direct connection can still fail because of network or browser restrictions, and no TURN relay is configured.

Cloudflare receives discovery-request timing as well as network address information. This connection functionality is independent of optional analytics. See the Privacy Notice and Cloudflare privacy policy.

While browser peers are streaming file bytes

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 product analytics is separate from tunnel coordination and is described in the Privacy Notice. The current release does not collect optional transfer-progress, outcome or volume events.

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

Operational logs and analytics are separate

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.

WolfP2P's browser application processes readable files locally. Its server processes coordination and operational information, while file contents and file-level details stay on the direct browser-to-browser path.

Data boundaries

The coordination server processes temporary tunnel state, peer roles, connection signaling, IP and request information, and final outcomes. Optional product analytics is separate from tunnel coordination; dormant transfer-volume analytics is not an active purpose.
Each WolfP2P browser client processes selected file bytes and file metadata, plus its own local settings, history, and reports.
The encrypted WebRTC connection carries file metadata, accepted file bytes, and transfer and verification messages directly between the browser peers.
The peer's browser processes offered file information, received file contents, the chosen destination, local settings, and local history and reports.
Both browsers communicate with the server for tunnel coordination. File contents do not pass through the server; both endpoints can process the readable bytes.

What the server does not learn from the transfer

The server cannot use the file-data channel to inspect what a photograph depicts, read a document, play a recording, scan an archive, classify a project, or reconstruct the transferred folder tree. Coordination does not receive the transferred file bytes or file-level details.

This does not make WolfP2P a zero-trust system. The website code runs in both browsers, the coordination server relays connection details, and both endpoints process readable file bytes. Confirm the intended recipient and use trusted, updated devices and browsers for sensitive material.

For the storage-exposure benefit, read Why Avoiding an Intermediary File Copy Improves Privacy. For the byte path, read How No Middle Copy Works.