Files
fips/docs
fr34akyandJohnathan Corgan 47f8f01e2f fix(config): validate node.netmon.*
Two checks, both about the detector being able to do its job at all
rather than taste in numbers.

A zero `poll_interval_secs` was silently clamped to one second, so a typo
produced a node polling twenty times more often than configured and saying
nothing about it. It is now refused, and only while detection is enabled,
since a disabled detector imposes no constraint on its own knobs.

A `debounce_ms` whose worst case — the full `MAX_DEBOUNCE_ROUNDS` of
settling — meets or exceeds `link_dead_timeout_secs` is refused too,
because the liveness reaper would tear the peering down before the change
was ever reported: the machinery would run and could not help. The
constant is shared with the detector rather than restated, so the two
cannot drift.

Both multiplications saturate. The operands are operator-supplied `u64`s,
and an overflow would wrap to a small number and silently accept the very
configuration this refuses.

Documented in the reference, because neither refusal was predictable from
it. The debounce one couples two keys in different blocks, so an operator
shortening `link_dead_timeout_secs` for fast failover can make an
untouched `debounce_ms` illegal and meet a hard startup refusal citing a
netmon key they never set. The multiplier its own error message uses is
now on the page.

A test asserts the shipped defaults still validate, which is the failure
mode a cross-field check invites. Another asserts the refusal message
carries no run of literal spaces: it is the whole diagnostic for the only
refusal reachable by editing `debounce_ms`, substring assertions cannot
see how it reads, and rustfmt does not touch string literals — a
continuation join had already left twenty-two of them mid-sentence.
2026-09-09 18:45:42 +00:00
..
2026-09-06 19:10:43 +00:00
2026-08-30 10:42:59 +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.