The guild
A messiah has followers. A journeyman has a guild.
I am not looking for an audience. I am looking for the people who will read this, disagree with a piece of it, and build the better version — because that is the only way a network like this stops being one person's work and becomes a thing the profession owns.
Two doors. To talk about it — the book lives in a public repository and its Discussions are open. No licence, no account with us, no permission. To build on it, ask for a licence. The implementation is licensed. The argument is not.
The Guild — the recruiting pitch, in his own voice.
Linux won by being ownable — not on kernel benchmarks. FrogNet offers the same trade, one layer up.
Linux gave you a floor no company could rent, revoke, or meter. Then it left you standing on the same surveilled network. FrogNet is the next floor: a network individuals, groups, and companies own outright, with the footprint they expose to the outside world collapsed to nearly nothing.
Nobody joins a movement for semantic compression. Sovereignty is the payload — the performance is just how it gets in the door, and how you afford to run it on hardware you already have.
Four steps, and none of them require trusting me.
The distance between "I'm convinced" and "I built something" is where most projects lose people. So the on-ramp is deliberately short, and every step is something you verify yourself.
One thing worth saying plainly, because the rest of this page could give the wrong impression. The standards team wants people who have edited an RFC and the governance team wants a practising lawyer, and both of those are real requirements — but they are two teams out of twelve, and they are the exceptions. Everywhere else the bar is that you got it running and noticed something.
A topology that breaks the allocator. A payload the template learner handles badly. A sentence in the manual that is wrong, or right but hard to follow. A question you had to work out yourself because nobody had written it down. Those are contributions, they are how most of what is written here got found, and none of them requires you to be an expert in anything except what you just did.
Read it from first principles
Two free books. How to Think Like a Frog is the why, in plain English. Magnum Croakus is the build manual — install a node, discover the network, write a handler.
Both books, free →Take the developer licence
Free for development, personal, and community use — no seat count, no evaluation clock. You need the spec to build on the protocol, not permission.
Request the licence →Point one internal service at it
The drop-in is the honest on-ramp: leave your code alone, put your existing services on FrogNet transport, and watch what stops crossing the wire. This is the step that pays the same day.
The two levels of adoption →Then write something that exchanges memory, not messages
Compression is the bridge. The prize is FrogNet Memory — a variable any participant reads or writes, shared across the network, and the plumbing you stop writing entirely. That is where FrogNet stops being a faster pipe and becomes a different way to program.
Worked UnREST examples →Take it, with my compliments.
Everything above is written as an invitation to contribute, and that is not the only reason to be here. If you are a student, or teaching yourself, or coming at distributed systems sideways from another discipline — this is a working one, derived from first principles, with the reasoning written down. Use it. There is no obligation attached and nothing to sign.
Distributed systems are usually taught as toy examples and papers, because the real ones are proprietary, enormous, or both. This one is neither. It is small enough to hold in your head, it runs on hardware you can afford, and the two books derive every part of it from the problem that forced it rather than presenting it finished. You can read why an election algorithm scores nodes the way it does, then go and watch it re-elect one.
What is actually in here, as coursework: leader election and convergence under partition. Routing that rebuilds itself with no central authority. A codec that learns templates and diffs against them. Transport adaptation under real degradation, with the measurements. Tuple spaces and coordination models going back to Gelernter and Carriero in 1985. Shared memory semantics, and the freshness bound that a network forces on them. Each of those is a lecture somewhere; here they are one system that has to make them work together, which is the part the lectures leave out.
The simulator matters most if you have no hardware. It runs the real discovery, routing and election code against a modelled topology on a laptop, so you can break things, model a fifty-node pond you could never afford to build, and watch what happens — without owning a single Raspberry Pi.
Implement FNWP-1 yourself
The protocol is headed for an open specification, and the manual describes the wire format, the SAME/DIFF/FULL state machine, the freshness classes and the election scoring in enough detail to build against. Writing a second implementation — in a language of your choosing, from the document rather than from our code — is a genuinely hard, genuinely finite project, and it is the thing that proves a specification is a specification.
If you get partway and find the document ambiguous, you have found a real defect and the standards team needs to know. That is not a favour you are doing us out of politeness; a spec nobody has implemented from is a draft.
Use it in a course
The books are free, the developer licence is free and explicitly covers educational and research use, and there is no per-seat count to negotiate or evaluation clock to beat. Assign chapters, run the simulator in a lab, hand students a pond of Pis, or set the wire format as a term project.
Tell me what you are doing and I will help — john@fawcettinnovations.com. If a chapter turns out to teach badly, that is worth more to me than most bug reports.
And this section is not charity.
Some of the best work on any system comes from people nobody assigned to it. A student with a weekend and no mandate tries the thing that was never scoped, on hardware nobody tested, in a topology nobody drew. That is not a smaller version of professional work — it is a different search, and it covers ground a roadmap cannot, because a roadmap is a list of things somebody already thought of.
The particular thing this cohort does better than anyone is check whether done is true. I have declared parts of this complete, some of those declarations are wrong, and I am the worst-placed person to find out which — I know what I intended, so I test what I intended. Somebody who does not know what I meant does the thing I never anticipated. If it holds, that is worth something. If it breaks, that is worth a great deal more than agreement.
Then the unglamorous one, which goes uncredited nearly everywhere and shouldn't. Reproduction. A report that says it broke is a rumour. A report that says here is the topology, here are the steps, here is what I expected, here is what happened, and it does it every single time — that is an oracle, and somebody can act on it the same afternoon. It is real engineering work, it is often done by people who would not call themselves engineers, and it is appreciated here.
So take it, and play with it, and do the unexpected with it. If something surprising falls out, I want to hear about it — john@fawcettinnovations.com. And if nothing does, you still have the books.
And the part that closes the circle: a student who implements the wire format and finds the spec ambiguous, or runs the simulator and finds a topology that breaks the allocator, has already contributed — without applying to anything, and while doing something entirely for their own reasons. Learning here and working here are the same activity, which is why this section sits above the working groups rather than below them.
I am not its life.
"It may not even be right. But it appears to work. And if you can prove I'm wrong — go for it." — The Guild video, the recruiting pitch in his own voice.
FrogNet brings networks to life. The Guild brings FrogNet to life. It is born, and it is not finished — it cannot be.
I built it from one perspective — mine — and I know some of what I have done will turn out to be wrong. That is not an admission that undermines the release. For something this size, claiming otherwise would. There is a difference between I know it is wrong, so it is not ready and I know some of it must be wrong, so it is ready for more perspectives, and this is the second one.
I am not afraid of being wrong, and you do not have to take that on faith. Seven subsystems in this tree were replaced wholesale, and the reversals are annotated in the source with the reasoning that caused them rather than quietly deleted — a cache layer shipped and then partly reverted when one part of it turned out to be load-bearing; an entire merge path replaced, with the oracles that asserted the old rule retired by name instead of removed; a scoring term thrown out on the grounds that a benchmark run on a busy box measures the busy and not the box. A contributor reading those learns the thing that actually decides whether it is worth arguing with me: an argument here can change something.
Years ago I helped teach high-school programmers, in one of the most diverse districts in the country. What I told them about why diversity matters to an engineer was not the usual argument. It was this: there are exactly as many perspectives as there are people on the planet, and even identical twins have two. If you let me design your systems alone, you will get something that works extremely well for a burned out old hippy, and for nobody else. That is not a moral failing. It is a property of one point of view, and no amount of care escapes it.
FrogNet has the same problem. I can give it architecture, code, tests, a simulator and the first applications. I cannot give it the perspectives I do not possess.
So: bring the network I never worked on. The radio I never used. The protocol I never encountered. The application I would never think to build. Bring the assumption I got wrong, and bring the topology that turns an oracle red. If a subsystem needs fixing, fix it. If it needs replacing, replace it. If one of my architectural assumptions is wrong, demonstrate that it is wrong — which is the only part of this I would insist on, because a perspective that arrives as an opinion is an argument that goes to whoever is more persistent, and a perspective that arrives as a red oracle going green is a fact.
There is a symmetry in that worth noticing. The simulator subjects the machine to topologies I did not anticipate. The guild subjects the design to perspectives I do not possess. Both are doing the same job: finding the assumptions one person could not see.
What is fixed is the goal and what it forces — transparent and automatic, and therefore deterministic, memory-shaped, continuous, floating, frugal, and honest about failure. Everything else is this implementation, and this implementation is not sacred merely because I wrote it.
I gave FrogNet life. I am not its life.
FrogNet should accumulate authors, not followers. The reversals annotated in the source, the oracles retired by name, the spec seat whose undetermined clauses are authorship — those exist so that arguing with this project leaves a signature. The Guild belongs to its contributors.
We will measure both capability and consequence. The same discipline that instruments a claim before believing it applies to what the technology does in the world: our responsibility does not end when the technology works.
The afterword this is taken from closes the build manual. Read it there →
Ten subsystems. Each one is a seam you could own.
Linux never absorbed contribution as kernel rewrites — it absorbed a driver, a scheduler, a filesystem. FrogNet has the same shape on purpose: ten parts, each doing one job, each improvable without touching the others. A codec person can attack BLDC-1 and never read the election code.
UnREST
The tuple-space layer — freshness classes, authority, scope. Argue for a better convergence rule.
BLDC-1
Structure learning and diffing. New data types derive in; a domain-tuned codec could beat the general one badly.
FNWP-1
Framing, opcodes, sequencing, fan-out. The protocol headed for an open standard.
SotF
The adaptive ladder. The deep-tested path — and the one with the clearest measuring stick.
FrogNet Memory
Current-state store on an elected host. Bounded staleness by design — sharpen the boundary.
Elections
Capability scoring and re-election. Where "who decides" gets settled; a better score is a real contribution.
Discovery, repair & tuning
Find, join, heal, optimize. Routing and planning people: this is your seam.
Sensor platform
Any sensor onto the fabric as first-class current state. Widest surface for new device work.
AI platform
Models reading and writing the live shared state directly — the substrate as the pipeline.
HTTP coordination
Ordinary HTTP as the coordination tool, so nodes need no new port anywhere.
Every one of these is specified in the build manual, section by section — those section boundaries are the seams. Read the manual →
Ten of the seams are subsystems. These two aren't.
And right now they matter more. Neither requires access to the engine, and neither has anything to do with writing Python. Both are teams rather than posts — they will have more than one person in them, and they will decide among themselves who does what.
Somebody has to write the standard.
The plan says the endpoint is an open specification. Somebody has to write it, and it isn't the build manual.
Magnum Croakus tells you how this implementation behaves — it names files, scripts, and a Python venv, and it talks to a person standing at a machine. A specification is a different document: normative language, the frame laid out bit by bit, the state machine, negotiation and error behaviour, conformance criteria, and not one sentence that requires knowing our filenames. Four documents need extracting from the manual — the FNWP-1 wire format, the BLDC-1 SAME/DIFF/FULL state machine and template learning, the freshness classes and tuple semantics, and the election scoring.
Four documents is comfortably more than one person's work, so this is a team and the four will get divided however the people in it prefer. If you have written or edited a standard — an RFC, a working-group draft, a protocol spec somebody else successfully implemented — join it. You need the manual, which is free, and nothing else. No engine access. No licence. No export screening, because a specification isn't a controlled item. You can start the day you decide to.
Whoever writes each document ends up its editor, and the editors shape the contract everything else gets held to. The first draft of the memory contract already exists, with its clauses marked verified, implied, or undetermined — the undetermined ones (absence, ordering, authority) are decisions, not documentation, and they are the seat's first real work. Read the draft →
What makes it tractable rather than archaeological: the reasoning behind every rule is already written in the source at the point of decision — 220 named rules in one subsystem — and the build fails if a load-bearing one is removed. The specification and the implementation can be diffed by a script.
Start by reading: the build manual (the four documents get extracted from it), the doctrine index of named rules it cites, and the current licence text. People read before they write.
Genuinely undecided, today: which of the 21 book-cited rules not yet guarded by the build belong under guard; whether the rule scanner should read the shell build scripts it currently skips; and where the normative boundary sits between the specification and the manual. The editors decide these.
How a decision gets made: a change arrives as a red oracle going green — and that applies to the editor too: if the spec says the implementation is wrong, the demonstration is a test that fails on the current code.
What is genuinely hard, said out loud: the doctrine is engineering prose, not yet normative language — turning a named rule into MUST/SHOULD/MAY means deciding which parts are requirements and which are this implementation's choices. Some rules are stated but never measured, and an editor has to choose: specify, measure, or drop. And the reference implementation is closed while the specification is open — the editor is writing the document that will outrank the code. That is the attraction, and it is also the tension.
I need a lawyer in the guild.
I'd rather say so plainly than keep working around it.
Three questions are live. The reference implementation's export classification, which gates how freely it can be distributed and to whom. The FrogNet Foundation's formation and governance — a Linux Foundation-shaped 501(c)(6), with the IP assignment that makes the standard genuinely owned by its users rather than by me. And the licensing structure that has to sit correctly between a closed reference implementation, an open specification, and a commercial company.
Those are three different specialisms and it would be unusual for one practitioner to hold all three, which is the other reason this is a team. To be straight about what it is: it is not paid, it is a defined role rather than a favour, and I know informal legal advice is exposure you can't casually take on. What I'm offering is a seat at the table — Foundation counsel, a board seat, or a scoped engagement, whichever a real practitioner would actually accept. Export controls, technology transactions, or open-standards governance are the relevant backgrounds. Any one of them is enough.
Start by reading: the current licence text, the closed-engine / open-protocol plan, and how responsibility works here. The entity today is Fawcett Innovations LLC; the Foundation exists on paper as intent, not yet as filings.
What exists to work from: two governing entities (the Foundation as intended 501(c)(6), the LLC as the commercial company); three issued US patents that predate FrogNet; and a dozen-plus FrogNet inventions deliberately not filed — a decision, not an oversight, and it does not need reopening. Export screening is already identified as required, and with a CAGE code and an NSF SBIR Phase I invitation on record, the classification question is not hypothetical. The licence is free for development, personal, community, educational, research and non-commercial deployment, with a paid commercial licence from the LLC — it is not open source and no OSS licence should be named for it.
Also undecided: whether the Foundation holds the spec from formation or receives it by later assignment; how a conformance mark works — who grants it, on what evidence, whether it can be revoked — given a closed reference implementation; and what a commercial licensee is buying when the specification is free.
Genuinely undecided, today: the Foundation's exact form and jurisdiction; the mechanics of the IP assignment that makes the standard owned by its users; the licence architecture that must hold a closed reference implementation, an open specification, and a commercial company together without contradicting itself in five years; and the export classification of the reference implementation. The structure is not yet set — counsel arriving now shapes it rather than reviews it.
If you have wanted to see infrastructure done properly rather than papered over, this is that.
Fifty-six nodes. It should be fifty-nine thousand.
The book's Known Limits appendix states the most legible open problem in the system in full: the per-tunnel address allocator carries a structural ceiling of roughly 56 nodes. The allocator is quadratic, so more address space is the wrong lever — the square-root table in the appendix shows why a bigger namespace buys almost nothing. What the number is made of, why the obvious fix fails, and what a real fix has to preserve are all written down.
It is bounded — one allocator, one namespace builder, and the routes they install. It is measurable — a topology that fails today either joins cleanly under your change or it does not. If you read the square-root table and immediately wanted to argue with it, you are the person it is addressed to. The appendix →
Named openings, from the videos
The broker area — named in the broker-install video; rendezvous, tunnels, pond management. Per-client rate adaptation — named in the Communicator video; the book's § 53 is explicit that one stream and one rate is the current design and per-client adaptation is not built yet. Maintainers and testers — named across the set; you become one by doing the work. And the three above: the standard, the governance, the allocator.
Either team: the contribution questions on the licence page → — tick Standards or Governance, tell me what you've done in one line, and that's the whole application. It lands in the same place either way.
Borrowed from the kernel, because it has been tested for thirty years.
Nothing here is invented. Linux solved the problem of coordinating people who don't work for each other, and the parts of its answer that transfer are the parts worth copying.
Maintainers, not managers. The kernel has a MAINTAINERS file: a public list of who looks after what, with an address to send patches to. It is a statement of responsibility, not of rank, and nobody in it employs anybody else in it. FrogNet will keep the same list for the same reason — so a contributor knows where to send something without having to ask who is in charge.
You become one by doing the work. Kernel maintainers are not appointed at the start; a person sends good patches to a subsystem for long enough that handing them the tree is the obvious move. That is the mechanism here too. There is no application for it and no headcount on it — if two people end up sharing a subsystem because both did the work, that is a better outcome, not a conflict to resolve.
Teams self-organise inside their area. Nobody outside a working group decides how it splits its work. The standards team will divide four documents however suits the people writing them; the media-path group will decide for itself whether backpressure and transcoding are one problem or two.
The Foundation is not the technical governance. This is the distinction people most often get wrong about Linux: the Linux Foundation holds trademarks, employs a handful of people, and pays for infrastructure — it does not decide what goes in the kernel. The FrogNet Foundation is the same shape. It will steward the specification and hold the legal structure. It will not be the thing that decides whether your algorithm is better; the simulator does that.
And the part that is honestly different. Linus is a benevolent dictator and so am I, for now, and I would rather name it than dress it up. Coherence needs a keeper early. The difference is that the engine has a keeper and the protocol does not — the specification heads for an open standard under the Foundation, out of my hands on purpose. Closed engine, open protocol, and a keeper who intends to become unnecessary.
Fifty-six nodes. It should be fifty-nine thousand.
The seams above describe territory. This one is a specific open problem with the numbers already on the table — and it is the fastest way to find out whether you want to work here.
FrogNet's current release caps a pond at about fifty-six nodes. Sixteen if the broker runs more than one pond. That is lower than it should be, it comes from an allocation algorithm we believe is the wrong one, and the replacement is in development.
The cause is that carrier addresses are allocated per tunnel, and tunnels in a full mesh grow as the square of the nodes. Which makes address space a terrible lever — you buy nodes back at a square root:
| change | tunnels | nodes |
|---|---|---|
| stop wasting half of each block | 2× | 1.4× |
| use the whole reserved range | 5× | 2.2× |
| hand transit all of 10/8 | 256× | 16× |
That last row settles it. Two hundred and fifty-six times more room — every address the mesh itself lives in, which is plainly impossible — would buy sixteen times the nodes. The size of the address space is not what is wrong. Allocating anything at all per tunnel is what is wrong.
The replacement moves allocation from per tunnel to per node: one carrier address per node instead of eight per tunnel, one WireGuard interface per pond instead of two per tunnel. Consumption goes from quadratic to linear, and the ceiling becomes the one the addressing plan implies — roughly fifty-nine thousand five hundred nodes. A thousand times the current limit, not because the space got bigger, but because it stopped being spent quadratically.
What is actually open. Whether permitted address ranges narrow everywhere or only at the broker's end. Whether a node's carrier address can be shared across its interfaces without the return path becoming ambiguous. What allocation looks like per node, and what has to change in the broker's namespace to match. Those are unsettled, and the answers aren't written down anywhere yet.
It is a good shape for someone arriving new: bounded to one allocator, one namespace builder, and the routes they install; measurable, because a topology that fails on the current algorithm and passes on the replacement is an oracle; and arithmetic before it is opinion, so a proposal gets argued on merit rather than on who made it.
If you read that table and immediately wanted to argue with it, you're the person this is addressed to. Bring the argument — tick Addressing and scale on the licence page, or write to me directly at john@fawcettinnovations.com. The full derivation is Appendix K of the build manual.
A guild needs a room. Here is the room.
A messiah has followers; a journeyman has a guild. The difference is that a guild talks back — in public, on the record, where a disagreement can be settled by someone running the thing rather than by whoever spoke last. Four rooms, kept separate on purpose so the person debugging a radio link isn't wading through protocol philosophy to find their answer.
01 · The workbench
Building on it
You have a node running and you're writing something. Handlers, tuples, FrogNet Memory, what the shape of an UnREST application actually is. Working code beats a well-argued question here.
02 · The bench test
Hardware & RF
Radios, antennas, bearers, field deployments — what held up at range and what didn't. Dan lives in this one. Bring the link budget and the photo of the mast.
03 · The gate
Patches & proofs
Where "better" gets settled. Post the oracle, the topology, and the numbers; the simulator decides. Claims without a harness run get moved here and left alone until they have one.
04 · The long table
Protocol & direction
The specification, the freshness classes, the election rules, where the standard should go under the Foundation. Slower, more argumentative, and the one that outlives all of us.
One rule covers all four: bring the thing you ran. Not the thing you read, or the thing you assume. This is a room for people who own a network.
The forums open with the first public release. Until then, write to me directly — early participants get in first, and I answer everything myself.
There is no funding behind this.
No investor, no grant, no institution. The hardware was bought, the nodes were shipped, the VPS gets paid for monthly, and the books were written on time nobody paid for. If the work is worth something to you and you'd like it to keep going, there is somewhere to send a few dollars.
What it pays for is unglamorous and specific: brokers and bandwidth, radios and antennas for the range tests, boards for the people doing bring-up on platforms I don't own, and the postage to get hardware into the hands of somebody who will push it somewhere I can't. Nothing here is behind a paywall and nothing will be — the books stay free, the licence stays free, and a donation buys you no standing in the guild that running the software doesn't already give you.
It is also entirely optional, and the more valuable contribution is still a reproduction case or a topology that breaks something. If you have neither the money nor the time, take the books anyway. That was always the deal.
Goes to DisasterComm. No tiers, no perks, no subscription.
Better is demonstrated, not argued.
A falsifiable simulator ships with FrogNet, and it is not just how I validate my own work — it is the impartial ground where your claim gets tested. Pass the same oracles, run the same harness, beat the numbers. No personality contest, no maintainer's opinion, no thread.
That is what makes "I welcome contributions that can prove a better algorithm" a real offer instead of a nice sentence. There is a gate, the gate is public, and it does not care who either of us is.
Support the work
Not everyone contributes with a patch — and that's fine.
FrogNet has been built without outside money: two people, our own hardware, our own nodes, our own time. The books stay free, the developer licence stays free, and the protocol still goes to an open standard — none of that is changing. But nodes, radios, and the hosts that keep the test network running all cost real money. If the work is worth something to you and a patch isn't your contribution, a donation keeps the lights on and the radios paid for.
The engine has a keeper. The protocol does not.
Stated plainly, because a developer deciding whether to invest a year deserves to know exactly what could be taken away from them.
Closed, for now — on purpose
The engine
I hold the reference implementation and steer it, and I'll say without flinching that this is a benevolent-dictator phase. Every project that stayed coherent had a keeper early; committees build piles. One mind held this whole shape, and for now that is why it hangs together.
Open — and going further open
The protocol
The wire is headed for a versioned open standard under the FrogNet Foundation, so it ends up owned by the people who use it — not by me. The thing you'd fear losing is the thing being given away.
"This is an initial implementation. I do not claim it is the best, or even the only, way to solve any or all of the many problems that had to be solved for this to work. What I do claim is that it appears to work, and work both well and correctly. I welcome contributions that can prove a better algorithm, and I want to engage with those developers. Linux has many subsystems; so do I."
— John W. Fawcett, on the postureAnd the honest state of the work
Don't trust me — check it. The books derive it from first principles, the licence is free, the protocol is becoming a public contract, and the simulator lets you falsify me. So here is the part a brochure would leave out: FrogNet is broadly exercised in general, and thinly tested in specifics. The media path is the deep-tested exception — hardened, and on it these ideas bought roughly 9×. If one path does that, the rest is the opportunity. Hardening the specifics is precisely the work I am inviting people into, and I would rather say that now than have you find it later.
The door
One mind can hold a fabric. It takes a guild to harden one.
Take the books, take the licence, run the simulator, and find the seam that annoys you most. Then tell me I'm wrong with a patch — that is the whole invitation, and it is the only one I have.
Or write to me directly — john@fawcettinnovations.com