Johnathan Corgan
5a79d3fc5e
Brings up the two release lines' work: the maint harness and guard fixes, the documentation corrections, master's probe, onion and epoch fixes, and both rebuilt changelog blocks. Three conflicts. The readme conflicted on the badge pair. Resolved by taking the Rust badge that no longer asserts a version, since rust-toolchain.toml is the only place that states one, and keeping this line's own v0.6.0-dev status badge. The peer machine conflicted, and the resolution is an adaptation rather than a pick. Master deleted PeerMachine.remote_epoch on the grounds that nothing read it, and that reasoning had to be re-derived here because this line's machine is the XX rewrite and shares almost no text with it. It holds. The shadow's only production write is inbound_msg3, which is where XX crystallizes identity, so it is inbound-only exactly as the msg1 write was on the other lines; conn carries the same value written from both legs, complete_handshake on the outbound one and complete_handshake_msg3 on the inbound; the only read is the cutover action payload, whose executor arm binds nothing; and the live consumer reads conn_remote_epoch. So an initiator cutover, which runs on an outbound machine, carried a zeroed epoch here too. One thing differs and needed handling. This line has an `established` constructor the others do not, and it writes the shadow and conn from the same argument, which would have made the field direction-correct. Its only caller is in the test module and its own doc comment calls the machine inert, so it is a seam that is not wired yet rather than a production path, and it does not rescue the field. Its assignment goes with the rest; the parameter stays, because conn still needs the value. The adaptation is folded into this merge rather than left to a follow-on, because master's half of the same change reached peer_actions.rs through a clean auto-merge. Keeping this line's field while accepting that auto-merge would have left the machine emitting a payload field the executor no longer has, which is a break that only the test build shows. The changelog conflicted because both lines had rebuilt their unreleased block. The Breaking section stays at the top untouched; Unreleased now holds the ten entries that are this line's own; and the other two lines' work sits below under 0.5.0 and 0.4.2 headings, neither dated, matching how master already carries 0.4.2. Four entries existed on both sides in branch-adapted form and were merged rather than picked, so each keeps the rework's wording and this line's accuracy: the OpenWrt entry drops its IK reference, the msg1 classifier keeps the promotion-state paragraph, the SessionAck entry keeps the two XX-only exits, and the msg3 epoch entry counts six sites here against master's five.
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.