First, I created FrogNet
It was 2 AM. Again.
The system had been tested. It had been sandboxed. It had gone through every gate you have. It was clean.
Then it met the production server and the whole thing came down. Again.
And it was my job to figure out why.
So there I was. Staring at logs from across the network. Trying to see where whatever it was happened. Was it using the right messages? Did all the machines have the right PHP? Had the cache been cleared everywhere? Where was the clue I'd been missing? The one that would point to a misspelled command or missing data?
And, silently, in the back of my head, I wondered how much longer before I could go home. Maybe Tom could help figure this out when he got in at 9 — but until then I was the one with bloodshot eyes drinking stone cold coffee.
If you saw yourself in the above story, you are my kin. I know every late-night fast food joint and gas station in a 30-mile radius.
I finally got tired of it. I decided to do something about it. I created FrogNet. →
Next, I made it wicked fast
$ pipe_workload.py frognethost.happydog all 100
traditional FrogNet
payload what it is REST FrogNet boost
------------------------------------------------------------------------------------
404 a path that does not exist 394.7 KB 172.8 KB 2.3x negative control telem 200 sensors, 5-10 changing per call 6.6 MB 702.3 KB 9.6x echo 50 B static text 335.8 KB 8.9 KB 37.9x chat 50-msg rolling window, ~20% new 3.4 MB 24.7 KB 141x mb 1 MB JSON, six live fields 256.3 MB 30.0 KB 8,741x
241 requests · measured 2026-08-26
traditional REST = bytes a conventional stack would have sent
FrogNet = bytes FrogNet actually put on the wire, live through the origin
FrogNet boost = REST ÷ FrogNet — how many times the traffic was cut
Every one of those requests hit the origin and got a live answer. Nothing was served from a cache. What crossed the wire was the difference.
Watch it work →How it works →Run it →
The template is learned once: the first request for the 1 MB payload costs ~91 KB on the wire; every request after it is the table above. "Would" counts uncompressed bodies — gzip gets a payload like mb to roughly 20–50x; FrogNet isn't compressing the unchanged part, it isn't sending it.
Then I gave it a brain.
My programming surface expanded to the whole world.
The network is alive. And living things have memory.
FrogNet's first fact is a network that behaves like a living thing — it discovers, organizes, elects, adapts, splits and heals, with no permanent external control plane. That machinery stands on its own. And once a network can maintain itself, a second abstraction becomes possible: the network is memory.
Programs on a FrogNet do not talk to each other. They share what they know. The application never sends a message and waits for a reply, never retries it, never versions the shape of it, never keeps a list of who has been told. It changes state, and FrogNet does whatever communication is necessary underneath. A value is put into shared memory, and whoever needs it looks. If the network is memory, then a distributed program is just a program with threads. You already know how to write that.
It works like RAM. Address a value, write it, read it.
One database per network, so one order — FrogNet Memory is the memory controller, the same way nobody writes a coherence protocol for a single-socket machine's DRAM. Across an internet, a deterministic election keeps there being exactly one. For current operational state, last write wins. When a problem actually requires an order, FrogNet elects for order rather than letting the shared picture pretend to provide one.
The address is three coordinates and you name them to fit your problem — program/variable/user, host/globals/variable, sensor/type/location. Same store, no schema, no registry. And the consequence that changes what a system costs to extend: a new reader requires no change in the writer, because the writer expressed state rather than delivery. The producer never learns the consumer exists.
REST is to FrogNet what assembly is to C — still there, still useful, and no longer the surface most application programmers should have to work at. FrogNet's own memory calls are HTTP underneath, which is exactly what a compiler emitting instructions looks like.
And living things learn: give FrogNet REST and it watches, learns the structure, and stops sending it — the semantic engine.
And now you can use it too…
Or just watch the damn thing work.
A live call over a 900 MHz radio while the link is deliberately starved — down to 160×120 with the audio intact, then back up. Nobody ever redialed. All the demonstrations →
Learn how it Works
A fully adaptive video communications system, from a standing start, in under two calendar months.
Built by one person, while simultaneously building and testing the network underneath it — and the site, and the thousand-page build record. It should have taken at least six months longer and one more programmer, and it would not have been as complete.1 The point is not the schedule. The point is what made the schedule possible:
A REST compiler. Real-time, Internet-wide network shared memory. And the video went over TCP — the transport you have been told not to use. The Communicator is not a demo written to flatter the architecture; it is the programming-model claim, measured in calendar days.
1. Yes, that is an estimate. I have been sizing this kind of work since 1975 — flight simulation at Boeing, Sierra, Electronic Arts, Microsoft, the SCCM agent for UNIX and Linux. Fifty years buys you the right to say how long something should have taken.
Eight videos, an empty box to a transcontinental call.
A call that holds at 160×120 and climbs back. No slides. One person at a terminal, saying out loud where the work is unfinished — and where it went wrong on camera.
Four ways in: see whether it's real · understand how it works · challenge or build it · I already have a network
Dan changed a value, and a lamp came on.
Dan changed a value in New York. The write crossed 2,400 miles to the elected database in Seattle, and a lamp three feet from him came on. His program didn't know Seattle existed. It didn't know the lamp existed. It wrote memory. No cloud in the path — and nothing had been configured to connect the switch to the lamp, because nothing connected them.
Dan did not know he was setting a tuple. As far as he was concerned he was setting a sensor, and something that reads sensors noticed.
MQTT can turn on a lamp. Home Assistant can turn on a lamp. Neither can do it for a program that never implemented the conversation — no broker to address, no topic to design, no subscription to manage, no delivery to confirm. The lamp is not an IoT demonstration. It is an attack on the assumption that the application needed to implement communication in the first place.
A surface has moved when competent people stop noticing the thing underneath it.
What follows is what was actually underneath.
The claim, up front
Is message choreography the assembly language of distributed systems?
On a FrogNet, wide-area distributed programs don't talk to each other. They share memory. REST isn't gone — it's underneath, where assembly went when programmers moved to C.
The last five bugs you chased: a message that arrived twice · a timeout · stale state · a retry that left half-finished work · a failure only under load. None of that was your actual job. The whole argument →
We built the machine. Here's what happened.
"I'm not saying FrogNet is the right way to do this. I'm not saying it's the only way. I submit it as a potential first implementation." — What It Is, video 2
In a hurry? The whole argument in five minutes →
Think the abstraction falls apart on a real network?
It is not a LAN abstraction. We made a transcontinental HD video call over an 850 Kbps link that was invisible to the Internet.
Then we dropped to 320p at 450 Kbps and back up — without interrupting the conversation.
An elegant model that collapses the moment the network gets ugly is not worth adopting, so here is the same shared memory under a genuinely nasty link. The ladder is not a media feature bolted on: it is a value in memory that one side writes and the other reads, which is why nothing has to negotiate anything. And the call was hard to find because programs that share memory instead of calling each other do not need application doors — the exposed surface is the one address you chose, not an inventory of services. Intercepting the link yields semantic packets, not the HD call beneath them.
1 Stated as reduction rather than guarantee: the doors a review enumerates were never built, because nothing outside was expected to knock. FrogNet implements no cryptography of its own.
The security is not bought by making the network useless. The first unedited run below carries 1280×720 video at 22 frames per second in both directions, across the country, through an encrypted tunnel and a constrained 900 MHz bearer.
Not here for the engineering?See what you'd actually do with it ↓- 2 yr+cross-internet
- ~10 yrrunning at home
- Falsifiabletest gate ships with it
- Patent lineagepop-up networking
The existence proof, unedited.
This is the actual first run, recorded as it happened and unedited: a live HD video call — 1280×720 at 22 frames a second, both directions, no delay — crossing the country over Wi-Fi, an encrypted tunnel, and a 900 MHz radio link carrying the session at approximately 850 Kbps. The counter on screen shows ~89% of the bytes never had to be sent.
Proof it works. HD bidirectional communication holding at approximately 850 Kbps over the 900 MHz link, ~89% of the bytes never sent.2
2 A did-vs-would estimate against published WebRTC bandwidth for the same session, not a packet capture — we label our numbers.
Two defaults, taken the other way.
Live media rides UDP and network programming means passing messages — both good defaults, and on a real degrading link both flip. FrogNet runs media on TCP and drops whole frames at the sender, so the picture thins instead of shattering; and it coordinates through shared memory, so changing quality is a value the far side reads, not a session to renegotiate. The full claim, with the tape →
A private layer beside the Internet
Your devices join the FrogNet; the FrogNet reaches the Internet — directly or through another FrogNet gateway — so you get both at once. Traffic to the private 10.x network rides the adaptive node; everything else routes out at normal speed. 10/8 is where the fabric lives, not where your program lives. Applications do not use it. A program writes a value under a service, a name and a scope, and reads it back by describing what it wants — it never names a machine, so it never names an address. Which is also why the fabric is not a boundary: Seattle and New York sit on one FrogNet while the packets between them cross the public Internet inside a tunnel. It coexists with a 10.x network you already run provided the addresses do not collide, and on an estate already using much of 10/8 that is real integration work rather than a formality.
A way to optimize the whole Internet
The gains — semantic compression, the adaptive wire, custom handlers — need a cooperating FrogNet on both ends. Talk to an ordinary public server and you reach it fine, as plain HTTP, with none of the advantages. And a FrogNet's size is bounded by its hardware, most of all the elected database host. Yes, both ends run it. That is the point rather than the caveat it sounds like.
Stop writing the plumbing. Write the values.
If you've ever wired a sensor to a dashboard or made two services agree on a number, you know the tax: a one-line goal that becomes a thousand lines of reconnect, retry, and serialization. FrogNet deletes that layer. Here is the interesting part: look at the code that isn't there.
# package a request, send it, BLOCK on a round trip resp = client.get("/sensor/42/reading") # handle the status code, deserialize the body reading = resp.json()["value"] # and it's already stale — so you poll. again. use(reading)
# producer writes the value where it computes it put("sensors", "reading", scope, {"value": v}) # consumer reads it where it needs it — current, with a timestamp reading = get("sensors", "reading", scope)["value"] use(reading)
No endpoint to design. No verb to choose. No status code to map. No poll loop. The shared space is the rendezvous; semantic transport is the efficiency. REST and UnREST, side by side — Magnum Croakus § 34 →
Read state, not a feed
Read the value where your code needs it and you get bounded-stale current state, with a timestamp so you can judge how old it is. The semantic layer compares each read with what the receiving side already knows, so an unchanged value costs nearly nothing on the wire — stability is the cheap case rather than the expensive one. There is no change-notification primitive yet — a program that must know the instant a value moves polls for it.
Tuple access is the whole interface
Write a named value where you compute it; read it where you need it. The producer doesn't know who reads; the consumer doesn't know who wrote. Time, presence, and identity all decoupled.
You stop programming the messages
Not that messages cease to exist — FrogNet's own memory calls are HTTP underneath, which is what a compiler emitting instructions looks like. What stops existing is the application code that expressed them: no curl, no HTTP handlers, no glue code, no JSON wrangling, no retries, no reconnect logic, no version numbers on a control channel. You describe what's true and where; the substrate moves it.
Because state is content-addressed, not party-addressed: watchers and replay come free — any reader can read the same current operational state, and the change log is the recording. (it's also why the efficiency chart above stays flat no matter how many people watch.)
Why it works
Exchange memory, not messages.
Every networked program rebuilds shared state by sending, receiving, ordering, and retrying messages — the hardest, most fragile code in the system. FrogNet inverts it: state is the medium, not the outcome.
The idea is forty years old — Linda tuple spaces, from David Gelernter and Nicholas Carriero at Yale in the mid-1980s — carried into the wide-area, partition-prone, sovereign world it was always shaped for. Your whole job collapses to four declarations: what the data is, how fresh each field must be, where truth lives, and what a received value means. Everything between is inherited from the substrate.
- CONTINUOUS
- audio — protected
- LATEST_ONLY
- video, status, positions
- LOSSLESS_EVENTUAL
- chat, moves, commands
- RESIDENT_ONCE
- schema, layout, scaffold
- freshness is the protocol
Ten software subsystems, one fabric.
Ten parts, each doing one job — the coordination layer, the codec, the wire protocol, the media ladder, the floating database, and the rest. I wrote the software; my co-founder Daniel Tone builds the hardware and RF that carry it onto real radios. It takes both.
Tuple-space coordination
The shared-memory layer. A tuple is a value located by three indices — for sensors, name, type and location — and the store answers on any combination of them: one by name, every one of a type, everything at a place. You write where you compute and read by describing what you want, never by naming the machine that holds it. The Linda idea, at network scale.
Magnum Croakus § 25 — From messages to memory →Semantic compression
A codec that learns a payload's structure once, then ships only the diff — and when nothing has changed at all, the whole exchange is 21 bytes each way in place of a full request and response. Not a cache: the far end re-executes and only says "unchanged" once it has proven that, so stale answers aren't possible. Compression is not the point — the mechanism is sending only what's relevant, and stock LZ4 rides underneath an already-reduced payload rather than doing the work.
How the semantic engine works →Wire protocol
The binary framing underneath — the SAME/DIFF machinery that makes "billed for change, never for liveness" true on the wire.
Magnum Croakus § 27 — FNWP-1, the wire →Adaptive real-time media
Song of the Frogs — an A/V ladder that sheds video before audio and steps fidelity to match the bearer, proven HD down to a 25-byte beacon and back.
Magnum Croakus § 31 — Song of the Frogs →Where the readings land
Born of a need, not a design: a sensor reports on its own schedule from anywhere, and the reader knows neither which machine it is on nor whether it is awake. The data needs somewhere to land — asynchronously, from anywhere, instantly readable by anyone. That store is this. It floats to another node if its elected host dies, because the meaning was never trapped in the process.
Magnum Croakus § 16 — One name, a moving target →Capability-scored roles
Hosts are chosen by measured capability and re-elected the moment a better node appears. Authority serves at the network's pleasure.
Magnum Croakus § 15 — Selecting the service hosts →Self-discovery, repair & tuning
Automated discovery, integration, repair, and optimization: nodes find each other, join, heal around failure, and tune their own routing and roles — the network administers itself instead of waiting for someone to.
Magnum Croakus — Discovery & autonomics →Extensible sensing
A pluggable framework for bringing any sensor — soil, camera, gate, telemetry — onto the shared fabric as first-class, always-current state, with no bespoke integration per device.
Magnum Croakus § 23 — The sensor platform →Extensible intelligence
A framework for running AI on the same shared memory, so models read and write the network's live state directly — the substrate is the pipeline, not a thing bolted beside it.
Magnum Croakus § 24 — The AI platform →HTTP as the control plane
Ordinary HTTP repurposed as the coordination tool — the one protocol already allowed nearly everywhere — so nodes discover and coordinate through existing infrastructure without demanding a new port.
Magnum Croakus § 13 — HTTP as coordination →Two levels of adoption — and you can stop at the first.
You don't have to rewrite anything to win. The first level is a drop-in that pays for itself the same afternoon; the second is where the architecture gives you everything it has.
Move your internal sites onto FrogNet
Point your existing services at FrogNet transport and leave the code alone. The engine takes the HTTP port on the node itself, so every client on the box — a script, a browser, a sensor, an application you shipped years ago — gets this unmodified. No library to link, no SDK to adopt. Most efficiency technologies make you rewrite something; this one you install. An unchanged response collapses to 21 bytes.
- An order-of-magnitude drop in bandwidth with no rewrite — the win lands before any redesign does.
- A smaller exposed surface: a compact binary frame instead of sprawling plaintext REST endpoints, and traffic that stays on your own fabric rather than fanning out through public infrastructure. That is exposure reduction — the encryption, where it is needed, is WireGuard's.
Rewrite the application as UnREST
Change the model, not just the wire. The application uses network shared memory instead of explicitly communicating with another application — write a value where you compute it and read it where you need it. FrogNet resolves the logical memory address to the currently elected database host; the application neither knows nor cares which machine currently holds that role.
- Maximum advantage: the stack of caches, sockets, and presence services collapses into one shared space that goes silent when nothing is changing.
- Stable addressing, moving host: applications address the memory, not the machine serving it. The database role moves deterministically as topology changes, while the programming interface remains the same.
Most teams take level one first — an order of magnitude for an afternoon's work — and move to level two where it earns them the most. The full walk-through, with worked numbers, is in Appendix D of the build manual and on the use-cases page.
- A transport-agnostic fabric — one flat plane of shared state over any bearers.
- Self-forming, sovereign, and partition-tolerant by default.
- Running across the internet for two years and counting; a home network for ~a decade.
- Not a cloud service — no company holds your data and no vendor account stands between you and it.
- Not a VPN or tunnel product — WireGuard is just one bearer it can use.
- Not request/response — it moves memory, not messages.
Built, running, and falsifiable.
FrogNet ships with a simulator whose only job is to try to break it. It does not model FrogNet — it runs FrogNet: the shipping discovery, election, memory, proxy and daemon code, on simulated machines and a real kernel, one network namespace per node. Forty-eight nodes settle in 314 merge events with zero unreachable pairs out of 2,256. It exits nonzero the instant any check fails, and every check is paired with a negative control that must make it fail. The report ends with what the run did not exercise, named from the source. The compression numbers at the top of this page came off that same real engine, not a slide. How the simulator works → The chapter →
That posture — find the root cause, instrument, prove — is the discipline FrogNet ships with, and the one behind every line you would build on it.
And living things evolve. FrogNet was born from one person's perspective, and it cannot mature on one. FrogNet brings networks to life. The Guild brings FrogNet to life. I gave FrogNet life. I am not its life.
Think I'm wrong? Good.
I am not claiming every algorithm is optimal, or that every decision I made is right. I am claiming that it works — and that its behaviour can be tested.
FrogNet ships with the simulator and the test gate used to validate it. Run the existing topologies. Break them. Replace an algorithm with yours. Pass the same oracles and beat the measured result.
If you have a better method, don't argue it in a thread. Bring an oracle. You don't have to bring the fix.
- Cross-internet mesh
- 2 years+
- Home network
- ~10 years
- Patent lineage
- pop-up networking ✓
- Developer license
- free ✓
- Falsifiable gate
- ships with it ✓
- Founders
- two · SW + RF
All the things you'd do with your people — somewhere that's just yours.
No accounts, no algorithm deciding what you see, no company quietly selling it back to you. Just the people you choose and the ordinary things you'd want to do together.
The call that won't drop
Your people, a map only you see
Game night across three houses
Interface previews — the Communicator, the family map, and the game table
Private calls, video & messaging
Reach the people you choose with calls, video, and chat that no company can read — because there's no company in the middle to read it.
Your family's own network
A presence map, shared photos, and a calendar for your people — living in your home, not on a platform that sells what it learns about you.
Works in a blackout
Storm, outage, or dead zone — everyone stays connected. It runs on local radios and Wi-Fi with no internet at all, and reaches across the web only when you choose.
Off-grid, anywhere
Ranch, worksite, boat, or back-country camp. If two points can reach each other by any means — Wi-Fi, long-range radio, satellite — FrogNet links them. Every transport it rides →
Your sensors and smart home
Cameras, gates, soil, weather — read into one private picture you own, with no gateway subscription and nothing routed through anyone's cloud.
Ready for the worst day
Built for when the infrastructure fails: emergency and disaster communication that keeps working while the towers, power, and internet are down.
No cloud, nothing rented
Runs on boxes you already have — a Raspberry Pi, an old laptop. FrogNet itself carries no recurring cloud fee and no off-switch in anyone else's hand. Owning the capability isn't the same as a lower bill, though: replacing a paid service only saves you money if you actually cancel it.
Yours to build on
Developers get a network you write to like local variables — the whole platform, free to build on. See where it's deployed →
Know that your conversations and your data are private
Not a policy you're asked to trust — the way the network is built. There's no company in the middle that could read them, sell them, or lose them, because there is no company in the middle at all.
You don’t have to be a network engineer. You plug in a box, it finds the others on its own, and you’re running — often the same afternoon. The same box does all of it at once; start with the one you need today. Already have a network? You do not migrate to FrogNet. You insert it. Start here →
We'll even tell you the one place it could be tapped.
Most services would never admit to one. Here's the honest picture. While your network stays on local Wi-Fi or radio, there is no point on the internet to tap at all. When you bridge two sites across the public internet, the traffic passes through a single relay — a broker — and that one point is, in theory, where machine-to-machine traffic could be intercepted. So look at what someone trying would actually be up against.
Won't answer a knock
The relay sits on an IP you control and a port you choose, behind WireGuard — which stays silent to bad probes. A scanner sweeping the whole internet gets no reply and no hint anything is even there.
On ground you picked
You choose the address and the port. No well-known endpoint, no service banner, nothing announcing itself — just one quiet door among billions of addresses.
WireGuard carries it
Anything crossing the public internet crosses a WireGuard bearer — that is the confidentiality, and it is standard, audited cryptography rather than anything of ours. FrogNet's job is the surface reduction, not the crypto. On top of that the payload is structurally uninteresting: what crosses is differences against state the far end already holds, so an intercept without that memory yields fields with nowhere to put them — a property of the encoding, not a second layer of secrecy. Three separate properties, kept separate: the absence of a remotely callable application surface; encryption, if you add it — FrogNet implements no cryptography of its own; and a passive observer lacking context, which is a consequence of statefulness, not cryptography.
And public input needs no door at all.3
Even a form on the open internet doesn't have to be a way in. It can sit exposed and still be air-gapped from the network: the public side only drops files into a watched folder — it never holds a socket the network answers. Inside, those files are picked up, inspected however you like, and only the vetted result is handed to the applications; replies make the reverse trip. Nothing on the internet can address the network; it can only leave a file the inside chooses to read. A selective directional gap — disconnected doesn't mean dark. It's the recommended way to face the open internet — and it's what the broker host already runs. See the architecture →
Finding it would be like finding a single grain of sand on a long beach. Making sense of what crossed it would be like extracting one strand of DNA from that single grain.
3 This is the established cross-domain pattern — a data diode or watched-folder drop — and it is no longer a plan: as of the current broker build it is the deployed architecture. The broker's own operator console sits behind exactly this gap, and the same air-gapped receiver ships for this site's license form — the public process holds no credential and answers no socket the network is on. How it works →
The whole idea — explained for anyone.
FrogNet is written down, from first principles, in two free books. Start with the story; drop into the manual when you're ready to build.
How to Think Like a Frog
The ideas behind FrogNet in plain English — no code, no jargon. Why the network you rent works the way it does, and what changes when you own it instead. If you read one thing, read this.
Magnum Croakus
How to Work Like a Frog — the engineering build manual. Install a node, discover the mesh, elect the database, and write your own handlers, with worked examples throughout.
Own it
Headed for an open standard — with a reference you can run.
The protocol underneath FrogNet is being written up as an open specification, so the wire is a public contract anyone can implement against — the engine you license is the reference implementation, not a black box. Both books are free, and so is the developer license — no seat count, no expiry. When FrogNet runs inside something commercial, a simple license covers it, with support and The Communicator included. And a Foundation is being established to steward the standard, so it stays owned by the people who use it. Closed engine, open protocol — on purpose: the plan →