v0.3.7

CD v0.3.7 includes the transfer performance work and supporting CLI, browser, relay, and verification changes from PR #63.

Transfer speed improvements

• Stop compressing already encrypted WebSocket records in the Worker, avoiding compression CPU work without changing encryption.
• Negotiate encrypted transfer chunks up to 768 KiB while retaining the 256 KiB base size and compatibility with older peers. Browser relay sends retain 256 KiB frames where larger frames measured worse.
• Read browser file sources in bounded 4 MiB blocks. A 64 MiB diagnostic workload needs 16 reads instead of 256. Single-file sends also skip a redundant rechunking copy; bundles retain their batching.
• Batch browser OPFS storage writes near 4 MiB and overlap decryption with one storage write at a time. Disk-write failures still propagate to the receiver.
• Decrypt exclusively owned CLI records in place and reuse ciphertext storage after synchronous TCP writes. Relay and WebRTC records retain separate ownership while queued or awaiting replay.
• Offer authenticated, encrypted TCP for same-network CLI transfers, including a reverse connection when the sender cannot accept inbound connections. Unavailable TCP falls back to WebRTC and relay. The TCP lane does not apply to browser or resumable v2 transfers.
• Calculate folder ZIP sizes from metadata instead of checksumming synthetic payloads during preparation. Adaptive browser send windows retain bounded queues and accommodate two negotiated chunks to avoid an acknowledgment deadlock.

Recorded results

These are the PR's local benchmark results on specific snapshots and workloads, not new benchmarks of the final merge. The TCP iteration's full dirty baseline was not published, so that result is a provisional historical observation and does not establish a speedup for this release. Receiver-plus-flush completion is the measured metric below. Each cited comparison uses seven trials; the report includes raw data, variation, and rejected experiments.

• Disabling WebSocket compression improved forced-relay completion by 1.86× for browser-to-browser, 2.57× for browser-to-CLI, and 1.52× for CLI-to-browser, compared with the prior CD compression setting. Direct-allowed results were mixed.
• Bounded source reads reduced browser-to-browser relay completion from 1151.2 to 1062.4 ms, and browser-to-CLI relay from 700.0 to 635.3 ms.
• The provisional TCP ciphertext-reuse experiment reported a 256 MiB RAM-output completion median change from 232.5 to 197.3 ms, an observed 1.18× improvement over prior CD. In that particular cohort, completion was 5.09× faster than the faster croc mode; readiness remained slower.
• Removing the extra single-file copy reduced browser-to-CLI relay completion by 6.8% and browser-to-browser direct-allowed by 4.6%. Browser-to-browser relay took 1.4% more time in that experiment.
• Against croc 11.5.5's official browser client, CD completion was 2.15×–4.45× faster in five of six direction/mode combinations. Browser-to-browser direct-allowed was 1.20× faster. These are same-host comparisons with preloaded pages and private relays, not public-internet measurements.

The original goal of being at least 1.5× faster than croc in every required scenario and timing metric was not achieved. The complete acceptance run verified 489 transfers but still missed readiness and several completion gates. The measured physical LAN used a 100 Mb/s link. No universal speedup is claimed, and the separate experiments above must not be multiplied together.

Full benchmark report and raw evidence

Other changes included

• Resumable v2 transfers with authenticated session binding, retained verified progress, bounded session history, and waiting/paired leases. CLI and browser support are included.
• Paired-device CLI commands and supporting device discovery, encrypted transport, and optional Firebase wake-up infrastructure. Android remains a development preview; this release does not include an APK or claim Android performance improvements. New device and resume endpoints require the matching Worker.
• QR output with cdx send --json --qr <fresh-png-path>, stable transfer identifiers, opt-in progress, structured failure/retry information, and request IDs for safely repeating background sends.
• Shared file-sharing skill generation, transfer-route diagnostics, benchmark comparisons with croc, and checks of real browser/CLI, relay, WebRTC upgrade, resume, retry, and device behavior.
• Retain main's receive-directory confinement, exclusive random staging files, overwrite protections, bounded bundle extraction, filename-collision handling, code-directory authorization/rate limits, cancellation, and ICE candidate fixes.
• Close the remaining review findings: bound browser ZIP directories to 8 MiB and 10,000 entries before allocating, validate safe integer offsets, serialize resumable admission, and make raw WebSocket diagnostic timeouts interrupt stalled sends. Larger bundle directories fall back to offering the ZIP.
• Retain a 32 MiB browser ordering buffer so delayed relay records can coexist with the CLI's 24 MiB striped send window. Browser send queues keep their separate 16 MiB cap.
• Keep benchmark proxy destinations fixed even for crafted request URLs, check resumable offsets before signed conversion, and bound record allocation arithmetic before adding lengths.
• Accept -- in cdx wait and cdx status so transfer identifiers beginning with a dash can be passed safely.
• Restore multi-file integration coverage, adjust storage tests for the larger batches, and update development dependencies to remove the reported npm vulnerabilities.

Validation and availability

The review includes JavaScript tests, Go tests and race checks, TypeScript, npm/Go vulnerability scans, history secret scanning, real browser/CLI transfers, and Worker deployment dry runs. All ten 64 MiB transport cases verify exact SHA-256 payloads, including forced relay, slow receivers, and relay-to-WebRTC upgrade.

The release provides cdx binaries for Linux, macOS, and Windows on amd64 and arm64, plus SHA-256 checksums. Run cdx update to update an existing installation. Publishing these binaries does not deploy the production website or Worker; browser/relay changes need a separate deployment.