Internet RAM Today
FrogNet can expose shared RAM across an ordinary network or the Internet. An application reads and writes named state in that RAM instead of building a message exchange with another application.
The familiar idea is memory shared by more than one machine.
Ordinary RAM gives a program locations where it can put a value and retrieve it later. FrogNet Memory keeps that basic model and gives the locations names that can be used across a network. A program does not need to know which other program will read a value, where that program is running, or how to send it a message.
Internet RAM is the same idea with the Memory service reachable at a well-known Internet location. The organization operating that service defines the Region: its namespace, API, schema, lifetime, backing store, residency rules and security policy. The RAM fabric itself does not impose those policies.
Cell
The basic unit of Memory. A cell contains one current value.
Address
Each cell is identified by three independent coordinates: service · variable · instance. A program can address one cell or leave a coordinate open and read the matching set.
Held read
A read can wait until relevant state advances. The program sleeps until something it needs changes instead of constructing a separate notification exchange.
How you address state determines what it means.
If only the current value matters, later writes replace earlier ones at the same address. If every value matters, each value gets its own address. Both use the same Memory operations; the application chooses the shape that matches its semantics.
Latest value
One address holds one current value. A later write replaces it. A temperature reading, presence state or current status naturally fits this shape.
Distinct state
Every value gets its own address, so one value does not replace another. Chat messages use this shape because each message is independently addressable state.
Build chat first.
Chat gives us a familiar application for seeing the difference. In the shipped FrogChat demonstration, a sender writes a line to the recipient's cell and the receiving thread blocks on its own cell. Neither side needs the other's network location. Neither side needs the other's network location.
The shipped FrogChat client is 471 lines and has no application backend. Presence and multi-recipient behavior were added without changing the RAM server.
Own the exchange
The application addresses a service, constructs and sends a request, receives a response, and assigns meaning to the exchange. We only attach byte and latency numbers when a concrete implementation has been measured.
Publish and read state
- Get the message and target.
- Write the line to the recipient's cell.
- The recipient blocks reading its own cell and wakes when that state advances.
That is the shipped demonstration. For workloads where every write must survive concurrent writers, use the distinct-state pattern introduced above: one independently addressed cell per value.
Count the work, the bytes and the network-dependent steps.
Every comparison on this path should say whether a number is measured, calculated from a stated protocol/workload, or estimated from explicit assumptions.
| Question | Conventional model | Ribbit model |
|---|---|---|
| What does the application address? | Server/process/endpoint | State |
| What does the sender wait to understand? | Application response | No application reply is required merely to publish the truth |
| What changes when recipient location changes? | Potentially routing/service/application deployment | The state address need not change |
| What should we measure? | Application operations · bytes on wire · latency-critical crossings · code required | |
The site will use packet captures or the actual FrogNet wire representation for byte comparisons. It will not invent a favorable REST transaction or assume a favorable Ribbit encoding.
Internet RAM and the Living Network are different deployment choices.
Internet RAM Today
The application talks to a RAM service at a well-known location; it does not need its own chat backend. How that Internet RAM Region is exposed and secured is entirely the vendor's responsibility, not a property of the RAM fabric.
Inside a local FrogNet
The application can remain entirely inside the LAN. There is no requirement to expose the application itself as a public Internet service.
Between FrogNet sites
Inter-site traffic traverses the broker path over WireGuard tunnel legs. The application programming model does not change when the state is remote.
Add ideas only when the application needs them.
Cells
Three independent coordinates identify a current value.
Held reads
Wait on a dependency without building a notification protocol.
Collections and references
Build higher-level structure out of independently addressable state.
Participants
Read truths, derive your truth, write it, sleep.
Regions
Let vendors own schema, API, lifetime, security, residency and backing.
Then attack something familiar.
Redis and PyTorch are useful precisely because FrogNet does not get to define whether they work. Their existing behavior and semantics provide the challenge.
Redis-on-Ribbit
Express a large familiar server contract using Ribbit state, then run Redis's own behavioral tests against it.
Redis evidence →Psychedelic FrogTorch
Preserve the required training contract while asking which distributed mechanisms actually belong in the application.
FrogTorch →