Demonstrations
Watch it keep working while everything changes.
FrogNet is engineered so that changing conditions are ordinary, not exceptional. The best way to see that isn't a benchmark — it's watching the system stay up while the link starves, a node reboots, or two networks collide. Every demo below reads two ways.
The two flagship captures below are the real first-run experiments — recorded live, unedited. The rest land as they're captured.
The conversation never stopped.
A live HD call held together over a 900 MHz radio while the link was deliberately starved. The headline isn't the resolution — it's that nobody ever redialed. What you're watching is the actual first run, recorded as it happened.
HD, then audio, then a heartbeat — and back.
What you see: a live HD video call — 1280×720 at 22 frames a second — running across a 900 MHz radio with a one-megabit ceiling. Squeeze the link and it steps down the ladder (987 → 637 → 450 kbps) with audio holding priority as the picture thins; ease off and it climbs right back to L7 and full frame rate. No reconnect, no redial — and an on-screen counter shows ~89% of the bytes never had to be sent — an estimate from published WebRTC bandwidth for the same session, not a packet capture.
- Transport path
- Wi-FiWireGuardInternetWireGuard900 MHz
- Link
- 900 MHz radio, ~1 Mbit ceiling
- Baseline
- 1280×720, 22 fps, no drops, bidirectional, no delay
- Bandwidth saved
- ~89% (did-vs-would counter, estimated vs WebRTC)
- Impairments
- bandwidth reductionjitter injection
- Observed ladder
- 987 kbps637 kbps · L6450 kbps · L5audio priority850 kbps · L7 · 17.5 fps
- Operator action
- A slider — no reconnect, no redial; recovers on its own
The path it ran over — one heterogeneous route, coast to coast
Wired Wi-Fi, an encrypted internet tunnel, and a 900 MHz radio — all in one call. The adaptation responds to the characteristics of the link (bandwidth, latency, jitter, loss), not to any specific medium. That is what "transport independent" means, shown rather than claimed. Every transport it rides →
The companion capture — establishing the baseline
"Proof it works" — the steady-state run. HD video holding over the 900 MHz link before any degradation, with the did-vs-would byte counter reading ~89% saved. This is the baseline the ladder climbs down from.
UnREST, in one sentence you can watch
What you see: a bidirectional 1280×720 call at 22 fps on a one-megabit radio, with no four-second delay — because the wire carries only the audio and video themselves, not the REST framing and control traffic that normally rides along. Strip the messages and the picture fits where it never fit before.
"I never thought I'd be able to do this level of video at this bandwidth."
— from the live capture, 900 MHz runFour more that make the same point.
Different failure, same behavior: the system treats the disruption as routine and keeps the thing you care about running.
The network healed itself.
What you see: two separate little networks come into range of each other and, without anyone configuring anything, become one — everybody can suddenly reach everybody.
- Setup
- Two independent ponds, no shared config
- Trigger
- networks come into range
- Observed
- discoveryconvergencehost re-electionroutes updated
- Operator action
- None — no configuration touched
A node rebooted. Nobody noticed.
What you see: on the live network monitor, a node drops off the map, restarts, and rejoins — while everything else keeps working the whole time.
- Fault injected
- node reboot
- Observed
- node dropsroutes re-formrestartrediscoveryre-absorbed
- Rest of mesh
- Kept working throughout
- Operator action
- None — self-healed
One message, a thousand times, almost free.
What you see: the same status echoed out to a whole mesh of nodes, over and over — and the bandwidth graph barely moves.
- Workload
- repeated fan-outmany nodes
- Mechanism
- SAMEDIFFverdicts on the wire
- Observed
- Bandwidth graph stays flat as repetition climbs
- Unchanged re-assert
- A few bytes, not a full payload
Everything at once, still calm.
What you see: chat, live telemetry, and discovery all running together on the same network — and it just behaves.
- Running at once
- chattelemetrydiscovery
- Shared substrate
- One transient database, concurrent handlers
- Observed
- Stable under mixed load — no single-feature happy path
- Operator action
- None
The point of all of it
We optimize for the day something goes wrong.
Not for the benchmark on a good day. Every demo shows the same discipline — solve the root cause, design for failure, automate over configure — so that links flapping, nodes vanishing, and networks splitting are ordinary weather, not an outage.