A challenge to the field
Network programming made two assumptions in 1969 — and never revisited them.
Networking itself advanced enormously — QUIC, HTTP/3, TLS 1.3, BBR. The pipes got faster and smarter. What never moved is the model you program the network in: still request/response, still stateless, still the shape it had decades ago. Two assumptions underneath it 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.
Nothing below needs a new protocol or a faster transport. Same primitives — sockets, packets, HTTP itself — arranged to remember instead of forget. That is why it layers onto what you already run instead of replacing it.
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.
Network programming 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.
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.
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.
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.
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.
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.
Where this actually stands
Don't trust me — check it. The books derive the whole thing from first principles, the developer licence is free, the protocol is headed for an open standard, and a falsifiable simulator ships with it so "is this better" gets demonstrated instead of argued. And the honest state of the work: broadly exercised in general, thinly tested in specifics. The media path is the deep-tested exception — hardened, and on it the principles bought roughly 9×. If one path does that, the rest is the opportunity. Hardening the specifics is the work I'm inviting people into.