Johnathan Corgan
19d8537e97
Three changes to FSP session handling. Five sites discarded a completed key epoch when only a handshake had failed. Four are the failure paths in the rekey msg3 responder arm; the fifth is the dual-initiation yield arm in the setup handler, which is gated on a rekey being in progress rather than on us having initiated it, so a peer-armed entry holding a completed epoch reaches it. All five now abandon only the handshake. Reachable in two unauthenticated messages once a completed epoch has waited out a full idle timeout. The four remaining sites in the ack initiator arm are left alone, and the reason is recorded at the site: an entry with the initiator flag set holds no pending session, so the two calls are the same action there. A forged ack of valid length destroyed an in-flight initiation, because the handler removed the entry before it knew the message was genuine. The entry is now put back. Reinserting alone is not enough: reading msg2 mixes the sender ephemeral into the symmetric state before authenticating it, so the kept handshake could never read the genuine msg2 afterwards and re-initiation was blocked until timeout. A wrapper restores the exact state the read writes when it fails. That mirror is maintained by hand and says so. The setup path passed no rate limiter, so forged msg1 naming distinct addresses inserted half-open entries without bound. It is now metered on the authenticated link peer the datagram arrived over, not the sender chosen address, which varying the address would defeat. Setups naming an already-established peer get their own budget, so a flood behind one link cannot silently suppress rekey for everything else behind it. A refused setup sends nothing, which also bounds the ack amplification. Green: fmt, build, clippy and test --lib, 1535 passed.
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.