The questions, and the answers that keep not landing.

A connected FrogNet has one storage location for the whole tuple space and one serialization point. Other nodes hold no copy. This is the single most common misreading, and almost every other misunderstanding on this page follows from it.

A node reads and writes by address, and the address resolves to whichever node currently holds the database role. The application never names a machine, which is why it looks local. It is not local, and it is not replicated.

The question presupposes two stores. There is one.

When a network splits, each region elects its own host and each has its own store. On reunion nothing is merged, nothing is migrated, and no value travels. Values written in a region are observable there under the ordinary rules; values last written elsewhere stay observable until they age past the reader's freshness window, at which point they cease to be observable rather than becoming wrong.

There is no reconciliation pass to describe, because there is no history to replay and no second copy to reconcile against. That was the trade: give up history, and there is nothing to merge.

A write is an upsert. The later write under a description replaces the earlier one, ordered at the one serialization point every write in the network arrives at. That is the contract, not merely the current behaviour.

It is not a conflict-resolution scheme, because there are no divergent replicas to resolve. There are no vector clocks, no tombstones, no merge law per type, no causal history. A CRDT's goal is convergence — every replica provably arriving at one merged state. FrogNet's goal is operation: act now on the current value of what you can reach. FrogNet does not converge. A value is current or it is not.

The question presupposes two values. A description holds a value, never a field of candidates for something to choose between.

So there is no authority rule, no per-scope authority, and no such thing as a write made without authority. Not an unwritten rule — an absent one. Nothing arbitrates because nothing is ever presented with two answers.

FrogNet Memory is backed by a database. It is not a database. It is an addressing surface over one, and contention on a key is the database's problem — a problem databases have spent fifty years being good at.

And if a thousand writers are fighting over one value, that is a design problem no substrate fixes. If it hurts, don't do it. That is a job for a transactional database and there are good ones. FrogNet is for the enormous majority of coordination that never needed consensus and pays for it anyway.

Every node can hold the role. A node alone on a bench elects itself and serves its own memory, so the backing store is never unreachable and a read never fails with a timeout. What may be absent is the particular value you asked for, if nobody within reach has written it.

The distinction matters: the store is always present; a given tuple may not be. A read that finds nothing returns nothing, promptly, rather than blocking on a machine that isn't there.

There is no background sync, no data ferrying, no anti-entropy, no delta stream keeping stores matched. Those all describe systems with more than one copy.

The diffs you have read about are BLDC-1, which is a wire economy between two endpoints of one exchange — the reason a live picture fits over links where full payloads never did. It has nothing to do with how memory is stored, and confusing the two produces a system FrogNet is not.

FrogNet does have a gossip layer, and the build manual describes it by name. When topology changes, a node notifies its direct neighbours, they notify theirs, and the news spreads. It is bounded three ways: every wave carries an identity so a node that has seen it drops it and the epidemic terminates; a node notifies only direct neighbours, so fan-out is O(neighbours); and arrivals are debounced.

What never gossips is FrogNet Memory. Tuple values do not propagate neighbour to neighbour, because there is only one copy of them to begin with. The tell is what a wave carries: a change notification, not a value.

Every node publishes what it alone knows — cores, memory, storage class, whether it is already running a database — into a control plane at a deterministic address. Every node then runs the same scoring over the same inputs and arrives at the same winner independently. Nobody is told. Nobody votes.

The highest IP breaks a tie between candidates that score equally, and nothing else. An older edition of the whitepaper did say highest-IP, which is where the claim comes from; it has not been true for some time.

This one gets invented from scratch fairly often, presumably because it is how multiplayer game netcode works. There is no intent layer, no reconciliation engine, and no unified board being assembled from submissions.

A program writes a value. The write lands at the one store. Another program reads it. That is the whole mechanism.

REQ_HASH_LEN = 16 is the length of the identifier inside the frame, not the frame. One byte of opcode, sixteen of identifier, and the framing around them: twenty-one bytes each way, in place of a full HTTP request and a full JSON response.

On a repeated request the far end re-executes against the real origin, compares the new answer against the previous one, and replies “same” only if they are genuinely identical — with a token bound to both the request and the response content. If the data changed, the change comes back as a difference. A stale answer is not possible, which is precisely what a cache cannot promise.

It does not convert payloads to cryptographic hashes, and the saving is structural rather than statistical — which is why no compression ratio is quoted for the codec itself.

Every cross-site packet transits the tunnels it terminates. That is a stronger claim than “the broker is hard to attack,” so assume it is owned.

Three things still hold. It holds no endpoint keys, so what transits it is not addressed to it and not openable by it. It runs none of the semantic stack and forwards in the kernel, so nothing at the application layer parses or stores the payload. And it is not itself a member of any FrogNet. Owning the transit point gives you the transit point and nothing else.

Free for developers and for individual and non-commercial use — personal, hobby, educational, research. Commercial use requires a paid licence. The protocol is being published as a versioned open specification; the engine is the reference implementation and is not opened.

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

A capture yields codec frames rather than the exchange beneath them, and that is a statement about the wire, not a confidentiality claim: anyone with the templates can reconstruct what was represented.

The narrower claim is the true one and it is stronger. A conventional application publishes an endpoint, a router, a parser, an auth path, parameter handling, deserialization, and logic behind them — and the standard attack is a pipeline: find the endpoint, learn its behaviour, find the flaw, build the request, invoke the handler. FrogNet is not better at surviving that pipeline. The pipeline has no first stage.

The real threat vectors, stated 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.

Different layers, and worth keeping apart. UnREST is how an application is written — write a value where you compute it, read it where you need it. FNWP-1 is the binary framing that carries the exchanges underneath. BLDC-1 is the codec that decides the smallest honest representation. SotF is the adaptive media ladder built on top of all of it.

A tuple is located by three indices the application names to fit its problem — program/variable/user, host/globals/variable, or for sensors a name, a type and a location. The store answers on any combination: one by name, every one of a type, everything at a place.

Scope — self, lillypad, chorus, pond — is nesting and visibility. It is not the address.

Linda, from David Gelernter and Nicholas Carriero at Yale in 1985, and the site says so more than once. Linda matches arbitrary tuples by pattern and says nothing about how many fields a tuple has or what they mean; the three-coordinate convention is FrogNet's, chosen because it fits the traffic.

What is new is not the idea. It is that the constraints which made it impractical in 1985 are gone, and that it now runs wide-area, partition-prone, over bearers that drop.

L8 Bullfrog (1080p) down through Chorus, Ensemble, Duet, Solo, Voice, Whisper, Beacon, to L0 Pulse. AUDIO_CH = 1 — mono, 16 kHz, Opus. Published material listing eight rungs topping out at CHORUS predates L8.

A video rung needs a camera and only a camera, so a camera-only box still ceilings at Bullfrog and killing the audio does not lower the video ceiling.

A node inserted just below the point where a site reaches the internet puts the existing machines on the mesh with no agent on any of them. The printer, the badge reader, the controller nobody will touch — they keep their addresses, their gateway, their firmware. What changed is the box their traffic already passed through.

The per-tunnel address allocator carries a structural limit near fifty-six. That is the current number and it is documented as a contained problem with an obvious test, not as where the architecture wants to stop. The addressing plan allows far more; the fix is designed and not implemented.

Beyond that, a pond's size is bounded by its hardware — most of all the elected database host.

There is no change-notification primitive. FrogNet is not event-driven, not publish/subscribe, and not push-based. This is on the honest list of what is not built rather than described as a design choice.