Files
fips/docs
Johnathan Corgan 6b6d2a8df9 feat(fipsctl): rework the probe report layout and fix the path row text
The stage block and the sections below it now share one left margin, the
stage rows carry shorter text, and a blank line separates the stages by
the question each answers: where is the target, how do we get there, can
we reach it.

The path row no longer appears when it computed a route. It restated the
heading of the path section printed below it, and that section said the
same thing in full. The row is kept when the stage failed or was skipped,
where it carries a finding that appears nowhere else in the block.

That exposed a defect the row had all along: its text ignored the stage's
reason, so a disjoint_trees or no_next_hop failure printed the success
wording. It now keys on the reason like every other stage.

Also in the report: the npub moves onto its own line so the three
identifiers align, the depth column no longer shifts with the length of
the coordinate list, the route line sits directly under the two
coordinate lists it derives from and is set off by a blank line on each
side, the next-hop class loses its underscore, and the round-trip row
names the exchange count only when it is not one. The path section
heading, which said the route was computed rather than observed, is gone;
the JSON keeps computed_locally and observed.

Off a terminal the block is rebuilt from the settled prefix rather than
appended row by row, because a group separator belongs to the row below
it and a single-row render cannot know whether that row exists yet.

A stage-pipeline diagram lands alongside the report, drawing the five
stages left to right at 16:9 with each stage's failure reasons below it,
and the bypass that skips both lookup stages when the coordinates are
cached or the target is a direct peer. Its branches come from the probe
state machine rather than from the report, so the path stage is drawn as
the one failure that does not stop the probe.
2026-08-29 06:38:22 +00:00
..
2026-08-22 10:46:42 +01: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.