Johnathan Corgan
472665ba2f
The established-link msg1 metering is re-authored against this line's handshake handler rather than taken from the merge. The two versions of src/node/handlers/handshake.rs differ by roughly 1437 lines from the earlier decomposition, so the conflict hunks spanned whole divergent bodies, including this line's restructured dual-initiation handling, and resolving them hunk by hunk would have spliced the two structures together. The file was taken from this line and the change re-applied by hand; the resulting diff against the pre-merge tip is the metering change and nothing else. The rate limiter itself needed no adaptation: src/node/rate_limit.rs was byte-identical on both lines, so the guard, the second bucket and the derivation merged in unchanged. Eighteen explicit pending-slot releases in handle_msg1 are replaced by a single guard held for the function's scope. Every one of the eighteen either preceded a return or ended a match arm, and the success path released at the end of the function, so the guard is behaviour-equivalent. One ordering difference: the slot is now released at function exit rather than immediately before each arm's reject-stat bump. Nothing outside the handler reads the pending count between those two points, so it is unobservable in tree, but it is an ordering change rather than a pure refactor. Four tests are ported from the other line, one with its wire-module import path adjusted for this line's layout. Known coverage gap: no test distinguishes the guard being held from the guard being released at acquire time. Rebinding `_slot` to a bare `_` leaves the whole suite green and draws no clippy warning, so the invariant rests on the binding name. Noted at the site.
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.