Johnathan Corgan
9e4b5d6a72
Carries thirteen commits up from maint: the source-comment sweep and its regression gate, and the v1 exposure remediation (key-material clearing, frame-length validation, and post-handshake identity confirmation). Ten paths conflicted. The resolutions: - Cargo.toml: kept both dependency additions, libm and zeroize. - src/control/queries.rs: took the corrected prose from maint but kept this branch's path to the relocated rx_loop module. Neither side was right alone. - src/control/read_handle.rs: took maint's corrected description of what the snapshot dispatch serves, and kept this branch's paragraph on the mutating profiling commands, which maint has never carried. - src/node/handlers/mod.rs: kept this branch's module list, widening handshake to pub(in crate::node) so the tests can name the waiver type. - src/node/dataplane/rx_loop.rs: union of the import blocks. - src/node/handlers/handshake.rs: kept the WireOutcome binding and dropped maint's possible_restart fix-up, which this branch folded away; placed the post-handshake identity confirmation above it, which keeps the confirmation ahead of the reverse-lookup repair as intended. - src/nostr/runtime.rs: took this branch's side. The function maint edits was relocated to traversal_machine.rs here and its copy already carries the same corrected text. - src/mmp/report.rs: deleted. This branch retired the module; maint's only change was removing a stale comment. - src/node/lifecycle.rs and src/peer/connection.rs: deleted, but their key-clearing work was relocated rather than dropped. The erasing guard now wraps both handshake entry points in src/peer/machine.rs and the outbound dial in src/node/lifecycle/mod.rs, since the files maint had changed no longer exist here. Without the relocation the guard type would have arrived with no callers at all. Eight further edits were forced by names that differ on this branch: the wire module path at seven sites, the connection lookup in the waiver classifier, and four test helpers the peer-machine work replaced.
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.