Current implementation: FD&F and the network path
Local operation.
A LAN-only FrogNet uses its local discovery and merge path. It can discover members, establish routes and select eligible service hosts without Internet access. Ordinary Ethernet, Wi-Fi and radio bearers supply connectivity; the same application state model sits above them.
A local lillypad is not necessarily the whole pond. It may become part of several scoped networks. Preserve the distinction between a local served LAN and the scopes in which that LAN participates.
Region operation.
In region mode, fdf-facts and fdf-client publish the node’s own state. FD&F owns discovery. The graph and daemon own route decisions and application; the old recursive crawl does not run for region membership.
The published state includes addresses, lease pairs, uplink observations, region tunnel facts, capabilities and generation. A generation changes only for a change that matters to the network plan. Others read it through the region.
Change is an input, not a reason to restart the world.
The region watch delivers membership, facts and mapping changes. One world read and one kernel WireGuard snapshot feed each event. The daemon replans and applies locally. It does not launch runMerge for each region event; runMerge remains on boot and interface changes.
r19-a15 makes both hosts-file writers use the same leaf-naming facts. Before that correction, a later runMerge could erase the PC or phone’s name even though the device remained a member.
Loss and reconstruction.
A clean session close is observed quickly. Silent death depends on TCP liveness settings and the path. The newer five-second keepalive configuration measured roughly four seconds in a namespace experiment, with more false deaths under higher packet loss. That tradeoff is not a universal convergence bound.
Transient application RAM and FD&F’s membership manager are different services. A new application RAM host means an application-world change and reconstruction. A restarted region manager ends and recreates member sessions. Read the failure contracts.
The broker transition.
The October 11 tree still contains broker-era code and installer dependencies. FD&F already drives region membership and hub routing. The October 12 cleanup proposes removing the broker and fixing fresh-install, key-generation and packaging dependencies; it is not a completed release in the evidence reviewed here.
Use the implemented baseline when deciding which commands or operational promises apply.