How WolfP2P works

Each participant runs a WolfP2P browser client locally in a browser tab. The coordination service creates a temporary tunnel, admits the two sessions, and exchanges the connection details their browser peers need. The peers then establish an encrypted direct connection: they exchange the file metadata needed to review the offer, and after acceptance they stream file bytes and verification information while the receiver writes locally. The coordination server processes coordination data, but not file bytes or file metadata.

The current connection configuration uses host candidates only, with no STUN traversal between separate private networks and no TURN relay. A shared or otherwise directly reachable network can work, subject to browser and network policy; remote reachability is not guaranteed.

The sender creates a tunnel and shares its invitation privately. The service admits the receiver and relays connection signaling. The browser peers exchange the offer, then transfer and verify accepted files directly. Coordination receives the terminal outcome; optional volume analytics are separate and consent-controlled.

These definitions are the canonical meanings of specialized terms used by the product and documentation.

A temporary transfer arrangement for two peers, identified by a six-character code. It reserves two seats—one for each peer—and carries one accepted file set. It is not a VPN or permanent network tunnel.

The other person participating in a tunnel. Each peer uses a browser tab, occupies a seat, and acts as the sender or receiver. Technical explanations may use browser peer for the browser endpoint itself.

One of the two participation places in a tunnel. A peer's session occupies or reserves its seat; once both seats are held, another browser cannot join that live tunnel.

The open browser page holding one WolfP2P session. Each tab handles one tunnel; separate tabs can run separate transfers.

WolfP2P code running locally in a participant's browser tab. With browser permission, a sender client can read selected files and a receiver client can write to the selected destination. The clients exchange the file metadata required to present and review an offer; after acceptance, they exchange the required file bytes and verification information over the direct transfer channel. They do not send file bytes or file metadata through the coordination server.

A WolfP2P browser client while it is participating as one endpoint of a direct peer-to-peer connection. A browser peer can hold the sender or receiver role; it is not a separate component with which the browser client shares files.

One browser tab's participation in a tunnel. It occupies a seat and holds the local information used for supported reconnection and recovery. It belongs to that tab rather than to an account.

The link or six-character code shared with the intended peer. It identifies the tunnel and lets a browser request its open seat, but it does not verify the identity of the person using it.

The six-character identifier included in an invitation. WolfP2P generates it from a 30-bit space of 1,073,741,824 possible codes. It is a temporary join credential, not proof of identity. Read how WolfP2P limits code guessing for the calculation, rate limits, and practical precautions.

The peer who selects a file set and sends its offer.

The peer who reviews the offer, chooses the available destination handling, and accepts or declines the file set.

The description of a file set shown before file bytes move. It includes offered paths, file count, and total size; accepting it begins the transfer.

The individual file, selected files, or folder collection included in one offer, moved in one transfer, and carried by one tunnel.

The contents of the files selected for transfer. The sender's browser client reads them and the receiver's browser client writes them. They travel through the direct transfer channel, not through the coordination server.

Information describing an individual selected file or its place in the offered collection rather than its contents. In WolfP2P, this can include the filename, relative folder path, per-file size, collection manifest, and content-derived verification information. The browser clients exchange the information required to review, reconstruct, and verify an accepted transfer. The coordination server does not receive this file metadata.

File metadata is distinct from metadata embedded inside file bytes, such as EXIF fields, and from filesystem metadata such as modification time, ownership, permissions, or extended attributes. Those categories have separate preservation rules.

The delivery of one accepted file set from the sender to the receiver over the direct transfer channel.

The browser-to-browser path over which a transfer moves information and file bytes. A browser-provided WebRTC data channel implements it, and DTLS protects it in transit.

The coordination service is the server-side WolfP2P capability that creates tunnels, admits participants, and exchanges the connection details required to establish the direct transfer channel. The coordination server is the component that performs this work, processes coordination data, and owns authoritative tunnel membership. In general-audience explanations, it may be called the WolfP2P server. It does not receive file bytes or file metadata.

Information used to create, secure, maintain, and observe a temporary tunnel rather than describe the transferred files. It can include tunnel lifecycle, participant roles, temporary identifiers, connection signaling, IP and request information, connection times, final outcomes, rate-limit events, coded operational events, and errors. The coordination server processes this data but does not receive file bytes or file metadata.

Durable destination progress recorded in Safe mode so part of a large file can be reused after an interrupted transfer or restored session.

An additional file copy uploaded to and held by an intermediary before the receiver downloads it. WolfP2P's direct transfer channel does not create a middle copy on its coordination server.