Johnathan Corgan
b549551828
A session setup message naming an already-established peer replaced that peer's session whenever node.rekey.enabled was false: the handler ran a fresh responder handshake and overwrote the entry, discarding the live keys. The message carries no authenticator and its source address is an envelope field, so anyone able to reach a node could name an established peer, take that session down, and hold it down by repeating the message. The established case now always arms the handshake alongside the running session and adopts the new keys only after a msg3 whose authenticated static key matches the key the session was opened with, which is the check the rekey path already applied. A peer that genuinely restarted still re-establishes, and a forged setup leaves the session carrying traffic. This changes no wire format and adds no configuration: a node with rekey disabled already answered such a message, it simply destroyed the session afterwards. Two adjacent gates come off the same flag. The drain sweep and the cut-over that retires an old key epoch now run whether or not periodic rekey is enabled, since a node with rekey disabled that adopted new keys otherwise held the superseded ones for the life of the session. And a rekey armed by a peer's setup message is now abandoned if the matching msg3 never arrives, rather than persisting for the life of the session; a stuck one made the node treat a later genuine setup message as a simultaneous initiation and drop it, which would have turned the fix above into a lasting block on re-establishment for roughly half of peer pairs. Count the forged setups refused and the rekey state abandoned Refusing to replace an established session, and expiring rekey state a peer armed and never completed, were both silent. Neither an operator nor the status pane could see a node being held under a stream of forged setup messages. Count both, and record the refusal through the existing typed rejection machinery rather than a new surface. Expire an abandoned handshake without discarding a completed epoch The responder-side expiry treated a pending session as stale rekey state and dropped it. But a responder-side pending exists only because a msg3 carrying the session's authenticated peer key was accepted, and the peer promotes that epoch on a timer gated on nothing the responder does. So the keys being dropped are not material the peer abandoned; they are the epoch the peer has already moved to, after which its frames are undecryptable and the reverse direction stays dead across repeated rekey attempts. The defect the expiry was closing lives in the armed-handshake state, not in the pending keys: a stuck one makes a later genuine setup message read as a simultaneous initiation and be dropped. So bound the veto rather than the keys. Only the armed handshake expires now, and it does so without clearing a completed pending beside it.
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.