Files
fips/docs
Johnathan Corgan 32bf476660 Resend a tree announce the peer did not receive
A tree announce was counted as delivered once the transport accepted it, so
a lost datagram left the peer on our old tree position until the periodic
re-broadcast up to a minute later, and indefinitely on a node with a single
peer, which has no periodic re-broadcast. Meanwhile the peer could leave
destinations out of discovery or route toward them by stale coordinates.

The tree state now keeps, per peer, the tree announce still awaiting
confirmation from the link's receiver reports, using the same delivery check
as filter announces. The declaration sequence is the lineage: a new sequence
refills the resend budgets, while a resend or periodic re-broadcast of the
same declaration spends from them. The tracking is dropped with the peer.

The node resends on a reported loss, and once after 30 s when the reports
cannot confirm the announce. Per declaration and session it resends at most
once unchecked and three times on loss, and at most six times a minute per
peer. The resend is an ordinary announce of the current declaration through
the rate-limited send path, and the "Sent TreeAnnounce" trace line now
carries the declaration sequence.

The node tests run on a converged line with every role read from the
converged tree, and share the loopback MMP, loss and rekey helpers of the
filter announce tests, now generalised to node indices.

The Ethernet mesh scenario's 60 s delivery window no longer sits at the
ordinary recovery bound, since tree and filter announces lost to a link flap
are now resent within seconds of the link returning, or after about 30 s
when the reports cannot confirm them. A comment beside the assertion says
so, so a red there is investigated rather than expected.
2026-09-27 19:35:48 +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.