P2P file transfer lifecycle
Initiation
The sender selects a file. HashDrop calls
generateSecureCode(), which uses the browser’s Web Crypto API (window.crypto.getRandomValues) to pick a cryptographically random adjective and noun from two 80-entry word lists, producing a human-readable Warp Code such as COSMIC-FALCON. The code is converted to a PeerJS peer ID in the format sr-warp-cosmic-falcon and registered with PeerJS signaling.Signaling
The Warp Code is registered on the PeerJS signaling server. HashDrop stores no file data at this stage — only the peer ID is known to the server. The code expires automatically after 5 minutes if no receiver connects, and only the first peer to match the code can establish a connection.
Discovery
The receiver enters the Warp Code on the Web client or Mobile app (iOS/Android). The input is validated against the pattern
^[A-Z]+-[A-Z]+$ and converted to the matching peer ID. The receiver’s PeerJS instance initiates a connection request to the sender’s peer ID via the signaling server.Handshake
Both peers exchange ICE candidates through the signaling server. STUN servers resolve public IP addresses, and TURN servers relay traffic when a direct path is blocked by NAT. Once candidates are exchanged, a DTLS/SRTP-encrypted data tunnel is established directly between the two devices. The signaling server is no longer involved.
Drop
The signaling server steps away. The sender reads the file as an
ArrayBuffer, splits it into 16 KB binary chunks, sequences them, and streams them directly to the receiver over the WebRTC data channel. No data passes through HashDrop’s servers. The receiver tracks progress chunk by chunk.Verification
Once all chunks arrive, the receiver reassembles them in order. HashDrop calls
crypto.subtle.digest('SHA-256', buffer) on the reassembled file and compares the result against the SHA-256 hash the sender computed before transmission. If the hashes match, the file is automatically offered for download. If they differ, the transfer is rejected.System diagram
Role of the signaling server
The signaling server is a broker, not a carrier. Its only job is to match Warp Codes to peer IDs and relay the ICE candidate exchange that lets two peers find each other. Once the WebRTC handshake completes, the signaling server is removed from the path entirely. It stores no file data, no metadata, and no logs.WebRTC and ICE
How HashDrop configures STUN, TURN, and PeerJS data channels.
Relay mode
What happens when a direct P2P connection cannot be established.
Encryption
DTLS/SRTP, SHA-256 verification, and the zero-trust model.