FrogNet is a self-forming mesh infrastructure that allows full web applications to operate across any available transport, including environments where the Internet is unavailable.
It is built as a three-layer system.
This isn't an abstraction for a whitepaper. It's how the software is actually organized, and the separation between the layers is the reason the whole thing works.
Layer 1: Applications
This is the top of the stack. It's what users and operators actually touch — dashboards, sensor monitors, alerts, AI agents, control panels, ordinary web applications. Whatever the deployment needs.
These applications are written the normal way. Standard web development. PHP, HTML, JavaScript, REST APIs, the usual tools.
They don't need to understand radio. They don't need to know about tunnels. They don't need to care whether the link between two nodes is gigabit Ethernet or a 4800-baud radio channel.
From the application's perspective, it's talking to a networked service. That's all it knows, and that's all it needs to know.
This matters because it means the entire existing ecosystem of web development applies to FrogNet. Any developer who can build a web application can build a FrogNet application.
No special SDK. No custom protocol library.
Just HTTP.
Layer 2: The Semantic Layer
This is the core innovation. It's what makes everything else possible.
The semantic layer sits between the applications and the transport. It watches the structured traffic flowing through the system — JSON, XML, HTML, CSV, whatever the applications produce — and learns the shape of it.
Automatically.
No schema files. No configuration. It simply observes real traffic and builds templates.
Once it understands the structure, it stops transmitting entire messages and sends only what actually changed.
A bitmap identifies which fields differ, followed by the new values.
If nothing changed, the system sends a single token — about twenty bytes — that says "same as last time."
A 10KB sensor response collapses to about 50 bytes when a few fields change.
In steady state, repeated exchanges shrink to micro-tokens as small as 16 bytes.
That's not theoretical. That's what the production testbed measures.
The applications don't know this layer exists.
They simply behave as if the network were normal.
But without it, nothing above would function over constrained links, and nothing below would carry enough useful data to matter.
The Internet routes packets.
FrogNet routes meaning.
Layer 3: Transport
This is the bottom of the stack. Whatever communications path actually exists.
WiFi. Ethernet. Encrypted Internet tunnels. LoRa. Packet radio. HF, VHF, UHF. Satellite.
FrogNet doesn't require a specific transport. It uses whatever path is available and adapts to whatever bandwidth and reliability that path provides.
If a node has multiple interfaces — WiFi to the local network, an Ethernet backhaul, and a radio link to a remote site — traffic routes across all of them simultaneously.
Something arriving on WiFi can exit over radio.
The routing layer doesn't care which interface a packet arrived on. It finds the best path.
If a link fails, the mesh routes around it.
If a link appears, the mesh starts using it.
No manual configuration.
Why the Separation Matters
Traditional systems bind these layers together.
The application knows what transport it's running on. The transport makes assumptions about what the application needs. Change one, and you have to rewrite the other.
FrogNet separates them cleanly.
Applications don't care how data moves.
Transport can change without rewriting software.
The same system works on a local LAN, across Internet tunnels, or over a radio link that most engineers would dismiss as unusable.
If the Internet disappears entirely, the system keeps working locally and across whatever links remain.
That's not a feature.
It's the architecture.
And it's the reason a web dashboard can update in real time over a 4800-baud radio channel with 20% packet loss — because the application thinks it's on a normal network, the semantic layer reduced the traffic to a few dozen bytes, and the transport layer delivered those bytes across whatever link was actually available.
Three layers.
Each doing its job.
None of them aware of the others' constraints.
That's FrogNet.