What's New in OpenDrop 1.0

OpenDrop 1.0 is out. This is the first build I'd put in front of anyone — preview releases were always meant for me, and a few patient testers, to break things. 1.0 is the baseline I'd want on my own phone, on my own desktop, with my own files moving across it. Here's what's new, what changed since the previews, and what isn't in the box yet. If you'd rather skim the full machine-readable list, the changelog page has the version markers and protocol numbers.

The headline: encryption everywhere, no exceptions

Every file you transfer through OpenDrop 1.0 is end-to-end encrypted on the sending device with ChaCha20-Poly1305 IETF AEAD (RFC 8439). The 32-byte content key is derived with HKDF-SHA256 from your account's shared secret — computed identically on each of your devices, so the key never travels over the network — with a fresh random 12-byte nonce prefix per transfer. Encryption is applied on every path:

• Chunked uploads, true-streaming uploads, and downloads (including range-sliced byte ranges)
• Thumbnails fetched from remote devices
• Direct desktop-to-desktop relays
• LAN and Wi-Fi HTTP/HTTPS transfers
• Phone-to-phone nearby Wi-Fi transfers
• Bluetooth Low Energy fallback transfers

On iOS we run the cipher through Apple CryptoKit; on Android API 28+ we use BoringSSL; older Android devices and the desktop run a pure-Dart or pure-Python fallback. The wire format is byte-identical across every implementation and is pinned by a shared test-vector file in the repo. Our infrastructure (the Cloudflare Worker control plane and our Fly.io / Oracle Cloud relay) routes ciphertext only and cannot read your files.

The desktop server and mobile clients advertise and require X-OpenDrop-Protocol: 2 on every request. Servers respond with HTTP 426 Upgrade Required to any client below protocol v2, and v1.0 clients refuse to connect to a server that reports a lower protocol version. The goal is to remove the downgrade-attack surface: there is no plaintext fallback, no "compatibility mode," no flag to disable encryption.

Auto-fallback transport: Wi-Fi, peer-to-peer, and the cloud

One of the questions I hear most often is "what does it use when?" The short answer: whatever's fastest and available, automatically.

• Same Wi-Fi. mDNS discovery via Bonjour (_opendrop._tcp.local.) finds your other devices on the same network. Files stream directly over LAN with no chunking and no size cap.
• Peer-to-peer. Across different networks, OpenDrop tries a direct device-to-device connection over WebRTC, using our own self-hosted STUN servers for NAT traversal (no third-party STUN, and no TURN). The free tier prefers this path to keep large transfers off the metered relay; on free, peer-to-peer transfers are sent in resumable 5 MB chunks (including downloads, via a forced byte-range request), while Pro streams over peer-to-peer.
• Bluetooth Low Energy. When the two devices are nearby but not on the same Wi-Fi (hotel Wi-Fi blocking mDNS, etc.), BLE handles small payloads.
• Encrypted relay. When a direct connection isn't possible, both apps dial out to OpenDrop's own relay, coordinated through our Cloudflare Worker control plane — there's no tunnel binary to download and no public URL to share. Free transfers go through our Oracle Cloud relay.
• Pro relay. Pro subscribers get the high-throughput Fly.io WebSocket relay (true streaming, no size cap) with automatic failover to a backup Oracle Cloud relay if Fly is ever down. Pro prefers this fast relay, with peer-to-peer as its fallback.

You do not pick the path manually. The app negotiates based on what it discovers during the mDNS phase and the relay connection state.

Cross-platform parity at launch

1.0 ships at the same baseline on iOS, Android, Windows, and Linux. The macOS desktop is the same Nuitka-compiled PySide6 build that ships on Windows and Linux, still in active development and not yet on the Mac App Store. The Flutter mobile apps use Apple CryptoKit on iOS and BoringSSL-accelerated AEAD on Android API 28+. The desktop server bundles an LGPL ffmpeg build for file conversion.

What OpenDrop Pro adds

The free tier covers direct-LAN streaming, remote transfers over our Oracle Cloud relay, QR pairing, BLE nearby transfer, and the single-device mesh. OpenDrop Pro at $2.99/month or $24.99/year (about 30% off annual) adds:

• Multi-device mesh. Pair multiple phones and multiple desktops to a single account, with same-account auto-connect via mDNS account hash.
• High-throughput Fly.io relay for large cross-network transfers (10 GB+), with automatic failover to a backup Oracle Cloud relay and no per-transfer size cap.
• Cross-device file conversion. Image (HEIC/PNG/JPG/WebP/BMP/TIFF), video (MP4/MOV/AVI/MKV/WebM), and RAW formats (CR2/NEF/ARW/RAF). Phone files queue against the desktop's ffmpeg; one-click undo restores from per-conversion backups.
• Cross-platform entitlement via RevenueCat. One subscription unlocks Pro on every device linked to your account, regardless of where you bought it (App Store, Google Play, or Stripe).

UX and theming

Nine built-in color palettes ship at 1.0: OpenDrop Brand (cerulean blue plus aqua cyan, the default), Ocean Breeze, Tide Pool, Sea Glass, Lilac Night, Cloud Blue, Peach Cream, Rose Petal, and Lavender Mist. Light, dark, and follow-system modes. iOS Cupertino dialogs honor system text size and Dynamic Type.

Other UX additions:

• Thumbnails for images, videos, PDFs, and SVGs across local and remote devices
• In-app preview for images (with InteractiveViewer zoom), code/text files, and PDFs
• Multi-select bottom action bar; breadcrumb folder navigation
• Recently Deleted with 30-day retention on the desktop server
• Drag-and-drop between tabs on desktop and across the mobile file and folder views
• Chrome-style device tab bar on desktop with per-device favicons

New privacy controls

The 1.0 release includes a few launch-day privacy improvements:

• Analytics opt-out in Settings on both mobile and desktop. When disabled, the app sends an X-OpenDrop-Analytics-OptOut: 1 header and our infrastructure discards the heartbeat without recording it.
• Site-wide cookie banner on nfdgames.com with Google Consent Mode v2, default-deny posture, and honoring of the browser Global Privacy Control (GPC) signal.
• New Vulnerability Disclosure Policy with coordinated-disclosure timelines and a safe-harbor clause for security researchers.
• EU/UK 14-day withdrawal form reproducing Directive 2011/83/EU Annex I(B). See the withdrawal page.
• Public status page auto-updated every 15 minutes by a Cloudflare Worker cron that probes each external service we depend on.

Headless and CLI mode

The desktop server can run without a GUI. A CLI client talks to a running GUI through a shared connection file, and single-instance detection on a dynamically chosen port keeps multiple invocations from colliding. The CLI is included in every desktop build and is the same binary as the GUI — there's no separate install. For automation, the CLI accepts pipes and lets you script transfers from a shell or scheduled task.

If you have an older build

Pre-1.0 builds were internal previews only. They cannot interoperate with the 1.0 protocol — any pre-1.0 client connecting to a 1.0 server gets HTTP 426 Upgrade Required. There is no compatibility mode and no plan to add one; the security goal is to eliminate the plaintext path. Please install the latest 1.0+ build from the download page before continuing to use OpenDrop.

What's still in flight

• macOS desktop is still in active development at 1.0. It's the same PySide6 desktop server that ships on Windows and Linux, just not yet released to the Mac App Store. iOS and Android cover the mobile side.
• Discovery is local-network-aware, not location-aware. Devices find each other through mDNS on Wi-Fi, Bluetooth Low Energy proximity, or cloud pairing. There is no GPS in the loop, and the apps don't read your coordinates.

That's the 1.0 line. Thank you to everyone who tested the preview builds, filed bugs, and yelled at me when something broke. The next milestones on the roadmap are: macOS desktop to GA, per-device and per-purpose key derivation (the info-tag work outlined in the AEAD module), and per-account subprocessor configurability for self-hosters. If something on that list matters to you, email support@nfdgames.com; I'm the engineer and I'll read it.