- Category
- Cybersecurity
- Rank
- No. 976Tools index
Previous survey · No. 963 ·
- Platform
- web · mobile
- Type
- APP
- Builder
- @deedydas
- GitHub
- 464 stars
- Date
About
QRFerry transfers a file between two devices entirely in-browser by streaming it as an animated sequence of QR codes, using RaptorQ fountain coding, Brotli/gzip compression, and WebAssembly-based QR rendering (fast_qr) and scanning (ZXing-C++) to survive dropped or blurred frames. It supports single and dual-lane 'Turbo' modes for higher throughput and verifies data integrity with layered CRC checks before saving, avoiding any server upload of the file.
What it does
QRFerry turns a sending screen into a temporary visual broadcast. Pick a file, point a phone camera at the display, and save after recovery completes. Repeated repair symbols let the receiver start late, ignore bad captures, and assemble the file without a direct device connection.
Why it's ranked here
The project pairs an unusual transport with unusually concrete engineering. It exposes measured render, camera, scan, and decode performance instead of promising speed blindly. Multiple profiles trade readability against throughput, while checks at several boundaries prevent a plausible-looking but corrupt download. The laboratory profile is clearly labeled rather than presented as routine performance.
What's good
The receiver accepts unique symbols out of order and tolerates erased camera frames. Compression earns its cost only when it saves meaningful space. Raw QR byte encoding avoids text expansion. Single-lane profiles keep one target stable, while dual-lane profiles alternate updates so each code remains readable longer. The test harness includes noisy WebAssembly render-and-scan round trips, corruption rejection, capacity checks, builds, and server rendering.
Tradeoffs
Fast dual-lane use is physically demanding. It requires fullscreen playback, a matching receiver option, landscape orientation, and a phone held close and steady. The densest profile is explicitly experimental. Browser builds cap files at 512 MB. Camera quality, display refresh, framing, and ambient conditions can reduce delivered throughput below the nominal optical channel. This is also a private application package, not a reusable published library.
How to use it well
Use QRFerry for local transfers where one device can display a file and another has a rear camera, especially when uploading the file to an application server is undesirable. Start with a stable single-code profile, watch the reported scan and decode metrics, then raise speed only when framing remains reliable. It does not replace remote sharing, unattended synchronization, or transfers where the devices cannot maintain visual contact.
Technical notes+
The current optical path in lib/optical-transfer.ts uses QF4 frames, QFC4 containers, CRC-32 validation, and @raptorqr/core WebAssembly RaptorQ packet encoding; lib/transfer-presets.ts derives symbol capacity and defines one-lane and two-lane profiles. lib/qr-renderer.ts renders raw bytes through @raptorqr/fast-qr-wasm, while lib/qr-scanner.ts configures zxing-wasm for one or two QR results per image. lib/compression.ts races gzip level 9 against Brotli quality 11 and retains compression only with at least a 64-byte margin. lib/qr-transfer.ts contains the older QF3 fountain-code protocol and legacy prefix support. package.json defines a private ESM TypeScript web application using Next, React, Vinext, Vite, Wrangler, and a Node.js requirement of at least 22.13.0. vite.config.ts targets a Cloudflare worker environment with optional D1 and R2 bindings; db/index.ts exposes Drizzle over D1, although the supplied transfer code does not show database use.
Observed
- Primary language
- TypeScript, with ESM configuration
- Interface
- Browser application with sender root page and camera receiver at /scan
- Packaging
- Private npm package; development uses npm install and npm run dev
- Runtime requirement
- Node.js 22.13.0 or newer for development
- Browser components
- WebAssembly QR rendering, QR scanning, Brotli compression, and RaptorQ coding
- File limit
- Browser transfer code caps original and transmitted files at 512 MB
- Test surface
- npm test covers codec behavior, WebAssembly render-scan noise, production builds, and rendered pages
- License
- No license is stated in the supplied repository text
Read from README.md, package.json, lib/qr-scanner.ts, lib/compression.ts, lib/qr-renderer.ts, lib/qr-transfer.ts, lib/optical-transfer.ts, lib/transfer-presets.ts, next.config.ts, vite.config.ts, drizzle.config.ts, eslint.config.mjs, postcss.config.mjs, raptorqr-assets.d.ts, db/index.ts.
What it can do
Transfer a file between two devices via animated QR code stream
File → Transferred file on receiving device
Encode file data using RaptorQ fountain coding to survive dropped or blurred frames
File data → Fountain-coded QR stream
Compress file data with Brotli/gzip before transmission
File data → Compressed data
Render QR codes using WebAssembly-based fast_qr
Encoded data chunks → QR code images
Scan QR codes using WebAssembly-based ZXing-C++
QR code video stream → Decoded data chunks
Stream data using dual-lane 'Turbo' mode for higher throughput
File data → Dual-lane QR stream
Verify data integrity with layered CRC checks before saving
Received data chunks → Verified file
Tags
Tech Stack
Comments (0)
No comments yet
Editorially curated, with community endorsements as a secondary signal. Corrections welcome.