Johnathan Corgan
eadc3257d8
show_peers, and the peer row the tick publishes for the control socket to serve, printed a peer's connectivity from a state stored on the active peer. That state starts at connected on promotion and nothing outside the tests ever changes it, so every peer read connected for as long as it stayed in the peer map, including one that had stopped answering and was waiting out its link-dead timeout. Both render sites now derive the value from how long the peer has been silent: connected while its idle time is at or below heartbeat_interval_secs, floored at one second, and stale above it. That is the rule discovery already applies when deciding whether to re-dial an active peer on the path it already has, so the rule moves to one helper on Node that the re-dial gate and both renders call. stale was already one of the field's values, so the set of values a client can see does not grow, and the response shape is unchanged. The stored state and its other readers are left as they are. The open-discovery tutorial described reconnecting and disconnected values that never occur, and the advertise-your-node tutorial said a new peer would read active, which the field never reports. Both now describe what the field reports. The new tests insert peers last heard from at chosen times and read show_peers both on the loop and from the tick-published snapshot. Under the default 10 s interval a peer silent for 15 s reads stale and one heard from just now reads connected; with a 30 s interval a peer silent for 15 s still reads connected, so the threshold is the configured interval and not a fixed ten seconds. Both failed on the unfixed code, which reported the silent peer as connected. A third test pins the boundary: connected at exactly the interval, stale one millisecond past it, and a zero interval floored at one second. Restoring the stored read at either render site alone fails both show_peers tests on that render, making the comparison inclusive fails the boundary test, and a fixed ten-second threshold fails the configured-interval and boundary tests.
FIPS Documentation
FIPS (Free Internetworking Peering System) is a self-organizing encrypted mesh network built on Nostr identities, capable of operating over arbitrary transports — local networks, the public internet, Tor, Bluetooth, or point-to-point links — without central infrastructure.
With FIPS, your machine becomes a node in the mesh with a self-generated cryptographic identity. There are two ways to deploy it.
As an overlay on top of existing IP networks, FIPS lets your node reach any other FIPS node wherever it sits — behind a NAT, on a different ISP, on a phone over cellular, on a laptop with only Bluetooth in range, or behind a Tor onion. The mesh forwards IPv6 traffic transparently and end-to-end encrypted, with no central VPN concentrator or coordinating server.
From the ground up over raw Ethernet, WiFi, or Bluetooth, FIPS provides a complete permissionless network without any pre-existing IP infrastructure, ISP, or DNS. Any node that joins the link gets routable IPv6 addresses, peer discovery, and a path to every other node automatically.
Either way, existing networking software runs over it unchanged: SSH, HTTP servers, file transfer, anything IPv6-native works the same way it would on a local network.
New to FIPS? Start with the Getting Started guide.
Documentation Sections
Tutorials
If you are starting from scratch and want a guided path to a working mesh, go here.
How-To Guides
If you have a specific task in mind — enabling a feature, deploying a component, diagnosing a problem — go here.
Reference
If you need to look up wire formats, configuration keys, command flags, or counter inventories, go here.
Design
If you want to understand how the mesh self-organizes, why FIPS makes the choices it does, or how the pieces fit together, go here.
Releases
If you want the notes for a particular version — what changed, what broke, and what to do about it on upgrade — go here.