A responsive browser application that helps nearby devices discover one another and transfer files directly with WebRTC.
Relay explores a simple question: how can file transfer between nearby devices feel immediate without requiring an account, native application, cable, or cloud upload?
The result is a ShareDrop-style web experience. Users open one URL, see available browser peers, approve a connection, choose files or a folder, select a destination, and approve the incoming transfer. The interface uses large visual steps and explicit status changes so the task is understandable with minimal reading.
I designed and implemented the product end to end:
- Product flow and responsive interaction design
- Browser peer discovery and presence lifecycle
- WebRTC negotiation and data-channel transfer protocol
- Distributed signaling for serverless deployment
- Consent dialogs, progress states, downloads, and error handling
- Automated tests, deployment, and production diagnostics
Browser-to-browser transfer combines several difficult constraints:
- Browsers cannot freely scan arbitrary devices on a LAN.
- Serverless instances do not share in-memory presence state.
- File payloads should not pass through the application backend.
- The interface must remain understandable across phones and desktop computers.
- Refreshes and short-lived sessions must not make a browser discover itself.
flowchart TD
D[Open Relay] --> P[Discover browser peers]
P --> C[Approve connection]
C --> F[Choose files or folder]
F --> T[Select destination and send]
T --> A[Receiver approves transfer]
A --> W[WebRTC streams file data]
W --> X[Receiver downloads files]
The hosted service derives a short-lived discovery cohort from a one-way hash of the outward-facing network address. Redis provides shared presence and signaling across serverless instances. Once WebRTC negotiation succeeds, file chunks travel directly through an encrypted RTCDataChannel.
The visible scan freezes after peers are found to prevent cards from continuously changing position. A manual Scan again action refreshes the snapshot, while an unobtrusive heartbeat keeps the browser reachable.
| Decision | Reason |
|---|---|
| WebRTC data channels | Keeps file bytes peer-to-peer instead of relaying them through the backend |
| Redis-backed signaling | Provides consistent presence across multiple serverless instances |
| Stable local peer identity | Prevents refreshed sessions from appearing as another nearby device |
| Separate connection and transfer consent | Gives recipients control before data is sent |
| Chunked streaming with backpressure | Avoids filling the browser's data-channel buffer during large transfers |
| Receiver-controlled downloads | Works with browser download-safety restrictions |
| Frozen discovery snapshot | Makes the device list visually stable and predictable |
- Three large steps: select device, choose files, send
- High-contrast selection and connection states
- Large accept/decline actions in modal dialogs
- Explicit destination name before sending
- Responsive single-column behavior on small screens
- Keyboard-operable controls and semantic status regions
The application was exercised across separate laptops and browser sessions on the same network. The interface visibly distinguishes the current browser identity from discovered peers and provides manual rescanning when the network changes.
- 10 automated tests covering protocol validation, network grouping, application routes, and deployment behavior
- Production health endpoint verifies the distributed signaling store
- Runtime error scans are checked after deployment
- Manual testing covers discovery, connection approval, file selection, destination selection, transfer approval, progress, and downloads
File contents are not intentionally stored by the signaling service. Presence and WebRTC signaling are short-lived. Users approve both the connection and the transfer.
Network-address grouping is a discovery convenience rather than authentication. VPNs, carrier-grade NAT, shared networks, and guest-network isolation can affect who appears or whether a direct peer connection succeeds. A future security milestone will add cryptographic pairing-code verification.
JavaScript · Node.js · Express · WebRTC · Redis · Vercel · HTML · CSS · Node Test Runner
Relay required treating networking, privacy, distributed state, browser constraints, and interaction design as one system. The most important lesson was that a reliable peer-to-peer experience depends as much on stable identity and clear state transitions as it does on transport code.
The production source is maintained in a private repository. This public repository intentionally contains only the case study and approved screenshots.