In the wilderness, the screen of a phone with cellular, Wi-Fi, and Bluetooth turned off suddenly lights up, receiving a short message sent from a few miles away. The message’s journey is quite tortuous: first traveling over the LTE cellular network to the cloud, then dropping back down from a Starlink satellite to a ground bridge, where it is converted into radio waves traversing a ground path packed with heavy vegetation and obstacles. After the ground path loses connection, a small drone suspended with a coin-sized development board takes off to relay the signal, finally delivering the data to the phone.
This engineering project follows the path of a fun geek experiment, unlike commercial telecom products. The star of the experiment is Reticulum. It uses no IP addresses and doesn’t care who the carrier is, managing to stitch together satellites, Ethernet, and weak LoRa radio waves into a self-sufficient network.
At Data Slayer’s test site, an LTE-connected phone sends a message to another phone with cellular, Wi-Fi, and Bluetooth turned off, with the message transmission path broken down at the underlying layer into five different carriers. The sender phone runs the Columba client on Android, sending data over LTE to a public Reticulum TCP node on GCP first, then across the Internet, down through a Starlink satellite link to Haven, a ground Linux bridge. The node on Haven drives an RF module via USB to inject the data directly into the 915 MHz LoRa radio band.
When the car drove about 2.5 miles away, the ground LoRa path lost connection; there was heavy vegetation and obstacles at the scene, though the video did not measure data sufficient to isolate the exact cause. Data Slayer pulled off a super cool on-site solution: he hung a micro MCU development board just a few centimeters square beneath a small drone and flew it directly above the tree canopy. Flashed with the open-source RTNode routing firmware, the board listened for broadcasts in mid-air. After climbing higher, triggering an Announce, and retrying repeatedly, the offline phone finally received this message that spanned the public Internet, satellites, jungle, and the sky.
Using a drone as an aerial relay not only demonstrates the resilience of wireless nodes under terrain obstacles, but the cost of building it by hand is also very attractive. The video author calls this Heltec V4 integrating an ESP32-S3 and SX1262 “a $20 transport node”. It does not require a full operating system, but still needs a LoRa radio, compatible firmware, matching wireless parameters, and power supply; a basic development board with only an ESP32 cannot directly serve as this relay. Although the long-distance segment of this test still used the Internet and Starlink, what it demonstrated was incredibly satisfying: even though the path crossed 5 segments of carriers, the cryptographic identity, application logic, and messaging protocol at both sending and receiving ends did not have to be rewritten for each segment.
Reticulum doesn’t follow the conventional TCP/IP path, but instead rewrote an independent networking stack from scratch in user space. While browsing the web normally relies on IP addresses and DNS domain names to find devices, Reticulum does away with IP at the bottom layer altogether.
In the world of Reticulum, finding a device relies entirely on the cryptographic Identity. Every endpoint or service generates an Identity containing an X25519 encryption public key and an Ed25519 signature public key. By hashing the Identity together with the application name and aspects, a 128-bit Destination address can be calculated:
destination = trunc128(SHA256(name_hash || identity_hash))
Doing so directly decouples device location from identity. The address only represents a specific application endpoint, regardless of where you are, what subnet you use, or what medium you travel across. Even if a device switches from LAN to Wi-Fi, or from Starlink to LoRa, its Destination address remains completely unchanged.
Finding paths relies on signed Announce broadcasts throughout the
network. Inbound SINGLE Destinations that need to publish
reachability proactively send an Announce; Transport nodes along the way
verify the signature, record in their routing table which interface the
next hop should take to reach this Destination, and then forward it
outward according to rules. There is no central brain holding a complete
map across the entire network—packets move toward their destination
entirely guided by next-hop instructions.
Various different media are neatly organized under this architecture. Reticulum abstracts all physical links into a unified Interface. For the exact same RNS packet, when traveling over the public Internet it is wrapped in a TCP packet, when traveling over a serial port it is sent directly as raw bytes, and when flying through the air it becomes a LoRa RF frame. Haven doesn’t need to translate LXMF messages into another application protocol; instead, it hands off the routing envelope from the TCP/Starlink side to the LoRa interface based on the RNS path, while the node on the drone simply continues forwarding between two LoRa hops.
Throwing network protocols into the infrastructure-less wilderness brings various physical constraints knocking immediately. Reticulum came up with many ingenious tricks at the protocol layer.
Mountains and dense trees blocking radio signals pose the first major obstacle. This ground configuration lost connection at about 2.5 miles; after the drone climbed above the canopy, the path was eventually restored, though this before-and-after comparison lacked controlled variables, so the failure cannot be definitively attributed to line-of-sight terrain blockage. Reticulum allows users to explicitly configure an instance running it as a Transport Node; this role is disabled by default, and practical networks typically designate only a small number of stable, well-positioned nodes to handle forwarding. The high-altitude drone relay is just a fun example—fixed high-elevation nodes, tethered balloons, or other continuously powered relays could also provide alternative paths. The source code sets the minimum media bitrate for establishing a Link to 5 bps, indicating that the control plane accounts for extremely low-speed links; this does not mean a link can be established under any arbitrary weak signal, nor does it imply 5 bps is sufficient for normal chatting or file transfers.
Extremely uneven transmission bandwidth is the second obstacle. Fiber Ethernet can swallow thousands of bytes in a single gulp, whereas the LoRa radio channel is meagerly narrow. Reticulum designed a three-tiered progression at the transport layer: - Packet: Suitable for single short messages, with a default MTU of only 500 bytes to keep overhead low in narrow channels. - Link: Establishes a verified, two-way encrypted session between both ends, automatically negotiating ephemeral keys and featuring forward secrecy by default. - Resource: Specifically designed to haul large payloads like images or files. A Resource automatically fragments, compresses, sends in order, and reassembles on the receiving end over a Link.
Ensuring security in an unmanaged network is the third major
obstacle. The SINGLE/Link LXMF messages used in the video
are designed by protocol to be end-to-end encrypted, and under normal
circumstances relays do not need a payload key; without compromising the
private key, relays cannot forge a legitimate sender’s signature either.
However, PLAIN traffic, Announce, and certain control or
proof packets are exceptions, where routing and lower-layer link
metadata remain visible; thus, acquiring relay hardware cannot be
generalized as seeing nothing but encrypted gibberish.
Of course, compared to mature telecom infrastructure, physical constraints for geek projects remain objectively present. LoRa is a low-bandwidth, half-duplex shared medium where airtime, retransmissions, and spectrum regulations jointly constrain capacity, making it suitable for sending short texts and control commands rather than supporting high-frequency real-time voice; mobile OS background sleep occasionally drops wireless connections as well. Yet none of this prevents Reticulum from being an eye-opening engineering archetype.
Reticulum’s starting point was building an unconstrained mesh network in the wilderness, but the engineering philosophy it highlights is equally inspiring for AI Builders who deal with models and APIs every day. Shifting our eyes away from radio waves and development boards to translate Reticulum’s decoupling philosophy into AI systems sparks a number of fascinating directions.
Current Agent architectures depend heavily on cloud control nodes and stable public internet APIs. If Reticulum’s networking capabilities are introduced to edge Agents—such as small models running on Raspberry Pis, phones, or in-vehicle head units—Agents could directly exchange messages via Bluetooth, Wi-Fi, or even LoRa in disconnected or local network environments. Reticulum can provide offline addressing, path discovery, and message transmission for these Agents; the application layer still needs to define Tool descriptions, capability matching, scheduling, task delegation, and result confirmation on its own, as Announce and Transport themselves will not perform these tasks automatically.
In many Agent frameworks, an Agent’s identity is always intertwined with deployment URLs, container IPs, or cloud vendor Client IDs. Once a server migrates, context and identity frequently vanish into thin air. Reticulum’s design—where addresses follow keys rather than IPs—provides a remarkably clean reference for Durable Agents: an Agent’s primary identity key, task memory, and state continuity should be thoroughly decoupled from the underlying execution environment. Even if servers or model providers are changed, the Agent’s cryptographic identity and uncompleted task contracts remain completely safe and sound.
Reticulum forces developers to figure out protocol efficiency within a 500-byte MTU limit. By contrast, current AI development is accustomed to squandering tokens, stuffing JSON packets with all sorts of redundant fields. If we need to transmit Agent intents and decisions over severely bandwidth-constrained channels—such as satellite communications or between edge devices—we must design tighter Agent protocols. Stripping away natural language filler and compressing tool calls and structured reasoning into compact binary payloads is an indispensable step for Agents moving into real-world constrained environments.
When deploying edge AI models to wilderness drones, cameras, or edge sensors, after configuring interfaces, wireless parameters, forwarding nodes, and reachable paths, Reticulum can carry control and telemetry messages while providing end-to-end encryption for suitable Destination types. AI can complete perception and inference at edge nodes, pushing high-value, minimal event summaries back to the control side over this message path. Anti-jamming, anti-blocking, and survivability still depend on RF design, redundant paths, power supplies, and deployment topologies—the protocol itself does not guarantee these properties.