A send on the active path that fails because the path is gone marks it
Suspect, and the next fast tick moves traffic to a live standby. Only
the kernel's unreachable errors (ENETUNREACH, EHOSTUNREACH) counted as
that. A connection-oriented transport has no route errors: when its
link drops it reports NotConnected (TCP, Tor, Nym) or, on BLE, an
untyped SendFailed("not connected"). Neither moved the path, so a dead
BLE or TCP path kept carrying a peer's traffic until the discretionary
switch. Seen on a phone moved from one USB cable to another while also
linked over BLE: every send failed "not connected" for 66 s, with a live
2 ms path beside it, before a discretionary switch took it.
`TransportError::is_unreachable` now also matches NotConnected, and BLE
returns the typed NotConnected for a send with no connection behind it.
Only a Live path is marked, so a path still connecting is untouched; the
background redial `send_nowait` already starts on NotConnected still
runs, and the path's own probes bring it back once it answers. With no
standby, Suspect changes nothing and the peer is not removed. BLE's
typed error also lets a msg1 reply take the same arrival-address
fallback TCP already takes in `handshake.rs`.
`a_send_that_finds_the_active_link_gone_moves_traffic_to_the_live_standby`
fails a dual-homed pair's cable sends with NotConnected (a test-only
switch on the loopback transport) and checks the cable goes Suspect and
traffic moves to the wifi on the next tick; it fails without the 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.