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 →
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. 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.
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 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.
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.
Same wire. Different programming surface.
Nothing above needed a new network or a faster radio. It needed a different way to program the one we already have. The pipes are not the problem — connections get reused, HTTP/2 multiplexes, caches help. The problem is what the application is asked to do on top of them.
A request/reply surface
REST gives the application a conversation to conduct: compose the request, send it, wait, parse the reply, handle the failure, and prove all of that machinery in tests. The transport underneath is fine. The churn is in the programming surface — in what the application must re-state, re-request, and re-verify on every exchange, forever.
A shared-memory surface
FrogNet uses HTTP underneath while handing the application a different surface: state. Both ends hold the same picture, so only the difference has to cross — nothing when nothing changed, the changed fields when they do, the whole shape only to teach it once. The conversation still happens. You stopped writing it.
That is the whole performance story: the message never carries what the far end already holds — which is how a full session fits over a link this thin. And it runs beside what you have; traffic that wants plain HTTP keeps it. The claim, in full →
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.
Billed for change — never for liveness.
Here is the whole efficiency argument in one game. Picture two people playing backgammon online while friends watch. A naive server hauls a full truckload every move: it bundles up the whole game and ships a fresh copy to everyone — and the load gets bigger every move. (Real systems send deltas and do better than that — the honest comparison is in the caption below.) FrogNet sends a courier instead, and the only thing the courier carries is the move — a few bytes — however long the game runs or however many people watch. Both ends already hold the board, so nothing else needs to travel. That is UnREST's shared memory doing the work; the codec is what makes the courier's parcel small, and even its largest parcel beats a truckload.
Mails the whole game, every move
Re-sends everything that has happened so far. By move 42 a single move costs 1,619 bytes — and it never stops growing.
Shares one board everyone reads
Sends only what changed — the move itself. About 45 bytes, flat, from first move to last. Extra watchers read the same board for free.
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; convergence 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. An unchanged value diffs to nearly nothing on the wire, so 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 sees the same converged 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 § 27 — 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 exchanges network shared memory instead of firing requests at a server — read a value where you need it, write it where you compute it, and let the substrate converge.
- Maximum advantage: the stack of caches, sockets, and presence services collapses into one shared space that goes silent when nothing is changing.
- Local reads, self-healing: every participant already holds the current state, so there is no centre to gate it, bottleneck it, or take it down.
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 — there is no center holding the meaning.
- 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 — building hostile topologies, killing nodes mid-run, partitioning the mesh — and it exits nonzero the instant any check fails. Green is green because every oracle passed, not by default. The backgammon number above came off that same real engine, not a slide. The simulator and its oracles — Magnum Croakus →
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
Play together
Cards, board games, party games — everyone at the same table, wherever they happen to be, with no app store or subscription sitting in the middle.
Share the album
Send the vacation photos and the home videos at full quality to the whole family — and they stay in the family, not parked on a platform mining them.
Talk any way you like
Group chats, voice, and video with your people — no phone numbers handed out, no stranger and no company reading along.
Movie night, in sync
Start a show and watch it together from different houses, in step, with the side chat running the whole time.
Know who's around
A simple presence map for the household — who's home, who's out — that no outsider and no company ever gets to see.
Pass things hand to hand
Documents, recordings, the shoebox of scanned photos — moved straight between your own machines, never left sitting on someone's cloud.
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 middle at all.
It starts with a private call. It doesn't stop there.
One network, running today — across the internet for years, and on local radios with no internet at all. Here's the range.
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 →
Already have a network? You do not migrate to FrogNet. You insert it. Start here →
Investigate what a network of your own makes possible.
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. From a single family to a whole town, here's what people stand up on day one.
Everyone under one private roof
Calls, video, messages, shared photos, and a where's-everyone map for just your people — no accounts, no cloud, nothing sold. It runs on a spare box in the closet and keeps working when the internet doesn't.
Your shop's own nervous system
Tie the registers, cameras, back office, and the phone in your pocket into one system without renting a separate SaaS for each. No monthly seat fees, and your numbers never leave the building.
Eyes on every acre — no cell bars needed
Soil, tanks, gates, and cameras spread across land the carriers gave up on, read into one picture over long-range radio. Set it up once; it heals itself when a node drops off.
Connectivity a town can own
A village, a co-op, or a disaster zone can stand up its own calls, messaging, and services with no carrier and no data center — and keep them running through the outage that takes everything else down.
The same box does all of it at once — you don't pick a lane. Start with the one you need today; the rest is already there when you want it.
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 →