A file transfer that refuses to die

watch the wi-fi lane — it dies mid-transfer, and the receiver bar never stops filling

The itch

Moving a file between two phones is still broken

Two people sit across a table. One has an iPhone, one has an Android. They want to move a 2 GB video from one to the other. In 2026, their realistic options are: a chat app that recompresses the video and routes it through a datacenter in another country, a cloud drive link that requires accounts and working internet, or giving up and using a cable — if anyone brought the right one.

AirDrop is excellent until the other phone is the wrong brand. Quick Share is excellent until it silently fails to discover a peer in a crowded café where the 2.4 GHz band is a war zone. And in the environments where direct transfer matters most — legal offices where documents must never touch a third-party server, air-gapped rooms, aircraft, hospitals — the tools simply don't exist.

Each of these systems fails the same way: it picks one path, and when that path breaks, the transfer dies with it.

The idea

Connectivity is a portfolio, not a pick

At any moment, two nearby devices share far more channels than either of them uses: infrastructure Wi-Fi, a direct Wi-Fi link, two flavors of Bluetooth, NFC, cellular through the cloud. Today's sharing tools audition these channels, crown a winner, and bet the entire transfer on it.

ARMT treats them as a portfolio. It discovers everything available, holds the set open, and lets the transfer draw on whichever channels currently make sense — shifting allocation as conditions change, the way an index fund doesn't panic when one stock dips. A channel failing isn't an error to recover from; it's a price movement to rebalance around.

A dying channel isn't an exception. It's Tuesday. The protocol's job is to make it boring.

The user-facing contract is one verb: Share. No mode picker, no “try again over Bluetooth?”, no knowing what a transport is. Everything below that verb is our problem, not theirs.

The system

Four layers, one contract

fig. 1 — the stack. plugins are deliberately promiscuous about what counts as a “channel”.

The plugin interface is deliberately loose about what qualifies. If it can move bits between two devices — at any speed, in any direction, at any layer of the stack — it can register. Several experimental plugins are under evaluation and omitted here; we'll write about them when the measurements are ready.

Before any bytes move

Finding each other, everywhere

A transfer can only be as resilient as its discovery. ARMT's control plane broadcasts and listens on every discovery surface at once — Bluetooth advertisements for whoever's physically near, LAN service discovery for whoever's on the same network, and a decentralized relay layer for peers across the internet: no accounts, no phone numbers, no company server that can go down or lock you out. Identity is a keypair. The same keys that find your peer encrypt your session.

fig. 2 — one identity, four ways to be found. the relay layer stores the handshake until your peer wakes up.

When things break

Failover as a non-event

Here's the behavior everything above exists to produce. Mid-transfer, the fast channel is killed — jammed spectrum, a dropped access point, someone walking out of range. Classic tools show a spinner, then an error, then a retry button. ARMT's scheduler notices a producer went quiet, rebalances onto what's left, and the delivery curve just… changes slope:

fig. 3 — the behavior we're engineering toward (conceptual). resume and failover are the same mechanism.

Getting this to be true — not demo-true, but boringly, measurably true across channel failures the OS doesn't even surface promptly — is most of the engineering. Detection latency, half-dead links, and channels that lie about their health are where transport protocols go to suffer.

The terrain

The widest channel range anyone’s scheduled

The channels in our portfolio don't differ by percentages. They differ by orders of magnitude — in bandwidth, in setup time, in energy per byte, in how they fail. Scheduling across them is a different problem from classic multipath, where paths are at least the same species:

fig. 4 — six orders of magnitude between the slowest and fastest channels in the portfolio.

Inside the scheduler

Sense, decide, rebalance — forever

The scheduler is a control loop, not a lookup table. It continuously estimates each channel's live behavior, weighs cost against contribution, and re-decides the portfolio — because the answers change while the transfer runs:

fig. 5 — the loop never exits. a transfer is a sequence of portfolio decisions, not a plan executed once.

Why it's hard

The open problems (the fun part)

None of the above is hard to say. All of it is hard to make true. These are the questions we're actually working on — described as problems, because the answers are the product:

activationWhen is a slow channel worth waking at all? Waking it costs energy, setup time, and — on shared spectrum — performance stolen from channels already running. There are regimes where the “slowest” channel wins outright and regimes where touching it is pure loss. Mapping those boundaries is a modeling problem, not a heuristic, and classic multipath scheduling has never had to answer it across a range this wide.
radios that eat each otherWi-Fi, Wi-Fi Direct, and both flavors of Bluetooth on one phone share the same spectrum — often the same antenna. Turn everything on and the sum of the parts is less than the parts. The scheduler has to reason about channels that sabotage each other, with coexistence behavior that differs per chipset and that no OS documents. (If you've ever watched per-core-optimal task placement collapse under shared memory bandwidth, this will feel eerily familiar.)
trusting a channel you haven't usedEvery activation decision needs an estimate of what a channel would deliver — before committing traffic to it. Probing costs the very capacity you're trying to measure; stale estimates are worse than none. Cheap, honest channel estimation on mobile radios is an open measurement problem we're deep inside.
the missing dimensionEvery scheduler on earth models bandwidth, latency, reliability, and energy. Our cost model carries a fifth dimension that we haven't seen represented in existing transport schedulers. It's the key to why our channel set can be wider than anyone else's — and it's all we're saying until the paper.

You'll notice we're describing the problems and not the answers. The answers — the models, the thresholds, the measurements — are the work, and they stay in-house until the paper.