Both projects begin from the same observation: the network that carries civilization's communication runs on a substrate of centralized coordination. ISPs allocate addresses, registrars gate domain names, certificate authorities vouch for identity, and DNS servers arbitrate reachability. Each of these functions imposes a dependency, and every dependency is a chokepoint that can be taxed, surveilled, or switched off.
Reticulum and FIPS respond by building mesh networks that require none of the above. A new node joins by connecting to any existing peer. Once connected, it generates its own address from a cryptographic keypair and starts routing over whatever physical medium is available to it. No one grants permission for any of it.
That shared premise is where the similarity ends. The two stacks make almost opposite engineering bets beneath the shared framing. Reticulum treats IP as something to route around entirely and optimizes for radio links so slow that five bits per second counts as usable bandwidth. FIPS treats IP as the interface legacy applications still expect and builds a mesh underneath that looks like IPv6 from the outside. Understanding why each choice follows from the other accounts for most of what separates these protocols in practice.
The Physical Layer: Agnostic by Design
Both protocols refuse to specify a transport. Whatever can move a datagram between two points is usable. Reticulum ships drivers for LoRa radios, serial links, packet radio over VHF, TCP and UDP tunnels, Ethernet, and I2P, with a minimum viable throughput of five bits per second and a physical MTU of 500 bytes. FIPS runs over WiFi, Ethernet, Bluetooth, UDP overlays, Tor circuits, serial lines, and satellite uplinks, and its IPv6 compatibility path needs at least 1357 bytes of transport MTU to carry an IPv6 minimum packet.
A word on MTU before moving up the stack. Every physical medium caps how many bytes can ride in a single packet, and that cap is the Maximum Transmission Unit. Ethernet and WiFi carry about 1500 bytes, a standard UDP-over-IP path lands near 1472, a Tor circuit sits a bit lower, and a LoRa radio running conservative parameters might permit only 256. Anything larger either gets fragmented by the link layer or dropped outright. Reticulum and FIPS both refuse to fragment at their own layers, so every packet they emit must fit inside whatever MTU the current hop provides, and that single packet has to carry protocol overhead, encryption envelopes, routing metadata, and application payload all together. Overhead eats directly into the payload budget, and the smaller the MTU, the more painful each byte of protocol framing becomes.
This 857-byte gap in minimum MTU is the first visible consequence of the different design targets. Reticulum expects its deployments to include hobbyist LoRa modules speaking across dozens of kilometers at bitrates too low to stream an email attachment in an afternoon. FIPS expects its deployments to include IPv6-capable transports that can carry a reasonable TCP segment without fragmentation. Both are valid environments, and they demand different overhead budgets and different fallback strategies when the medium misbehaves.
Below the drivers, neither protocol assumes trust at the physical layer. A WiFi access point is treated with the same suspicion as a radio broadcasting over open spectrum. Every link carries authenticated, encrypted frames, and every mesh-level operation survives transport-level tampering. The transport is a pipe for ciphertext, nothing more.
Identity as Address
In the classical Internet, your address is assigned and your identity is asserted, and the two are held together by a certificate issued by a third party. Both protocols collapse this into a single cryptographic operation.
Reticulum calls its identity primitive an Identity: an Ed25519 signing keypair combined with an X25519 encryption keypair. From an Identity you construct destinations, each of which appears on the wire as a 16-byte truncation of a SHA-256 hash over a dotted naming hierarchy. A destination name looks like lxmf.delivery or environmentlogger.remotesensor.temperature, and the hash of that name, combined with the destination's public key for private types, becomes a 128-bit address. One Identity can publish any number of destinations for different purposes.
FIPS uses secp256k1. Bitcoin and Nostr use the same curve, which means a FIPS node can derive its identity from an existing Nostr nsec without generating anything new. A node's public key, encoded in bech32 as an npub, is its application identity. From the raw x-only pubkey, FIPS derives a 16-byte node_addr by truncating SHA-256, and from that derives an fd00::/8 IPv6 address by prepending 0xfd. The three identifiers serve different layers: npub for users, node_addr for routing, IPv6 for legacy applications.
Two consequences follow from these choices. First, Reticulum's destinations are application-scoped while FIPS identities are node-scoped. A Reticulum Identity publishes a distinct destination hash for each application, giving every app its own routable endpoint, though every destination's announce still carries the Identity's public key and an observer correlating announces can recover the shared Identity. A FIPS node exposes every application through a single npub and dispatches to them using port numbers above FSP. Reticulum is more fine-grained in addressing; FIPS is simpler to reason about.
Second, the choice of elliptic curve has practical downstream effects. secp256k1 lets FIPS inherit Nostr identities directly, so any user with an nsec already holds a usable FIPS identity. Ed25519 and X25519 give Reticulum access to faster, batch-verifiable signatures and a well-audited lineage of NaCl-style constructions, at the cost of sitting outside the cryptographic world that Bitcoin and Nostr occupy.
How the Mesh Finds Itself
Addressing is cheap; finding the holder of an address is where mesh protocols get expensive. Reticulum and FIPS answer that question in opposite ways.
Reticulum uses an announce mechanism. When a destination wants to become reachable, it broadcasts a signed packet containing its destination hash, its public key, and optional application metadata. Transport nodes receive this announce and forward it, recording which direction it came from and how many hops it took. Announces propagate with randomized delay, bandwidth limits configurable per interface, and priority weighted inversely by hop count, so that slow segments stay responsive to local traffic while still gradually learning about distant destinations. Every transport node ends up holding a lookup table that says "to reach destination X, forward to peer Y," where each entry encodes only the next hop toward the destination and no node has the full path in memory.
FIPS builds a spanning tree. Every node picks the peer that offers the best measured path to a deterministic root, chosen as the node with the lexicographically smallest node_addr, and the resulting parent-child relationships form a tree over the mesh. Each node's position in the tree becomes its coordinate: the sequence of node_addr values from itself back to the root. To route a packet, a node finds the peer whose coordinate is closest to the destination's coordinate by tree distance. For destinations not known through the tree, nodes exchange bloom filters advertising reachability, and consult those filters when tree routing alone would drop a packet.
The tradeoffs here are subtle but real. Reticulum's announce model is simple and resilient. It converges quickly on networks with reasonable bandwidth, handles topology changes through the same gossip channel that propagated the initial announces, and requires no coordination between nodes beyond the signed announce format. The cost is memory: every transport node holds a routing entry for every destination it has ever heard an announce for, and bandwidth spent on announce floods grows with the number of announced destinations.
FIPS's spanning tree is tighter. Coordinates are computed from local information, forwarding decisions iterate only the direct peer list to find the closest coordinate to the destination, and bloom filters compress reachability information at the cost of occasional false positives. When the network partitions, each segment independently re-elects a root and reconverges in O(diameter) rounds. The cost is complexity: spanning tree construction, MMP link measurement, bloom filter gossip with split-horizon rules, and a coordinate cache that must be consulted before every forwarding decision.
Both approaches handle partition healing automatically, and that property is load-bearing for a mesh designed to survive adversity. Neither needs human intervention when a link goes down. The difference is that Reticulum will route your packet through whatever path an announce has carved out recently, while FIPS will route your packet along the spanning tree's idea of the shortest path right now.
A subtler architectural choice shows up in the packets themselves. Reticulum omits source addresses entirely; a forwarded packet carries only the destination hash and the payload, and transit nodes track return paths through the link identifier they remembered when the link was established. FIPS includes both source and destination node_addr values in the FMP routing envelope, because the spanning tree forwarding logic needs to know where to send responses and because the two-layer encryption model treats the envelope as cleartext to transit routers by design. The trade is concrete: Reticulum gets a stronger anonymity story at the cost of a more constrained forwarding model, while FIPS gets simpler routing at the cost of revealing source and destination hashes to every hop.
The Cryptographic Core
Reticulum and FIPS both encrypt everything by default, and both refuse to carry unencrypted traffic on multi-hop paths. Beyond that shared commitment, their cryptographic layers look like they come from different decades.
Reticulum's primitive list reads as a conservative choice from the mid-2010s: Ed25519 for signatures, X25519 for ECDH, HKDF for key derivation, AES-256 in CBC mode for bulk encryption, HMAC-SHA256 for message authentication, and SHA-256 plus SHA-512 for hashing. Every packet to a single destination gets a freshly generated ephemeral X25519 keypair, which performs ECDH against the destination's public key to derive a per-packet symmetric key. No handshake is needed because the sender already knows the destination's public key from a previous announce. Encrypt-then-MAC via AES-CBC and HMAC-SHA256 provides authenticated encryption in the older composition style that predates AEAD constructions like ChaCha20-Poly1305. A destination can optionally enable a ratchet, so that per-packet ECDH uses successive ratchet keys instead of the long-term public key, giving forward secrecy to link-less traffic.
FIPS uses the Noise Protocol Framework with ChaCha20-Poly1305 as the AEAD. Every link between adjacent peers runs a Noise IK handshake, which completes mutual authentication in one round-trip because the initiator already knows the responder's static public key. Every end-to-end session runs a Noise XK handshake, which hides the initiator's static key until the third handshake message, so transit routers cannot learn the initiator's npub from observing the handshake. Both Noise instances produce AEAD keys used with ChaCha20-Poly1305 for the rest of the session.
The architectural difference runs deeper than primitive choice. Reticulum applies encryption per-destination-type: single destinations get ECDH-derived per-packet encryption, group destinations use a preshared AES-256 key, plain destinations are cleartext, and link destinations establish an ephemeral X25519 tunnel with forward secrecy. Which encryption you get depends on how you addressed the packet.
FIPS applies encryption in two independent layers, always. The lower layer, called FMP, encrypts every hop under its own Noise IK session, so a node forwarding a packet decrypts under the incoming link key and re-encrypts under the outgoing link key. The upper layer, called FSP, encrypts the end-to-end payload under a Noise XK session and remains opaque to every intermediate hop. The construction resembles Tor's onion model at a smaller scale, without the anonymity guarantees that Tor's three-hop circuits and large shared user base provide.
The two-layer construction gives FIPS a cleaner story about what each observer can see. A transit router sees FMP-decrypted packets containing opaque FSP payloads and routing envelope data: source and destination node_addrs, TTL, path MTU. It can tell that a particular pair of node_addrs is exchanging traffic and watch the volume and timing of that exchange, but the FSP payload stays sealed and the npubs behind those hashes stay out of reach. Reticulum approaches the same threat model through its claim of initiator anonymity: the sender's identity is never revealed on the wire for packet-style communication, and for link-style communication the initiator can choose to authenticate only after the link has come up and been verified.
Sessions and the Shape of a Conversation
For single-shot datagrams, both protocols offer simple encrypted delivery. For extended conversations, the abstractions diverge again.
Reticulum's Link is a first-class construct. Establishing a link costs three packets totaling 297 bytes, during which both sides contribute fresh X25519 keypairs to an ECDH exchange that derives an ephemeral symmetric key. The link carries its own identifier, a hash of the link request packet, and every transport node along the path remembers this identifier so that subsequent traffic can address the link directly instead of re-resolving the destination. The link provides forward secrecy, receipt proofs via Ed25519 signatures, and bidirectional addressing. Keeping a link open costs roughly 0.45 bits per second, which means a 1200 bps packet radio channel can host a hundred concurrent links with ninety-six percent of its capacity still available for actual data.
FIPS's FSP session is less explicit. Every end-to-end exchange runs a Noise XK session, which provides forward secrecy and bidirectional AEAD encryption from the first message. There is no separate link-establishment phase visible to the application; the session is the delivery mechanism. Reliability is handled above FSP, either by the native API contract or by TCP running inside the IPv6 adapter, because FSP delivers datagrams only and leaves stream semantics to the layer above.
The practical consequence is that Reticulum applications tend to be written against the Link API for anything larger than a notification, and the Resource abstraction on top of Link handles chunking, compression, and reassembly of arbitrarily large transfers. FIPS applications tend to be written against the native datagram API when they can be, or against the IPv6 adapter when they need to speak to unmodified software, and they inherit whatever reliability layer lives in the application protocol.
The Rest of the World
At some point both protocols have to answer the question of what happens when an application written for the normal Internet wants to talk to a peer on the mesh. The two answers point in opposite directions.
Reticulum's answer is to write new applications. The project ships Nomad Network, LXMF for messaging, Sideband for mobile use, and a handful of other tools that speak Reticulum natively. No compatibility shim for SSH or curl exists. If you want to run a service on a Reticulum network, you link against RNS and implement your protocol against destinations and links. The design bet is that applications meant to survive adversarial environments should be built for those environments from the start, and that dragging along the assumptions of a TCP/IP application stack into a five-bit-per-second LoRa link is a category error.
FIPS's answer is a TUN adapter. The daemon creates a virtual interface, assigns itself an fd00::/8 address derived from its node_addr, and asks the kernel to route the entire fd00::/8 block through the interface. When an application opens an IPv6 socket to a fips0 peer, the adapter receives the packet, looks up the destination's pubkey in a DNS-primed identity cache, and hands the packet to FSP. TCP MSS clamping keeps segments within the effective 1395-byte MTU. ICMPv6 Packet Too Big messages fall back to path MTU discovery for applications that bypass the MSS clamp. A separate fips-gateway sidecar extends this trick to LAN clients that do not run FIPS themselves, allocating virtual IPs from fd01::/112 and installing nftables rules that NAT traffic between the LAN and the mesh.
Reticulum is a parallel network stack that competes with IP at the application layer, while FIPS is a mesh substrate that preserves IP at the application layer. Applications running over Reticulum stay inside the universe Reticulum defines, with no substrate for DNS, TLS, or HTTP conventions to attach to below them. Applications running over FIPS keep their existing codebase but inherit every IPv6 behavior the operating system already implements, including the ones that can surprise you inside a mesh.
Each approach fits a different problem. An off-grid community deploying LoRa radios gains the most from Reticulum's willingness to throw away the old assumptions; a self-hosted user routing SSH and Syncthing across a censored border gains the most from FIPS's willingness to preserve them.
What Each Threat Model Promises
Reticulum claims initiator anonymity. Packets sent to single destinations carry no identifying information about the sender, and links can be established and used without the initiator ever authenticating to the destination. The destination learns that a link was established; the initiator's identity stays hidden until the initiator chooses to authenticate inside the encrypted channel. Once authenticated, the identity is visible only to the verified destination. This property is load-bearing for applications like anonymous messaging or whistleblowing tools.
FIPS declines to claim anonymity. Direct peers learn each other's npub through the Noise IK handshake, and there is no mixing layer, cover traffic, or tunnel rotation. A direct peer always knows who you are. What FIPS does claim is that transit routers, meaning peers who are not direct neighbors but are forwarding your session, see only opaque routing hashes and cannot correlate traffic to npubs. The claim is weaker than Reticulum's by design: FIPS assumes you know your direct peers, and the protocol optimizes for privacy against adversaries further away.
Both projects are explicit that a global passive observer with vantage points across multiple transports can perform traffic analysis against them. Neither pads packets, batches traffic, or rotates through decoy paths the way a mix network would. Payloads stay confidential; the occurrence of a conversation remains visible to anyone with enough observation points. Mix networks solve a different problem and impose padding and cover-traffic overheads that these stacks are built to avoid.
On eclipse resistance, both rely on topological diversity. Cryptographic signatures on tree announces or on routing packets cannot save a node whose every direct peer is hostile, because the hostile peers hold valid identities too. The defense in both protocols is the same: peer across independent operators and independent transports, so that any single compromise leaves the target with other views of the network.
Where Each One Wins
For a LoRa mesh across a valley, where the medium is a 300 bps radio channel and the nodes are Raspberry Pis with RNodes, Reticulum is the protocol. FIPS's IPv6 compatibility path requires transport MTUs that LoRa cannot sustain, its spanning tree would reconverge constantly in a mesh where links come and go with weather, and its application story assumes you have applications that can be recompiled to run over it. Reticulum was designed for exactly this environment, and its Link API, Resource abstraction, and announce-based path discovery all pay off in the low-bandwidth regime.
For a Nostr-native mesh where users want to SSH into their home servers over a Tor-transported overlay without standing up Cloudflare tunnels or tailnets, FIPS is the protocol. Its npub-as-identity model inherits the social graph users already have on Nostr, and its IPv6 adapter lets most existing tools work without modification. Noise-based two-layer encryption matches the trust structure of deployments where direct peers know you and distant peers should not, and the spanning tree performs well on the transport MTUs a Tor circuit or WiFi LAN provides.
Coexistence between the two is possible in principle. A FIPS gateway running on a node that also participates in a Reticulum mesh could bridge traffic between them, and both projects are sufficiently medium-agnostic that nothing in their design prevents nesting one inside the other. In practice the communities and tooling sit apart, and the cryptographic curves never meet.
A Note on Age and Maturity
Reticulum was dedicated to the public domain in 2016 and has a shipping 1.x reference implementation in Python, a thorough manual, the RNode open-source LoRa hardware platform, and a growing catalog of applications including Nomad Network, Sideband, LXMF, and MeshChat. It has not been externally audited, which the project is explicit about, but its primitives are conservative and its design has had close to a decade to settle.
FIPS was built during SEC-07 at Sovereign Engineering and is, at the time of writing, young software. Specs are public, the reference implementation lives on GitHub, and a learning site walks through every layer with interactive simulations. It inherits cryptographic primitives from the Noise Framework and from Nostr tooling, which mitigates some of the risk that comes with new protocol work, but the network-level behavior has not seen years of deployment stress yet. Anyone planning a production deployment should weigh that accordingly.
The Convergent Insight
Despite their different answers, Reticulum and FIPS share the same deep claim: a network can function without central coordinators, identity and addressing follow from cryptographic keypairs held by the participants themselves, and every link in such a network should be encrypted by default because there is no reliable way to know which links are hostile.
Two implementations of the same claim, making different bets about which tradeoffs to prioritize. Both worth running. Both worth understanding on their own terms before picking one.