Backbone, infrastructure, edge, gateway, propagation — what the community vocabulary actually means, and why none of it appears in your config file.
Someone posts in a forum: "How do I configure my node to be a backbone node?"
It's a reasonable question. They've seen the term everywhere — in READMEs, Discord threads, the RNS directory listings. They assume there's a setting somewhere. A node_role field. A dropdown. A firmware flash.
Open your Reticulum config file and search for node_type. You won't find it. There is no field, no flag, no designation that makes a node a "backbone node" or any other named type. The protocol doesn't have that concept.
The official documentation does draw one meaningful protocol-level distinction: a Reticulum instance (any running stack) versus a transport node (an instance with enable_transport = yes in its config). Transport nodes actively forward traffic for others, propagate path announces, and serve as routing intermediaries. Instances without transport enabled can still send and receive — they just won't relay for the rest of the network. That's a deliberate trade-off for edge and mobile setups where forwarding overhead isn't worth the cost.
So there is one protocol-level toggle that matters. What the protocol doesn't have is the richer vocabulary the community uses: backbone, infrastructure, gateway, propagation node. Those describe roles that emerge from configuration and context — and that's what this article is about.
enable_transport = noenable_transport = yesA backbone node is one that other nodes depend on for long-distance path establishment. The term describes a role — not a configuration state. In practice, a backbone node has four characteristics:
BackboneInterface type — designed for efficient, high-scale interconnects and faster than plain TCPClientInterface at volume.directory.rns.recipes, rmap.world, or a similar public resource so other nodes can peer with it. An unlisted backbone node serves only whoever already knows its address.If your node peers with rns.beleth.net or rmap.world, you are using backbone nodes. Those remote peers are the backbone. Your node is an edge node that hangs off of it — which is exactly the right setup for most operators.
The backbone matters because Reticulum doesn't broadcast traffic blindly — it establishes paths. When your node wants to reach a destination it has never contacted, it sends a path request outward. Backbone nodes propagate that request across the network and carry the path announce back. Without them, Reticulum works fine locally but cannot bridge distant mesh segments.
A backbone node is a type of infrastructure node — but not all infrastructure nodes are backbone nodes. Infrastructure means any node whose primary purpose is to serve the network rather than serve a user directly.
Backbone nodes are the highest tier: always-on, internet-reachable, foundational to long-distance routing. But several other node types also count as infrastructure without being backbone nodes:
Reticulum's messaging layer (LXMF) is store-and-forward by design. A propagation node stores messages for destinations that are currently offline and delivers them when the destination node announces itself. Without propagation nodes, messages sent to offline nodes are simply lost. Running lxmfd alongside rnsd is what makes a node a propagation node — still no special config flag, just an additional service.
Any node running NomadNet can serve pages at n:// addresses — Reticulum's equivalent of a web server. A node that stays online to keep its pages available is functioning as infrastructure for anyone navigating the mesh.
Hardware nodes running RNode firmware with no user apps attached. Pure radio forwarding at the LoRa layer — no CPU cycles spent on user interfaces. When an RNode is paired with rnsd (common in gateway setups), the interface can be configured with mode = ap to optimize for local access point behavior rather than full mesh flooding, which is useful when the node's primary role is connecting nearby clients to the backbone rather than relaying across a wide area.
Nodes that bridge two physical link types: for example, a LoRa radio interface and a TCP/IP backbone interface in the same rnsd config. The bridging happens automatically — Reticulum doesn't care that two interfaces are different media types. A gateway is infrastructure for the people within LoRa range of it, and an edge node from the backbone's perspective.
A gateway occupies two roles simultaneously. Nodes within LoRa range see it as local infrastructure — their connection to the wider network. The backbone sees it as an edge node that checks in and syncs traffic. Both views are correct. The same node, described from different vantage points.
Here is every term the community uses, what it actually means, how to recognize one, and a note on whether it's protocol-defined or community shorthand.
| Term | What it means | How you become one | Origin |
|---|---|---|---|
| Transport node | An instance with enable_transport = yes set. Actively forwards traffic for others, propagates path announces, serves as a routing intermediary. The protocol's own term. |
Set enable_transport = yes in your Reticulum config. Edge/mobile nodes often leave this off to reduce overhead. |
Protocol |
| Backbone node | Always-on, internet-connected, transport-enabled, publicly listed. Others depend on it for long-distance path establishment. Often uses BackboneInterface for scalable high-throughput peering. |
Stable hardware + enable_transport = yes + TCP/BackboneInterface to peers + directory listing + uptime. |
Community |
| Infrastructure node | Umbrella term. Any node that serves the network rather than a user. Backbone nodes, propagation nodes, and page hosts all qualify. | Run services other nodes depend on. Stay online. | Community |
| Gateway node | Bridges two physical link types — e.g. LoRa radio to TCP/IP backbone. Infrastructure for local mesh; edge node from backbone's perspective. | Configure both a radio interface and a TCP interface in the same rnsd config. |
Community |
| Propagation node | Runs LXMF propagation. Stores messages for offline destinations and delivers them when the destination announces itself. | Run lxmfd alongside rnsd. Announce as propagation node in config. Stay online. |
Community |
| Edge node / leaf node | End-user device. Originates and receives traffic but isn't a relay anchor. Transport is often disabled to reduce overhead, though edge nodes with enable_transport = yes will still opportunistically forward. |
Default state for most operators. Run NomadNet or Sideband and connect when needed. | Community |
| Mobile node | Intermittently connected. Checks in, syncs LXMF messages, drops off. Designed around store-and-forward. | Any device that connects and disconnects: laptop in the field, phone running Sideband. | Community |
| BackboneInterface | A dedicated interface type optimized for high-scale, efficient interconnects between transport nodes. Faster and more scalable than plain TCPClientInterface at volume. Used by most public backbone nodes. |
Configure [[BackboneInterface]] in place of TCPClientInterface when connecting to or serving as a backbone peer. |
Protocol |
| RNode relay | LoRa-only hardware node. No user apps. Pure radio forwarding at the lowest overhead point in the stack. | Flash RNode firmware to a compatible device. Run without rnsd or any user-facing software. |
Hardware |
You don't configure a type. You configure capabilities. The role follows from what you run and how reliably you run it.
enable_transport = yes in your Reticulum configrnsd persistently as a systemd serviceBackboneInterface or TCP interfaces to existing backbone peersdirectory.rns.recipes or equivalentrnsd with stable connectivity (see backbone)lxmfdenable_propagation = yes in lxmfd configRNodeInterface in config.yml for your radioTCPClientInterface pointing to a backbone nodernsd — the bridge is automaticrnsd directlyMeshtastic and MeshCore use explicit role assignment. You pick "Router" or "Client" in a menu, and the firmware adjusts its retransmit behavior accordingly. The role is a configuration state.
Reticulum takes a different approach. The only protocol-level toggle is enable_transport — and even that is intentionally minimal. The protocol avoids rigid node roles because Reticulum is designed to run across wildly different media: LoRa radio, TCP/IP, I2P, serial links, audio modems. Brittle assumptions about what a "router" or "client" should do would break across those media boundaries. Instead, roles emerge from what a node actually does — how long it stays online, what interfaces it runs, which services it offers — and the community vocabulary describes those emergent roles.
A node becomes infrastructure the moment other nodes start routing through it consistently. The vocabulary — backbone, gateway, propagation — just gives us a shared way to describe that. The role is defined by who depends on you, not by your config.
This is why the forum question "how do I configure my node to be a backbone node?" doesn't quite have a direct answer. You set enable_transport = yes, configure interfaces, run services, and stay online. The network decides what you are based on whether it relies on you. The label follows the reality — not the other way around.
Two command-line tools let you observe the network topology as your node experiences it. rnstatus shows all active interfaces, their link states, and current traffic stats — useful for confirming your backbone peers are actually connected. rnpath <destination_hash> traces the path your node would use to reach a given destination, showing you exactly which transport nodes it routes through. Running these after connecting to a backbone peer makes the whole routing model concrete.
Transport nodes and propagation nodes carry real overhead. A busy propagation node with many active peers can consume around 280 MB of RAM under load. Backbone nodes benefit from stable hardware with adequate memory — a low-end VPS or a reasonably specced mini PC handles it fine, but a single-board computer with 512 MB RAM will struggle under heavy propagation load. Edge and mobile nodes that leave enable_transport disabled sidestep this entirely.
If you want to stand up a backbone node, start with the Multi-Interface Node guide — it covers the rnsd config, systemd setup, and TCP interface configuration in detail. For gateway builds, any always-on Linux device with a serial-connected RNode radio and a TCP interface in its config is already doing the job — a used mini PC running Ubuntu is a perfectly capable gateway for under $100.
The Reticulum source and protocol specification live at reticulum.network. For a live backbone directory, see rmap.world and directory.rns.recipes.