A file transfer is a conversation between two browsers.

Moving a file to another device should not require creating an account or leaving a copy in cloud storage. TransmitFlow starts with two actions—Send and Receive—and pairs the browsers through a room code, share link, or QR code.

The interface has to distinguish waiting for a peer, establishing a connection, transferring, and finishing. A progress bar alone cannot explain all four. The transfer controller keeps those states together, while separate panels render the sender, receiver, and progress views.

This separation matters when an attempt fails: the interface can offer a specific recovery action instead of leaving the user with a spinner and a generic error.

A Socket.IO signaling server coordinates the room and exchanges connection information. File payloads travel over a WebRTC DataChannel. A direct connection is preferred; TURN can relay traffic when the network requires it and a relay is available.

On the receiving device, chunks can be persisted in IndexedDB to reduce memory pressure. The transfer flow tracks missing chunks and uses SHA-256 integrity checking before treating a file as complete.

An expired room code cannot become useful just because the user presses Retry. The v0.2.0 changelog records a change to sender retries: create a fresh room code after a timeout or terminal failure, rather than reusing an expired one.

1. 01

   Failure

   A timeout or disconnect ends the current attempt.

2. 02

   Reset

   The sender creates a fresh room code.

3. 03

   Reconnect

   The receiver joins the new attempt using the updated code or link.

The engineering lesson is small but useful: an error action needs to reset the underlying state, not only change what the screen says. Role-specific recovery actions and clearer transfer messages are part of the same release.

The repository includes integration tests for out-of-order chunks, duplicate detection, missing-chunk repair requests, cancellation, and resource limits. They use a simulated peer transport, which makes those conditions repeatable. Real browser and network testing remains a separate part of validation.

• Large files can still strain low-memory devices, even with chunking and local storage.
• Connection success depends on the network and the availability of signaling and relay services.
• The application avoids server-side file storage. That does not mean a server can never relay encrypted traffic.
• Cached interface assets do not remove the need to establish a connection between peers.

A useful next validation step is a documented device-and-network matrix, especially for larger files and interrupted transfers. This page makes no throughput or reliability guarantee.