Johnathan Corgan
ee2b70dcd3
Everything the release needs except the version number, which stays at 0.4.2-dev until the tag. The changelog entry is built from a walk of all 117 commits since v0.4.1 rather than from the open block, which is how the six gaps were found. Two of them were whole missing effects: the identity write path discarded six results, so a node configured for a persistent identity could fall through to an ephemeral one in silence and change its npub, routing address and mesh address on every start; and the OpenWrt zig download verification was described only in part. Chronological fix sequences are collapsed to their net state, and fixes for bugs introduced and closed inside this cycle are folded away rather than described, since no user ever saw them. Sixty-one CI and harness commits are summarized in four entries rather than left out, because they change what a contributor running the local pipeline sees. Two entries carry effects no commit message mentioned. Clearing every copy of private key material added Drop to four public types, so their fields can no longer be moved out, which is source-breaking for anyone using the crate as a library and is reachable through node.identity on the public config. And the responder-side rekey narrowing covers five call sites, not the four the original entry claimed; the ack initiator arm is the one that deliberately still abandons the whole rekey. Release notes ship in both the versioned archive and the root mirror, kept byte-identical. They carry an upgrade section for the two configurations that now fail validation at start time, since a node that will not restart after a package upgrade is the sharpest surprise a release can hold. Four documentation defects are fixed alongside. The readme contradicted itself about the required Rust version, so the badge no longer asserts one and the toolchain file is the single source. The persistent-identity tutorial still sent macOS readers to the Linux configuration directory. The testing readme claimed twenty chaos scenarios where ten exist, and the chaos readme documented three that exist nowhere. The bloom-storm scenario is now described honestly as retired from both runners with no replacement, which is a coverage gap rather than a migration. The changelog entry is restructured by subsystem rather than by change kind. Keep a Changelog puts Added/Changed/Fixed/Security at the top level, which for a release this size scattered one subsystem across up to four disconnected places: NAT traversal appeared four times, Admission three, the data plane three, docs and tooling three. Subsystem is now the top level and the Keep-a-Changelog kinds sit underneath it, so everything about one part of the system is in one place. That takes 29 subsections down to 14 sections. This is a reorganization and not a rewrite. All 80 entries are moved verbatim: the bullet multiset is identical before and after, the word count is unchanged at 14814, and everything from the [0.4.1] heading down is untouched. The departure from Keep a Changelog is deliberate and is the cost of the change; the trade is per-subsystem readability against per-kind readability, and with Security at 60% of this release the per-kind reader is the one who loses. Note this decides the format for [Unreleased] on master and next as well, which still accumulate v0.5.0 entries in the old shape. The release notes gain a section on the security content and drop the references to individual reviews. Most of this release began with reviews the project did not commission, and the note says so: they are driven by current frontier language models, their authors say so, the findings have been legitimate under adversarial re-reading, and none has been reported active in a deployment. The reviews are described as a class rather than enumerated, because naming each report tells a reader nothing they need in order to decide whether to upgrade. For the same reason the batch section no longer itemises what it leaves open. It says that some findings are not addressed here, that a wire-format fix is not a candidate for the 0.4.x line at all, and points at SECURITY.md for the trust model, which is where that belongs and where it already is. The notes describe the release rather than how it was assembled. The opening said a further nineteen fixes landed after the notes were first drafted, which is drafting history and tells a reader nothing about whether to upgrade; it now states what the release closes, the added items folded in beside the rest. The batch heading becomes "Limits, provenance checks and fail-closed defaults", a description of the work rather than of its arrival, and the portability paragraph leads with the two defects fixed instead of with when CI caught them relative to a gate. At a glance is grouped rather than listed. It was eleven bullets in no order, with security split across three of them and configuration across two. The groups are what a reader needs in the order they need it: what to check before upgrading, security, connectivity and performance, the new optional keys, and dependencies. The bullets themselves are unchanged apart from the two that carried the chronology. The provisional release date moves to 2026-08-24 in all three files that carry it. It stays provisional: the playbook confirms the date and clears that wording at the tag, in Phase 7, and this is still Phase 4 content. All three are updated together because the v0.4.0 release shipped a wrong date in two of them by scoping the step to one file.
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.