HOW TO THINK LIKE A FROG
Networking for the 21st Century
FrogNet combines fifty years of lessons in networking, programming, and hardware engineering to move the science into this century. From the user's perspective, nothing changes — and a great deal more becomes possible.
John W. Fawcett, CEO · Daniel Tone, VP of Engineering
The FrogNet Living Network · Fawcett Innovations LLC
Revised August 2026
Network engineers can skip this section. The technical material starts at the Introduction.
The rest of this document is for network engineers. This section is for everyone else. It is shorter than the rest on purpose — you do not need the technical detail to understand what FrogNet does or why you might want one.
Imagine a small box — about the size of a deck of cards — plugged in at your house. Your mother has one at her house. Your sister has one at her flat in London. Each box costs about what you'd spend on a nice dinner out.
Plug them in and they find each other. You do not configure anything. You do not set up accounts. You do not pick a service plan. The boxes form a private, encrypted network that runs a photo gallery, a family chat, a shared calendar, a bulletin board for sticky notes, a family map that shows where everyone is, and video calling — all on hardware that belongs to your family and nobody else.
Your photos are not on iCloud. Your messages are not on WhatsApp. Your location is not sold to data brokers. Everything stays on your boxes. The only thing that crosses the internet is encrypted traffic that nobody — not your internet provider, not a hacker, not a government — can read, and that does not look like FrogNet to anyone watching.
The ongoing cost is a few dollars a month — a small broker subscription that lets your phones reach the network when you're away from home. That is all. No per-person fees. No storage tiers. No annual price increases. No surprise changes to the terms of service. A small broker subscription, and your family has its own private internet — internationally — for as long as the boxes are plugged in.
The actual cost depends on how the broker is deployed. A typical family network running on a commercial broker service is expected to run a few dollars a month — primarily data transfer for the traffic that crosses the internet between your boxes. A family running the broker on their own hardware pays essentially nothing beyond electricity. Larger or more active networks cost more; the current FrogNet development network, running heavy testing traffic across Seattle and New York, runs about forty dollars a month. A typical Mom-and-family deployment will be on the low end of that range, not the high.
Most people are already paying for all of this. They are just paying a different company for each piece, and their data is spread across those companies. Here is what a typical family pays today for the services a single FrogNet box would replace, and what each service costs on FrogNet.
| What You Do | What You Use Today | Typical Cost | How FrogNet Does It | FrogNet Cost |
|---|---|---|---|---|
| Store family photos | iCloud+, Google One, Amazon Photos | $3–$10 / mo | Private gallery on your box | Included |
| Know where family is | Life360 (Gold), Find My | $15 / mo | GPS map in the FrogNet app | Included |
| Monitor your home | Ring, Nest, SimpliSafe | $10–$20 / mo | Sensors on your box, no cloud | Included |
| Check on an aging parent | Life Alert, medical alert services | $30–$60 / mo | Passive sensors + family alerts | Included |
| Share files with family | Dropbox, Google Drive, OneDrive | $10 / mo | Peer-to-peer, on your hardware | Included |
| Message your family | WhatsApp, iMessage, Signal | Free but with tradeoffs | FrogChat on your box | Included |
| Video call family | FaceTime, Zoom, Meet | Free with limits | The Communicator — peer-to-peer, no call service | Included |
| Shared calendar | Google Calendar, Apple Calendar | Free, but your schedule trains AI | Calendar on your box | Included |
| Typical family total, today | $60–$120 / mo, plus unlimited access to your personal data | Total on FrogNet | A few $ / mo, and your data stays yours |
Look at the bottom row. The right side is the whole bill on FrogNet — one broker subscription, for every person in your family, everywhere you live, for as long as the boxes stay plugged in. Your data stays on hardware you own.
The left side is what you already pay — money leaving your household every month, plus a second price that never shows up on the bill: unlimited access to your personal data. The companies in that column read your messages, scan your photos, sell your location, and train their AI on your schedule. You pay them, and then they monetize you on top. FrogNet is the offer to stop paying both prices.
If there is one scenario that explains why this matters, it is this one.
An elderly parent lives alone. You want to know she is okay. The options on the market are not great — cameras she will hate, wearables she will forget, services that charge sixty dollars a month to watch her.
A FrogNet box at her house, with a few small passive sensors, learns her daily patterns. When Mom gets up. When she makes coffee. When she moves through the house. It does not watch her. It does not record her. It notices when the pattern changes. If Mom does not get up at her usual time, the system alerts the family — through the private FrogNet, not through a company's servers. No cameras. No surveillance. Her dignity stays intact. Your peace of mind goes up.
That one use alone is worth the cost of the box.
Every app on your phone assumes the internet is there. When it is not — a storm, a blackout, a rural road with no bars — your apps are useless. You cannot call, text, or check on anyone.
FrogNet does not assume the internet is there. Each box is a complete, self-contained network. If the internet disappears, the box keeps running. If two boxes can see each other by WiFi or Ethernet, they mesh together and share everything — photos, messages, sensor data, GPS positions — with no internet required. When the internet comes back, everything catches up.
This matters most in the moments you cannot plan for: when a hurricane takes out the cell towers, when your kid is at a camp with no coverage, when an ambulance drives through a dead zone with a patient in the back. The same box that handles your family photos in good weather keeps working in bad weather. That is not a feature anyone else offers.
For a longer look at how FrogNet performs in emergencies, see Appendix A.
People ask how FrogNet compares to Signal, or to a VPN. The short answer is that Signal is excellent at what it does, and a VPN is useful for what it does, but neither one does what FrogNet does.
Signal protects the content of your messages from the people carrying them. FrogNet eliminates the carrier. There is nobody in the middle to trust, compromise, or compel. No servers to subpoena. No phone numbers. No accounts. No metadata. And it keeps working when the internet does not.
A VPN is an encrypted tunnel to someone else's building — the cloud, Google, Apple, Meta. Your data still ends up on their servers. A FrogNet is not a tunnel. It is your own building. The services run on your hardware. There is no "other end" where a company has your data. There is no company at all.
Everything in this document has been recorded. There is a video series that goes from a bare Linux box to a transcontinental video call, and a set of deeper recordings that open the hood on each layer. Where a section of this document describes something that was filmed, the recording is linked in the margin. Nothing here asks you to take a claim on faith that you could instead watch.
WATCH Welcome — the origin, and the network running now
WATCH What It Is — the whole proposition in eight minutes
Everything described above is operational today. FrogNet runs across nodes in Seattle and New York, over Ethernet, WiFi, WireGuard tunnels, and a 900 MHz radio link, with more locations coming online. On April 17, 2026, a collaborator in New York completed the first independent end-to-end closed-loop demonstration — a web application, a sensor, and a physical actuator, all on a WiFi network in New York, coordinating through shared memory 2,400 miles away in Seattle, entirely over FrogNet's semantic protocol. It is not a prototype. It is not a simulation. It is a production system built over more than a decade by a network architect with fifty years of experience at companies including Boeing, Electronic Arts, Sierra On-Line, Microsoft, and NanoString Technologies.
The rest of this document explains how it works. It describes thirteen paradigm shifts — foundational assumptions about how networks have worked since 1969 that FrogNet replaces — followed by a comprehensive inventory of everything FrogNet is and does. If you are not a network engineer, you do not need to read it. If you want to understand why the claims in this section are architectural truths rather than marketing promises, read on.
COMPANION This document is the why. Its companion, The Magnum Croakus, is the how — the complete build and reference manual, with the source-level detail, the worked examples, and the parts that are not built yet named honestly. Where a shift below has a chapter that goes deeper, that chapter is named.
Every network in existence today was built on a set of assumptions that made sense in 1969. Connectivity is rare and expensive, so design for disconnection tolerance. Memory is scarce, so keep the network stateless. Administrators are available, so require human configuration. The internet is reachable, so treat it as the backbone.
Those assumptions have calcified into orthodoxy. Fifty years of protocol design, tooling, and engineering education have been built on top of them. Nobody questions them because everybody learned from people who learned from people who learned from people who never questioned them either.
FrogNet questions all of them.
This document describes thirteen paradigm shifts — foundational assumptions about how networks work that FrogNet replaces with better answers for the environments it actually operates in. It then describes, in detail, everything FrogNet is and does.
Reading this document will not make you a FrogNet engineer. But it will make you think differently about what a network can be — and that is the prerequisite for understanding why FrogNet matters.
FrogNet did not make incremental improvements to existing networking. It went back to first principles and replaced thirteen foundational assumptions with designs that match the actual constraints of the environments it operates in.
The paradigm shifts in this document are not theoretical, and the clearest evidence for them is a fact about the schedule. The work spans more than a decade — most of it spent inside the old assumptions, making slow progress against problems that would not yield. The system described here — the transport-abstracted fabric, the semantic compression engine, the discovery and routing layer, the shared memory, the sensor and AI platform, and a real-time adaptive media plane — came together in under a year, and it came together only after those assumptions were set down.
That is not a claim about unusual talent. It is a claim about the leverage of the ideas. Most of the effort in conventional networked systems goes into building and debugging the very machinery these shifts delete: the message-passing, the session state, the consensus, the per-application protocols. Remove the machinery and one person can hold the whole system in their head. The proof of a paradigm is not that it can be argued for — it is that it lets a small number of people build what used to take many. The decade is what it cost to find the shifts. The year is what they were worth.
Every network stack in existence is built around a specific transport assumption. TCP/IP assumes reliable-ish packet delivery. Radio protocols assume unreliable, low-bandwidth, high-latency links. WiFi assumes high-bandwidth local area. The entire OSI model is built around the idea that you choose your transport and build your protocol for it.
FrogNet separates transport from processing completely. The application layer has no idea what transport is underneath. The same code runs identically over fiber, WiFi, Ethernet, WireGuard tunnel, LoRa, satellite, or a narrowband RF link. You don't configure for the transport. You don't optimize for it. You don't even know it's there. The semantic compression layer adapts automatically to whatever the link gives it.
This isn't just transport agnostic as a marketing claim. It's an architectural decision that eliminates an entire category of protocol design work. It also means that a single deployment can span WiFi, Ethernet, and RF simultaneously — the same network, the same code, the same behavior, regardless of what the physical layer is doing underneath.
One line worth stating explicitly: the radio is just a pipe. Which radio? Whichever one is there. FrogNet does not care, and FrogNet is not a radio protocol. The conclusions in this document about performance, compression, and survivability are consequences of what happens above the transport, not of any particular choice of transport below it.
CROAKUS Part III, Hooking Up the Network — the three honest ways to attach a node, and why the differentiator is transports multiplexed in one topology.
WATCH Hardware — the same claim, demonstrated on a bench with three radios
Every networked application ever built assumes connectivity as the baseline and treats disconnection as an error condition to be handled. Offline mode is a feature you add later, grudgingly, when users complain. Progressive Web Apps, service workers, local storage — these are all retrofits on top of a fundamentally online-first architecture.
FrogNet inverts this. Offline is the default. Every node operates fully standalone as the baseline condition. Connectivity is an enhancement that arrives when available and disappears without consequence. Applications built on FrogNet don't handle disconnection — they never assumed connection in the first place. The architecture matches the physical reality of the environments FrogNet operates in, where connectivity is intermittent by nature.
DNS was designed for a world where networks are large, stable, and administered by professionals. You configure a nameserver, you delegate zones, you manage TTLs, you wait for propagation. The assumption underneath all of it is that the network topology is known, relatively static, and has a central authority responsible for keeping the namespace consistent.
FrogNet operates in the opposite environment. Nodes appear and disappear. Topology changes without warning. There is no central authority. There is no administrator. The network manages itself or it doesn't work.
DNS fails in this environment — not because it's poorly implemented, but because it was designed for a different problem. A nameserver that goes offline takes its zone with it. A TTL that hasn't expired serves stale data. Split-brain scenarios during network partitions produce inconsistent resolution across the mesh.
FrogNet resolves mesh names through /etc/hosts — the oldest, simplest, most reliable name resolution mechanism in existence. Every node maintains its own hosts file, and the merge rewrites it every time the topology changes. There is no TTL to expire, no zone to delegate, no nameserver to go offline. Name resolution order is files first, then DNS: mesh names are answered locally and instantly, and anything not on the mesh goes upstream over the untouched default route. Each node also runs dnsmasq so the phones and laptops on its own segment get the same names by DHCP without any client configuration.
The service names — databasehost.frognet and mediahost.frognet among them — are rewritten into every hosts file on every merge. No node ever holds a stale address for a service. The moment the topology changes, the hosts file changes with it, and a program that asked for the name gets wherever the role is running now.
DNS is the right answer for a stable, administered network. Local ground truth is the right answer for a self-forming mesh where the only thing you can rely on is what the node can directly observe.
CROAKUS Part V, Discovery — the walk, and why .2 proves while .1 carries.
WATCH Discovery — the host table deleted on a live node, and rebuilt by the merge
WATCH Discovery, Deeper — echo, getHosts, and the resolver chain in detail
Every network you use today depends on someone else's infrastructure. Your WiFi depends on your ISP. Your ISP depends on backbone providers. Your applications depend on cloud providers. Your DNS depends on root servers. At every layer, someone else is in the chain — someone who can fail, someone who can be compromised, someone who can cut you off, someone who can surveil you, someone who can monetize your traffic.
FrogNet has no such dependencies. The network is yours. The data is yours. The infrastructure is yours. No ISP, no cloud provider, no DNS authority, no certificate authority, no backbone provider is in the chain. You are not a tenant in someone else's infrastructure — you are the infrastructure.
This matters differently in different contexts. For a family it means privacy. For a business it means control. For a military unit it means survivability. For a community it means resilience. But the underlying shift is the same: from dependent networking, where you operate at the sufferance of others, to sovereign networking, where you operate on your own terms.
The internet was designed. IANA allocates address space. ICANN manages domains. ISPs negotiate peering agreements. BGP routes are configured by human administrators. The entire global routing infrastructure is the product of deliberate human decisions made by known authorities.
FrogNet's internet emerges. No allocation authority. No routing administrator. No peering negotiation. Nodes discover each other, calculate topology, write routes, and form a coherent network — automatically, repeatedly, every time the topology changes. The internet that results wasn't designed by anyone. It assembled itself from the nodes that happened to be reachable at that moment.
This is a fundamentally different model of what a network is. The traditional internet is a constructed artifact. A FrogNet is a living system.
Every network built since the early days of the internet is stateless by design. Each request arrives with no memory of what came before. The server reconstructs context from scratch — parsing headers, re-establishing session state, re-transmitting data the other end almost certainly already has. This was a reasonable choice in 1969 when memory was scarce and connections were unreliable. It has been the default assumption ever since, and nobody questioned it.
FrogNet questions it.
The semantic compression engine introduces state at the network level. The fabric remembers what it has already seen. Templates are learned from the structure of real traffic and cached on both ends. When an exchange matches a known template, only the values that changed cross the wire — not the structure, not the unchanged fields, not the overhead. The network itself carries the context so the application doesn't have to re-transmit it.
This is not delta encoding. Delta encoding sends the difference between two versions of a document. BLDC-1 — the Bullfrog Long Distance Communications Protocol — goes further: it separates structure from value, learns the structure once, and then transmits only values. An exchange whose content has not changed collapses to a twenty-one-byte frame. A large structured payload with a handful of moving fields collapses to those fields and a map saying where they go. The application never changes. The protocol never changes. The wire changes completely.
The stateless model was a constraint imposed by 1960s hardware. FrogNet removes the constraint.
CROAKUS Chapter 26, The Accelerant — Semantic Compression, and the appendix Inside the Compression Engine — including the section called Twenty-one bytes, which prints every one of them.
WATCH Semantic Compression — SAME, DIFF and FULL explained, with the wire watched live
Every compression system ever built is an application-level decision. You choose to compress a file. You choose to gzip an HTTP response. You configure your CDN to minify assets. Compression is something developers do deliberately to specific data when they decide it's worth the effort.
FrogNet makes compression an infrastructure property. The developer writes REST. The network compresses everything, automatically, transparently, using a codec that learns the structure of the actual traffic flowing through it. There is no configuration, no decision, no per-endpoint optimization. Every HTTP exchange between nodes is compressed. The developer never thinks about it.
This is the same paradigm shift that happened when hardware TCP offloading moved network stack processing from software to silicon — except FrogNet does it for semantic content, not just packets. All system-level coordination within FrogNet uses REST, which means the coordination overhead itself is compressed. On a steady-state network, management traffic approaches zero wire cost.
The mechanism has two halves and they are worth separating, because they are separate technologies that happen to run together. BLDC-1 decides what the smallest honest representation of an exchange is — SAME when nothing moved, DIFF plus a map when a few fields did, FULL when the template has not been learned yet. FNWP-1, the FrogNet Wire Protocol, is what carries those frames over a socket the proxy and daemon hold open permanently, so there is no connection setup or teardown to pay for. Neither one is the other, and the deep-dive recording separates them explicitly.
WATCH The Proxy and the Daemon — the proxy, the daemon, the permanent socket, and byte accounting on a live run
WATCH Semantic Message Handlers — adding a format the codec does not speak yet — two functions, no schema
Traditional request/response networking is serial at its core. A request goes out. The sender waits. The response comes back. The next request goes out. Even with pipelining — which overlaps the sending of requests — processing remains sequential and the wire sits idle between transactions.
On a constrained link, idle time is catastrophic. Every microsecond of dead air is bandwidth you cannot recover. A 4800-baud link is already at the edge of what's usable. Wasting half of it on dead air between serial transactions makes it unusable.
FrogNet eliminates the dead air entirely.
A pool of worker threads means many requests are in flight simultaneously — not sequentially overlapped, but genuinely parallel, each on its own thread, each with its own database connection, all interleaved onto the one standing socket. By the time the wire finishes transmitting one frame, the next is already queued and waiting. The transmitter never starves. The link runs at or near 100% duty cycle continuously.
There is a second effect that matters as much as the first, and it only becomes visible under load. When many callers ask for the same thing at once, the proxy notices that an identical request is already in flight and makes the later callers wait for the answer the first one is going to get. The daemon does the same on its side: one execution against the local web server, one answer, distributed to everyone waiting. Three hundred simultaneous requests become one round trip and one execution. That is why the burst figures in the measurements below are not simply the serial figures multiplied.
The result is that effective throughput is not limited by processing speed — it is limited only by physics. You cannot move bits faster than the channel allows. FrogNet makes sure every bit the channel allows is carrying useful payload.
CROAKUS Chapter 41, Measuring It on Your Own Box — the pipe_workload tool, its four phases, and why the echo workload is the ceiling rather than the typical case.
Every AI deployment ever built follows the same model. Data is collected, sent to a central location, processed by a model, and results are returned. The AI lives in the cloud. The sensors live at the edge. The network is the pipe between them. The AI is smart but blind — it can only see what gets sent to it, with whatever latency the pipeline introduces.
This model has three fundamental problems. It requires connectivity. It introduces latency between observation and action. And it concentrates intelligence in one place, which means a single point of failure, a single point of compromise, and a single point of control.
FrogNet dissolves all three.
Every node can run its own AI. Every AI has direct, real-time, read-write access to FrogNet Memory — which means every AI can see every sensor on the entire mesh, not just the sensors on its own node. Multiple AIs can run simultaneously on different nodes, observing the same data, writing to the same scratchpad, coordinating through shared memory without any message-passing infrastructure, without any API contracts between them, without any orchestration layer. They share a world. They act in it.
Multiple dashboards can do the same thing — any node, any browser, any connected device sees the same real-time network state simultaneously. There is no master dashboard and no replica. There is one shared memory and every observer reads it directly.
The sensor-to-actuator loop — sensor writes a value, AI reads it, AI writes a control value, actuator reads it — runs entirely within the mesh. It survives complete internet loss. It survives the loss of any individual node. It survives network partitions, because each fragment continues operating on the sensors it can reach. The first independent end-to-end demonstration of that loop was completed on April 17, 2026 — a button press in a web UI on a WiFi network in New York, routing through shared memory in Seattle, activating a physical actuator back in New York.
The traditional model puts intelligence in the cloud and data at the edge, connected by a fragile pipe. FrogNet puts intelligence at the edge with the data, connected by a mesh that heals itself. That is not an improvement on centralized AI. It is a different theory of where intelligence lives in a network.
Every distributed system ever built treats the network as a pipe — data lives in databases, the network moves it between them. You have servers with databases, clients that query them, and a network that connects them. The database and the network are separate concerns.
FrogNet collapses that distinction. FrogNet Memory isn't behind the network — it is the network. Every node reads and writes it. Every sensor writes to it. Every dashboard reads from it. Every AI queries it and writes back. There is no client-server distinction because there is no separate tier for data storage — the data is in the network itself, always available, always current, always at the same name regardless of which physical node is holding it at any given moment.
The addressing model is Linda's tuple space, developed by David Gelernter and Nicholas Carriero at Yale in 1985: a value is located by a small number of coordinates, and any program that can name those coordinates can read or write it without knowing who else is doing the same. FrogNet uses three coordinates. That is FrogNet's convention rather than a requirement of Linda, and it is the right size for the job: a sensor name, a sensor type, and a location will identify a reading; a program name, a variable, and a user identifier will identify a shared variable between two copies of a program on opposite sides of a continent.
Underneath, the store is an ordinary relational database on the node currently holding the role, and the tables are visible to anyone who wants to open them and look. That is deliberate. Shared memory that cannot be inspected acquires magical properties in the reader's imagination, and there is nothing magical here — there is a table, there are rows, and the reason so little crosses the wire is that almost nothing in a row changes between one write and the next.
CROAKUS Part VI, The DatabaseHost, and the appendix REST, the Drop-In, and UnREST. A note on names: what earlier drafts called the transient database is called FrogNet Memory throughout the current material. The mechanism did not change; the name stopped describing it as a database, because programs use it as memory.
WATCH Intro to Tuples — three coordinates, and a two-player game lobby with no messages in it
WATCH The FrogNet Monitor — the same record read from two nodes on opposite sides of the continent
Every network you administer has a topology you designed, documented, and maintain. Subnets are planned. Routes are configured. VLANs are assigned. When something changes you update the documentation, push new configs, and hope nothing breaks. The network is a designed artifact that requires human maintenance to stay consistent with reality.
FrogNet's topology is never designed and never documented because it doesn't need to be. It is calculated fresh from observed reality every time anything changes. Routes are written to match whatever interfaces are actually up. Hosts files reflect what the node can actually reach. The network's representation of itself is always derived from ground truth, never from a plan that may have drifted from reality.
Two details keep that from being romantic. First, the service roles are not assigned by address. Every node writes its own capability — cores, memory, storage, whether it is running the database, what encoders it has — as a tuple into a control plane that sits at a deterministic, arithmetic address, so that every node reads the same inputs from the same place without having to know the answer first. Then every node runs the same scoring against those same inputs and arrives at the same winner independently. Nobody is told. Nobody votes. The election is a pure function of facts everyone can already see, which is why it produces the same answer on every node and why it is safe to run it again the moment anything changes.
Second, recalculating is not the same as churning. A route that is already installed and whose destination is alive and healthy over its own path is left alone, even when a challenger measures faster. Re-ranking on every walk would move routes whenever two paths measured close together, and every move tears down live traffic — an open database connection, a call in progress, a transfer halfway done. Discovery state starts clean on every merge; installed routes do not.
Network engineers spend enormous effort keeping designed topology consistent with actual topology. FrogNet eliminates that gap by never having a designed topology in the first place.
The clearest day-to-day consequence is something administrators of conventional networks would call impossible: moving a node from one network to another without touching the node. A node's pond — the network it belongs to — is recorded in the broker, not in the node's own configuration. When the pond assignment changes server-side, the node's next poll returns a different set of peers, a different chorus membership, and a different set of tunnels to maintain. The node's daemon diffs the new state against the old, tears down what's gone, brings up what's new, and the node is now on the new network. No script ran on the node. Nobody logged in. No configuration file was edited. The truth changed in the broker; the node's view of itself was rebuilt from that truth automatically on the next poll.
CROAKUS Chapter 15, Selecting the Service Hosts; chapter 17, Two Names, Two Planes — Why one is elected and the other is not; and chapter 14 for the route-incumbency rule and the worked example behind it.
WATCH Installation, Part 2 — First Boot — a node booting knowing nothing, and finding the network
Every traditional security model assumes a hostile perimeter. The internet is outside, attackers are out there, and you build walls to keep them away from your services. Every service behind those walls still needs its own authentication layer because the perimeter is assumed to be already breached.
FrogNet's position is different, and it is worth stating precisely rather than dramatically, because the precise version is the one that survives a scan.
There are no discoverable application endpoints. The applications on a FrogNet are not published to the internet, do not advertise themselves, and are not reachable from it. To reach them you have to be on the mesh, and to get on the mesh you have to be physically near it — breaking the WiFi, taking the hardware, being in the room. That is not a firewall rule. It is a property of where the services live.
There is one thing on the internet that answers, and pretending otherwise would be dishonest. A node getting its first tunnel cannot ride a tunnel that does not yet exist, so the broker has an address and a port that accept a connection. Both are chosen by the operator — not a well-known service, not a registered name, not a standard port — so there is nothing to enumerate toward. Scan it and you learn that something is listening; probe it and service detection fails on bytes it cannot classify. What crosses that connection is FNWP-1 carrying an HTTP conversation, not stateless HTTP itself, so a capture yields length-prefixed codec frames that require a FrogNet endpoint rather than a protocol analyser to interpret. That is a statement about what the wire carries. It is not encryption and it is not a substitute for authentication: an attacker who compromises an endpoint or obtains the templates can reconstruct what was represented. Confidentiality across the internet comes from WireGuard, whose endpoint does not answer unauthenticated probes at all.
Network membership is the trust boundary, and membership is not address space. Being a 10-network machine is not enough — a candidate has to answer the liveness gate when discovery calls, and one that does not never becomes a neighbour and never gets a route. This is why FrogNet can be inserted into a corporation that already lives in 10-space without anyone renumbering anything.
The practical consequence is that the complexity, latency, and overhead of PKI, TLS handshakes, session tokens, and credential stores are not required at the application layer — overhead that can consume twenty-five seconds of a 4800-baud link just for a certificate chain. A node is also an ordinary Linux machine, so every conventional tool you want on top of that is available: firewalls, certificates, key rotation, whatever your policy requires.
The honest summary is that the vulnerabilities of a FrogNet are largely human. Social engineering, a shared WiFi password that never gets rotated, a machine left logged in. Those are the attacks worth defending against, because the architecture has already taken the remote ones off the table.
CROAKUS The Security part — chapters 35 through 38, beginning with Nothing on the Internet Answers, which prints an actual scan of the live broker rather than describing one.
This is the shift that underlies the other twelve, and the one that took the longest to see — because it is the hardest to unlearn. Every networked system in common use is built on messages: one party sends, another receives, and the entire discipline of networking is the management of that exchange — requests, replies, acknowledgments, retries, sessions, subscriptions, ordering, delivery guarantees. FrogNet does not send messages between applications. It exposes a shared memory, and the only two things a program does are write a value where it computes one and read a value where it needs one. There is no sender and no receiver, because there is nothing in flight — there is only memory that several machines can see, and which converges to its current value beneath the application without the application orchestrating the exchange.
Be precise about the scope of that claim, because the precise version is stronger. REST does not disappear. The call a program makes to read or write shared memory is an ordinary HTTP call to an ordinary endpoint, and underneath it the proxy, the daemon, and FNWP-1 are moving bytes. What disappears is the part programmers actually spend their lives on: designing a message format, writing a handler on each side, sequencing the exchange, handling the retry, versioning the protocol when the fields change. A C compiler did not abolish assembly language; it wrote the assembly for you and moved the surface you think at. This is the same move, applied to the network.
The distinction is not cosmetic. Most systems that claim to simplify networking only hide the message behind a nicer surface — remote procedure calls, message queues, web APIs all still have a send and a receive in the programmer's model, and that model reasserts itself the moment something fails. FrogNet removes the category from the programmer's model entirely. There is no degraded message path waiting to leak through, because at the level where you are working there is no message.
The elegance is in what the shift lets you stop writing. A programmer describes a piece of shared data with a few declarations: what its fields are, how fresh each field must be, where authority over it lives if anywhere, and what a received value means. From those declarations, an entire category of hand-written code simply ceases to exist — the retry loops, the version counters, the acknowledgment handling, the deduplication, the jitter buffers, the backpressure protocols. In the adaptive media system, "video gives way before audio on a failing link" is not an algorithm anyone wrote; it is two freshness declarations, one marking audio as the protected stream and one marking video as droppable. The hard behavior became a property you declare once rather than logic you build and debug.
And because it is one mechanism, it spans the entire system with no seams. Presence, a multiplayer game, a sensor-fusion loop, a live video call, a control setpoint driving hardware — all of them are the same handful of declarations over the same shared memory. In a conventional stack each of those is a different subsystem with its own protocol: a publish-subscribe bus, game netcode, an industrial control bus, a media stack, a messaging layer, each with its own failure modes and its own glue. Collapsing them onto a single coordination model is what makes possible the programming that was previously out of reach for a small team — not because any one of those capabilities was impossible elsewhere, but because composing all of them on one substrate, without an army of integration code, was.
There is an honest boundary that is itself part of the design, and naming it is what keeps the claim credible. A shared memory of this kind gives you bounded-stale current state — the best available answer right now — but it does not give consensus, a total ordering of all writes, or atomic changes across many values at once. FrogNet does not pretend otherwise. For the few things that genuinely require an order — whose turn it is, who holds a lease, which of two commands won — it elects a single authority and routes those decisions through it. The discipline is simple to state: design for merge, elect for order, and never let the shared picture pretend to be the order. The reason the model is so light is precisely that it refuses to impose the heavy distributed-systems guarantees on the overwhelming majority of coordination that never needed them. Treating all coordination as if it required consensus is the original mistake that made conventional networked software so heavy; declining to make that mistake is as much a part of this shift as the shared memory itself.
CROAKUS Part The Programming Surface — chapters 40a through 40f, which take this shift apart properly: fifty years of moving the line, what distributed systems missed, and the test that settles it.
The following is a description of FrogNet's architecture, capabilities, and measured performance as of August 2026.
These are figures read off narrated runs on the live network, not a tuned rig. Where a measurement is a best case, it is labelled as one.
| Measurement | Result | Conditions |
|---|---|---|
| Live HD call over radio | 1280×720 at 22 fps, bidirectional, no drops, 89% of bytes never sent | 900 MHz HaLow link with a 1 Mbit ceiling, Seattle to New York |
| Call held under starvation | audio unbroken at 450 kbps; picture thins, conversation continues | bandwidth driven down by hand from 987 to 637 to 450 kbps |
| Repeated identical exchange | 1.0 KB sent where 39 KB would have been | echo workload — the best case, and named as one |
| Mixed exchange, ~20% new content | 6.4 KB sent where 414 KB would have been | chat workload, 25 requests, serial |
| Large structured payload | 38 KB sent where 347 MB would have been | megabyte workload, 300 concurrent, six dynamic fields |
| Throughput on a constrained link | 44× improvement | Ethernet shaped to 4800 baud with added jitter and 20% loss |
The two figures worth understanding together are the last two. The wire saving comes from BLDC-1, and it is enormous on structured data because structured data is mostly structure. The throughput improvement comes from never letting the link go idle, and from answering a repeated question once instead of three hundred times. They are different mechanisms and they compound.
WATCH Proof It Works — the 900 MHz call, with the bytes-saved counter on screen
WATCH Bandwidth Experiments — the link starved by hand while the call stays up
WATCH Installation, Part 1 — the installer run end to end, prompts and all
FrogNet's scope hierarchy answers a problem that conventional networking solves with much heavier machinery: how do you segment a network without designing the segmentation in advance, and how do you change membership without reconfiguring the members?
Four scopes, nested:
The broker keeps pond and chorus membership, and it carries the inter-site data path: every cross-site packet transits the tunnels it terminates. That is a stronger claim than “the broker is hard to attack,” so assume it is owned. Three things still hold. It holds no endpoint keys, so what transits it is not addressed to it and not openable by it. It runs none of the semantic stack, and forwards in the kernel, so nothing at the application layer parses or stores the payload. And it is not itself a member of any FrogNet. Its own picture is a cache rebuilt from node polls — wipe it clean and the next round of polls rebuilds the whole thing — so a pond whose broker goes dark loses only the ability to onboard a stranger or open a new cross-internet tunnel, while everything already formed keeps running. Owning the transit point gives you the transit point and nothing else.
Two consequences fall out. Membership is data, not configuration — moving a node between ponds is a single broker record change, because there is no config to push and the node will read the new truth on its next poll. And sensors and actuators live in lillypads while their data lives in the pond: a board reading a light level writes into shared memory through its host node and becomes visible across the entire pond immediately.
WATCH Standing Up a Broker — a broker stood up from nothing, and a pond created
The design lineage traces to the real-time data buses used in commercial aviation, specifically ARINC 429 — the broadcast bus that has carried flight-control, navigation, and instrumentation data on commercial aircraft for nearly five decades. ARINC 429 is simple: no store-and-forward, no reconciliation, no message addressing. A transmitter broadcasts current state, and any subscriber that needs a given parameter reads it. There is no notion of delivery, because the bus is always carrying the current truth — if you missed it, the next sample is on its way.
FrogNet Memory is that idea projected onto a network. Any node writes its current state. Any reader sees it. No history, no reconciliation on rejoin after a split, no delivery semantics to negotiate. Whether a value is too old to use is the reading application's decision and not the fabric's — the fabric's job is to make the current value available and to say when it was written.
A NOTE ON NAMES The tables underneath are called sensors and sensor_data because FrogNet Memory began as a place to put sensor readings. They are the tuple tables for everything — a game lobby, a call roster, a program's shared variables. The name is legacy; the mechanism is general. Anyone reading the API will meet that within a minute, so it is said here rather than left as a surprise.
These scenarios were referenced in the opening section and are reproduced here for readers who want concrete examples of how FrogNet performs when conventional infrastructure fails. Each one is a deployment pattern the current system supports today, not a future roadmap.
Your twelve-year-old is at a camp in the mountains. There is no cell service and barely any electricity. The camp does not have commercial internet, but the ranger's station has a long-range RF link to a gateway at the trailhead, and the trailhead has a satellite uplink that comes up for a few hours each evening.
The camp has a FrogNet box. So does your house. For most of the day, the camp's box operates on its own — a local network inside the camp for the staff and kids. When the evening uplink comes up, the camp's box and yours find each other and synchronize everything that happened during the day. Your kid's check-ins, their photos, their GPS dots on the family map — all of it arrives in a single batch that the semantic compression engine sends over the narrow link in a fraction of the bandwidth it would normally take.
You leave a sticky note that says "Grandma says hi." The camp's box picks it up the next evening. Your kid sees it when they wake up.
Nothing goes through any company's servers. No cell service is required at the camp. The link between camp and home is a few hours of narrowband a day, and FrogNet treats that as perfectly sufficient — because for this kind of family communication, it is.
A paramedic crew responds to an emergency. They load the patient and begin treatment. Between the scene and the hospital, they pass through areas with no cell coverage. In a conventional system, the data they are collecting — vitals, treatment notes, patient status — cannot reach the hospital until they drive back into cell range. The emergency room gets no warning, no preparation time, no head start on the case.
With FrogNet, the ambulance has a box. The hospital has a box. The boxes connect through whatever path is available — cellular, WiFi along the route, a commercial narrowband data radio, or a relay. Patient data flows to the hospital in real time when connectivity exists. When it does not, the ambulance's box holds everything locally and transmits the moment a link reappears. The ER sees vitals updating as the ambulance approaches. They are ready before the doors open.
This is not hypothetical architecture. The semantic compression engine was designed to deliver full web applications over links as narrow as 4800 baud — slower than a 1990s dialup modem — and has been validated at that rate. On a steady-state feed like patient vitals, most of each update is structure that has not changed, so almost nothing crosses the wire. That is small enough to send over almost anything that carries IP.
A hurricane hits the Gulf Coast. Cell towers are down. Power is out. The internet does not exist. First responders from six agencies converge on the area with no way to coordinate because every system they use depends on infrastructure that is no longer there.
Each FrogNet box is a sovereign network. Drop one at the command post, one at the field hospital, one at the staging area, one in each search-and-rescue vehicle. They mesh automatically over WiFi when they are near each other. When they are out of WiFi range, they connect by whatever IP-capable radio is in the truck. Sensor data from the field flows into a shared memory every node can see. An AI running on one of the boxes watches the feeds and flags anomalies. Dashboards at the command post show real-time positions of every unit.
None of this requires the internet. None of it requires a cell tower. None of it requires any infrastructure the hurricane could take out. The FrogNet is the infrastructure, and it came in the back of a truck.
The network grows. When two independent FrogNets come within range of each other, they discover each other and merge into a single, larger network — automatically, with no human intervention. A rescue team from Texas arrives with their own FrogNet, drives within WiFi range of the command post, and the two networks see each other, exchange what they know, and become one. Every node on both sides can now reach every other node.
The same merging works across different transport types simultaneously. The command post connects to the field hospital by Ethernet. The field hospital connects to a remote unit by narrowband radio. A supply convoy connects through a satellite uplink. From the application's perspective it is all one network. The applications do not know and do not care whether the bytes travel by wire, WiFi, radio, or satellite.
A small business with three locations and ten remote employees replaces its cloud suite with FrogNet boxes at each office and each home. Internal files, messaging, a company wiki, and sensor monitoring at the warehouse — all running on their own hardware, all private, no monthly per-seat fees, no corporate data passing through anyone else's servers.
A family farm deploys sensor nodes in the fields and a FrogNet box at the farmhouse. Soil moisture, temperature, humidity — all flowing into a local dashboard through an RF bridge. A local AI makes irrigation recommendations. None of this requires cell coverage in the field. None of it requires a cloud subscription to view your own sensor data.
And a network that already exists does not have to be replaced to get any of this. A FrogNet node inserted just below the point where a site reaches the internet puts the existing machines on the mesh without an agent on any of them — the printer, the badge reader, the controller nobody will touch. They keep their addresses, their gateway, their firmware. What changed is the box their traffic already passed through. It is not a migration. It is an insertion.
SotF-ACP — the Song of the Frogs Adaptive Communications Protocol — is the media plane of the Communicator, and it is described separately for two reasons.
The first is the protocol itself: a communications protocol that does not stop, built for the case that matters most when everything else fails — two people trying to talk across a link that is degrading toward zero.
The second is broader. SotF-ACP rides an extension point in the semantic compression engine that allows entirely new wire protocols to be plugged in as infrastructure, with no application changes, no schema declarations, and no per-endpoint configuration. SotF-ACP is the first non-trivial use of that extension point. Its story is therefore also the story of a generic capability with implications well beyond adaptive media.
Conventional communication has two states: working, or dropped. A video call is up, or it ends. A voice call is up, or it ends. A text message goes through, or it queues forever waiting for connectivity that may never come. The user experiences a binary outcome.
SotF-ACP has eight.
If you have ever stood by a frog pond at dusk, you have heard it. One frog calls. Another answers. A third joins. Within seconds the pond is a chorus of dozens of voices, overlapping, layered, continuous. The song is the multitude.
Take any one frog out. The song continues. Take most of them out, and the song continues quieter. Take all but one, and that one still sings — and if anyone is listening, the song is still there. The medium changes. The meaning does not.
That is the shape SotF-ACP is built around. Two users have a conversation. The protocol underneath decides, in real time, what shape of message the current link can carry — full bidirectional video at one end of the spectrum, a single byte-scale heartbeat at the other — and renders it appropriately on the other end. The users experience one continuous conversation. The wire carries whatever it can. When the link improves, the protocol climbs back up. When it gets worse, it slides down. Neither end has to know what level the other is at.
The ladder spans roughly six orders of magnitude of bandwidth. Every rung has a name, because on a live network you end up saying them out loud. The four video rungs need a camera and nothing else — a webcam with no microphone is a perfectly reasonable thing to be. The two audio rungs need a microphone. The bottom three need no hardware at all, which is why the floor of a call is never the floor of the network. The rungs, from richest to leanest:
Even at L0 the connection is not dropped. It is the smallest possible song. If anything more is possible, the protocol climbs back. If even L0 fails — total link loss, full jamming, the radio physically destroyed — that is the only condition under which the conversation actually ends.
One detail of the ladder is worth stating because it is counter-intuitive and it is deliberate: frame rate steps before geometry. A picture that updates less often is easier to watch than a picture that has gone small, so the rate comes down first and the resolution only follows when the rate has run out of room.
Every real-time media protocol in widespread use — RTP, WebRTC, SIP, the voice and video stacks that ship in every consumer app — handles a degrading link the same way: fire packets into the network as fast as you can, hope most of them arrive, and patch up the wreckage on the receiving end. UDP is the substrate. Packets are independent. The sender does not know which ones got through. The receiver assembles whatever shows up, runs jitter buffers and packet-loss concealment over the gaps, and renders the result. When the link is good this works well. When it degrades, the receiver renders the corruption: blocky video, audio that warbles and drops out, partial frames sewn together from packets that arrived and packets that did not.
Call it the shotgun approach. The sender sprays. The receiver salvages.
SotF-ACP inverts every part of this.
The substrate underneath is TCP — reliable, in-order delivery. Frames arrive complete or they do not arrive at all. There is no such thing as half of a frame reaching the receiver. There is no packet-loss concealment, because there is no packet loss; there is only frame delivery or frame omission, and both are clean.
This is the part that sounds wrong to anyone who has built a media stack, and the objection is a good one: a large keyframe on a slow link will block the socket, and while it blocks, the audio stops. That is exactly what happens if you hand a whole keyframe to the socket. So the Communicator does not. It owns the wire, so it breaks a keyframe into segments, sends them one at a time, and interleaves audio between them. The receiver reassembles the keyframe and paints it when it is whole. That is why audio survives at bandwidths where the picture has nearly stopped — the frame that would have starved it is no longer a single indivisible write.
The decision about what to drop is made at the sender, on evidence it already has: the operating system telling it the outbound buffer is filling, the frame rate it is actually achieving, the drops it is seeing in a one-second window. Whole frames are dropped before they cross the wire — not pieces of frames. The receiver never has to know.
The user-visible effect on a degrading call is therefore not corruption. It is a lower frame rate, then a smaller picture, then audio alone — each a clean rendering of the same conversation at a level the link can carry. A brain can fill in a missing frame but cannot unscramble a half-pixelated one. It tolerates audio that pauses and resumes; it fights audio that warbles and clicks. Conventional protocols deliver exactly the degradation human perception handles worst. SotF-ACP delivers the kind it handles best.
Coming back up is deliberately slower than going down. A step down is taken on the first good evidence, because the cost of staying too high is a call that breaks. A step up requires several consecutive clean seconds, because grabbing the bandwidth back all at once is how you lose it again. Roughly seconds to fall, roughly fifteen to climb a rung. That asymmetry is the design, not a limitation of it.
SotF-ACP is not a clever protocol bolted onto a fragile stack. It is the direct beneficiary of everything in the main body of this document.
That last point deserves precision, because it is the one people assume must be wrong. There is no negotiation between the endpoints about what rate to run. Each participant publishes what only it knows — a sender what it is sending, a receiver what it is getting and whether it is keeping up — and each participant independently derives the same rate from those published values. No request, no reply, no acknowledgment, no round trip anyone waits on. The rate is not agreed; it is derived, in the same way and from the same shared memory as everything else in FrogNet. This is the hardest real-time problem in the system, solved with the same mechanism as a chat message.
SotF-ACP was possible to build because the semantic compression engine is not a single fixed codec. It is a host for wire protocols, and BLDC-1 is the default one that rides it. The extension point BLDC-1 uses is the one SotF-ACP uses. Anything else that wants to define its own wire shape can use it too.
The interface is two functions. That is the entire contract:
No schema to declare. No callback to register beyond those two. No protocol-aware framing the proxy needs to know about. No negotiation handshake the proxy mediates. The custom protocol sees bytes in and produces bytes out. The application never knows it exists.
What can ride that interface is limited only by what someone wants to build. Domain-specific compression for medical imaging or instrument telemetry, where a tuned codec beats a general one. Application-layer encryption on top of the tunnel, so payloads are opaque even to other endpoints in the mesh. Protocol mimicry, shaping wire bytes to resemble something else entirely. Format translation, so the application keeps speaking whatever is convenient while the wire sees whatever is efficient. Carrying a foreign protocol — an industrial control bus, a messaging protocol — through FrogNet as a generic data link. Or something that does not have a name yet.
The comparable extension architectures are all positioned somewhere this one is not. Application-layer interceptors require the application to opt in and impose a schema. Custom transport options require kernel support and collide with middleboxes the moment they leave a controlled environment. Service meshes offer per-service shaping but require sidecars, configuration, and a control plane that is itself a protocol. This one is application-transparent, schema-free, and runs as infrastructure rather than middleware.
For a family network, this is a feature people will use rarely and value when they do — the call from the cabin that degrades to text instead of dying, the message from the ambulance that gets through as a token when video cannot.
For a business or institutional deployment, it is the difference between "the link went down" and "the link is degraded but the conversation continues." Operational coordination does not stop when bandwidth drops.
For deployments where lives depend on the link — first responders, field medics, disaster zones, units operating in contested environments — it is an architectural answer to a problem the industry has not solved. Every other system in this space treats degradation as a sequence of failure modes to be handled. SotF-ACP treats degradation as a continuum along which communication never stops.
There is one condition under which SotF-ACP cannot help: no path of any kind between the two endpoints. No protocol delivers a byte across a link carrying zero bytes. But the door at which conventional systems give up is several orders of magnitude above the floor SotF-ACP operates at, and the space between those two points is enormous.
The protocol runs a full adaptive loop with recovery, end to end, on real hardware over real links. Degradation is bidirectional and self-healing: each side steps its own quality down when its link congests and back up after the link has been clean for long enough, with deliberate hysteresis so it settles rather than oscillates.
Two things are now field measurements rather than models. A bidirectional 1280×720 call at 22 frames per second held over a 900 MHz radio with a one-megabit ceiling, coast to coast, with 89% of the bytes never sent. And a call driven down by hand — 987 kbps, then 637, then 450 — with the picture thinning at each step and the audio never breaking, then climbing back to full quality when the bandwidth was returned.
What remains is specific and worth naming. The relay forwards one stream, so the whole call runs at one rate and the slowest participant sets it. That is honest and defensible — nobody sends faster than the slowest end can take — but it means a fast viewer cannot be served a better picture than a struggling one, and fixing it requires transcoding at the relay rather than forwarding: decode once, encode per client at that client's budget. That is a real capability and a real cost, and it is the difference between a relay that forwards and a relay that serves. It is named here, and named in the Croakus, rather than left for someone to discover.
CROAKUS Chapters 45 through 51 for the Communicator and the wire under the call; chapter 50, How the Ladder Actually Decides, for the rules; and chapters 52 through 54, What Is Not Built Yet, for the rest of the honest list.
Fawcett Innovations LLC · john@fawcettinnovations.com · (206) 335-9639 · CAGE 1A5Y5