Johnathan Corgan
a37c62898c
The guard that drops a returning copy of this node's own lookup request recognises an id only while that lookup is outstanding and the id is among the last eight its ladder issued. Nothing pinned either limit: the existing test covers only an id inside the window of a live lookup. Two new tests do. A copy arriving after the lookup timed out is recorded and forwarded as transit, and its next copy is a duplicate. A copy of an attempt older than the recorded window is likewise recorded and forwarded, while a recent id on the same lookup is still dropped as our own. The mesh operation design said a node tests its own outstanding lookups before consulting recent_requests, and that a returning copy of the originator's request never enters the transit cache. The first is the response path's order; the request path runs the dedup test first and the own-request check second, where the order is immaterial because an id the originator check recognises is never in the dedup cache. The second holds only while the check recognises the id. The design now says both, and how far the check reaches, and its heading no longer says the originator check runs first. When a node's own looped-back lookup request got its own counter, the comments justified the split by saying req_duplicate means a peer resent a request, and that the own-loop counter says nothing about the peer. Neither holds. The duplicate test is on the request id alone, so one flood arriving through two neighbours is counted there too, and no discovery counter is per peer. Justify the split by cause instead: the node's own fan-out returning, versus a request id the node has already recorded arriving again. Say that neither counter identifies the delivering peer, that own-request loopbacks come back through bloom false positives and so rise with the filter's fill ratio, and that an own copy outside the loop check's reach is recorded and forwarded as transit, with a later copy counted as a duplicate.
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.