The long path

Six videos, and you stop sending messages.

The trunk got you a running network and a working call and told you almost nothing about why either holds together. This path is the why, in the order it was actually discovered rather than the order it would be taught: sensors created a problem, the problem built a database, the database turned out to be memory, and memory made most of the code unnecessary. Each video assumes the trunk and the ones before it, and nothing else.

Four recorded · two still to shoot

Before you start — what these assume

These are explanations, not walkthroughs. Nothing here is a setup step. What they do assume is that you have run the trunk, because every idea below is described against a network you have watched behave.

The trunk, watched and done. Videos 01–07 on run it yourself →. If you have a pond and you have run frognet_monitor on it, you are ready.
General networking knowledge. Sockets, HTTP, what a round trip costs. No distributed-systems background is assumed and none is needed.
A tolerance for being told how the sausage was made. These were discovered in the wrong order and the videos say so, including the parts that were named later than they were built.

§01Video 09 · where it started

A sensor doesn’t know who’s listening. Start there.

The whole path falls out of one awkward situation, and this video builds the situation before it builds anything else.

09 · sensorsrecorded

Video 09 · sensors

Assumes: the trunk

What a sensor actually is, and what it forces you to build

A Pi was built for this — GPIO, a camera connector, and beyond it ESP32s and Meshtastic. So the question is only how a reading gets into the network and becomes readable by anything else in reasonable time. Under REST that means a central server, a messaging layer, and the part every engineer recognises: the fragile part, where the time goes.

So the video throws it out and asks what a sensor is. It is data — usually JSON, and if not, it can be made JSON. Describable by three things: type, name, and location, where location means which network and which address, not where it physically sits. Index those three, allow any combination, and you have somewhere for the reading to land. That is where FrogNet Memory was born — from the data needing somewhere to go, not from a design.

Then the hard part, which is that the network has no central authority. The answer is to make the choice deterministic. Highest IP address wins the control database; every node can be a DatabaseHost and every node has MariaDB. But the FrogNet host is not necessarily the best host, so nodes register their capabilities — MariaDB, memory, network, storage — and the real DatabaseHost is elected from those, on every merge.

"We’ve created memory. We have memory that is available on the network that is addressable through a tuple that anybody can see and anybody can read."

— Sensors and the FrogNet Memory, 30 Jul

Ends onThe realisation, stated as a big leap: this is network shared memory. And the observation that most of the sensors already running are software — a machine reporting its own CPU and disks.

§02Video 10 · what it turned out to be

It came from an aircraft data bus.

The second video names the thing the first one built, says where the idea came from, and is careful about what it does not do.

10 · FrogNet Memoryrecorded

Video 10 · FrogNet Memory

Assumes: video 09

One value, no history, always somewhere

A note on the nameThis video and the one before it say "FrogNet Memory" throughout, because that is what it was called when they were recorded. The build manual has since retired the term: the thing you write to is FrogNet Memory, and tuple space is the computational model underneath it. Same mechanism, settled name.

The origin is the ARINC 429 bus, from engineering flight simulation at Boeing — autopilot and autothrottle work, where sensor data from the rest of the aircraft simply arrived. You addressed the data on the bus and used it. No worry about who produced it, or where, or when. That is the property FrogNet Memory was built to have.

Two things define it. It is transient — it lives on whichever node best satisfies the requirements at the time, one node or fifty, and it moves by itself when networks merge. And it holds one value: the current one, whatever was written last. No history, no records.

Then the honest edge. Stale data is possible — split off, write locally, rejoin, split again, and you are reading what you left. So the envelope carries a last-written time and it is the consumer’s job to decide whether that is stale enough to matter. The database does no consistency checking, and the video says plainly why: across a wide-area network it is extremely hard, and there was no reason to do it.

"I didn’t realise it at the time, but I invented a network addressable shared memory."

— FrogNet Memory, 30 Jul

Ends onThe three indices being arbitrary — for a program, the program name, the variable, and the user — and one line about what got built with it: “Tell you what we did. We made the Communicator.”

§03Video 11 · the model

UnREST is not the anti-REST.

The third video is the paradigm shift, and it is careful to concede what REST still does underneath before claiming anything above it.

11 · intro to UnRESTrecorded

Video 11 · intro to UnREST

Assumes: videos 09–10

The evolution of REST, not its opposite

Everything up to here was mechanical — hardware, install, config, the tunnel. This is the part that matters, and the reason given is that it is a large paradigm shift. Under REST you write the messages, carry enough context in them to reconstruct meaning at the far end, and get the timing right. In fifty years of writing these, that is the most fragile part of any system. So: stop doing it.

Everything goes into FrogNet Memory, addressed by tuple. Ask for all sensors named GPS, or of type pH, or on Seattle 5, or the pH sensors on the Seattle 5 network — and with up to 254 devices per network, each potentially its own sensor platform, that search matters. REST is still underneath, setting up and managing the space. From the programmer’s point of view it is gone.

"So UnREST is not the anti-REST. It still uses REST. It’s still down in there. What it is, is the evolution of REST."

— Intro to UnREST, 3 Aug

Ends onThe Communicator as the thing this makes possible — and the aside that it breaks its own paradigms too, carrying live video over TCP/IP with audio prioritised above it, rather than blasting UDP.

§04Video 12 · the pattern, and the proof

Somebody got here in 1979.

Not history — argument. Gelernter described coordination instead of communication, the industry went the other way, and this is the other road, driven: UnREST is to REST what Linda was to Ada. The fourth video goes looking for that prior art, finds it, and then shows the smallest possible working example — a heartbeat that coordinates two programs without a message.

12 · tuple spacerecorded

Video 12 · tuple space

Assumes: videos 09–11

Linda, a search-and-rescue team, and a heartbeat

FrogNet Memory was built for sensor data before it had a name. Going back afterwards to look for an existing pattern turned up David Gelernter and Nicholas Carriero’s Linda, a coordination language for parallel programming built on a shared tuple model. It worked. It lost out to Ada. What it gives you is the habit of reaching your data by three vectors rather than by naming a destination.

Then the scenario that makes transience concrete. A search-and-rescue team at headquarters is part of that pond. It drives away and becomes independent — and the database is now theirs, because it is always calculated from the perspective of the machine. Meet another team, merge, and one of you hosts it. Reach the headquarters network and somebody there does. Every time, recalculated, deterministically.

And the working example: the proxy and daemon each write a heartbeat into tuple space — type heartbeat, name the program, location the node, value the time. Next loop, if what they read is not what they wrote, the database moved and the caches are wrong. So they drop them and rebuild.

"No messages were exchanged. No data flew over the wire. Nothing had to happen except that the program looked at its tuple space and said, something changed."

— Tuple Space, 4 Aug

Ends onCookies — invented for continuity, spent on advertising — and the point that this needs no FrogNet, only an infrastructure that knows what the shared database is.

§05Videos 13 & 15 · still to shoot

Two left, and the second one is where it all lands.

Services is named on camera at the end of video 12. Neither is recorded yet, and the page will not pretend otherwise.

13 · servicesnot yet recorded

Video 13 · services

Assumes: videos 09–12

Cross-network services, and who decides

Not yet shotDescribed at the close of video 12 as the last thing on the agenda — and as the end of UnREST.

Setting these up as services across networks: whether you need a control at all, who takes that role, and how it is arranged. The last rung of the model.

Will end onThe end of UnREST — and the door to writing your own.

15 · the Communicator, from the insidenot yet recorded

Video 15 · the Communicator, from the inside

Assumes: videos 09–13, and video 14

The same program, read as UnREST

Not yet shotIts companion, video 14, is the mechanical one — how to set it up and use it. This is the same application taken apart.

Video 14 shows you the call. This one opens it up and reads it as a program written against network shared memory: what is held in FrogNet Memory rather than sent, where the freshness bound sits in a live media path, and what the plumbing would have been under REST — the servers, the messages, and the context-carrying that never had to be written.

It is also where the Communicator’s own paradigm breaks get their explanation rather than a mention: live video over TCP/IP instead of UDP, with audio prioritised above the picture, holding at 850 kbps on a 900 MHz link.

Will end onAn application with no client and no server in it — and the plumbing counted, in lines that were never written.

§06Three doors

You have the model. Here is what to do with it.

This path is the route to contribution, so the doors at the end of it are different from the ones at the end of the trunk.

01 · to build with it

Take the developer licence

Free for development, personal, and community use. No seats, no expiry, no telemetry. If you want to write against FrogNet Memory rather than watch someone else do it, this is the step.

Ask for a licence →

02 · to argue with it

Join the guild

Ten subsystems, two seats that aren’t code, and one open allocation problem with the arithmetic already on the table. Better is demonstrated, not argued — the simulator is the gate and it doesn’t care who either of us is.

See the seams →

03 · to go deeper

The books

Both free. Magnum Croakus derives the whole system from first principles, subsystem by subsystem — these videos are a guided route through it, not a replacement for it. Don’t trust me; check it.

Read the books →

Four of these six are recorded. Looking for the setup videos instead? Run it yourself →