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.

1a. The thesis, and what it maps onto

Stop building a distributed system out of computers. Build a computer out of a distributed system.

The conventional model is independent computers plus the machinery that makes them behave collectively: endpoints, protocols, synchronisation, retries, coordination. This specification describes the inversion — the distributed collection is the machine, and a program uses the abstractions that machine supplies rather than programming the relationships between its parts.

Read literally, that gives every component in this document a counterpart in ordinary computer architecture. The correspondence is not decoration; it is why the rest of the specification takes the shape it does.

The correspondence extends to how the machine is measured. A conventional computer is asked how fast its processor executes instructions. A FrogNet is not usefully asked that: its nodes already execute independently and concurrently, and adding one adds computation rather than adding a client. What the parts share is memory, so the machine-level question is how many shared-memory operations the machine services per second — not how fast any node runs (§14.1a).

That reframes what a large elected host is. It is not a big server the others depend on; it is a more capable memory subsystem fitted to the machine (§17.3). And it reframes the transport mechanisms: persistent sockets, SAME/DIFF, semantic compression and duplicate-work collapse are not networking optimisations bolted on, they are what keeps the memory subsystem from being the part that limits the machine.

The correspondence is a reading aid, not a conformance claim. It breaks in the places this specification names — there is no cache coherence protocol because there is nothing to make coherent (§2a), no notification when a value changes (§17.2), and the interconnect can partition, which a backplane cannot (§6). Where the analogy and a normative statement disagree, the normative statement governs.

2. Conformance

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.

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

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.

Programming-model note. FrogNet applications should not normally recreate client/server relationships above Memory. A producer publishes what it knows without identifying a consumer; a consumer reads the state it needs without identifying a producer. If an application is primarily constructing requests, replies, subscriptions, acknowledgements, retries, or recipient lists on top of tuples, it has recreated the programming model FrogNet Memory is intended to replace (§10.3b).

Conceptually the surface is:

/* the shape of the surface, not its signatures.
   The implemented operations are put / get / get_all — see §10.3 */

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

The third is listed so that no reader goes looking for the call, and named that way deliberately: it is not an unfinished FrogNet operation. Observing change is application policy and does not belong in the fabric (§10.3a) — a substrate that knew which changes mattered to which program would have those programs’ semantics inside it. There is no notification when a value changes, anywhere in FrogNet (§9.4, §17.2); how a program observes change is its own choice (§10.3a). A callback on role reassignment is a different mechanism, belongs to the UnREST service definition, and does exist (§10.7). 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.