Johnathan Corgan
b285c83538
Carries the v0.5.3 maint batch and the master-only portable_atomic change up to next. The link and session rekey fixes from maint are written against the IK link handshake and the XK session handshake; next runs XX on both, so each was adapted or left out as follows. Previous-session link frames kept out of MMP: adapted. Both decrypt paths in the encrypted-frame handler report which session authenticated the frame, and a previous-session frame is not counted by the MMP receiver and a ReceiverReport it carries is dropped. Next has no spin bit, so that part of the change has nothing to gate. Next's initiator msg3 confirm on the same paths is left as it was. The node tests are rebuilt on next's three-message rekey: the initiator reads msg2, its msg3 is held back from the responder, and it cuts over on its own tick. Resend of a lost link rekey msg2, the per-peer record of answered msg1s, and answering msg1 on the established link: not carried. All three depend on the IK responder installing its new session when it answers msg1 and holding it until adopted. Under XX msg1 carries no identity, so the responder cannot tie a msg1 to a peer, holds nothing until an authenticated msg3 declares the rekey, and answers a duplicate msg1 from the same address with its stored msg2. A replayed msg1 cannot be carried to a msg3, since that needs the initiator's ephemeral key. The msg2 has to go to the msg1's source because the peer is not known yet. The FMP core, peer and handshake-handler changes and their tests are dropped, along with their changelog entries. Forged session msg3 and setup: the setup hold is carried. A setup naming an established peer while a handshake that peer armed awaits its msg3 is dropped and counted as rekey_held, and the dual-initiation tie-break now runs only for a handshake this node initiated, with the retry and tie-break tests updated to match. The rolling-back msg3 read targets the XK read, which next does not have; next's XX msg3 arms are left as they were here and get their own change.
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.