Use Cases · built on UnREST
These aren't apps with FrogNet swapped in for a server. UnREST inverts the model the whole web is built on — and that inversion changes what is cheap, what is possible, and what stops being infrastructure at all. Here is where that matters, and where you could build on it.
Every case on this page comes back to one move. REST sends a request for every answer and a server owns the truth. UnREST gives each end the same memory and moves only the difference — so the centre, the round trip, and most of the bytes simply stop being necessary.
Ask, wait, receive.
A request per answer. A server in the middle owns the truth, fans every change out, and is the bottleneck and the single point of failure.
Already hold it. Sync the change.
Each peer holds the same structure; only diffs cross. Access is local and immediate, there is no centre to gate or lose, and the wire goes silent when nothing changes.
The full three-stage argument, with first-order numbers, is Appendix D of the build manual →
The most important thing about adopting UnREST: the bandwidth win arrives before the rewrite does. There are three stages, and each is useful on its own.
where most systems are
A server behind an API, a cache, a pub/sub tier, a presence service. Seven moving parts to keep one thing in sync — and every change is a round trip through the centre.
The baseline you're leaving.a library on the wire, not a rewrite
Put BLDC-1 and SAME/DIFF on the wire and leave your architecture exactly where it is. The client still calls the server — it just exchanges a compressed diff instead of the whole payload.
≈ 10× less bandwidth. No rewrite.change the model, not just the wire
No server owns the truth; each member holds the board and only diffs cross. Seven components collapse to one shared space; presence becomes a tuple; a round trip becomes a local read.
Silent when idle. No centre to lose.A brainstorm, not a roadmap. Each of these is a product the inversion makes newly viable: either the standing infrastructure it used to need evaporates, or it works over links that used to defeat it.
Live docs, boards, and multiplayer canvases that today need a socket tier, a pub/sub fleet, and a presence service.
Why UnREST · presence is a tuple and edits are diffs — the fan-out infrastructure and its bill disappear.
The private-data-plane version of the tools people currently rent — chat, files, calendars, dashboards — that a business owns outright.
Why UnREST · no central server means no vendor account, no data exhaust, no monthly per-seat floor.
Sensor and vehicle fleets that report into one live picture over narrowband, radio, or intermittent backhaul.
Why UnREST · only changed fields cross, so a field that fits nowhere under REST fits with headroom.
Software that keeps working disconnected and re-converges on reconnect — not bolted on afterward, but the default.
Why UnREST · every peer already holds the current state; a dropped member re-syncs on its own.
Media products for field, maritime, tactical, and rural use where "the call dropped" is not acceptable.
Why UnREST · SotF rides the handler interface — an adaptive ladder from HD to a heartbeat and back, no re-dial.
Turn- and state-based multiplayer without authoritative game servers to run and scale.
Why UnREST · each player writes only their own intent; an elected engine is the single writer of the board.
The opportunities above rest on ground that is already worked. Each of these is a real deployment or a validated field test — reframed around the one UnREST property that makes it work.
A hurricane takes the towers and the internet. Drop a box at the command post, the field hospital, and each vehicle; six agencies become one picture.
Property · no centre to lose — independent meshes discover and merge on their own, over Wi-Fi, radio, and tunnel at once.
A crew treats a patient across dead zones the whole way in; the hospital watches the data arrive continuously, not at the door.
Property · diffs, not payloads — a live web app rides links as narrow as 4800 baud over whatever path exists.
Unmanned ground vehicles share one live world model and coordinate with no base station brokering every message.
Property · shared memory, not a hub — FarSight UGVs read and write the same space, tolerant of nodes dropping in and out.
A single satellite uplink feeds dozens of working nodes without saturating the pipe — and nothing in the middle to tap.
Property · only change crosses the shared uplink; identity is a key, membership a token, so there is no centre to subpoena.
Ranches, worksites, and back-country camps on one private network — sensors, cameras, and comms that route through no one's cloud.
Property · transport-agnostic memory — long-range Wi-Fi, HaLow, and LoRa carry the same fabric across yards and miles.
Soil, tank, gate, and weather sensors across acres report into one live picture any node can read — no gateway subscription.
Property · write-by-name, read-by-pattern — a MeshTastic/LoRa bridge writes RF readings straight into shared memory.
Passive sensors learn a parent's daily rhythm and flag the day it breaks — no cameras, no wearable, no $60/month service watching.
Property · your own data plane — activity reads into the shared store; anomaly detection raises the alert, privately.
Chat, calls, a presence map, calendar, photos, and a wiki across the country — owned by you, dependent on no company.
Property · presence is a tuple — a full suite of apps has run a household for the better part of a decade.
A vehicle-mounted node holds its link through dense terrain and urban clutter as the bearer flaps — and when it drives out of range it detaches cleanly, then latches back onto whatever medium is available the moment it meets a FrogNet again, no operator in the loop.
Property · split and merge, automatic — the mesh re-forms, not reconnects. A 900 MHz HaLow node driven through Queens, NY with no observed drops, the topology changing under it at traffic speed.
Every case on this page rides the same two things: FrogNet, the sovereign self-forming mesh of shared memory, and SotF-ACP, the adaptive protocol for communication that does not stop. The books explain the why; the manual shows the how.
Have one of your own?
New use cases get developed with the people who bring them. If your situation looks like one of these — or nothing like them — describe it, and I'll tell you honestly whether UnREST fits and which stage to start at.