Every chunk, as it lands.
The inspector's piece map is the journal's own bitmap. It proves a resumed transfer kept what it had, and it is where a failed hash shows as a cell going from Have back to Missing.
Braidfor macOS, Windows and LinuxOne file, every network you have.
Most download managers open more connections to the same server over the same link. Braid opens them over different networks. Your Wi-Fi, your Ethernet and your phone’s 5G pull the same file at once, and every chunk is checked before it counts.
- App size
- 15.5 MiB
- Tests
- 507
- Written in
- Rust
- Licence
- GPL-3.0
ubuntu-26.04-desktop-amd64.iso
- Ethernet0.0 MiB/sen1, 0 chunks
- Wi-Fi0.0 MiB/sen0, 0 chunks
- Phone, 5G0.0 MiB/sPixel 7 Pro, 0 chunks
- Probed the server: 1.17 GiB, ranges honoured, ETag present. Split into 120 chunks.
A simulation of Braid’s scheduler, running in your browser. Unplug a path, damage a chunk or kill the process, and watch what the real engine does in each case.
You can see which road carried what.
The bar under each transfer is split by interface, and the sidebar shows every path’s live speed. A link that is contributing nothing is visibly contributing nothing.
The running application, with one thing staged: the machine it was captured on has a single routable interface, so Ethernet, USB Tether and Wi-Fi here are three loopback connections wearing those labels. The torrent’s swarm is a stand-in backend.
Bound, not routed
Each connection is pinned to a network interface, not left to your operating system’s routing table, which would send all of them down one link.
Measured, not assumed
Chunks go to whichever path is fastest right now. A slow link gets fewer, a link that dies has its work moved, and a cap you set is a ceiling.
Your phone counts too
With Braid for Android, a phone lends its mobile data as one more path. Scan a code once and it appears in the sidebar.
It would rather fail than hand you a wrong file.
A corrupt file that looks complete is worse than an error. Braid checks every chunk with BLAKE3 as it lands, and it treats these server behaviours as the warnings they are.
Advertises Range, then sends the whole fileRefused. Writing it would put the file's first bytes into every chunk.Answers 200 where a 206 was asked forThe resource changed. The partial is discarded, never spliced.Content-Range total changes mid-downloadSame verdict: a different file, so it starts clean.Gzips a ranged responseRanges would address compressed bytes. The chunk is aborted.Serves a login page with a plausible Content-LengthCaught before a byte of it reaches your file.Signed link expires under 16 connectionsRe-resolved before it lapses, once, not sixteen times.
The one rule a crash cannot break.
Chunk data is made durable before the journal claims the chunk. Swap the last two steps and resume trusts bytes that were never written. Try both.
- 1Write the chunk10 MiB lands in the .part file at its offset.
- 2Wait for the driveThe bytes are flushed, not just handed to the OS.
- 3Journal the chunkOnly now is it recorded as done, with its hash.
Pick an order, then cut the power between the steps.
| Durability mode | Flushes | Journal |
|---|---|---|
| Safe | After every chunk | Waits for the drive |
| Balanced, the default | Every 5 s or 64 MiB | Waits for the drive |
| Fast | Every 30 s or 512 MiB | Left to the operating system |
A native app on every desktop.
One Slint interface, built for three desktops from one source, with each platform’s own metrics and selection styling. A menu bar item, a queue, and handlers for magnet links and .torrent files.
Your interfaces, and how they are bound.
Tick the networks Braid may use and cap any of them. The Binding column shows the mechanism actually in force, so a quiet fall back to a plain source-address bind is visible instead of assumed.
Limits that know what time it is.
Paint the hours you want capped. Outside them Braid runs unlimited, and the schedule reaches a transfer that is already running, not just the next one.
A URL, a magnet link or a .torrent.
For HTTP, Braid asks the server first: the size, whether ranges really work, whether there is a validator to resume against. Checksum verification is offered up front, not discovered afterwards.
Expiring links, refreshed once.
Pre-signed URLs from cloud storage and CDNs are re-resolved before they lapse, not after they fail. Sixteen connections hitting a dead link produce exactly one refresh. A signature bound to your address is resolved once per path, because each path leaves from a different address.
BitTorrent, in the same list.
Magnet links and .torrent files sit beside everything else. A torrent expands to its files with per-file progress, reports peers and seeds, and obeys the same limits and schedule as an HTTP transfer. Braid registers as the system handler, so clicking a magnet link in your browser opens it here.
It is a client, not an index: no search, no bundled tracker list, and there will not be. Seeding is publication. Joining a swarm announces your address to everyone in it, and binding a transfer to one interface is not a privacy control.
Ways to connect.
A transfer’s paths are fixed when it starts, so add a phone first, then download.
| Setup | What carries the file | Needs the Android app |
|---|---|---|
| Computer alone | Every interface you select | No |
| Plain USB tethering | The phone shows up as one more network card | No |
| Phone on your network | Your connection plus the phone's mobile data | Yes |
| Phone on a cable | Your connection plus its mobile data plus its Wi-Fi | Yes |
| Several phones | Every network of every phone, each weighted by its speed | Yes |
Your phone is a second internet connection.
Braid for Android lends your phone’s mobile data to Braid on your computer. It forwards bytes untouched and stores nothing. The phone decides which networks it offers and how much data it will spend, and nothing is shared until you switch it on.
Install it.
Every package installs two programs: the braid desktop app and dl, the same engine on the command line.
| Platform | File |
|---|---|
| macOS 11 or later | Braid-0.1.0-macos.dmgOne universal build. Unsigned, so the first launch is right-click, then Open. |
| Windows 10 or later | braid-0.1.0-x86_64.msibraid-0.1.0-aarch64.msix86_64, and ARM for Windows on ARM. |
| Debian, Ubuntu | braid_0.1.0-1_amd64.debbraid_0.1.0-1_arm64.debsudo apt install ./braid_*.deb |
| Fedora, RHEL | braid-0.1.0-1.x86_64.rpmbraid-0.1.0-1.aarch64.rpmsudo dnf install ./braid-*.rpm |
Or drive it from a terminal.
Spread one download over two interfaces, cap the metered one, and check the result.
$ dl interfaces
$ dl add https://releases.ubuntu.com/26.04/ubuntu-26.04-desktop-amd64.iso \
--interfaces en0,en5 \
--limit-interface en5=5M \
--verify sha256:9d3f...Ctrl-C pauses rather than kills. Run the same command again and it resumes from the journal. Every flag is in the docs.
What has not been verified yet.
Braid is built and used on a Mac. Stated here so nobody assumes otherwise.
- Windows at runtime. CI builds it and runs the test suite on it, but nobody has installed the MSI and used it. Multi-interface binding there follows Microsoft’s documentation, not an experiment.
- The Linux desktop. Tested by CI on x86_64 and ARM64. No one has used the app on a Linux desktop yet.
- Real multi-NIC hardware. Per-interface binding is proven in CI with virtual interfaces, which is not the same as a machine with two real uplinks.
- Torrents across paths. A torrent uses one interface at a time for now.