DashBeam pairs once, then sends without tickets, and that is the trade

Auto-accept turns a one-time pairing code into a standing grant

The v0.7.1 release is named DashBeam 0.7.1 - Trusted Devices, and the trusted devices row is the new mechanism in the feature list: you opt a paired device into auto-accept, and its files land without a prompt.

Before that existed, every send needed a ticket. The paired devices row describes pairing once with a code, remote or Nearby, and then sending without tickets. So the human decision happens exactly once, at pairing, when a verification code appears on both screens. Everything after that is trust you have already extended.

That is what makes transfers unattended, and it is also where the audit trail thins. The preview and history row gives you see before download plus a local transfer log, so the record of what a trusted peer sent is the local transfer log. Turn auto-accept on for a shared or family device and you will not be told what arrives; read the log instead.

Only one of the three send routes needs the other side installed

The README frames three routes: send a link or a QR code that opens on any device, send to a device you paired once, or send to a device already on your network. All three move the same bytes directly, encrypted end to end.

The route with no install is the link and QR code, where the receiver needs a browser or the app. The installation table labels the browser build at app.dashbeam.net as Web (Limited throughput) and gives no size for it, against roughly 10 MB for Windows, 15 MB for macOS, 13 MB for Linux and 15 MB for Android. The CLI is 4 to 5 MB.

So the zero-install route is also the limited-throughput one. The real-world stats table peaks at 125 MB/s on a gigabit link, and the footnote under it says throughput depends on your device, network and connection path. Plan bulk moves around the paired-device route and treat the link as the fallback for people who will not install anything.

Nearby discovery rides on mDNS, which guest networks and VPNs block

The nearby flow is documented in detail. Apps on the same network appear under Nearby in Settings, Devices, and also in the Send to a device list while you are sharing. Picking one and using Pair & Send pairs and starts the transfer in one step, though you can also pair from Settings without sharing anything. First contact shows a verification code on both screens, and who can find you is set in Settings, Network, Your discoverability.

The mechanism underneath is mDNS, and the README says plainly that it is often blocked on guest Wi-Fi and VPNs, with a troubleshooting page linked for exactly that case. mDNS is multicast, which is why networks that restrict multicast return an empty list rather than an error.

The consequence for everyday use is that an empty Nearby list is a network property, not a bug in your setup. The routes that survive a hostile network are the pairing code and the link, so if you depend on Nearby, check it on the networks you actually use before you build a habit around it.

The web build compiles the same WASM bridge the desktop app links

The scripts explain how one codebase serves both a Tauri desktop app and a web build. The relevant pair is short:

		"predev:web": "test -f frontend/src/wasm/pkg/wasm_bridge.js || ./scripts/build-wasm-bridge.sh",
		"build": "tsc -b && vite build",
		"build:web": "pnpm build:wasm && pnpm check:wasm && tsc -b && vite build --config vite.config.ts --mode web",

and the two steps build:web calls in front of the bundle:

		"build:wasm": "node ./scripts/build-wasm-bridge.js --release",
		"check:wasm": "tsc -p tsconfig.wasm-parity.json",

There are two Rust trees in the repository, engine and src-tauri, plus a wasm-bridge directory, so keeping the web and desktop builds in step is a maintenance obligation rather than a nicety. The mechanism handles it with a typecheck: check:wasm runs tsc against tsconfig.wasm-parity.json and fails the web build before vite ever runs. The hosted deploy path does the same with WEB_BASE set to a root.

Eleven installer files for one release, and Linux arm64 is not among them

The download table is pinned to v0.7.2 and lists a recommended format plus alternatives per platform. Windows x64 has a setup executable with an MSI and a portable ZIP, about 10 MB. macOS universal has a DMG with separate Apple Silicon and Intel DMGs, about 15 MB. Linux amd64 has a .deb with .rpm and AppImage alternatives, about 13 MB. Android lists a Google Play badge, with arm64, armv7 and universal APKs as alternatives, about 15 MB. The CLI and the browser build point at the downloads page and at app.dashbeam.net.

Two gaps are worth noticing. The Linux row is amd64 only, so a Raspberry Pi or an ARM workstation has no listed package even though the Android row offers armv7. And Windows covers x64 with 386 and arm64 nowhere in the table.

On Linux the flatpak/ directory and a flake.nix exist in the repository, but the table does not point you at either.

Formatting and linting span two Cargo manifests and one Biome config

Contributor tooling is defined in package.json and it is not TypeScript only. Formatting touches both Rust trees:

		"format": "biome format --write && cargo fmt --manifest-path engine/Cargo.toml && cargo fmt --manifest-path src-tauri/Cargo.toml",
		"format:check": "biome format && cargo fmt --manifest-path engine/Cargo.toml -- --check && cargo fmt --manifest-path src-tauri/Cargo.toml -- --check",

Linting is biome plus a typecheck, and there is a separate script for library tests under scripts/run-lib-tests.js. Around that sit .nvmrc, rust-toolchain.toml, biome.json, commitlint.config.js and .husky/, so node, Rust, formatting and commit conventions are all pinned in the tree, and deny.toml suggests the dependency licences of the Rust side are checked too.

The practical cost of a two-runtime codebase is one command chain: a change to engine means formatting two manifests, and a contributor without a Rust toolchain cannot run format:check at all.

Eleven translated READMEs and one source, in AGPL-3.0

The README you land on is one of eleven files. English sits at the repository root and the other ten live in docs/readme as README.zh-CN.md, README.ru.md, README.pt-BR.md, README.es.md, README.de.md, README.fr.md, README.ja.md, README.ko.md, README.pl.md and README.ar.md. The application itself advertises a longer set of supported languages behind flags, and Troubleshooting lives in docs/troubleshooting.md with notes on collecting logs.

Duplication that size has a cost. A correction to the installation table has to be made eleven times. Assume a translated README is behind and use the English one for anything you act on.

On licensing, the repository is AGPL-3.0, which is a stronger copyleft than MIT for anything you deploy as a service. PRIVACY.md and SECURITY.md sit beside CONTRIBUTING.md and CODE_OF_CONDUCT.md, and the project is explicit that there are no accounts, no tracking and no ads, which follows from the transfer itself happening between devices rather than through a stored link.

Reported speeds stop at one gigabit, so the ceiling is the link

The stats table reports a largest transfer of 452 GB, a fastest large transfer of 54 GB at 123 MB/s for roughly 1 Gbps, a high-speed bulk transfer of 328 GB at 93 MB/s, and a peak speed measured of 125 MB/s, again 1 Gbps.

Every one of those numbers lands on the same ceiling, which is about a gigabit link. The feature list claims multi-gigabit speeds that saturate fast connections, so the claim is about capability on hardware you may own and the table is about what was measured. Do not plan an SLA on either; the footnote says throughput depends on your device, network and connection path.

Two other feature rows are relevant. Resumable and multi-peer means an interrupted transfer resumes and one send can reach many peers. And self-host relays, configured under Settings, Infra, give unthrottled remote transfers through a relay of your own.

Editorial conclusion

DashBeam suits anyone moving large files between their own devices or a paired contact's device, and it suits them better than a hosted link service precisely because the bytes never land on a server. Two things to check before you rely on it: nearby discovery needs mDNS, which guest Wi-Fi and VPNs block, so confirm your usual networks before depending on the Nearby list; and if you enable auto-accept for a paired device, the verification code you saw at first contact becomes the last human check you get, because the preview and local transfer log are the only record afterwards.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. tonyantony300/dashbeam on GitHub