Distributed programming has spent fifty years moving messages. FrogNet moves state.
FrogNet is a working network and programming environment built around addressable shared state. The claim is large, so the measurements and running systems come first.
You can use Network Shared RAM directly today, or build the complete Living Network and follow the longer path that led to it.
The Major Paradigm Shifts You MUST Make to Work with FrogNet
We explicitly reject much of the plumbing and architecture that has defined distributed programming for the last 50 years. The underlying transports haven't changed, and neither have the results applications need to produce, but the way we get to those results is radically different.
You cannot understand FrogNet by thinking about it as a conventional distributed system with some of the pieces renamed. Many of those pieces simply aren't here. Others have moved out of the application entirely.
If something seems to be missing, don't assume we forgot it. Before asking how FrogNet implements the conventional solution, ask whether the problem that required that solution still exists.
Empirical evidence gathered while implementing things like Redis (4 days) and PyTorch (9 days) using shared memory conclusively demonstrates the result. By removing almost all of the infrastructure imposed by the conventional REST and message-oriented model, performance improved, often significantly, with many of the current results in the 2x–3x range. This was expected. We removed work.
A useful network should keep helping when the connection gets bad.
FrogNet was built for places where connectivity cannot be assumed: a home or farm that still needs to work when the Internet is down, a rural site behind one fragile upstream link, a ship, a disaster site, or any system that cannot afford to turn into a collection of "Connection Lost" screens.
The call kept going
In this recorded Communicator experiment, the available bandwidth is driven down by hand from 987 to 637 to 450 Kbps. Video degrades as the link tightens, audio keeps priority, and the call recovers as capacity returns. A separate demonstrated operating point reached bidirectional 160×120 at 24 fps with uninterrupted audio at about 121 Kbps.
Watch the Communicator evidence →The same idea at home
An earlier single-LAN FrogNet ran at home throughout development to keep IoT devices separated. The point is the same whether the network is one house or crosses a continent: local systems should remain useful locally, and outside connectivity should extend them rather than become a prerequisite for them.
Start with ordinary hardware
You do not need a datacenter to begin. Raspberry Pi 4 hardware has run as a FrogNet node, and two machines are enough to form a network and watch discovery happen.
Start with two machines →Chat exposes the programming difference without requiring a new application concept.
The shipped FrogChat client is the useful evidence: a 471-line client with no application backend. Presence and multi-recipient operation were added without changing the RAM server. The program writes state and blocks on the state it needs.
The application owns a conversation
It must address a service, construct and send a request, receive a reply, and attach application meaning to that exchange. The exact bytes and latency depend on the concrete protocol and implementation, so FrogNet does not invent a favorable REST transaction here.
The application publishes state
The shipped FrogChat demonstration writes a line to the recipient's cell, while the receiving thread blocks on its own cell. That is the implementation the 471-line client demonstrates. Where every individual write must survive concurrent writers, the Memory contract also provides the distinct-state pattern: each value occupies its own address rather than replacing the current value in one cell.
receiver: blocking read on own cell
The comparison that matters is in the running client: application networking machinery disappears without replacing it with an application server.
State is addressed directly.Writers publish their own state.Readers read the state they depend on.Networking mechanics stay below the application.
You should not have to take a claim this large on faith.
FrogNet is built to be challenged with running code, external contracts and measurements. These are examples of the evidence already produced.
Semantic transport
Published pipe_workload.py workload ratios, from the deliberately bad case through mostly-static megabyte data with six live fields. The harness ships so the comparison can be repeated.
Same application, less latency
Published echo workload: direct Apache averaged 201 ms; hot FrogNet SAME/DIFF averaged 118 ms on the recorded run.
Communicator
Bidirectional 160×120 at 24 fps with uninterrupted prioritized audio over the real Seattle → broker → New York → 900 MHz path.
Psychedelic FrogTorch
Same-campaign Gloo time / FrogNet time while preserving ordinary DDP semantics in the compared arm, with matching correctness evidence.
Redis-on-Ribbit
Redis's own behavior used as an external oracle rather than replacing the contract with a FrogNet-specific test.
Physical network
Real Ethernet, Wi-Fi, WireGuard, Internet and radio paths rather than a topology that exists only in a simulator.
You do not have to learn the whole network before using the programming model.
Internet RAM Today
Start at the application. Use a familiar chat program to learn the RAM contract, held reads, distinct state, Regions and Ribbit without first building a FrogNet fabric.
Short path: chat → shared RAM → Internet RAM → Ribbit → Regions → familiar systems such as Redis and PyTorch.
Take the short pathIntegrate Network Shared Memory into a Complete Workflow
Start where FrogNet started. Install it, watch it discover itself, understand routing and failure, cross the Internet, work with sensors and services, and arrive at shared Memory with the machinery underneath already understood.
Long path: install → discovery → network → Internet → services/sensors → semantic transport → Memory → Ribbit.
Take the complete pathFrogNet applications can span sites without publishing their own Internet-facing protocols.
LAN
A local FrogNet application is not exposed as a public Internet endpoint. The local network has to be reached before the application can be reached.
WAN
Inter-site broker paths use WireGuard tunnels. The application still does not publish its own protocol as an Internet-facing service.
Internet RAM is separate
Internet RAM Regions are independently governed. Their vendors are responsible for securing them; that security is not supplied by the shared-RAM programming contract.
The same programming surface has already been pushed far beyond chat.
The point of these experiments is not that everybody needs Redis or distributed training. It is that the same small shared-state model keeps turning up in applications that normally require very different networking machinery.
Ship the app, not another backend
FrogChat is a 471-line client with no application backend to deploy. Presence and multi-recipient operation were added without changing the RAM server.
Put spare machines to work
Psychedelic FrogTorch has trained across heterogeneous machines in Seattle and New York while preserving the required training result. The application can work against shared state instead of being built around where every worker lives. That is the beginning of a virtual-datacenter resource model: useful distributed compute assembled from machines you already have rather than requiring a homogeneous datacenter fabric. It describes what resources can participate, not a claim that FrogNet reproduces a conventional datacenter scheduler, management plane or interconnect.
Keep familiar software familiar
Redis-on-Ribbit implements a mature, independently designed API over the same Memory model and checks the result against Redis's own test suite. Existing application contracts do not have to disappear just because the machinery underneath them changes.
FrogNet can be approached from the RAM or from the network.
What it is not
Not a cloud service, not a VPN, not a database, and not merely a compression tool. Those technologies can participate in FrogNet; none defines it.
Start small
The long path begins with ordinary Linux hardware, installation and discovery. The point is to watch the network form before asking you to accept the programming model.
Follow the complete workflow →Physical evidence
A New York lamp was actuated from Seattle through the shared-state path, about 2,400 miles each way: roughly 4,800 network miles to cross a room.
See the evidence record →The Guild is where unfinished work goes.
FrogNet is running software, not a declaration that every answer is final. Open problems are documented so somebody else can attack them, reproduce them, disagree with them, or replace them with something better.
Challenge a claim
Find the assumption, build the counterexample and bring the measurement.
Take an open problem
The current roughly fifty-six-node allocator limit is one example: root cause understood, replacement designed for about 59,500 addresses, and consciously deferred because the present physical network does not come close to the existing limit.
Try something new
The complete capability inventory is evidence of what has been tried, not a boundary around what FrogNet is for.