A challenge to the field

The networking world made two assumptions in 1969 — and never revisited them.

They were reasonable when memory was scarce and links were rare. They calcified into orthodoxy, taught by people who learned them from people who never questioned them. Both are wrong for the networks we actually build on now — and here is the tape that shows it.

Assumption one

Real-time media belongs on UDP.

Every stack you have ever used — RTP, WebRTC, SIP — sprays packets and salvages the wreckage, because TCP's reliability was ruled "too slow" for live media. So when the link degrades, you get corruption: blocky video, warbling audio, a call that dies.

We run live media on TCP, and drop whole frames at the sender under buffer pressure. There is no half-frame to salvage — only clean frames, or clean omission.

SoThe reliability everyone called a liability is exactly why ours stays clean while theirs corrupts.
Assumption two

Networking means sending messages.

Requests, replies, acknowledgments, retries, renegotiation. The entire discipline is the management of an exchange that reasserts itself the moment something fails.

We deleted the category. FrogNet is a shared memory — you write a value where you compute it and read it where you need it. Changing call quality isn't a renegotiated session; it's a memory write.

SoOur ladder auto-adjusts from HD down to a heartbeat and back with no redial. Theirs falls off a cliff.

The result

Clean, self-adjusting audio and video below 500 Kbps over a real 900 MHz radio — degrading and recovering on its own. Not a configurable floor. A floor you can live on.

§The evidence

Two first runs. Unedited.

Not a rehearsed demo reel — the actual experiments, recorded as they happened, narrated in real time. One establishes the baseline; one starves the link and watches the ladder move.

First run · live

Baseline. HD video holding over the 900 MHz link — 1280×720 at 22 fps, bidirectional, no delay — with the did-vs-would counter reading ~89% of the bytes never sent — an estimate from published WebRTC bandwidth for the same session, not a packet capture.

First run · live

The ladder. The link is starved live — 987 → 637 → 450 kbps — audio holding priority as the picture thins, then a clean climb back to full frame rate. No reconnect. No redial.

Video files land in media/ at deploy; the branded first-run frames stand in until then.

The dare

We are not claiming nobody can. We are asking: reproduce it — or tell us which assumption you're still defending.

And if you're already filing this under something you know — CRDTs, Reticulum, an overlay — the honest map takes each one in turn.

Show us clean, sustained, self-adjusting audio and video below 500 Kbps over a real degrading link, that recovers without a redial. If you can, we want to see it. If you can't, the two assumptions are worth revisiting — and that is the whole point.

§Why this generalizes

The call is the hardest case — not the only one.

Live video, bidirectional, over a starved radio is the worst thing you can ask a network to carry. It is also just one handler. SotF rides the same UnREST handler interface as the database and the game table — write a value where you compute it, read it where you need it, ship only the difference. The Communicator is a demonstration of that interface, not the ceiling of it.

Bring your own protocol — a sensor bus, a control loop, a codec — as a handler on the same interface, and it inherits what the call already has: the compression, the convergence, the degrade-don't-drop, the self-healing routes underneath. You supply the meaning; the fabric already moves it. Write a handler →