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].

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 two read operations — a value by name, a set by prefix.

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 that cannot determine which node wrote a value it displays. That is not a limitation of the Monitor; it is §2e visible in a program.

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.