Scope and terminology.

FrogNet Specification — Draft 0.9, revision 2026-08-29. Cite a conformance claim against this revision, not against a section number alone.

1. Scope

This specification defines the FrogNet Living Network: a self-forming, self-healing mesh network that replaces the HTTP substrate with a stateful system optimised for network shared memory. It states what a conforming implementation MUST do. It does not argue for the design; the reasoning lives in the build manual, and each section names the chapter it derives from.

The specification covers five separable bodies of work, in dependency order: network formation (§4, §6), overlay and span (§5, §7), role election (§8), a stateful substrate in place of HTTP (§10, §11), and network shared memory (§9). The fifth is the purpose of the other four. An implementation MAY conform to a subset, and MUST state which sections it claims.

2. Conformance

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in RFC 2119.

These key words are normative only where they appear in capitals. Where this document describes behaviour without them, it is describing the reference implementation, not constraining a conforming one.

A claim of conformance MUST name the sections claimed and MUST be accompanied by evidence produced from the implementation's own output, not from description. §16 states the evidentiary standard: a component counts as exercised only where its registered log marker appears in the run's own log, and every oracle MUST be paired with a control that forces it to fail.

3. Terminology

Croakus: §1, §1a

Term	Definition	Defined in
node	A host running the FrogNet stack. A node is a whole network alone; membership widens what it can see and changes nothing about how it is programmed.	§3
pond	A set of nodes sharing one membership, one topology view, and one authoritative FrogNet Memory store. A pond is not declared; it is the current set of nodes that can reach each other, recomputed whenever reality changes.	§6
control host	The node holding the coordination plane — capability, presence, the services table. Selected deterministically as the highest node address, not elected. Distinct from the database host.	§8.1a
chorus	A synthetic infrastructure address plane. Not a tuple scope and not walked as a discovery target.	§4.2
scope	The third tuple coordinate, qualifying a variable name. Constructed, not free-form: host, node, role or session (§10.3).	§10.3
broker	A rendezvous node carrying the inter-site data path. It holds no node identity and no pond secret, runs none of the semantic stack, forwards in the kernel, and is not a member of any pond.	§7
database host	The elected node holding the authoritative store, reachable as databasehost.frognet. Elected on capability, not by address.	§8
SotF	Song of the Frogs Adaptive Communications Protocol. The media plane of the Communicator: a nine-rung ladder that trades fidelity for continuity as the link tightens. Distinct from FNWP-1 and BLDC-1, which carry the control plane beneath it.	§15
media relay	SotF's relay: forwards one media stream and bounds the call rate to the slowest participant. Distinct from the broker, which is the WireGuard rendezvous; the two MUST NOT be conflated.	§15
tuple	A value addressed by three caller-chosen coordinates. The store imposes no schema; a key exists when it is first written.	§9.2
FrogNet Memory	The network-wide addressable store. One store per connected pond, backed by a database. It is not a database.	§9
UnREST	The memory-first application programming model over FrogNet Memory.	§10
handler	An object conforming to one interface with a small number of virtual slots, through which every exchange is processed. A handler naming a ROLE_NAME participates in election; one naming none is a content handler.	§10.7
FNWP-1	FrogNet Wire Protocol. The binary framing: length-prefixed, opcode- and sequence-tagged frames on an established socket. The wire constant is the ASCII literal FNW1; the protocol name is FNWP-1 and the two MUST NOT be confused.	§11
BLDC-1	Bullfrog Long Distance Communications Protocol. Semantic compression by far-end re-execution and comparison. Not a cache: it re-executes against the origin and reports identity, and never answers from a stored copy.	§11
transport	Any bearer capable of carrying FNWP-1 frames. TCP is the reference bearer.	§11
hostReset	A no-argument verb any object in any process MAY answer to, meaning re-state what you are into wherever the coordination plane now lives. Not confined to handlers and not a class hierarchy.	§6.6

4. The model this specification assumes

Croakus: §1a

There is no client and no server. A program does not fetch a value from somewhere; it reads a value that is present, and writes values that then are. The question a distributed program normally asks — which service do I call, and what if it does not answer — is replaced by what is the current value, which has no failure mode of its own.

Conceptually the surface is:

/* the shape of the surface, not its signatures */

  memset(tuple, value)      write what you know
  value = memget(tuple)     read what is currently true
  memwatch(tuple)           be told when it changes     NOT IMPLEMENTED

The third does not exist and is listed here so that no reader goes looking for the call. There is no notification when a value changes, anywhere in FrogNet (§9.4, §17.2); a program requiring timely observation MUST poll. Topology change is separate and does propagate, as a notification that something changed and never as a value (§4a.5, §11.13). The implemented calls are put(), get() and get_all() (§10.3).

FrogNet Memory defines the distributed memory model; applications define behaviour. Where a value lives, how it travels, and what happens when two writers arrive at once belong to the memory model once, rather than to every application in turn. What a value means belongs to the application. That division is normative: an implementation MUST NOT require an application to supply any part of the first, and MUST NOT interpret any part of the second.

5. Document conventions

Each section names its derivation in the build manual on a cross-reference line beneath its heading. Where a normative statement rests on a value in source, that value is cited with its file. Where a section is not yet complete, an explicit PENDING SOURCE block states what is missing rather than supplying a plausible figure; an unmarked absence is a defect in this document, not a permitted implementation choice.

Two named errors recur in readings of this specification and are corrected here once. First, nothing is copied: there are no replicas, no deltas, no anti-entropy, and no merge (§2). Second, gossip carries topology, never memory: a gossip wave carries a change notification, never a value (§4).

6. References

Normative: all sections of this specification. Informative: the build manual (Magnum Croakus), Internals, UnREST by example, and the simulator. Lineage: Gelernter and Carriero, Linda tuple spaces, Yale, 1985; the three-coordinate key is FrogNet's indexing convention, not Linda's.