1. The sender creates a temporary room
Selecting files creates a temporary room with a QR code, private link, and six-digit code. These options help the receiving device find the room; they do not grant access by themselves.
The receiver sends a join request with its device name and a temporary cryptographic key. AllFileGo forwards the request, but no file names or file data are shared yet.
2. Both devices show the same security code
The two browsers create the same security code. Compare the code on both screens, confirm the receiving device, and approve or deny the request on the sender.
After approval, the browsers encrypt the connection-setup messages. Old or repeated messages are rejected.
3. The devices create a direct browser connection
WebRTC uses ICE to test possible routes between the devices. A STUN service helps each browser discover a reachable network address, but it does not carry the file.
The selected route may stay on the local network or travel directly over the internet. TURN relays are currently disabled, so the transfer stops if the browsers cannot create a direct connection.
4. The devices send and check the files
The sender divides each file into small pieces and sends them through an encrypted WebRTC DataChannel. Control messages handle readiness, pause, resume, stop, progress, and recovery.
The receiver writes and checks the file as data arrives. It completes the file only when the expected size and SHA-256 fingerprint match. Sender progress shows data confirmed by the receiver, not data merely waiting in the sender's browser.
5. A short connection drop may recover
If the network changes or the file connection closes, AllFileGo tries to reconnect while the same session remains open. The sender continues from the last point confirmed by the receiver instead of starting the file again.
Closing or reloading either page ends the transfer. AllFileGo does not keep the file for a later restart.