Jeff GardnerandJohnathan Corgan
5e3892edb8
On any Unix host that falls through to the last-resort /tmp/fips-control.sock path, bind chowned the socket's parent unconditionally, and that parent is /tmp itself. A root daemon on such a host changed the group ownership of /tmp to fips at every start. The mode was left alone, so nothing lost access, but the ownership was ours to take and never ours to keep. macOS has no /run, so the resolver's /var/run/fips arm only fired when the directory already existed, and nothing on macOS creates it: /var/run is cleared at boot and the shipped LaunchDaemon has no equivalent of the FreeBSD rc.d fips_precmd. The packaged macOS daemon has therefore been landing on /tmp/fips-control.sock every boot. A privileged macOS process now selects /var/run/fips before its leaf exists, so that bind creates it, and the clients follow once it is there. The two halves are the same change: the bootstrap only works if bind may create and secure that directory, and the /tmp chown had to go before bind could be trusted to. Which parent bind may secure is keyed on the directory's identity rather than on which call created it. is_managed_socket_parent matches only the resolver's own candidates: /run/fips, /var/run/fips where the platform policy consults it, and $XDG_RUNTIME_DIR/fips. Keying it on creation alone was tried first and regressed Linux, because systemd removes RuntimeDirectory=fips when the unit stops and recreates it as root:root on the next start, while the tmpfiles fragment that sets the fips group runs only at install and boot. The daemon's own chown was what repaired that at every bind, so a fips-group operator lost fipsctl after the first restart following a boot. Matching on identity restores it and still leaves /tmp, and any operator-configured directory, alone. The resolver is split into a pure core taking the policy, the XDG_RUNTIME_DIR value and an is_dir predicate, so the macOS and Linux policies are both exercised deterministically on a Linux runner with no environment mutation. The deb-install suite gains the end-to-end half: after a service restart it asserts /run/fips is 750 root:fips and that a real non-root fips-group user can reach the socket, which is the property an operator actually has. Also corrects a configuration.md paragraph claiming the daemon and the clients use different fallback orders, which stopped being true when the resolver order disagreement was resolved and the prose was never updated.
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.