DirectlyDrop Technical Transparency and Release Notes

This record explains how DirectlyDrop actually behaves, not just how it is marketed. Features that do not exist are not implied; limitations, external dependencies, and failure conditions are documented as part of the product.

The page is updated alongside the published source and production build when transfer behavior, services, or user flows change.

The interface uses React and Vite, PeerJS handles pairing, and WebRTC RTCDataChannel carries files. Each session receives a cryptographically random four-digit peer identifier with the pangodrop prefix, preserving leading zeros.

Files are divided into 16 KB chunks. Sending pauses above a 256 KB buffered amount. Transfer begins only after recipient approval, acknowledgement timeouts are enforced, and a selection can contain up to three queued files.

DirectlyDrop does not upload file contents to a permanent app archive. Data normally travels browser to browser, while encrypted WebRTC traffic may be forwarded by TURN when a direct route is unavailable.

With OPFS support, incoming chunks are written to a temporary transfer file and removed after the browser download begins. Without OPFS, chunks remain in memory, so practical capacity depends on the browser and device.

PeerJS's default signaling service helps peers find each other. Google, Twilio, and Metered STUN servers may help gather ICE candidates. When VITE_TURN_CREDENTIALS_URL is configured, the app can load a valid TURN server list. These services may process IP addresses and connection metadata.

A TURN provider can impose limits, experience outages, or change policy. If credentials fail to load, direct WebRTC is still attempted but restricted networks may have no relay fallback. Production relay configuration therefore requires a forced-relay test.

Production pairing and local production-preview transfers were tested with synthetic 1, 5, and 20 MiB files. All nine timed runs reached completed states on sender and recipient, with methods and raw times published on the Test Results page.

The build also audits every indexable page for a title, description, canonical URL, one H1, structured data, and the AdSense account tag, plus sitemap, robots.txt, ads.txt, and the contact form shell.

Interrupted transfers cannot resume, offline download links are not generated, and there is no user-defined file password. Both peers must be online at the same time, and the room code is not a password.

Mobile operating systems may suspend background tabs, public TURN availability is not guaranteed, and large files can pressure memory when OPFS is unavailable.

A dedicated results page, three-run benchmark table, and real completion screenshot were added. Median same-device Chromium times were 286 ms for 1 MiB, 898 ms for 5 MiB, and 3,188 ms for 20 MiB, published as a bounded best-case measurement.

A local browser feature check and opt-in synthetic-file test mode were also added. Neither starts an automatic connection or transfer.

Room codes changed from seven digits to four cryptographically random digits with leading zeros preserved. Incoming files are no longer downloaded automatically; the recipient reviews sender, name, and size before accepting or rejecting each offer.

Zero-byte hangs, unbounded acknowledgement waits, and overlapping desktop sends were fixed. A dead relay host was removed, optional production TURN credentials can be loaded at runtime, and the UI reports direct or TURN routes.

Five repetitive guides were consolidated into one comprehensive guide, with permanent redirects from old URLs. Security, large-file, WebRTC, compatibility, and troubleshooting guidance now share one context.

Transfer Tools gained a local API diagnostic and a SHA-256 comparison tool that does not upload the selected file. Each tool states what it can and cannot verify.

The mobile room field now requests a numeric keyboard, limits digit-only typing to four characters, and still accepts a full invitation link pasted from the clipboard. The connect command is enabled only for a four-digit code or a valid DirectlyDrop invitation link.

If temporary-file writing or download preparation fails in the receiving browser, the incomplete transfer state and temporary entry are cleared and the sender receives a cancellation signal. Mobile selections above three files now explain that only the first three were queued, and PWA installation event listeners are removed when their component is unmounted.

For multi-file sends, the success screen no longer appears before the last queued file completes. A connection that closes during transfer now reports an error instead of silently clearing progress, and a recipient cancellation in the middle of a file also stops the sender loop.

Two minutes without incoming data or one minute without send-buffer progress now ends the stalled transfer. Temporary OPFS entries are cleaned when cancellation overlaps storage preparation or a disk write, and a stale write cannot reopen the old UI state. Chunks are written to their indexed positions in the temporary file, while desktop file selection is locked when disconnected or another transfer is active.

Content pages gained static HTML, distinct canonical URLs, structured data, corporate and policy pages, home navigation, a Netlify contact form, noindex error pages, and automated deployment checks.

A race that could drop the first incoming chunk while storage was being prepared was fixed, and simultaneous mobile and desktop interface mounting was prevented.