Johnathan Corgan
8f2565e437
The arming check tested whether a dampening deadline had ever been set rather than whether one was still in effect, so the first episode disarmed the mechanism permanently. A node in a second flap storm went on switching parents under hold-down alone, and neither the flap_dampened counter nor the "Flap dampening engaged" warning fired again, so the storm was invisible to anyone watching that counter. Retire a lapsed episode explicitly, clearing both the deadline and the switch counter, so a second episode requires a fresh threshold of switches within one window rather than re-engaging on the first switch after lapse. Hold-down was unaffected throughout and continued to limit discretionary switching, which is why the practical effect at shipped settings was lost visibility and a lost escalation tier rather than unrestrained flapping. An episode engaged through the parent-ancestry update path now reports the counter and the warning as the other switch paths already did. One path remains silent, a re-engagement during parent-loss recovery, which runs inside the tree state where no metrics handle is reachable. Also cap node.tree.flap_dampening_secs at one year, so a value large enough to overflow the monotonic clock no longer panics the node when dampening engages. Report flap dampening engagement from every path that engages it One re-engagement path stayed silent, during parent-loss recovery, because it runs inside the tree state where no metrics handle is reachable. Return the fact of engagement to the caller that does have one, so every path that engages dampening reports the counter and the warning rather than most of them. Report dampening engagement without moving a published signature The observability change altered the return type of a published library function on the maintenance line, which would break a downstream caller at a patch release. Restore the signature and record the one path that stays silent as a known gap, which is what the design called for.
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.