The planning post before the implementation post. FIPS is an open-source mesh protocol with cryptographic identity and transport-agnostic routing. My sovereign AI stack is sovereign at the model and the hardware, and leaks the whole workload at the network boundary. Here is why that gap matters, the five concrete pieces of work I am committing to, and why I write the plan in public before I know if it works.

FIPS, the Mesh Protocol, and Why I Need to Build It to Believe It

12 min read
strategynostragentsmcpdgx-spark

I have a habit of distrusting things I have not personally configured. The habit predates sovgrid.org and is responsible for most of what makes the engineering log readable. When I read about a new protocol, the article tells me what the protocol promises. The implementation tells me what the protocol delivers. The gap between the two is where the work lives.

So when I listened to Matt Odell’s Citadel Dispatch episode 193, which featured Arjen and Jonathan talking through a mesh-networking project called FIPS, I noticed myself doing two things at once. The first was getting excited. The second was filing a quiet note that the excitement was not yet earned, because I had not yet typed git clone and watched the thing run on hardware I trust.

This article is the planning post. The implementation is the next post. I want to write the planning post in public because I think the project is interesting enough that other people should consider running it too, and because I want the future implementation post to be readable against this baseline. If I get something wrong here, the next article will say what.

What FIPS is, in plain words

FIPS is an open-source mesh networking project. Today’s internet runs through companies and governments that can monitor or block almost any communication. FIPS proposes a different architecture. Every node has a cryptographic identity, every connection is encrypted by default, nodes discover each other through local broadcasts and route messages through whatever transport is available, and the existing applications people already use (browsers, SSH clients, regular HTTPS calls) work on top of it without modification.

The architectural choice that interests me most is the decoupling of transport from routing. FIPS does not care whether the underlying connection is Wi-Fi, Bluetooth, LoRa, Starlink, or a piece of fiber that someone is paying a telecom for. The routing layer treats them all as substitutable. If one transport fails or becomes too expensive, the routing layer can shift to another. This is the same architectural move that made the original internet resilient (TCP/IP did not care whether the packet was traveling over copper or satellite), except now applied one layer up, with cryptographic identity replacing IP addresses as the unit of addressing.

The episode also mentioned a DNS trick using IPv6 mapping that lets existing applications use FIPS as a transparent transport. This is the kind of detail that determines whether a protocol survives or fades. The mesh-networking literature is full of projects that asked users to abandon their existing software stack. Most of them are abandoned themselves. FIPS apparently is taking the opposite approach: keep the apps, replace the substrate, make the migration invisible. If that works, it is a meaningful design choice. If it does not work, the failure modes will be specific and educational. Either is interesting.

Arjen is the same person who built TollGate, the project that lets routers charge per-byte using Cashu, in tiny Bitcoin micropayments, so the access economics of a mesh become market-priced rather than ISP-mediated. FIPS and TollGate are clearly designed to compose. A mesh that routes by cryptographic identity and prices its packets by Cashu micro-payments is a different shape of internet than the one we have. It is the shape that the Sovereign Engineering project list has been quietly assembling for three cohorts now.

I have not implemented either of these. I am writing this with the discomfort of having strong opinions about software I have not yet run. That discomfort is itself the reason for the implementation work I am committing to.

Why I think this matters for self-hosted AI specifically

The conversation about sovereign AI tends to focus on the inference layer. Whose model, whose hardware, whose data, whose keys. These are the right questions and I spend most of my time on them. But there is a layer below the inference layer that the conversation rarely reaches, which is the network layer that the AI agent uses to reach its tools, fetch its inputs, and deliver its outputs.

Right now, in 2026, that network layer is approximately the same boring stack every other piece of software uses. TCP/IP over a residential or commercial connection, DNS lookups against operator-controlled resolvers, TLS terminated at a reverse proxy, the whole machine sitting at an IP address that the ISP can revoke. The sovereignty I have built into my AI stack (local model, owned hardware, no cloud API) terminates at the network boundary, where I am dependent on the same middleboxes as everyone else.

A mesh-networking layer with cryptographic identity and protocol-agnostic transport changes the shape of that dependency. An AI agent that addresses other agents by npub rather than by IP, that can route over Wi-Fi or Starlink or local Bluetooth depending on availability, that can pay for transit in sats rather than in monthly ISP fees, is a more sovereign agent than the one running today. The model and the hardware can be perfectly sovereign while the network layer leaks the entire workload to a Verizon log.

I want my MCP server to be reachable over FIPS. I want my agent’s tool calls to use cryptographic identity all the way down. I want the inference pipeline I describe in the book to be one that does not depend on the existing DNS hierarchy or the existing ISP duopoly. None of that is possible today on my stack. It might be possible after the implementation work this article anticipates.

Why I need to build it to believe it

The skepticism is not about Arjen or Jonathan or the FIPS project. The skepticism is about every mesh-networking project I have read about over the last ten years. The history is rough.

Briar promised mesh-resilient messaging and built something that mostly works for a small group of Android users in specific configurations. Meshtastic built a real product on LoRa but operates as a niche radio-amateur tool more than a general-purpose mesh. cjdns proposed a beautiful protocol-stack-replacement and ran into the problem that nobody could get it working except cjdns developers. NostrMesh on ESP32 is a clever proof of concept that is not, by anyone’s serious metric, ready for production traffic.

The pattern is consistent enough that I have learned to demand implementation before I trust any new claim in this space. The mesh-networking literature is rich in good ideas that did not survive contact with real-world physics, real-world adoption curves, or real-world adversaries. Bloom filters that work in simulation collide in production. Peer discovery that works at a hackathon stalls at scale. Encryption schemes that survive the lab fail when an unexpected NAT traversal pattern shifts the threat model.

So when Arjen describes FIPS in the episode (cryptographic identity per node, Noise-protocol handshakes, Bloom-filter-based peer discovery, transparent IPv6 mapping for backwards compatibility) I want to believe each piece. I will not, though, until I have configured each piece on hardware I trust, with a workload I care about, and seen what fails.

There is a particular failure mode I am watching for, the one that has killed most mesh projects before this one. The failure mode is the gap between “two laptops in the same room can talk to each other through this protocol” and “a node in Brazil can reach a node in Madeira through three intermediate hops, two of which are unreliable home connections, with end-to-end latency under one second and packet loss below five percent.” The first benchmark is achievable in an afternoon. The second is the one that determines whether the protocol is useful. The audio in CD193 hints that the FIPS team understands this, mentions Starlink bridging and global routing as future ideas, and is honest about which capabilities are early. Honesty about which capabilities are early is itself a good sign.

The work I am committing to

Five concrete pieces of work, ordered by what I will attempt first.

Phase 1: Reproduce the basic FIPS demo on two machines

I have two devices on my desk that can stand in for a small mesh. Reproducing the basic two-node FIPS handshake, with Noise encryption, npub identity, and at least one application traffic flow (probably SSH because it is the most-stressed remote-access tool I use), is the first milestone. If the demo runs, I trust the rest of the project enough to invest deeper. If the demo does not run, the implementation post becomes a different kind of article, and that article is also valuable.

Phase 2: Reach my MCP server over FIPS from a separate machine

The interesting test for my work is whether mcp.sovgrid.org can be served over FIPS from a peer agent. If it can, my MCP becomes addressable by npub rather than by domain name, and the entire Nostr-native agent ecosystem gets a real path to consume it. This is the work that overlaps with the existing ContextVM and Nomen projects (also SovEng-cohort outputs), so the experimentation here is potentially of upstream interest to those projects too.

Phase 3: Reproduce TollGate alongside FIPS

TollGate prices mesh transit in Cashu micro-payments. If I run TollGate on a router on my home network, with FIPS routing the traffic, then I have a working microcosm of the sovereign-internet architecture the SovEng project list has been building toward. The microcosm proves the composition or surfaces the composability bugs that need to be filed upstream.

Phase 4: File real issues against the FIPS repository

This is the part that matters most for the upstream-PR ethic that sovgrid.org runs on. Whatever I find during Phases 1 through 3, the bugs go upstream. Issues filed where the FIPS repo lives. Patches submitted where I can write them. Documentation improvements where the existing docs left me confused. The point of running the implementation is partly self-interest and partly to make the next person’s implementation easier. If I can save one future operator three hours by writing one good bug report, the time spent writing the bug report has paid back.

Phase 5: Write the implementation post

The implementation post is the public record of what worked, what did not, how long things took, and what I would tell the version of me that was reading this planning post. The implementation post will be honest about which of the hypotheses in this article were correct and which were wrong. If FIPS turns out to be early-stage but viable, the post will say that. If it turns out to be early-stage and not yet viable, the post will say that too. The sovgrid.org engineering log lives on the discipline of saying what is actually true after the work, regardless of what one might have hoped during the planning.

How this connects to the bigger sovgrid.org argument

The book I am writing argues for sovereign AI as an engineering discipline. Sovereign AI assumes a sovereign substrate. Today the substrate is not sovereign at the network layer, regardless of how sovereign the model and the hardware are. If FIPS works, or if some near-cousin of FIPS works, the substrate question gets closer to answered. If neither FIPS nor any of its cousins work, then the book has a chapter to write about the open problem of sovereign-network-layer infrastructure, and that chapter is honest and useful even if uncomfortable.

Either outcome teaches the book something. I think this is the only honest reason to do exploratory engineering: because the result, whichever way it goes, teaches you something that improves the next thing you build. The implementation will run. The post will get written. The book gets one more chapter regardless of which direction the chapter has to go.

Why I am writing this in public before doing the work

A reader might fairly ask why I am writing the planning post at all, before I know whether the work succeeds. Three reasons.

First, the SovEng pattern. The people building these protocols ship in week-scale rhythms with public demos. Hiding work in progress until it is polished is the opposite culture. I am borrowing the demo-day culture for my own work: planning post becomes the Tuesday talk, implementation post becomes the Friday demo. Different cadence, same shape.

Second, the accountability. Writing publicly that I will run an experiment increases the probability that I will actually run the experiment. The probability matters more than the polish. A scruffy public commitment that ships is worth more than a polished private plan that gets postponed.

Third, the invitation. Arjen and Jonathan are building this protocol publicly. Anyone reading this article who is also interested can run the same demos at the same time, file the same bugs, contribute the same patches. The implementation post in a month or two will reach a wider readership if a handful of other operators are running their own implementations in parallel. The whole stack benefits if more eyes are on it before the protocol is stabilized.

If you are one of those operators, the FIPS repo location is in the CD193 episode notes; the repo is anchored on Nostr-native git infrastructure, which is itself part of the experiment. Pulling the repo is the first hand-shake with the protocol. If you are working through a stack like mine (heavy AI inference on owned hardware, Nostr-native identity, Lightning payments) the implementation work will likely be relevant to your stack too.

I will report back. The next article in this series, weeks from now, will say what happened.

Illustration: FIPS, the Mesh Protocol, and Why I Need to Build It to Believe It