Why FrogNet exists

Not architecture. Not history. Seven observations.

FrogNet didn't start as a product. It started as a short list of things that are simply true about real networks — observed over fifty years of building distributed systems that had to work when conditions changed. Every design decision downstream is a consequence of taking these seriously.

01

Networks partition.

Not occasionally, not as an error — as a matter of course. Links drop, nodes go out of range, a truck drives into a tunnel. A network that treats a split as a failure is a network that fails constantly.

SoEach fragment keeps operating on what it can reach, and rejoins with no reconciliation when the path returns.
02

Bandwidth changes.

The same path is fiber one minute and a starved radio the next. Designing for a fixed capacity means breaking the moment reality moves off the number you assumed.

SoThe system adapts to whatever the link gives it right now — degrading in clean steps instead of dropping.
03

Users shouldn't have to care.

The person on the call, or the application making a request, should not know or need to know whether the bytes are crossing Wi-Fi, a tunnel, or a 900 MHz radio. Transport is the system's problem, not theirs.

SoTransport is fully abstracted — the same code runs identically over any bearer, and the application never sees the difference.
04

Intelligence belongs where the data is.

Shipping every observation to a distant brain and waiting for a verdict adds latency, a single point of failure, and a dependency on a link that may not be there. The decision should happen next to the sensor.

SoEvery node can run its own AI against live shared state — the control loop stays inside the mesh and survives the loss of the internet.
05

Shared state beats point-to-point coordination.

Most networking effort is spent managing an exchange — send, acknowledge, retry, sequence — that reasserts itself the moment something fails. A value several machines can simply see removes the whole category of that work.

SoThe network is a shared memory: write a value where you compute it, read it where you need it, with nothing in flight.
06

Recovery should be automatic.

If healing a network requires a human to log in and run a script, then every failure waits on someone being awake, reachable, and correct. Systems that depend on people at 3 a.m. are systems that are already broken.

SoDiscovery, election, routing, and repair run on their own — the network administers itself instead of waiting to be administered.
07

Infrastructure should belong to its owner.

A network you depend on but do not control is a network someone else can fail, surveil, monetize, or switch off. Ownership is not a privacy feature bolted on the side — it is the foundation everything else stands on.

SoNo ISP, cloud, or authority sits in the chain. You are not a tenant in someone's infrastructure — you are the infrastructure.
The thread

Solve the root cause once, at the architectural level.

None of these is a hard observation on its own. What was hard — and what took fifty years to see clearly — was refusing to treat any of them as an exception to be handled after the fact. Take all seven as the baseline, and a different kind of network falls out: one where the disruptions everyone else calls incidents are simply the weather it was built for.

The one line

Changing conditions are ordinary, not exceptional.