FrogNet / Internet RAM Today

Short path

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.

Current implementation: the shared-RAM contract and engineering record

Choose the vendor and the contract.

The vendor supplies a RAM host, a schema and a binding. Its host may run locally or on an Internet-reachable machine. Reachability, access, lifetime and persistence are deployment decisions. The application addresses state in that region.

Use a host you control or a region whose operator has given you its connection details. This site is not an offer of an anonymous production RAM service. Region composition and policy explain the deployment choices.

The smallest useful program.

Choose one truth each participant owns. Write that state. Read the state the other participant owns, then hold a read for changes. Start with a price and a sale: a price is one rewritten cell; a sale is one cell per record. Those two address choices explain latest state and distinct state without another backend.

The earlier FrogChat demonstration used recipient cells and a blocking read, with a published 471-line client count. That is a historical implementation count. A shared recipient slot can replace an earlier value when multiple writers race; use distinct owned addresses when every line must remain observable.

Progress to a held application view.

Keep the table your participant needs and update it on held-read wakes. Answer local queries from that view. Publish your applied mark so another participant can know what has been incorporated. Test the program by killing and restarting a participant, then inspect the state and the mark.

Keep the networking underneath.

C++ and Python clients use the shared library’s permanent-session and semantic transport machinery. The supplied JavaScript guide exposes the same programming rules. The Kotlin FD&F member is an independent RAW-protocol client; its purpose is network membership.

When the program needs ordinary packet connectivity to services inside a pond, add FD&F membership separately. Shared-memory access and routed access are different capabilities.

Learn the programming rules Find source and build instructions

Start with RAM

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.

Specification: §9 Memory

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.

Two useful shapes

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.

Now build something familiar

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.

Message-oriented application

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.

FrogChat

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.

Measure the difference

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.

Read the deployment and security boundaries →

From chat to Ribbit

Add ideas only when the application needs them.

Specification: §10 UnREST

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.

Memory contract Regions and vendor RAM

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 →