v0.2.0 — Transfers finish, and links open the app

Most phones want app-arm64-v8a-release.apk.

Transfers no longer stop just short of the end

TRANSFER_COMPLETE travels on the control channel, and SCTP orders each
stream independently — so on a link slow enough to have a queue, the
announcement overtook megabytes still sitting on the data channel. The
receiver compared byte counts, found itself short, and discarded a file that
was still arriving. It hit reliably near the end of any relayed transfer to a
phone, and never once locally, which is why the test suite was happy.

Both clients now wait for the bytes they were promised, giving up only after
ten seconds of silence. Verified against a phone over a relay: 101 MB, app in
the background the whole way, completed and checksum-verified.

Share links open the app

The manifest had always claimed /t/ links, but nothing read the intent and
verification was off, so a tapped link opened a browser tab and the link was
lost. Tapping one now lands on the offer screen, cold start or not.

An icon, and no white flash

A real adaptive launcher icon — the same mark the web client uses — including
a monochrome layer for Android 13 themed icons, and a launch window that
follows the system scheme instead of flashing white before a black app.

Also

• Release builds are shrunk, with WebRTC's native callbacks kept.
• Pill-shaped actions, matching the web client.

v0.1.3 — Works on mobile data

Transfers now work on mobile data.

What changed

A TURN relay is configured. Until now, two devices on mobile data could not connect at all:
carrier NAT gives neither side a reachable address, and no amount of retrying changes that.
A relay is the only way through, and there is one now.

A direct connection is still preferred. WebRTC only falls back to the relay when it cannot
find a direct path, so transfers on the same Wi-Fi go device to device exactly as before and
never touch it.

The relay cannot read your files. WebRTC encrypts end to end; the relay forwards
ciphertext it has no key for. It sees addresses, timing and volume — not contents.

Relay credentials are minted by the signaling service and expire. They are never shipped
inside the app, because an APK can be unzipped and anything inside it is public.

Also in this build

The app now fetches its connection configuration from the service at startup rather than
having it baked in, which is what lets the relay be added, changed or removed without
shipping a new version.

Installing

app-arm64-v8a-release.apk for essentially any phone made in the last several years.
Unsigned release builds, so Android warns about an unknown source.

Install this one on both phones — an older build ignores the relay and will keep failing on
mobile data.

v0.1.2 — Sending the link no longer kills the transfer

Fixes the reported failure: copy the link, switch to a messaging app to send it, and within a
minute the transfer is dead — which is fatal, because switching away to send the link is the
one thing the flow asks of you.

What was wrong

The app was frozen while waiting. The foreground service only started once bytes were
moving, so during the wait for someone to open the link Android suspended the app and the
connection to the signaling service died. The service now starts the moment there is a link
to share.

The server refused the peer coming back. A dropped socket stays registered for a while,
and that is exactly the window a returning peer arrives in. Reconnecting was rejected as
"role already connected". The returning party holds the capability for that role, so it now
takes the role over.

A dead socket announced a departure that had not happened. When the stale connection
finally tore down, it told the other side the peer had left — ending transfers that had
already recovered. A departure is now only announced if that connection still held the role.

Both clients gave up on the first drop. They now reconnect with backoff while the peers
are still finding each other, and stop once the data channel is open and signaling no longer
matters.

Also

A direct connection that cannot be established now says what to try instead of just stating
the problem. The usual cause is mobile data or a restrictive Wi-Fi; the quickest fix is
putting both devices on the same Wi-Fi.

Known limitation

There is no relay (TURN) server configured. On mobile data, carrier NAT usually prevents two
devices connecting directly, and no amount of retrying changes that — a relay is the only
way through. Same Wi-Fi is the reliable configuration today.

Installing

app-arm64-v8a-release.apk for essentially any phone made in the last several years.
Unsigned release builds, so Android warns about an unknown source.

v0.1.1 — Loading feedback while setting up a transfer

Feedback while a transfer is being set up, on both the web client and the Android app.

Choosing a file could sit on a single line of static text for the better part of a minute
with nothing moving — indistinguishable from a frozen screen.

What changed

The wait is mostly gone. The signaling service sleeps when it has been idle, and the first
request afterwards paid the whole cold start. Both clients now wake it as they open, so that
happens while you are still choosing a file rather than after you have committed.

Waits show that they are working. Anything with no measurable progress now has a moving
indicator instead of static text.

Slow waits explain themselves. If a wait runs past four seconds, a line appears saying why
— the service waking up, a network blocking direct connections. The fast path stays quiet.

Android: the file picker is covered too. The system copies a large file out of shared
storage before handing it over, which for a video takes real time and previously showed
nothing at all.

Installing

app-arm64-v8a-release.apk for essentially any phone made in the last several years.
Unsigned release builds, so Android warns about an unknown source.

Everything in v0.1.0 still applies: both sides online at the same time, nothing stored, and
files verified by checksum at both ends.

v0.1.0 — Direct: web, signaling and Android

Send a file straight from one device to another. The bytes travel directly between the two
peers over an encrypted WebRTC connection — nothing is uploaded, nothing is stored, and there
is no copy to delete afterwards.

Try the web client: https://direct-file-transfer.vercel.app

What's in this release

Web client — Next.js. Send and receive in the browser, with streaming to disk on
Chromium-based desktop browsers for files up to the full 100 GB.

Signaling service — Go. Introduces the two peers and then gets out of the way. It relays
SDP and ICE between exactly two participants and never sees a byte of your file.

Android client — Flutter. The reason it exists: a foreground service keeps a transfer
running while the app is in the background, which a browser tab cannot do. Progress shows in
the notification.

Installing the Android app

Download the APK matching your phone — app-arm64-v8a-release.apk for essentially any
phone made in the last several years. armeabi-v7a is for older 32-bit devices, x86_64 for
emulators.

These are unsigned release builds, so Android will warn about installing from an unknown
source. Both devices need the app, or one can use the web client in a browser — the two speak
the same protocol and interoperate.

How a transfer works

1. One side picks a file and gets a link. Nothing uploads; the file is read from disk as it sends.
2. The link goes to the other person however you like. The key lives after the #, which
   browsers never send to a server — so send the whole link, some chat apps trim it.
3. They open it, the two devices connect directly, and the file streams across.
4. Both ends hash the file as it moves and compare at the end. A mismatch fails loudly and
   discards the partial file rather than handing over something that will not open.

Worth knowing

• Both sides must be online at the same time. There is no server copy, so you cannot send
  to someone who is asleep. That is the trade-off for nothing being stored.
• Some networks block peer-to-peer traffic — strict corporate firewalls, a few mobile
  carriers. The app says so rather than hanging. TURN would work around it but relays your
  bytes through a third party, so it is off by default.
• Firefox and Safari can send any size but receive only up to 256 MB, because they cannot
  stream to disk. The page tells you before you accept, not partway through.
• On Android 15, a background transfer is capped at six hours per day by the platform.

Not done yet

Pause and resume across a dropped connection, an iOS client, and TURN configuration. The
largest transfer verified end to end is 157 MB; the 100 GB path is written and memory-bounded
but has not been exercised at that scale.