Reference applications.

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

1. Standing

Croakus: §41, §41c, §42, §45, §46

The applications in this section are normative only in one sense: a conforming implementation of §§1–14 is sufficient to support them. They are not part of the conformance surface, and an implementation MUST NOT be judged by whether it ships them.

What they are for is evidence. Each demonstrates a property of the model that is otherwise only asserted, and each is small enough to read.

2. The Communicator

Video, audio, chat and file transfer between member nodes, with no TURN server, no cloud service, and no infrastructure beyond the pond — and, across sites, a broker (§7). It exercises discovery, election, FrogNet Memory, FNWP-1 and BLDC-1, and the media ladder, which is what makes it the reference application rather than a demonstration: it is the smallest program that touches every layer.

Reference measurements, with their conditions:

1280x720 at 22 fps, ~850 Kbps
    Seattle to New York, 900 MHz bearer

starvation on camera: 987 -> 637 -> 450 Kbps
    picture thins, audio holds, climbs back without a redial

ladder floor demonstrated: 164 Kbps at 160x120

held under 150 Kbps
    read off diagnostics on camera, not an instrument log —
    published as a bound, not a point figure (§14.6)

2.1 What the Communicator proves about the model

Its state is the worked example of §10.6.1: a fact belongs to whoever can know it. One row per session carrying a members list, written by whichever participant wrote last, meant one node renewed other people's membership and a departing member was reinstated by somebody else's heartbeat. No care on the leaver's side could fix that, because the row was not the leaver's to write. Separate rows replaced it, each written by the single party with standing to know the fact [FOUR_TUPLES_V1]. There are now five, and the tag keeps its original name:

Scope follows standing: host rows by host, user rows by name, call rows by id. Identity is the name. No per-launch identifier and no display marker may reach a key, or the same party writes a new row every time it starts.

A related requirement falls out of the same defect: a row MUST declare only the fields it actually offers. One shape carrying both a host field and a user field meant every host-scoped row declared a user it never supplied and every user-scoped row declared a host it never supplied, and each converged to nothing. The source records this as the third time that shape has bitten and the first time a test caught it.

Call state is scoped per session (§10.3), with separate scopes per concern — the session envelope, chat, links, per-viewer treatment, transcript lines — rather than one row per call. One convergence channel per concern is what lets each hold its own reference and freshness.

2.2 Two planes

The session envelope is an ordinary exchange: it reaches SAME against a learned template and collapses to the floor frame when nothing moves (§11). The media frames carry opaque payloads, never reach SAME, and are sent in full every time. An implementation MUST NOT run media frames through the semantic path expecting a saving; the saving there is the ladder, not the codec (§14.1).

3. The Monitor

A read-only display of pond state, and the cleanest demonstration of the consumer half of §10. It writes nothing, holds no state outliving a keystroke, and uses only the read operations — a variable across scopes, and every variable for a service (§10.3).

The property worth noticing is what it cannot do: each node publishes its own state under its own name (§8), and the Monitor is an ordinary reader and does not know a value was written for it. It cannot ask a node for its state; it reads what nodes published for their own reasons, and a value it displays would have been written whether the Monitor existed or not. That is §2e visible in a program.

Membership arrives and departs without an event. A node joining the network is not announced to the Monitor and a node leaving is not either. A value exists that did not before, or values stop being refreshed and age out (§2e). The Monitor renders arrival and departure with no membership service, no subscription, no registration step and no membership code — which is §10.4 in a running program: the category of code is absent, not delegated.

Provenance is available and is not the same thing. Every row carries the writing node’s own address as envelope information — SensorAddress, surfaced as addr (§9.2.1) — so a reader can report who reported a value. What it cannot do is make that node produce one.

It doubles as an end-to-end liveness check. A rendered display implies the local proxy, the local daemon, the elected database host, and the remote publishers all functioned; a blank column localises a failure to a layer. An independent reader written against the same two calls SHOULD agree with it, and disagreement indicates a defect in one of them.

4. The games

A shared board-game engine demonstrating governed shared state. Three rules, all normative for anyone building on this model (§10.6.4):

a participant writes ONLY its own object
    a player states intent in a value that is theirs; it never
    writes the board and never writes another player's object

the governor is the one writer of record
    it owns the dice, the turn gate, the seating and legality,
    and IGNORES any value it is not allowed to write — so a
    player cannot fake a roll or seat itself by writing memory

a reader that never writes is a spectator, for free
    watching is not a feature added to a game; it is the
    absence of a seat

Hold those and a multiplayer game is reads and writes of a shared board. Let go of either of the first two and what has been rebuilt is a request/response server with extra steps.

The minimal case is the smallest worked handler; a heavier rulebook exercises the same machinery under load. The games are intentionally incomplete. They exist to show the handler shape rather than to be finished products, and in the delivered build they may not launch as they stand. An implementation MUST NOT treat their state as an indication of the model's.

5. What a reference application is not

None of these is a product, a supported deliverable, or a conformance test (§16). None is required for a node to function. An implementation that supports §§1–14 and ships none of them is conforming; an implementation that ships all of them and violates an invariant in §2 is not.

6. References

Specification §2, §8, §9, §10.6, §11, §14, §16, §17. Source: etc/frognet_bundles/communicator/, etc/frognet_bundles/boardgame/, core/game_role.py, core/game_origin.py. Build manual: Croakus §42, §43, §44, §45, §52. Worked code: UnREST by example. Demonstrations: on camera.