Files
fips/docs
Johnathan Corgan 40c67abbe6 Merge master into next, forward-porting each side onto the other
Five files conflicted and each needed a different call, because the two
lines had rewritten different halves of the same code.

The handshake handler takes next's version whole. master's entire change
there was three comment blocks and one widened debug_assert, and the
assert names HandshakePhase::ReceivedMsg1, a variant next's XX rewrite does
not have. Nothing semantic was dropped.

The peer reaper takes master's: reap_peers_on_transport is new and its
route_link_dead doc now describes both callers, which is true on this line
too.

The ethernet transport takes master's binder rewrite with next's wire
format re-applied on top. The send path, the receive path and the frame
tests merged to the 4-byte header on their own, but three sites are new in
master's rewrite and had never seen it: the Binding default and both arms
of the binder's MTU calculation still subtracted 3. The transports snapshot
fixture moved with them, 1499 to 1496, and that single field was the whole
diff. Beacons carry no pubkey here, so local_pubkey leaves the transport,
its binder context and the node's transport construction with it.

The changelog keeps both sides' entries, with master's Added subsection
lifted back out of Changed where the merge had left it.

Two tests do not come across. a_transient_msg2_failure_keeps_the_link_for_
the_retry and its restart-path sibling assert that the machine rests at
ReceivedMsg1. This line's nearest state is SentMsg2, and it means something
else: the inbound leg parks there awaiting msg3, where on the other line
that phase was the last stop before promotion. Renaming it would produce a
test that passes without exercising the deferral. The behaviour they guard
did merge and sits in the transient arm of the msg2 send failure; what is
missing is coverage shaped for this handshake, which is tracked separately.

The two connected-socket tests did come across. Their helper took the
responder's session straight after msg2, which is an IK assumption; it now
runs msg3 as well. Both pass here and both go red when the clear is removed
or made unconditional.

The test-harness fixes arrive through master rather than as follow-ups
here, so this line never carries the versions that failed: the
interface-binding suite's veth naming, and the chaos veth restore, random
streams, settle wait, netem restore and shared down-node set.
2026-09-10 19:19:27 +00:00
..
2026-08-30 10:42:59 +00:00

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.