fr34akyandJohnathan Corgan
10b4e6ea60
The reaction dropped every peer's connected socket and heartbeated every connectionless peer, whatever the change actually named. That was defensible while the fingerprint was host-wide and could not say which peering had moved. Keying it on peers removed that excuse, and introduced a reason to care. `probe_target` is the observed source address of the last authentic packet a peer sent, updated with no throttle. So the trigger is now within reach of a remote party for the first time: a peer alternating between two of its own addresses that leave this host by different interfaces moves the fingerprint at will. Node-wide, that one peer could drive every other peering's socket teardown and heartbeat, repeatedly, bounded only by the poll interval — up to `max_peers` drain threads torn down and respawned per period. Scoped, the only peer in the set is the roamer itself, whose connected socket the data plane has already cleared on the address change. The lever closes by construction rather than by a rate limit. Nothing is left stranded by the narrowing. A peer absent from the set is one whose local source address the kernel still resolves to the same place, and that is the entire content of the fingerprint: a peer that did not move is a peer whose socket is not stale. To be clear about what this was worth: nothing black-holed before it. The sockets reinstall on a later tick and sends continue over the wildcard socket meanwhile, so the cost was internal teardown and respawn work rather than an outage. It is done here because this change is what created the lever, not because it was urgent. The test holds two peers, moves one, and asserts the other keeps both its socket and its heartbeat timestamp. The medium-change lab still passes 17/17, which is the end-to-end check that the peer whose route really did move is still in the set and still repaired.
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.