The long path
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.
frognet_monitor on it, you are ready.The six lectures, aircraft-data-bus origin, Linda lineage, sensor reasoning and learning exercises remain in their original sequence below. The newer programming surface adds held views and write-order marks to that foundation. Programming Ribbit develops those rules; FD&F applies them to the network itself.
The whole path falls out of one awkward situation, and this video builds the situation before it builds anything else.
Assumes: the trunk
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 JulThe second video names the thing the first one built, says where the idea came from, and is careful about what it does not do.
Assumes: video 09
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 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 JulThe third video is the paradigm shift, and it is careful to concede what REST still does underneath before claiming anything above it.
Assumes: videos 09–10
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 AugNot 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.
Assumes: videos 09–11
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 AugServices is named on camera at the end of video 12. Neither is recorded yet, and the page will not pretend otherwise.
Assumes: videos 09–12
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.
Assumes: videos 09–13, and video 14
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.
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
Free for any use under the GPL — including commercial. 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.
Get the source →02 · to argue with it
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
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 →