The FrogNet Living Network

How FrogNet works.

A value set in New York was written to the elected database in Seattle and read back by a process three feet from the writer. No cloud service was in the path and nothing was sent to the reader. The writer set a variable; the distribution was the platform's.

Current implementation: FD&F and the network path

Start above the transport.

A participant owns an addressed truth. It writes the value and holds the values it depends on. The vendor’s RAM host answers those operations. The application need not know which network route carries the session.

The semantic machinery.

The library retains semantic structure and current values so unchanged or partly changed answers need fewer bytes. That is an implementation mechanism beneath the state surface. Its benefit depends on payload structure and repetition; a changing workload has a different ratio from a mostly static blob.

The network has its own state.

Each node publishes its observations into the membership region. The world read returns participants and mappings. Every node derives the graph, places itself and applies the part it owns. The hub derives packet peers from that same present state.

The application may use another region.

The membership region is not automatically every application’s memory. A Communicator room, a vendor’s product catalog and a network’s membership can occupy separately governed regions. Their servers may be placed together, but their authority and lifetime are different contracts.

A failure changes a contract.

A lost membership session withdraws session-owned state. A failed hub removes a packet path. A replaced application memory host creates a new memory world. Identify which event occurred, then reconstruct the corresponding state instead of assuming all three are one failover mechanism.

The memory model.

Programs on a FrogNet do not exchange messages. A producer writes a value where it computes one; a consumer reads it where it needs one. Neither knows who the other is, where it is, or whether it is running. Producer and consumer lifetimes are independent.

Coherence is structural, not a protocol

There is one database per network, so there is one serialization point, so there is one order. Nobody writes a coherence protocol for a single-socket machine’s DRAM either — the memory controller is the coherence. Across an internet, the elected database host is.

Which is why there is nothing to reconcile. No replicas, no merge law, no vector clocks, no eventual consistency. Last write wins, because that is what a write is.

The address is yours

A value is located by three coordinates you name to fit your problem — program/variable/user, host/globals/variable, sensor/type/location. The store answers on any combination: one by name, every one of a type, everything at a place.

What happens when the link drops — and why it needs no copies

This is the point at which almost every reader concludes there must be replication, because the reasoning looks airtight: both sides keep working after a split, therefore both sides must have had the data. That inference is wrong, and the alternative is simpler than replication rather than more complicated.

When a pond splits, each fragment elects a machine to hold its memory and carries on. Neither side received a copy of the other’s values, because there was never more than one copy to send. What each side has is what it can still reach — and a value written on the far side is not stale, not conflicting, and not wrong. It is absent. A read for it returns nothing, which is a result a program can act on.

Nothing merges on rejoin, for the same reason. There are no two versions to reconcile, no timestamps to arbitrate, no rule about which site wins. The two fragments become one pond, one machine is elected to hold its memory, and every participant re-states what it currently is. Work done during the split is not replayed and writes made where the store was unreachable did not queue — they never happened.

That is the whole of it, and it is why there is no conflict-resolution algorithm to describe: there is never a second value to resolve against. The cost is real and stated plainly — you lose what the other side did while you were apart. The system does not pretend otherwise, and does not invent an answer about data whose meaning it does not hold.

What FrogNet does not pretend to give you

No consensus. No transaction across two values. No history. If your problem genuinely needs an order across several values, elect for order and route the decision through the elected role — do not ask the shared picture to pretend it is one.

The normative version, clause by clause →

The 21-byte exchange.

When nothing has changed, a request and its answer cost twenty-one bytes each way, in place of a full HTTP request and a full JSON response. The payload is not sent, because both ends already hold it.

4 bytes the protocol magic 1 byte the opcode — repeat, diff, full, same 16 bytes the identifier, binding this exchange to a request and an answer both ends hold ———————— 21 bytes out. 21 bytes back.

This is not entropy coding, and compression ratios are the wrong measure. Most network traffic is repetition — status polls, sensor readings, health checks, dashboards refreshing — and repetition can be named instead of transmitted.

The answer is verified, not assumed

On a repeat the far end re-executes the request against the real origin, compares the new answer to the last one, and replies “same” only if they are genuinely identical. A stale answer is not possible, which is exactly what a cache cannot promise.

The wire format and opcode table →

Attack surface.

FrogNet programs do not call each other, so a node exposes no application endpoint to the internet. There is no hosted service, no escrow, and no account held by anyone else; the mesh is between your machines and the machines you federate with.

FrogNet implements no cryptography of its own. Traffic crossing the public internet crosses a WireGuard bearer, and that is the confidentiality — standard, audited, not ours. What FrogNet contributes is surface reduction, which is a different property and is stated as reduction rather than guarantee.

The real exposure, named rather than omitted: host access, wireless admission, WireGuard credentials, an authorised node that has been taken, the broker, local privilege boundaries, supply chain, and bugs in FrogNet itself.

Trust boundaries, normatively →

Further reading.

Three routes, depending on what you need.

The specification → The build manual → Download →

Also: how it compares to CRDTs, mesh VPNs, brokers and classical DSM, and the simulator, which runs the real discovery and election code against a modelled topology because none of that code asks where anything came from.