RMAP, Crosstalk, Columba and Ratspeak: A Practical Guide to Reticulum Mesh Networking
Imagine being able to send a message from a phone or laptop without creating an account, buying a SIM card, or depending on a central messaging server. The path might use Bluetooth for the next room, Wi-Fi across a building, an RNode and LoRa for a longer hop, or TCP when an internet connection is available. The application does not need to change when the transport changes.
That is the promise of Reticulum, a cryptography-based networking stack for resilient local and wide-area networks. Reticulum is not one public network and it is not a single chat application. It is a toolkit that lets communities build networks over different kinds of hardware and connect independent network segments when they choose.
Several projects make that idea easier to understand and use. RMAP World publishes a live, opt-in map of discovered Reticulum interfaces. Crosstalk is a field-focused desktop and Raspberry Pi client for messaging, files, calls, network infrastructure and off-grid experiments. Columba brings Reticulum messaging and voice calls to Android. Ratspeak is a separate Reticulum-based network and application ecosystem with its own public node map, documentation, clients and embedded hardware targets. The Parallel GitHub organisation places Crosstalk alongside RNode, HaLow and other open infrastructure projects.
These projects are related, but they are not interchangeable. This article explains where each one fits, how their maps differ, what a useful test deployment looks like, and what amateur-radio operators should consider before putting encrypted traffic on the air.
Last updated: August 2026.
The Reticulum Layer Beneath The Apps
Reticulum is a network stack, not a social platform. The official project describes it as a way to build local and wide-area networks that can continue operating with high latency and very low bandwidth. It is designed to run over many interfaces, including LoRa radio, TCP/IP, I2P, serial links, Wi-Fi and other transports.
The important concepts are:
- Self-sovereign identities. A device creates cryptographic identities locally. There is no central account database that has to issue a username before the device can participate.
- Destination-based addressing. Reticulum does not use conventional source addresses in every packet. Applications announce destinations, and the network discovers paths to those destinations.
- Hop-by-hop routing. Transport-capable nodes can propagate announces, answer path requests and forward traffic for other nodes.
- End-to-end encryption. Reticulum requires encrypted communication and uses modern cryptography with forward secrecy. Applications do not need to invent a second security layer just to protect a message while it crosses the mesh.
- Interface independence. The same application can use a local interface, a TCP link, a LoRa RNode, an I2P interface or another supported transport, depending on the configuration.
- No single mandatory network. A club, neighbourhood, expedition or emergency team can operate its own Reticulum segment. Networks can remain independent or connect through mutually trusted infrastructure.
Reticulum normally runs as a Python module or service. Its configuration lives in ~/.reticulum/config, and an always-on machine can run rnsd as a shared instance for several applications. A graphical client such as Crosstalk or Columba hides much of that configuration, but the underlying model is still present.
This distinction matters because people often say “the Reticulum network” as if it were one global service. RMAP is a public discovery map. Ratspeak is a particular project and network. A private Reticulum deployment on a Raspberry Pi may never appear on either map and can still work perfectly for the people who operate it.
Reticulum also does not make every kind of metadata disappear. Encryption protects message contents and destination traffic from ordinary network inspection, but an observer may still learn something from radio activity, timing, signal strength, packet volume, public discovery settings or the physical location of a node. Privacy is improved by the architecture, not guaranteed by a slogan.
RMAP World: A Live Map Of Discoverable Interfaces
RMAP World is the most direct way to see Reticulum infrastructure in a browser. Its current map presents categories such as Backbone, RNode LoRa, I2P, TCP Client and KISS, along with map layers, a node list and details for discovered interfaces.
The useful word is discoverable. RMAP v4 does not silently scan every Reticulum node. It listens for Reticulum interface-discovery announces from operators who have explicitly enabled discovery. The RMAP guide describes the older v3 map as manually maintained and v4 as an automatic discovery map.
What RMAP Shows
Depending on what an operator publishes, a discovered interface may include:
| Information | Why it matters |
|---|---|
| Display name | Gives the operator a readable label instead of only a hash |
| Interface type | Shows whether the node is a backbone, RNode, I2P or another interface |
| Coordinates and height | Places the node on the map and helps operators understand geography |
| Radio parameters | Frequency, bandwidth, spreading factor and coding rate may be shown for an RNode |
| Reachable address | Gives compatible Reticulum clients a way to connect when the operator has published one |
| Last announce | Indicates whether the node has recently refreshed its presence |
The map is therefore both a visual directory and a diagnostic aid. It can show that a region has active transport infrastructure, help a builder find a public backbone, and make it easier to understand how a local LoRa segment might connect to a wider Reticulum network.
The Basic Discovery Configuration
The exact configuration should be checked against the current Reticulum and RMAP documentation, but the pattern looks like this:
[reticulum]
enable_transport = yes
[interfaces]
[[RMAP World]]
type = TCPClientInterface
enabled = yes
target_host = rmap.world
target_port = 4242
[[My Public Node]]
type = TCPServerInterface
enabled = yes
listen_ip = 0.0.0.0
listen_port = 4242
discoverable = yes
discovery_name = My Public Node
latitude = 3.1390
longitude = 101.6869
height = 20
The public RMAP connection is not the same thing as making every local interface public. Each interface that should appear needs discovery enabled. Location and radio parameters should be treated as public information. Do not publish a precise coordinate, public address or site description unless you are comfortable with it being visible to anyone who visits the map.
Why LoRa Nodes Need A Transport Bridge
An RNode can communicate over LoRa, but it cannot send an announce directly to a web service. To reach RMAP, a LoRa segment normally needs a Reticulum transport node that has both the radio interface and a TCP-connected interface. The transport node carries discovery traffic from the radio side to the wider network.
That is a useful lesson for every mesh project: a radio link, a routing node, a backhaul link and a public directory are four different things. A map can show the existence of a node without guaranteeing that a handheld device at a particular location can reach it.
RMAP Is A Directory, Not A Control Plane
RMAP does not control Reticulum routing and does not issue network addresses. It collects opt-in announcements and presents them in a browser. If rmap.world disappeared tomorrow, a private Reticulum network could continue routing as long as its own interfaces and transport nodes remained available.
That separation is important for resilience. Public maps are convenient for discovery and learning, but they should not become a hidden single point of failure for an emergency network. Keep local configuration, known destinations and backup routes under your own control.
Crosstalk: A Field-Oriented Reticulum Workbench
Crosstalk is a fork of Reticulum MeshChat from the Parallel project. It keeps the familiar Reticulum application features, then puts more emphasis on infrastructure visibility, configuration and field operation.
The project describes itself as a network workbench for messaging, file transfer and off-grid communication experiments. That is a better description than simply calling it a chat client because the application includes tools for understanding the Reticulum instance behind the messages.
What Crosstalk Adds
The current README highlights several areas:
- LXMF messaging, including attachments and file transfer.
- Audio calls, where the chosen Reticulum transport can support the required throughput and latency.
- Propagation-node support, allowing messages to move through infrastructure even when the recipient is not directly reachable.
- Nomad Network browsing, for accessing NomadNet pages over Reticulum.
- Infrastructure discovery, with a dedicated view for signed Reticulum interface advertisements.
- Network visualisation, showing infrastructure nodes, hop counts, radio parameters and connection state.
- Easier interface setup, including import, export, editing, deletion and predictable backend restarts.
- Cross-platform packaging, with builds for Windows, macOS and Linux, plus Docker, Raspberry Pi and Android through Termux.
The infrastructure view is particularly interesting for operators. A normal messaging window tells you whether a message was delivered. Crosstalk also tries to show what is carrying the traffic, which interfaces are present, which nodes are relay-only, and how the local configuration relates to the wider network.
Crosstalk And RMAP World
Crosstalk includes a public-backbone onboarding path with an RMAP World connection disabled by default. That default is sensible. A new user can explore the application, create local interfaces and decide whether to use public infrastructure, rather than automatically publishing a node or routing traffic through a service they have not evaluated.
RMAP and Crosstalk serve different layers:
| RMAP World | Crosstalk |
|---|---|
| Browser-based map and node directory | Installed application for users and operators |
| Receives opt-in interface-discovery announces | Configures and uses Reticulum interfaces |
| Helps people discover public infrastructure | Helps people send messages, files and calls |
| Shows a public view of selected nodes | Shows local status and infrastructure from inside the client |
A useful deployment might use Crosstalk to operate a Raspberry Pi transport node, publish that interface to RMAP, and then use the RMAP listing as one public way for other operators to find it. A private deployment can omit the RMAP connection entirely.
The Iridium IMT Experiment
Crosstalk also documents a native Reticulum interface for a USB-connected RockBLOCK 9704, using Iridium Messaging Transport. The project describes encrypted Reticulum packets over the satellite link, duplicate inbound-packet suppression, bounded LXMF retries and delivery or signal feedback in the conversation UI.
This is a good example of Reticulum’s design goal. The application does not need a new chat protocol for every transport. Instead, a difficult, slow and expensive link is implemented as another Reticulum interface, while the messaging layer continues to use LXMF.
Satellite messaging is not free and it is not a substitute for local radio coverage. The retry policy matters because every unnecessary packet can consume paid airtime. It is best treated as a specialist backhaul for situations where delay and cost are acceptable but terrestrial infrastructure is not.
Who Should Try Crosstalk?
Crosstalk is a good fit for a builder who wants to see and modify the network rather than install a minimal phone messenger. It is especially interesting for:
- Raspberry Pi transport nodes and portable field computers.
- Clubs experimenting with local Reticulum infrastructure.
- Developers who want a visible test bench for interfaces, paths and discovery.
- Emergency communications teams testing multiple backhauls.
- Operators who want desktop access to LXMF, attachments, NomadNet and calls.
The repository is MIT licensed. When building from source, its current instructions call for Python 3, Node.js 22.12 or newer, a frontend build and the Python requirements. Packaged releases are usually the better starting point for an operator; source builds are valuable when you want to audit, modify or contribute.
Columba: Reticulum Messaging On Android
Columba puts the same general networking model into a native Android application. Its repository describes it as a messaging and voice app for the Reticulum network, using LXMF for messages and LXST for voice calls.
Columba’s appeal is that it treats a phone as a real mesh endpoint rather than as a thin front end for a cloud service. It generates an identity on the device, shares identities through QR codes, and can communicate through several kinds of local or remote interface.
Columba’s Transport Choices
| Transport | Good starting use |
|---|---|
| Bluetooth LE | Nearby phone-to-phone or phone-to-device tests without a router |
| Wi-Fi | A home, clubroom or field-site local network with higher throughput |
| LoRa through an RNode | Longer-distance low-bandwidth links where suitable RNode hardware is available |
| TCP | A connection to a Reticulum transport node when internet or an IP backhaul is available |
The Columba website gives approximate examples such as about 100 metres for Bluetooth LE and 20 or more kilometres for an RNode link. Those are project-level illustrations, not guarantees. Bluetooth range depends on phones, antennas, obstacles and power settings. LoRa range depends on frequency, bandwidth, spreading factor, antenna height, terrain, legal limits and interference. A good mesh design measures the actual link instead of planning from a headline number.
More Than Text Messages
Columba includes several features that make it useful for field work:
- Encrypted LXMF text messages.
- Encrypted voice calls through LXST where the transport can carry them.
- Secure location sharing and a dedicated map view.
- Vector and raster offline maps in MBTiles format.
- NomadNet browsing over Reticulum.
- Relaying traffic for other nodes.
- Multiple local identities, with import and export for migration or backup.
- QR-code identity sharing between users.
- Custom colour themes and a native Material Design 3 interface.
The offline MBTiles support is a practical detail. A communications application that depends on a live web map is still partially dependent on the internet. Downloading or importing a vector or raster map before deployment lets the phone show the operating area after the backhaul is gone.
A Sensible Android Test
Columba’s website lists Android 12 or newer as the requirement and links to the GitHub releases and Obtainium. A first test can be small:
- Install the same release on two Android devices.
- Create a separate identity on each phone and record the backup material securely.
- Start with Bluetooth LE or the same Wi-Fi network before adding an RNode.
- Exchange identities using the in-app QR tools.
- Send a text message, then share a location.
- Turn off mobile data and Wi-Fi internet, and repeat the test over the local transport.
- Import an MBTiles map and verify that the map still works in airplane mode.
This test answers a more useful question than “does the app install?” It tells you whether the phone, permissions, local transport and identity workflow work together when the cloud is absent.
Columba is licensed under MPL 2.0. Its repository also provides release verification guidance. Treat identity backups and APK verification as part of the deployment, not as optional housekeeping.
Ratspeak And Its Public Network Map
Ratspeak presents itself as a decentralized mesh network with privacy built into the core. Its documentation and website are aimed at both users and developers, and the project targets desktop, mobile, MCU and single-board-computer form factors.
Ratspeak uses Reticulum, but it is not the same thing as RMAP World. It is an application and network ecosystem with its own community, downloads, protocol documentation and public map. The Ratspeak map gives a browser-based view with a legend for IPv4, IPv6, Radio, I2P, Yggdrasil and Manual nodes.
That map is useful as a network-specific view. It should not be interpreted as a universal inventory of every Reticulum interface in the world. RMAP and Ratspeak may display different nodes because they are collecting different announcements, from different deployments, with different registration or discovery rules.
Ratspeak’s Product Shape
The Ratspeak project lists a broad set of targets:
- Desktop clients for macOS, Windows and Linux.
- Mobile clients for iOS, Android and GrapheneOS.
- Directly flashable hardware such as the T-Deck Plus, Cardputer Adv and T-Pager.
- A browser-based flashing workflow for supported devices.
- A 12-word identity backup phrase generated during setup.
- Wi-Fi, LoRa, 5G and Bluetooth as possible data transports.
- Open documentation and community support through Discord, Telegram and GitHub.
The hardware targets are significant. A network becomes more resilient when it does not require every participant to carry a general-purpose laptop or a modern phone. A small pager-like device can be a message endpoint. An MCU board can act as a low-power field node. A desktop can provide storage, transport or a bridge to another network.
The tradeoff is complexity. Every additional device class creates more release images, radio drivers, power constraints and testing combinations. Before a deployment, confirm that the chosen build supports the transport, map format and identity workflow you need.
Ratspeak Compared With Columba
Columba is a native Android client for the Reticulum ecosystem. Ratspeak is a broader project with its own application family and hardware targets. They can be discussed together because both aim to make private mesh communication usable, but a user should not assume that installing one automatically joins the other’s community network.
The common ground is the Reticulum model: local identities, encrypted traffic, multiple transports and communication that can continue without a central messaging account. The practical difference is the surrounding ecosystem, release channel, network map and supported devices.
Parallel: The Larger Open Infrastructure Context
The buildwithparallel GitHub profile describes Parallel as a project focused on technological sovereignty, open code, owned hardware, decentralized networks, local services and durable identity. Its repository list shows why Crosstalk was included in this article rather than treated as an isolated chat fork.
Parallel’s public repositories cover several layers of the stack:
| Layer | Examples from the organisation |
|---|---|
| Reticulum applications | Crosstalk |
| RNode and radio work | reticulum-rnodes |
| IP mesh and field networking | Haven MANET IP Mesh Radio |
| Wi-Fi HaLow and OpenWrt | openwrt-morse-rpi5, OpenWrt and Morse-related forks |
| Documentation and community | The organisation profile, build guides and linked community channels |
The pieces are complementary. A Reticulum client gives users messages and identities. An RNode gives the network a radio interface. A transport node forwards traffic. A HaLow or IP mesh can provide a higher-throughput backhaul. A map gives operators a way to discover selected public infrastructure.
That layered approach is familiar to amateur radio operators. A handheld, a TNC, a digipeater, an APRS-IS gateway and a map service are not one device. They are separate components that can be combined. Reticulum projects apply the same discipline to a different protocol and a wider range of transports.
For related reading, compare this ecosystem with Haven’s Raspberry Pi and Wi-Fi HaLow MANET, OpenMANET field networking and Geogram’s off-grid peer-to-peer suite. These projects solve different layers of the off-grid problem, and the differences matter when choosing hardware and spectrum.
RMAP, Crosstalk, Columba And Ratspeak Compared
The following table is the short version:
| Project | Main role | Typical device | Transport examples | Mapping role | License or model |
|---|---|---|---|---|---|
| RMAP World | Public Reticulum interface discovery and map | Browser and public Reticulum service | Reticulum discovery announces | Maps opt-in public interfaces | Public service and open documentation |
| Crosstalk | Field-oriented messaging and network workbench | Desktop, Raspberry Pi, Linux, Windows, macOS, Termux | Configured Reticulum interfaces, RMAP, RNode, TCP, optional Iridium IMT | Local infrastructure view and network visualisation | MIT |
| Columba | Android messaging, calls and location sharing | Android phone or tablet | Bluetooth LE, Wi-Fi, RNode/LoRa and TCP | Location map and offline MBTiles | MPL 2.0 |
| Ratspeak | Multi-platform mesh application and network ecosystem | Desktop, phone, MCU and SBC | Wi-Fi, LoRa, 5G, Bluetooth and other supported links | Its own public network map | Open source project with published client and protocol documentation |
| Parallel | Broader open infrastructure project family | Hardware and software projects | IP, mesh, LoRa, HaLow and Reticulum-related work | Supports the tools that expose and operate infrastructure | Multiple repositories and licenses |
The choice is not necessarily one project or another:
- Use RMAP when you want to inspect public Reticulum infrastructure or publish an opt-in node.
- Use Crosstalk when you want a desktop or field computer that exposes network configuration and infrastructure state.
- Use Columba when the phone is the primary field device and you want local messaging, calls and offline maps.
- Explore Ratspeak when you want a broader multi-platform ecosystem with embedded device targets and a network-specific map.
- Look at Parallel’s organisation when you are interested in the radio, IP mesh and hardware layers beneath the application.
A Practical Path From Browser To Field Network
You do not need to build a global mesh on the first day. A staged test avoids confusing application problems with radio or routing problems.
Stage 1: Observe
Open RMAP World and Ratspeak’s map. Compare the legends, node categories, update behaviour and available details. Notice that one map can show a node that the other does not. That is expected because the maps represent different discovery or registration views.
Stage 2: Test Two Local Endpoints
Use two phones with Columba over Bluetooth LE or one local Wi-Fi network. Alternatively, run Crosstalk on two computers. Create separate identities, exchange them, send messages and confirm that the test still works when the internet connection is removed.
Stage 3: Add A Transport Node
Run Reticulum on a Raspberry Pi or another always-on machine and enable transport only when the machine is suitable for forwarding other people’s traffic. Add a TCP interface for an IP backhaul or an RNode interface for LoRa. Test the path with the local tools before publishing anything publicly.
Stage 4: Add Offline Maps
For a field exercise, import or download the required MBTiles in Columba or the chosen client while connected. Test map panning, zooming and location display with the phone offline. A map that has not been cached before deployment is not an offline map plan.
Stage 5: Publish Selectively
If you want other operators to find a public node, set discoverable = yes only on the intended interface, add an approximate location if appropriate, and review the resulting RMAP entry. If the node is private, keep discovery disabled and share identity or connection details directly with the people who need them.
A Useful Test Checklist
- Two independent identities are backed up.
- A message works with internet access disabled.
- A message works after a relay or transport node is introduced.
- The selected radio interface has the correct frequency and legal settings.
- The phone can show its offline map without tile access.
- The operator understands whether the current path uses BLE, Wi-Fi, LoRa, TCP or satellite.
- Public discovery is enabled only on interfaces intended for publication.
- Batteries, antennas, cables and spares are tested before a field deployment.
What These Projects Do Not Magically Solve
Open-source mesh software is powerful, but it does not repeal radio physics.
Range is still a system property. Antenna height, line of sight, terrain, frequency, bandwidth, transmit power, receiver sensitivity and interference determine whether a link works. A map marker does not guarantee useful coverage from the road, valley or building where an operator happens to be.
LoRa is not a high-speed backhaul. It is attractive because it can work over long distances at low power, but its throughput is limited. Text, small status updates and store-and-forward messages are sensible. Large attachments and voice calls may require a better local or IP transport.
A serverless application may still need infrastructure. Reticulum avoids a mandatory central server, but a large network benefits from transport nodes, reachable interfaces, battery power, backhaul and maintainers. “No central server” does not mean “no nodes, no routing and no operational work.”
A public map can expose more than expected. Coordinates, radio settings and reachable addresses help operators connect, but they also make an installation easier to locate. Discovery is an opt-in tradeoff, not a free privacy feature.
Voice is more demanding than text. Columba and Crosstalk can expose voice features, but the experience depends on the path. A nearby Wi-Fi or Bluetooth link is a very different environment from a multi-hop LoRa route or paid satellite link.
Interoperability is layered. A client may speak Reticulum and LXMF while still using different application features, release channels or network defaults. Check the client documentation before assuming that every feature, identity format, voice call or map exchange works across every project.
The Amateur-Radio Question
Reticulum is relevant to amateur radio because it can use radio interfaces, RNodes and low-bandwidth paths. That does not automatically make every Reticulum deployment legal on amateur frequencies.
Many Reticulum applications are designed around encryption and privacy. Amateur-radio rules differ by country and may restrict messages whose meaning is obscured, commercial traffic, unattended operation, frequencies, power, bandwidth or the use of specific digital systems. In Malaysia, operators should check the current MCMC rules and their licence conditions before transmitting encrypted Reticulum traffic on amateur allocations. Operators elsewhere should consult their own regulator.
The practical approach is simple:
- Use unlicensed or other authorised spectrum only within its local rules.
- Do not modify radio hardware or exceed permitted power and bandwidth.
- Treat a Reticulum-over-amateur experiment as a regulatory project as well as a technical project.
- Separate a legal amateur-radio test from a private community-network deployment on Wi-Fi, Bluetooth, LoRa or another authorised service.
- Keep emergency communications claims modest. A mesh test is not a substitute for a trained, tested and legally compliant emergency-communications plan.
This is where the wider ecosystem becomes useful. APRSdroid 9M2PJU Mod and the 9M2PJU LoRa APRS Tracker are amateur-radio tools with a different protocol and operating model. Haven is an IP mesh on Wi-Fi HaLow. Reticulum projects add another approach. Knowing which layer and service you are actually using is more useful than calling all of them “mesh radio.”
Why This Family Of Projects Matters
RMAP, Crosstalk, Columba and Ratspeak show a maturing pattern in open communications software. The hard part is no longer only inventing a routing protocol. It is building the surrounding experience:
- A map that makes infrastructure visible.
- A client that explains paths and interfaces.
- A phone application that handles identities and offline maps.
- Embedded targets that can operate with less hardware.
- Documentation that tells users how to build, connect and recover.
- A community that can inspect the code and keep services running.
That pattern should feel familiar to radio operators. The best amateur-radio projects are rarely just a modem or just a map. They include configuration tools, reference data, gateways, hardware notes, logging and a community that notices when something stops working.
The most interesting idea here is not that one application replaces every other application. It is that a shared network layer lets different clients and transports evolve independently. A Raspberry Pi can carry a transport interface. An RNode can provide a LoRa path. Crosstalk can expose the infrastructure. Columba can put a user on the mesh. RMAP can show a selected public node. Ratspeak can package the same general principles into a broader multi-platform experience.
That is a useful direction for off-grid communications. Build the network in layers, make the tradeoffs visible, keep identities under the operator’s control, and make the system useful even when the internet is not.
Sources And Further Reading
- Reticulum official site
- Reticulum system usage manual
- Reticulum interface documentation
- Reticulum source code
- RMAP World live map
- RMAP World information and discovery guide
- RMAP World discovered node list
- Crosstalk source repository
- Parallel GitHub organisation
- Reticulum MeshChat upstream project
- LXMF message format
- LXST voice protocol
- Columba project site
- Columba Android application source
- Columba BLE Reticulum implementation
- RNode firmware
- Ratspeak project site
- Ratspeak network map
- Ratspeak documentation
- Ratspeak source organisation
- Haven MANET article on this blog
- OpenMANET article on this blog



Post Comment