Implementation considerations.

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

1. Reference platform

Croakus: §5, §38, §58

The reference implementation targets 64-bit Debian Bookworm (§3.1). Nothing in §§1–17 depends on that choice; it is what has been built and run, not a requirement on a conforming implementation.

2. Bearers

TCP is the reference bearer for FNWP-1. WireGuard tunnels, Wi-Fi and unlicensed radio are interchangeable bearers beneath it, and the fabric above does not change by a line when one is substituted for another (§12.5).

That interchangeability is a design requirement rather than an observation: an implementation MUST NOT make any layer above the bearer aware of which bearer is in use. The one place bearer identity legitimately enters is per-hop rate measurement (§11.5) and per-edge latency calibration (§16.5), both of which measure the link rather than branch on its type.

A bearer that reorders or drops is outside what has been established. Loss and jitter are not modelled (§16.7), and no conformance claim covers them.

3. Registries

The FNWP-1 magic value, the opcode assignments, and the three-coordinate address convention are defined by this specification. No IANA registry is requested while the protocol is Experimental, and an implementation MUST NOT claim a registered assignment it does not hold.

Two naming facts that recur as errors and are stated here once. The wire constant is the ASCII literal FNW1; the protocol is FNWP-1, the FrogNet Wire Protocol, and material naming the protocol by the wire constant is using an obsolete name (§1.3, §11.3). BLDC-1 is the Bullfrog Long Distance Communications Protocol and SotF is the Song of the Frogs Adaptive Communications Protocol; the three are distinct layers and MUST NOT be used interchangeably.

4. Regulatory

Operation on amateur radio allocations is excluded where encryption or commercial content is prohibited. The exclusion is a property of the allocation, not of FrogNet: since FrogNet implements no cryptography of its own (§12.1), an operator on such an allocation is choosing a plaintext bearer, and §12.7 states what that leaves exposed.

FrogNet is free software under the GNU General Public License, version 3 or, at your option, any later version. This is settled. Material published before this date states otherwise — including an earlier Apache 2.0 statement and, before that, a request-a-licence model. Both are superseded.

Nothing in this specification requires registration, approval, attestation, or a form, and an implementation MUST NOT state or imply that it does. The one condition is copyleft: a work derived from the reference implementation and distributed to others carries the GPL with it. That is a condition on distributing a derivative — conveying the software, or a work based on it, to another party. It is not a condition on using FrogNet, running it in production at any scale, modifying it for internal use, or implementing this specification independently — an independent implementation written from this document is a separate work and carries whatever licence its author chooses.

It is published as open-source software from the United States. Export-control, sanctions and other laws may apply to particular users, destinations, uses or redistributions, and obtaining or using it makes the obtainer responsible for the laws applicable to them. Nothing in this specification is a representation that FrogNet has received a commodity classification, export licence, jurisdiction determination or other government ruling, and an implementation MUST NOT state or imply one.

5. Falsification

The standing challenges are maintained with the public repository, each with an oracle definition. Three are named here because they are the claims most worth attacking:

Challenge	Against
Broker pivot	§7.7, §12.6 — that an owned broker, which sees the inter-site path in plaintext, still cannot mint a SAME tag a member will accept, and cannot read a diff against a template it never observed being learned
Application recovery	§6, §13 — that re-assertion re-establishes state without a merge or a replay
Credential manufacture	§12.2 — that the SAME identifier cannot be forged without the secret

A challenge is only a challenge where it can fail. Each MUST carry an oracle whose failure mode is demonstrable, on the same standard as §16.3: an oracle never observed failing has not been shown to test anything.

6. Doctrine tags

Requirements throughout this document cite tags of the form [NAME_V1]. These are markers in the source, not identifiers in a registry, and they exist so a requirement can be traced to the code that enforces it and to the defect that established it.

Two obligations follow. A cited tag MUST exist in source — a specification citing a tag the tree does not contain is asserting provenance it does not have. And a tag comment describes intent, not necessarily behaviour: where a comment and the code below it disagree, the code is the better evidence of what the implementation does and the comment is a defect. This is a rule about reading source, not about the standing of this document (§18.8). This specification records at least one case in which a comment described a flush that had no caller for weeks (§4.4.2), and one in which a comment described a reachability probe the same function had removed (§13.2.1).

7. Deployment cautions

Stated because each has cost real time and none is discoverable from the specification alone.

Configuration edits must land where the server reads them. Where the enabled-site directory holds real files rather than links, an edit to the available copy alone does nothing.

Stale bytecode wins. Extraction restores sources with their original modification times, so a compiled artifact from a prior build can be newer and be used in preference. Purge at install and at every merge (§3.5.3, §4a.6).

A build tarball MUST NOT carry node identity, tunnel keys, certificates, or credentials. A release gate MUST scan exactly the files injected rather than walking the tree, and MUST fail the build rather than warning.

Generated documents MUST be edited at their generator. Editing generated output is lost at the next build, and a specification that quotes a hand-edited generated document quotes something that will not survive.

8. Where the deeper treatment is

This specification states what a conforming implementation must do. The build manual states how the reference implementation does it and why alternatives were rejected; Internals carries mechanism notes; the simulator and the demonstrations carry the evidence.

This document is normative. The reference implementation is one implementation expected to conform to it. Where they disagree, one of two things is true and they are not the same thing:

Situation	Resolution
The specification describes behaviour the designers did not intend	A defect in this document. Issue an erratum and revise; the revision becomes normative.
The implementation departs from what this document requires	A defect in the implementation, whatever this document's provenance.

During drafting the source is the best available evidence of intent, and every requirement here was checked against it. That makes source the arbiter of fact while drafting; it does not make source the arbiter of requirement once published. A specification that defers to code forever cannot be implemented from without consulting that code, which defeats the purpose of publishing it.

9. References

Specification §1, §3, §7, §11, §12, §16, §17. Build manual: Croakus §5, §38, §58, Appendix L (Doctrine Index). Licence and export posture: download.