Skip to content

Frequently Asked Questions

faragher edited this page Aug 17, 2024 · 12 revisions

So what is ...

Reticulum: A cryptographically centered network stack. Also generally refers to the entire project and associated systems.

RNS: The Reticulum Network Stack: the routed network stack underlying all of Reticulum.

Shared Instance: The RNS only starts once per machine, and all other programs connect to it. However, if the first one goes down, they all lose their connection. This is why the RNS daemon (rnsd) is run as a service or prior to any other application.

Sideband: A cross platform, Kivy powered, GUI messenger app. It includes image, voice, and telemetry features, including distributed telemetry and situation mapping.

Nomad Network: A terminal-based messenger app that also includes distribution net, page, and page viewing capabilities.

MeshChat: A cross platform messenger app that includes image, voice, and additional features, such as preliminary page viewing capabilities. Under rapid development.

Distribution Net: An E2EE message store to allow storage of messages for offline destinations.

LXMF: Lightweight Extensible Message Format. A message format built for Reticulum that supports text or binary encoded information. Typically uses "fields," which are msgpack'd byte arrays that allow images, audio, files, telemetry, etc. to be attached to message and handed by the end user while maintaining full backwards compatibility (a new field or message type will remain unhandled, but feed bad data into the app)

_**LXMRouter: **_The system that actually routes LXMF messages, and is run behind the scenes for Sideband, NomadNet, and MeshChat.

How is Reticulum different from Insert System Here?

It's hard to say without knowing both systems rather well. Reticulum is a routed network stack that functions over multiple media, physical and virtual, including TCP, RF, Serial, and I2P.

If you're asking about a messenger app, then you're comparing it to Sideband or Nomad Network, which uses LXMF to transmit messages over Reticulum.

If you're asking about a LoRa radio messenger, then it provides multiple physical interfaces beyond LoRa.

If you're asking about a file transfer app, then LXMF can transfer files across Reticulum with E2EE.

If you're asking about voice transmissions, then LXMF uses CODEC2 to transmit voice at approximately 2400 bps while still being intelligible. Due to the limitations of CODEC2, this will not be the quality of typical VoIP, but a custom Reticulum app could provide VoIP-like communications over high-speed links.

If you're a developer, it's a network stack. It transfers data. It is end to end encrypted and uses ephemeral AES encryption over links established using public/private key exchanges. It currently lacks multicast (for encryption reasons) but the "group" destination with distributed routing is currently under development.

Reticulum prizes efficiency, decentralization, and security. Without examining other projects from the ground up, this is as good a primer as possible.

What's the legality of the system?

This is not legal advice, as even if a contributor is a lawyer, they are not your lawyer.

So long as encrypted communication is legal in your jurisdiction, it's almost certain Reticulum itself is legal. Reticulum is always encrypted, so any law preventing encryption will affect its legality.

In many jurisdictions, transmitting encrypted data over the radio is restricted, especially in amateur radio bands. Any license will clearly state what can and cannot be done on the band, be it a public or private band.

Unlicensed bands vary greatly between band and jurisdiction. This can cover not just frequency, but duty cycle and radiated power (both in raw dBm and in directed power, taking into account a directional antenna). For example, Digikey provides some basic guidance regarding LoRa products, but even this requires substantial investigation to ensure compliance. Many of the supported RNode boards from LilyGO are both FCC certified and are within frequency and power limits for most regions.

If your jurisdiction has laws regarding "service providers" for E2EE messengers, the distribution network functionality of NomadNet can be disabled, turning a node into a router without any storage of user data (which is encrypted and unavailable to the server in any case). Similarly, a node doesn't need to have a TCP server, further isolating the node from such restrictions.

Reticulum is as legal as any other system providing the same functionality, so laws regarding encryption over the Internet, radio, telephone, wire, broadcast, etc. all apply. This is a tremendously complicated field, and if there's any question, a specialist attorney would need to be told the specific application in question.

What's to stop someone from flooding the network?

As a routed network, a packet sent to a single destination would go through a single path and likely jam a single router. Sending packets to multiple other destinations would cause issues for local routers, but the larger network would be less affected as paths diverge. This is generally true of all routed networks, and proper interface settings and topography can assist in a single router's overload not affecting the wider network.

There is a conceptual threat behind using announces, which are generally a TTL enabled flood route, but there are systems in place to mitigate this.

First, annouces have a bandwidth cap. No matter the number of announces pending, a router will use the bulk of its bandwidth for transmitting messages, not announces. Second, announce flood triggers special logic that prevents unknown destinations from broadcasting large numbers of announces, allowing known-good destinations to continue unimpeded operation and queuing any suspicious announces until they can be rebroadcast at a reasonable rate after the burst has concluded. Third, individual servers can limit announce rates of all destinations, preventing a destination from announcing far more frequently than is useful.

What's to stop someone from flooding the radio to prevent communication?

Nothing. This is a matter for local authorities, be it law enforcement or the private owner of the band. Electronic warfare is a major discipline and solutions to this issue are of international interest. That being said, radio direction-finding is a mature technology and RF power drops off quickly, so leading enforcement to a jammer is somewhat trivial; it's like finding what light bulb was left on.

What are the system requirements for a node?

This varies significantly and is becoming far more consistent. Most Pi-like SBCs can run the network stack and a node without issue, although the Gen 1 and Zeroes tend to require manual compilation of the crypto libraries or a less secure pure-Python implementation. Through experimentation, a major node can run on a single core in the GHz class with about 780 MB of RAM. This includes file transfer and other capability, but this is application specific, as Reticulum can load a file and transfer it, requiring the file be loaded into RAM, or stream it directly with a much lower overhead. At time of writing, major nodes are running on a 2 gig VM, a Pi 4, and a 2 gig Le Potato.

A pure router written in C for microcontrollers is under development, but does not currently support all features of the network stack.

What is the range of an RNode

Line of sight.

The distance varies so wildly, that's the best answer available. Tests from a node in a house to inside a car across hilly, wooded terrain had links available to around one kilometer. Some tests in major cities had a range of a hundred meters. SSH sessions have been successfully used over 16 kilometers. Much greater distances have been reported with more or less evidence available.

The location of the antenna will make a substantial difference, as will the intervening terrain. Models are only available for determining the effects of changes on a known system, not to estimate range whole cloth.

What is the power consumption of an RNode?

Depends on the hardware. ESP32 based devices idle at around 150 mA for planning numbers, and varies wildly with transmit power.

nRF52 based systems have dramatically lower idle power consumption.


Note: As with all wikis, this information is only as accurate as the author. More accurate but still user friendly corrections are always welcome. - Mike

Clone this wiki locally