FrogNet / Memory
Programming surface

Memory and Ribbit

FrogNet Memory is network shared RAM. Programs read and write named state rather than sending messages to one another.

Current implementation: the shared-RAM contract and engineering record

One address. One current value.

Use the three-coordinate key to identify one truth. The owner replaces its value when that truth changes. A write-order id names the memory’s publication order. A separate cell for each event provides distinct state; repeatedly rewriting one cell provides latest state. The distinction comes from the address, not a second transport.

TruthAddressingReader behavior
Latest valueOne owned cell, rewrittenA slow reader receives the latest value, not a backlog.
Distinct stateOne cell for each recordRead records past the reader’s write-order mark.
CollectionOne cell per elementA partial address selects the table; the instance names the element.
ContainerPart cells, then a headerThe owner publishes the visibility marker after the parts.
ReferenceA tuple name in a cellRead the referenced state instead of making a second copy of its truth.

A held read is part of the contract.

A reader can ask for state past an id and wait at the host until the condition can be answered. This replaces an application polling loop. It does not make every interface in the legacy FrogNet tree event-driven: some wrappers and compatibility paths still have their own limitations.

Freshness is a read selection. An old cell need not be deleted by a timer to stop being eligible for a fresh read. Session-bound FD&F membership is a different contract: the RAM manager removes its announcement and mappings when the session ends.

RAM is not a replication promise.

The Living Network’s transient memory host is selected from eligible members. If the host or the connected scope changes, the applications must treat the new memory world according to their recovery contract. They reassert their own truth and read the new world. There is no general promise of replicated copies, merged application histories or restoration of the old RAM.

An Internet RAM vendor can choose persistence and recovery policy in its own region implementation. That choice is additional to the shared-state programming contract. Read the explicit boundaries.

Use the surface deliberately.

Read and hold the truth your participant needs. Keep collections as element cells. Publish a container’s header last. Give foreign systems one truth owner. Derive totals and liveness from state instead of maintaining a second, stale copy.

Read the programming guide →

Memory is organized as cells. Each cell has three independent coordinates: service · variable · instance.

A cell contains one current value. Writing a new value replaces the old value. A program can read one cell, or leave a coordinate open and read the matching set of cells. A held read waits until the state being read changes, so a program can sleep until something it needs becomes available.

Different kinds of state use different addressing patterns. A sensor may continually replace its current reading in one cell. A chat message that must be observed individually can be written as distinct state, with each message occupying its own address. Collections are sets of individually addressable cells rather than a serialized object stored as one value.

That is the memory model.

Ribbit is the programming model built on it. A Ribbit program knows the state it owns and the state it needs. It reads the truths it depends on, determines its own truth, writes that truth, and waits until something relevant changes.

It does not need the identity or location of another program. It does not construct a message for another participant, find that participant, send the message, wait for a reply, or interpret the reply. Other participants do the same thing against the same shared state.

The result is a distributed application assembled from small participants operating on shared truth rather than programs having conversations across a network.

The Memory contract is small.

Specification: §9 Memory · §2 Architectural invariants

Address

Each cell has three independent coordinates: service, variable and instance. A read can name one cell or leave coordinates open to read a partial index.

Operations

Write, read, held read, freshness-constrained read and remove. There is no separate notification verb.

Value

A coordinate holds one current value. Writing replaces it. Memory records current state, not history.

Participant Adetermines A's truthreads dependencies FrogNet Memoryservice.variable.instanceservice.variable.instanceservice.variable.instance Participant Bdetermines B's truthreads dependencies writereadwriteread / held read
Participants do not address one another. Each publishes the truth it owns and reads the truths on which its own work depends.

Ribbit is what programs do with that contract.

Specification: §10 UnREST

Ribbit ideaMeaning
CellAn independently addressable truth.
ReferenceA truth that names another truth or collection.
ParticipantAn ordinary program that reads what it depends on, does one job and publishes what it learned or did.
Held readBlock on a real dependency instead of polling or inventing a callback protocol.
WantDemand itself can be published as state.
ClaimCompetition can be represented as published state where the application needs it.
BatchA set of truths that must become usable together can itself be one published truth.

The server does not acquire a new verb every time an application needs a new behavior. Participants build behavior from the Memory contract.

Two useful behaviors fall out of addressing.

Latest value

Repeated writes replace the same cell. A slow reader gets the newest value rather than an accumulated backlog.

Distinct state

Give each value its own address and every value can remain independently readable. The application chooses the shape.

What it does not claim

Specification: §17 Known limits