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.
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.
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.
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.
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.
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.
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.
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.
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.
Taking all seven as the baseline changes the programming surface, and the trade is one programmers have made before: moving from assembly to C meant giving up hand-managed registers and taking a compiler. FrogNet asks the same trade — give up the message, take the memory. What you give up is protocol design, and the objection is correct on its own terms: you do lose control of something you learned to do well. The programming surface, in full →
Take all seven seriously and the network comes alive.
The Living Network is not plumbing under FrogNet Memory — it is the first product of the observations, and it stands on its own. It discovers its environment and other nodes. It organizes itself and elects its roles. It adapts to topology and transport changes, across heterogeneous bearers. It splits when physical connectivity separates it, and heals and merges when connectivity returns. It keeps operating with no permanent external control plane, and its nodes are sovereign rather than helpless clients of infrastructure.
That machinery is useful to applications that never touch FrogNet Memory at all: emergency communications, rural and off-grid networks, robotics, mobile systems, degraded networks, unusual radio bearers, disaster response, sensor fleets, tactical environments. If all you take is a network that behaves like a living thing, that is already the product.
And it is why the rest of the story exists. Once a network can maintain itself, it can have memory. Once it has memory, applications can share state instead of choreographing every conversation — which changes the programming surface. Living things learn, grow, and — through the Guild — evolve.
The one line
Changing conditions are ordinary, not exceptional.
A network you own is not a thing one person can hand you.
Linux won by being ownable. That took a community with working groups and maintainers, not a founder with a following, and it is the honest reason this page ends with an ask rather than a download.
The engine has a keeper; the protocol does not. It is headed for an open specification under the Foundation, and somebody other than me has to write it — that is a working group with no code in it, open now, needing no engine access or licence. So is the governance work underneath it.
Ten subsystems are open besides, and joining one is a decision you make rather than a position you are given. Ownership of an area goes to whoever does the work, which is also how it will go for the parts I currently hold.
A messiah has followers; a journeyman has a guild — and the difference matters here, because better gets demonstrated against the simulator rather than argued.
"C didn't replace assembler. It uses assembler. You lose some of that exquisite control, and you gain so much more. That's what FrogNet Memory does for you."
The Monitor video — watch the series →