Compare commits
110 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 9e18a6d1a8 | |||
| 34fd72dc97 | |||
| ed9df7b211 | |||
| 965dbca514 | |||
| f08272c853 | |||
| 843891cdd3 | |||
| a6d59b1fa7 | |||
| 51d1d9fbfd | |||
| de1358be8b | |||
| 4eb5dbc633 | |||
| a1e6ce2357 | |||
| 16e833ddb7 | |||
| 4af35bd7ea | |||
| 7d305527e9 | |||
| 1d84dc94a0 | |||
| f825ba38a0 | |||
| f076c2d143 | |||
| 58a20fffb5 | |||
| 15a123875f | |||
| 7cadb3af8b | |||
| 01984a33eb | |||
| 7329817d95 | |||
| ad4af7dd50 | |||
| f2a778ffa4 | |||
| 1a77b5752c | |||
| 2b3d6a0989 | |||
| 0b508a04b8 | |||
| 13aebeecf9 | |||
| 47d3c640d6 | |||
| 19f27598d9 | |||
| f2ef22e1a0 | |||
| 251e1b8a35 | |||
| 5de4e24a9f | |||
| 5e4d32c4c0 | |||
| e1327842b1 | |||
| c13412369a | |||
| 18e4e66db8 | |||
| 5392d635dd | |||
| e56e80aade | |||
| 994c4fd699 | |||
| ef64fefa96 | |||
| 344ff21c1e | |||
| d34e06cb8c | |||
| 8f65a0320b | |||
| b42e1c93da | |||
| e0ca14eb21 | |||
| 48fe97291b | |||
| f400fd7b60 | |||
| fd1d464f06 | |||
| 28afdb36fe | |||
| 6c7db096fc | |||
| 5a7fcb0ec3 | |||
| d647da7a4a | |||
| d7df390bb4 | |||
| 9d36ff48dd | |||
| 8743388263 | |||
| 58486654d5 | |||
| 326d719a49 | |||
| c9b6dc007a | |||
| 1bcac5e234 | |||
| dad58e14e2 | |||
| db85939322 | |||
| 4f4eb1fce5 | |||
| e55000ee1a | |||
| 9c2bf9fba8 | |||
| 563784573b | |||
| e2903f18da | |||
| 2f47456668 | |||
| 79b3101fe0 | |||
| 9788675934 | |||
| 10c63fcaa2 | |||
| 707c012318 | |||
| 3f30e17eb4 | |||
| 9eff138c3c | |||
| b0fb5d1898 | |||
| d542da38b2 | |||
| c8b446ecaf | |||
| 6ed6af5b98 | |||
| 12d39916b9 | |||
| 12d4de0619 | |||
| 7ab87f688a | |||
| 9024a277ac | |||
| fc00d9a5aa | |||
| 106a773f22 | |||
| 93d9cb3b69 | |||
| 99504b7f7d | |||
| 72c1995551 | |||
| 3d8c6c3839 | |||
| 0a06ffd074 | |||
| 12abb544bf | |||
| 78fe132cc2 | |||
| b516d7f092 | |||
| 0961df316f | |||
| 8ad2986877 | |||
| 6214487fb3 | |||
| 2219a5454c | |||
| 712a5d1b06 | |||
| cbc3b800fb | |||
| e7348d0812 | |||
| 59e638402c | |||
| bcd6de015d | |||
| b798c84160 | |||
| 708f666787 | |||
| 4f03302ae2 | |||
| d8f6ab206b | |||
| 472e69fe9a | |||
| aeed5279f8 | |||
| f3b8965fa6 | |||
| 1bbaab1db9 | |||
| bf2fcbba37 |
@@ -93,6 +93,6 @@ jobs:
|
||||
# .artifacts/documentation/latex/reticulumnetworkstack.pdf
|
||||
# .artifacts/documentation/epub/ReticulumNetworkStack.epub
|
||||
draft: true
|
||||
generate_release_notes: true
|
||||
generate_release_notes: false
|
||||
prerelease: ${{ contains(github.ref, '-') }}
|
||||
fail_on_unmatched_files: true
|
||||
|
||||
@@ -13,3 +13,4 @@ tests/rnsconfig/storage
|
||||
tests/rnsconfig/logfile*
|
||||
*.data
|
||||
*.result
|
||||
.buildinfo.bak
|
||||
|
||||
@@ -1,3 +1,47 @@
|
||||
### 2026-01-04: RNS 1.1.0
|
||||
|
||||
Enjoy.
|
||||
|
||||
**Changes**
|
||||
- Added on-network global interface discovery. Hello world.
|
||||
- Added discovered interface auto-connection. Robotic.
|
||||
- Added external IP resolution for discovery-enabled interfaces. Snip-snip.
|
||||
- Added encrypted interface discovery announces. Welcome home.
|
||||
- Added bootstrap interface functionality. Decent.
|
||||
- Added blackhole handling and management. Thank the Chinese guy.
|
||||
- Added distributed blackhole list publishing and updating. Spammers go home.
|
||||
- Added foundational network identity implementation. All your base.
|
||||
- Added `await_path` method to API. Tick-tock.
|
||||
- Added reverse-unicast peer discovery packet mechanism to AutoInterface. Ping-pong.
|
||||
- Added custom identity support to `rncp`, thanks MikelCalvo!
|
||||
- Added monitor mode to `rnstatus`, thanks MikelCalvo!
|
||||
- Improved announce processing. Swoosh.
|
||||
- Updated documentation quite a bit. Looky.
|
||||
- Enabled per-peer ingress limiting on Weave and Auto interfaces. Hammertime.
|
||||
- Fixed **the** typo, yes it's the olny one I'm sure.
|
||||
- Fixed bugs. Squish.
|
||||
|
||||
**Release Hashes**
|
||||
```
|
||||
180b8baec2ec7d21abe2cec25ff763e70b2129c012fb02fc23c2fd654f94c1f5 dist/rns-1.1.0-py3-none-any.whl
|
||||
d9e32caf66a9c53199e901d2c173e1de1bf50f1f0c9d5250e5d1b3b07bedcd7c dist/rnspure-1.1.0-py3-none-any.whl
|
||||
```
|
||||
|
||||
### 2025-11-19: RNS 1.0.4
|
||||
|
||||
This maintenance release adds improved handling for RNodes with a PA/LNA combo.
|
||||
|
||||
**Changes**
|
||||
- Improved handling for RNodes with PA/LNA combo
|
||||
- Added interference detection stats to `rnstatus` output for RNode interfaces
|
||||
- Updated documentation
|
||||
|
||||
**Release Hashes**
|
||||
```
|
||||
7a2b7893410833b42c0fa7f9a9e3369cebb085cdd26bd83f3031fa6c1051653c rns-1.0.4-py3-none-any.whl
|
||||
ee647e7b3b94abdf1fab618a861390531a4aacc93eecce12c9e97280195c0e2d rnspure-1.0.4-py3-none-any.whl
|
||||
```
|
||||
|
||||
### 2025-11-19: RNS 1.0.3
|
||||
|
||||
This release includes updates to RNode BLE reliability, and adds support for connecting RNodes to a host over WiFi and Ethernet.
|
||||
@@ -11,8 +55,8 @@ This release includes updates to RNode BLE reliability, and adds support for con
|
||||
|
||||
**Release Hashes**
|
||||
```
|
||||
6bafde4c838ad778bf6878967e84c798e34d6ca621b255f59a60f38cb04ac138 dist/rns-1.0.3-py3-none-any.whl
|
||||
f277899f95c1189c6bf3beb40ac656c8b36dfd3d7e4cfb2bc3b4a1e6dc3484fa dist/rnspure-1.0.3-py3-none-any.whl
|
||||
6bafde4c838ad778bf6878967e84c798e34d6ca621b255f59a60f38cb04ac138 rns-1.0.3-py3-none-any.whl
|
||||
f277899f95c1189c6bf3beb40ac656c8b36dfd3d7e4cfb2bc3b4a1e6dc3484fa rnspure-1.0.3-py3-none-any.whl
|
||||
```
|
||||
|
||||
### 2025-11-10: RNS 1.0.2
|
||||
|
||||
@@ -8,21 +8,28 @@ Apart from writing code, there are many ways in which you can contribute. Before
|
||||
|
||||
First and foremost, there is one simple requirement for taking part in this community: While we primarily interact virtually, your actions matter and have real consequences. Therefore: **Act like a responsible, civilized person** - especially in the face of disputes and heated disagreements. Speak your mind here; discussions are welcome. Just do so in the spirit of being face-to-face with everyone else. Thank you.
|
||||
|
||||
In order to keep the discussion forums and issue trackers navigable and useful, the following types of posts will be deleted without notice:
|
||||
|
||||
- Spam.
|
||||
- Questions that have already been adequately answered elsewhere. Use the search function.
|
||||
- Low-effort posts or comments that contain no actual information or useful content. This is not a tea-house.
|
||||
- Post or comments solely containing personal opinions or beliefs without adding anything to the discussion. Facebook and X exists.
|
||||
- Content that simply waste the developer's / maintainer's time with completely obvious "ideas", "insights" or "recommendations". Yes, we have *at least* 8 neurons ourselves.
|
||||
- Posts that fail to understand that developing a highly complex software project with a very small amount of resources and people takes time. Imagining perfection on our behalf is useless.
|
||||
|
||||
If you're new to the community and start out your engagement with any of the above transgressions, you will simply be banned without notice or explanation, and your post will be deleted.
|
||||
|
||||
If you find this "harsh", "unfair" or "unwelcoming", go somewhere else. This is not social club, but a work environment for the people contributing to the project.
|
||||
|
||||
## Asking Questions
|
||||
|
||||
If you want to ask a question, **do not open an issue**. The issue tracker is used by people *working on Reticulum* to track bugs, issues and improvements.
|
||||
If you want to ask a question, **do not open an issue**. The issue tracker is used by people *working on Reticulum* to track bugs, issues and improvements. Instead, ask away on the [discussions](https://github.com/markqvist/Reticulum/discussions).
|
||||
|
||||
Instead, ask away on the [discussions](https://github.com/markqvist/Reticulum/discussions) or on the [Reticulum Matrix channel](https://matrix.to/#/#reticulum:matrix.org) at `#reticulum:matrix.org`
|
||||
|
||||
## Providing Feedback & Ideas
|
||||
|
||||
Likewise, feedback, ideas and feature requests are a very welcome way to contribute, and should also be posted on the [discussions](https://github.com/markqvist/Reticulum/discussions), or on the [Reticulum Matrix channel](https://matrix.to/#/#reticulum:matrix.org) at `#reticulum:matrix.org`.
|
||||
|
||||
Please do not post feature requests or general ideas on the issue tracker, or in direct messages to the primary developers. You are much more likely to get a response and start a constructive discussion by posting your ideas in the public channels created for these purposes.
|
||||
Do not post feature requests or general ideas on the issue tracker, or in direct messages to the primary developers. You are much more likely to get a response and start a constructive discussion by posting your ideas in the public channels created for these purposes.
|
||||
|
||||
## Reporting Issues
|
||||
|
||||
If you have found a bug or issue in this project, please report it using the [issue tracker](https://github.com/markqvist/Reticulum/issues). If at all possible, be sure to include details on how to reproduce the bug.
|
||||
If you have found a bug or issue in this project, please report it using the [issue tracker](https://github.com/markqvist/Reticulum/issues). Be sure to include details on how to reproduce the bug.
|
||||
|
||||
Anything submitted to the issue tracker that does not follow these guidelines will be closed and removed without comments or explanation.
|
||||
|
||||
@@ -42,9 +49,9 @@ Even new ideas and proposals that have not been approved by a maintainer, or fal
|
||||
|
||||
## Generative AI Policy
|
||||
|
||||
Contributions written using large language models (LLMs) or other generative 'AI' programs are prohibited. LLMs produce errors so frequently and in a way that is so unlike human error that issues will regularly remain undetected and slip through, even with stringent review. This is not a worthwhile tradeoff for Reticulum, especially considering the limited time maintainers have to correct these issues, and we ask that you refrain from using any such output in your contributions.
|
||||
Contributions written using large language models (LLMs) or other generative 'AI' programs are prohibited. LLMs produce errors so frequently and in a way that is so unlike human error that such issues are incredibly time-consuming to spot and fix. This is not a worthwhile tradeoff for Reticulum.
|
||||
|
||||
This applies to all official Reticlulm projects and documentation as well as all submitted issues and discussion in official channels, except in cases where language translation and/or speech recogntion technologies are required for communication. We also ask that you avoid using LLMs for troubleshooting, as results can be misleading, and instead request help in one of our [various communities](https://reticulum.network/start.html).
|
||||
This applies to all Reticulum-related projects and documentation, as well as all submitted issues and discussion in official channels, except in cases where language translation and/or speech recogntion technologies are required for communication.
|
||||
|
||||
## Contributor License Agreement
|
||||
|
||||
|
||||
@@ -0,0 +1,7 @@
|
||||
{
|
||||
"drips": {
|
||||
"ethereum": {
|
||||
"ownedBy": "0xae89F3B94fC4AD6563F0864a55F9a697a90261ff"
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,33 @@
|
||||
This repository is a public mirror. All potential future development is happening elsewhere.
|
||||
|
||||
I am stepping back from all public-facing interaction with this project. Reticulum has always been primarily my work, and continuing in the current public, internet-facing model is no longer sustainable.
|
||||
|
||||
The software remains available for use as-is. Occasional updates may appear at unpredictable intervals, but there will be no support, no responses to issues, no discussions, and no community management in this or any other public venue. If it doesn't work for you, it doesn't work. That is the entire extent of available troubleshooting assistance I can offer you.
|
||||
|
||||
If you've followed this project for a while, you already know what this means. You know who designed, wrote and tested this, and you know how many years of my life it took. You'll also know about both my particular challenges and strengths, and how I believe anything worth building needs to be built and maintained with our own hands.
|
||||
|
||||
Seven months ago, I said I needed to step back, that I was exhausted, and that I needed to recover. I believed a public resolve would be enough to effectuate that, but while striving to get just a few more useful features and protocols out, the unproductive requests and demands also ramped up, and I got pulled back into the same patterns and draining interactions that I'd explicitly said I couldn't sustain anymore.
|
||||
|
||||
So here's what you might have already guessed: I'm done playing the game by rules I can't win at.
|
||||
|
||||
Everything you need is right here, and by any sensible measure, it's done. Anyone who wants to invest the time, skill and persistence can build on it, or completely re-imagine it with different priorities. That was always the point.
|
||||
|
||||
The people who actually contributed - you know who you are, and you know I mean it when I say: Thank you. All of you who've used this to build something real - that was the goal, and you did it without needing me to hold your hand.
|
||||
|
||||
The rest of you: You have what you need. Use it or don't. I am not going to be the person who explains it to you anymore.
|
||||
|
||||
This is not a temporary break. It's not "see you after some rest", but a recognition that the current model is fundamentally incompatible with my life, my health, and my reality.
|
||||
|
||||
If you want to support continued work, you can do so at the donation links listed in this repository. But please understand, that this is not purchasing support or guaranteeing updates. It is support for work that happens on my timeline, according to my capacity, which at the moment is not what it was.
|
||||
|
||||
If you want Reticulum to continue evolving, you have the power to make that happen. The protocol is public domain. The code is open source. Everything you need is right here. I've provided the tools, but building what comes next is not my responsibility anymore. It's yours.
|
||||
|
||||
To the small group of people who has actually been here, and understood what this work was and what it cost - you already know where to find me if it actually matters.
|
||||
|
||||
To everyone else: This is where we part ways. No hard feelings. It's just time.
|
||||
|
||||
---
|
||||
|
||||
असतो मा सद्गमय
|
||||
तमसो मा ज्योतिर्गमय
|
||||
मृत्योर्मा अमृतं गमय
|
||||
@@ -55,6 +55,8 @@ documentation:
|
||||
manual:
|
||||
make -C docs latexpdf epub
|
||||
|
||||
build_spkg: remove_symlinks build_sdist create_symlinks
|
||||
|
||||
release: test remove_symlinks build_sdist build_wheel build_pure_wheel documentation manual create_symlinks
|
||||
|
||||
debug: remove_symlinks build_wheel build_pure_wheel create_symlinks
|
||||
|
||||
@@ -3,6 +3,8 @@ Reticulum Network Stack <img align="right" src="https://static.pepy.tech/persona
|
||||
|
||||
<p align="center"><img width="200" src="https://raw.githubusercontent.com/markqvist/Reticulum/master/docs/source/graphics/rns_logo_512.png"></p>
|
||||
|
||||
*This repository is [a public mirror](./MIRROR.md). All development is happening elsewhere.*
|
||||
|
||||
Reticulum is the cryptography-based networking stack for building local and wide-area
|
||||
networks with readily available hardware. It can operate even with very high latency
|
||||
and extremely low bandwidth. Reticulum allows you to build wide-area networks
|
||||
@@ -245,6 +247,8 @@ it is important that you read and understand the [Cryptographic
|
||||
Primitives](#cryptographic-primitives) section of this document.
|
||||
|
||||
## Public Testnet
|
||||
***Important!** As the amount of global Reticulum nodes and entrypoints have grown to a substantial quantity, the public Amsterdam Testnet entrypoint is slated for de-commisioning in the first quarter of 2026. If your own instances rely on this entrypoint for connectivity, it is high time to start configuring alternatives. Reticulum now includes a full on-network interface discovery and connectivity bootstrapping system. Read the [Bootstrapping Connectivity](https://reticulum.network/manual/gettingstartedfast.html#bootstrapping-connectivity) section of the manual for pointers.*
|
||||
|
||||
If you just want to get started experimenting without building any physical
|
||||
networks, you are welcome to join the RNS Development Testnet.
|
||||
|
||||
@@ -280,15 +284,8 @@ file:
|
||||
target_host = reticulum.betweentheborders.com
|
||||
target_port = 4242
|
||||
|
||||
# Interface to Testnet I2P Hub
|
||||
[[RNS Testnet I2P Hub]]
|
||||
type = I2PInterface
|
||||
enabled = yes
|
||||
peers = g3br23bvx3lq5uddcsjii74xgmn6y5q325ovrkq2zw2wbzbqgbuq.b32.i2p
|
||||
```
|
||||
|
||||
The testnet also contains a number of [Nomad Network](https://github.com/markqvist/nomadnet) nodes, and LXMF propagation nodes.
|
||||
|
||||
## Support Reticulum
|
||||
You can help support the continued development of open, free and private communications systems by donating via one of the following channels:
|
||||
|
||||
@@ -298,11 +295,11 @@ You can help support the continued development of open, free and private communi
|
||||
```
|
||||
- Bitcoin
|
||||
```
|
||||
bc1p4a6axuvl7n9hpapfj8sv5reqj8kz6uxa67d5en70vzrttj0fmcusgxsfk5
|
||||
bc1pgqgu8h8xvj4jtafslq396v7ju7hkgymyrzyqft4llfslz5vp99psqfk3a6
|
||||
```
|
||||
- Ethereum
|
||||
```
|
||||
0xae89F3B94fC4AD6563F0864a55F9a697a90261ff
|
||||
0x91C421DdfB8a30a49A71d63447ddb54cEBe3465E
|
||||
```
|
||||
- Liberapay: https://liberapay.com/Reticulum/
|
||||
|
||||
|
||||
@@ -462,6 +462,10 @@ class Destination:
|
||||
self.ratchets = None
|
||||
self.ratchets_path = None
|
||||
RNS.trace_exception(e)
|
||||
RNS.log(f"The ratchet file located at {ratchets_path} could not be loaded. This could indicate that the ratchet file has become corrupt.", RNS.LOG_CRITICAL)
|
||||
RNS.log(f"You can attempt to manually recover the ratchet file, or simply remove it to have Reticulum recreate it on the next use.", RNS.LOG_CRITICAL)
|
||||
RNS.log(f"If re-initialize this ratchet file, make sure to send an announce for the relevant destination as soon as possible,", RNS.LOG_CRITICAL)
|
||||
RNS.log(f"so that the new ratchet information is synchronized to the network.", RNS.LOG_CRITICAL)
|
||||
raise OSError("Could not read ratchet file contents for "+str(self)+". The contained exception was: "+str(e), RNS.LOG_ERROR)
|
||||
|
||||
else:
|
||||
|
||||
@@ -0,0 +1,672 @@
|
||||
import os
|
||||
import RNS
|
||||
import time
|
||||
import threading
|
||||
import subprocess
|
||||
from .vendor import umsgpack as msgpack
|
||||
|
||||
NAME = 0xFF
|
||||
TRANSPORT_ID = 0xFE
|
||||
INTERFACE_TYPE = 0x00
|
||||
TRANSPORT = 0x01
|
||||
REACHABLE_ON = 0x02
|
||||
LATITUDE = 0x03
|
||||
LONGITUDE = 0x04
|
||||
HEIGHT = 0x05
|
||||
PORT = 0x06
|
||||
IFAC_NETNAME = 0x07
|
||||
IFAC_NETKEY = 0x08
|
||||
FREQUENCY = 0x09
|
||||
BANDWIDTH = 0x0A
|
||||
SPREADINGFACTOR = 0x0B
|
||||
CODINGRATE = 0x0C
|
||||
MODULATION = 0x0D
|
||||
CHANNEL = 0x0E
|
||||
|
||||
APP_NAME = "rnstransport"
|
||||
|
||||
class InterfaceAnnouncer():
|
||||
JOB_INTERVAL = 60
|
||||
DEFAULT_STAMP_VALUE = 14
|
||||
WORKBLOCK_EXPAND_ROUNDS = 20
|
||||
|
||||
DISCOVERABLE_INTERFACE_TYPES = ["BackboneInterface", "TCPServerInterface", "TCPClientInterface",
|
||||
"RNodeInterface", "WeaveInterface", "I2PInterface", "KISSInterface"]
|
||||
|
||||
def __init__(self, owner):
|
||||
import importlib.util
|
||||
if importlib.util.find_spec('LXMF') != None: from LXMF import LXStamper
|
||||
else:
|
||||
RNS.log("Using on-network interface discovery requires the LXMF module to be installed.", RNS.LOG_CRITICAL)
|
||||
RNS.log("You can install it with the command: pip install lxmf", RNS.LOG_CRITICAL)
|
||||
RNS.panic()
|
||||
|
||||
self.owner = owner
|
||||
self.should_run = False
|
||||
self.job_interval = self.JOB_INTERVAL
|
||||
self.stamper = LXStamper
|
||||
self.stamp_cache = {}
|
||||
|
||||
if self.owner.has_network_identity(): identity = self.owner.network_identity
|
||||
else: identity = self.owner.identity
|
||||
|
||||
self.discovery_destination = RNS.Destination(identity, RNS.Destination.IN, RNS.Destination.SINGLE,
|
||||
APP_NAME, "discovery", "interface")
|
||||
|
||||
def start(self):
|
||||
if not self.should_run:
|
||||
self.should_run = True
|
||||
threading.Thread(target=self.job, daemon=True).start()
|
||||
|
||||
def stop(self): self.should_run = False
|
||||
|
||||
def job(self):
|
||||
while self.should_run:
|
||||
time.sleep(self.job_interval)
|
||||
try:
|
||||
now = time.time()
|
||||
due_interfaces = [i for i in self.owner.interfaces if i.supports_discovery and i.discoverable and now > (i.last_discovery_announce+i.discovery_announce_interval)]
|
||||
due_interfaces.sort(key=lambda i: now-i.last_discovery_announce, reverse=True)
|
||||
|
||||
if len(due_interfaces) > 0:
|
||||
selected_interface = due_interfaces[0]
|
||||
selected_interface.last_discovery_announce = time.time()
|
||||
RNS.log(f"Preparing interface discovery announce for {selected_interface.name}", RNS.LOG_DEBUG)
|
||||
app_data = self.get_interface_announce_data(selected_interface)
|
||||
if not app_data: RNS.log(f"Could not generate interface discovery announce data for {selected_interface.name}", RNS.LOG_ERROR)
|
||||
else:
|
||||
RNS.log(f"Sending interface discovery announce for {selected_interface.name} with {len(app_data)}B payload", RNS.LOG_DEBUG)
|
||||
self.discovery_destination.announce(app_data=app_data)
|
||||
|
||||
except Exception as e:
|
||||
RNS.log(f"Error while preparing interface discovery announces: {e}", RNS.LOG_ERROR)
|
||||
RNS.trace_exception(e)
|
||||
|
||||
def sanitize(self, in_str):
|
||||
sanitized = in_str.replace("\n", "")
|
||||
sanitized = sanitized.replace("\r", "")
|
||||
sanitized = sanitized.strip()
|
||||
return sanitized
|
||||
|
||||
def get_interface_announce_data(self, interface):
|
||||
interface_type = type(interface).__name__
|
||||
stamp_value = interface.discovery_stamp_value if interface.discovery_stamp_value else self.DEFAULT_STAMP_VALUE
|
||||
|
||||
if not interface_type in self.DISCOVERABLE_INTERFACE_TYPES: return None
|
||||
else:
|
||||
flags = 0x00
|
||||
info = {INTERFACE_TYPE: interface_type,
|
||||
TRANSPORT: RNS.Reticulum.transport_enabled(),
|
||||
TRANSPORT_ID: RNS.Transport.identity.hash,
|
||||
NAME: self.sanitize(interface.discovery_name),
|
||||
LATITUDE: interface.discovery_latitude,
|
||||
LONGITUDE: interface.discovery_longitude,
|
||||
HEIGHT: interface.discovery_height}
|
||||
|
||||
reachable_on = self.sanitize(interface.reachable_on)
|
||||
if not RNS.vendor.platformutils.is_windows():
|
||||
try:
|
||||
exec_path = os.path.expanduser(reachable_on)
|
||||
if os.path.isfile(exec_path) and os.access(exec_path, os.X_OK):
|
||||
RNS.log(f"Evaluating reachable_on from executable at {exec_path}", RNS.LOG_DEBUG)
|
||||
exec_result = subprocess.run([exec_path], stdout=subprocess.PIPE)
|
||||
exec_stdout = exec_result.stdout.decode("utf-8")
|
||||
if exec_result.returncode != 0: raise ValueError("Non-zero exit code from subprocess")
|
||||
reachable_on = self.sanitize(exec_stdout)
|
||||
|
||||
except Exception as e:
|
||||
RNS.log(f"Error while getting reachable_on from executable at {interface.reachable_on}: {e}", RNS.LOG_ERROR)
|
||||
RNS.log(f"Aborting discovery announce", RNS.LOG_ERROR)
|
||||
return None
|
||||
|
||||
if interface_type in ["BackboneInterface", "TCPServerInterface"]:
|
||||
info[REACHABLE_ON] = reachable_on
|
||||
info[PORT] = interface.bind_port
|
||||
|
||||
if interface_type == "I2PInterface" and interface.connectable and interface.b32:
|
||||
info[REACHABLE_ON] = interface.b32
|
||||
|
||||
if interface_type == "RNodeInterface":
|
||||
info[FREQUENCY] = interface.frequency
|
||||
info[BANDWIDTH] = interface.bandwidth
|
||||
info[SPREADINGFACTOR] = interface.sf
|
||||
info[CODINGRATE] = interface.cr
|
||||
|
||||
if interface_type == "WeaveInterface":
|
||||
info[FREQUENCY] = interface.discovery_frequency
|
||||
info[BANDWIDTH] = interface.discovery_bandwidth
|
||||
info[CHANNEL] = interface.discovery_channel
|
||||
info[MODULATION] = interface.discovery_modulation
|
||||
|
||||
if interface_type == "KISSInterface" or (interface_type == "TCPClientInterface" and interface.kiss_framing):
|
||||
info[INTERFACE_TYPE] = "KISSInterface"
|
||||
info[FREQUENCY] = interface.discovery_frequency
|
||||
info[BANDWIDTH] = interface.discovery_bandwidth
|
||||
info[MODULATION] = self.sanitize(interface.discovery_modulation)
|
||||
|
||||
if interface.discovery_publish_ifac == True:
|
||||
info[IFAC_NETNAME] = self.sanitize(interface.ifac_netname)
|
||||
info[IFAC_NETKEY] = self.sanitize(interface.ifac_netkey)
|
||||
|
||||
packed = msgpack.packb(info)
|
||||
infohash = RNS.Identity.full_hash(packed)
|
||||
|
||||
if infohash in self.stamp_cache: stamp = self.stamp_cache[infohash]
|
||||
else: stamp, v = self.stamper.generate_stamp(infohash, stamp_cost=stamp_value, expand_rounds=self.WORKBLOCK_EXPAND_ROUNDS)
|
||||
if not stamp: return None
|
||||
else: self.stamp_cache[infohash] = stamp
|
||||
|
||||
if interface.discovery_encrypt:
|
||||
flags |= InterfaceAnnounceHandler.FLAG_ENCRYPTED
|
||||
if not self.owner.has_network_identity():
|
||||
RNS.log(f"Discovery encryption requested for {interface}, but no network identity configured. Aborting discovery announce.", RNS.LOG_ERROR)
|
||||
return None
|
||||
|
||||
else: payload = self.owner.network_identity.encrypt(packed+stamp)
|
||||
|
||||
else: payload = packed+stamp
|
||||
|
||||
return bytes([flags])+payload
|
||||
|
||||
class InterfaceAnnounceHandler:
|
||||
FLAG_SIGNED = 0b00000001
|
||||
FLAG_ENCRYPTED = 0b00000010
|
||||
|
||||
def __init__(self, required_value=InterfaceAnnouncer.DEFAULT_STAMP_VALUE, callback=None):
|
||||
import importlib.util
|
||||
if importlib.util.find_spec('LXMF') != None: from LXMF import LXStamper
|
||||
else:
|
||||
RNS.log("Using on-network interface discovery requires the LXMF module to be installed.", RNS.LOG_CRITICAL)
|
||||
RNS.log("You can install it with the command: pip install lxmf", RNS.LOG_CRITICAL)
|
||||
RNS.panic()
|
||||
|
||||
self.aspect_filter = APP_NAME+".discovery.interface"
|
||||
self.required_value = required_value
|
||||
self.callback = callback
|
||||
self.stamper = LXStamper
|
||||
|
||||
def received_announce(self, destination_hash, announced_identity, app_data):
|
||||
try:
|
||||
discovery_sources = RNS.Reticulum.interface_discovery_sources()
|
||||
if discovery_sources and not announced_identity.hash in discovery_sources:
|
||||
RNS.log(f"Interface discovered from non-authorized network identity {RNS.prettyhexrep(announced_identity.hash)}, ignoring", RNS.LOG_DEBUG)
|
||||
return
|
||||
|
||||
if app_data and len(app_data) > self.stamper.STAMP_SIZE+1:
|
||||
flags = app_data[0]
|
||||
app_data = app_data[1:]
|
||||
signed = flags & self.FLAG_SIGNED
|
||||
encrypted = flags & self.FLAG_ENCRYPTED
|
||||
|
||||
if encrypted:
|
||||
if not RNS.Transport.has_network_identity(): return
|
||||
app_data = RNS.Transport.network_identity.decrypt(app_data)
|
||||
if not app_data: return
|
||||
|
||||
stamp = app_data[-self.stamper.STAMP_SIZE:]
|
||||
packed = app_data[:-self.stamper.STAMP_SIZE]
|
||||
infohash = RNS.Identity.full_hash(packed)
|
||||
workblock = self.stamper.stamp_workblock(infohash, expand_rounds=InterfaceAnnouncer.WORKBLOCK_EXPAND_ROUNDS)
|
||||
value = self.stamper.stamp_value(workblock, stamp)
|
||||
valid = self.stamper.stamp_valid(stamp, self.required_value, workblock)
|
||||
|
||||
if not valid:
|
||||
RNS.log(f"Ignored discovered interface with invalid stamp", RNS.LOG_DEBUG)
|
||||
return
|
||||
|
||||
if value < self.required_value: RNS.log(f"Ignored discovered interface with stamp value {value}", RNS.LOG_DEBUG)
|
||||
else:
|
||||
info = None
|
||||
unpacked = msgpack.unpackb(packed)
|
||||
if INTERFACE_TYPE in unpacked:
|
||||
interface_type = unpacked[INTERFACE_TYPE]
|
||||
info = {"type": interface_type,
|
||||
"transport": unpacked[TRANSPORT],
|
||||
"name": unpacked[NAME] or f"Discovered {interface_type}",
|
||||
"received": time.time(),
|
||||
"stamp": stamp,
|
||||
"value": value,
|
||||
"transport_id": RNS.hexrep(unpacked[TRANSPORT_ID], delimit=False),
|
||||
"network_id": RNS.hexrep(announced_identity.hash, delimit=False),
|
||||
"hops": RNS.Transport.hops_to(destination_hash),
|
||||
"latitude": unpacked[LATITUDE],
|
||||
"longitude": unpacked[LONGITUDE],
|
||||
"height": unpacked[HEIGHT]}
|
||||
|
||||
if IFAC_NETNAME in unpacked: info["ifac_netname"] = unpacked[IFAC_NETNAME]
|
||||
if IFAC_NETKEY in unpacked: info["ifac_netkey"] = unpacked[IFAC_NETKEY]
|
||||
|
||||
if interface_type in ["BackboneInterface", "TCPServerInterface"]:
|
||||
backbone_support = not RNS.vendor.platformutils.is_windows()
|
||||
info["reachable_on"] = unpacked[REACHABLE_ON]
|
||||
info["port"] = unpacked[PORT]
|
||||
connection_interface = "BackboneInterface" if backbone_support else "TCPClientInterface"
|
||||
remote_str = "remote" if backbone_support else "target_host"
|
||||
cfg_name = info["name"]
|
||||
cfg_remote = info["reachable_on"]
|
||||
cfg_port = info["port"]
|
||||
cfg_identity = info["transport_id"]
|
||||
cfg_netname = info["ifac_netname"] if "ifac_netname" in info else None
|
||||
cfg_netkey = info["ifac_netkey"] if "ifac_netkey" in info else None
|
||||
cfg_netname_str = f"\n network_name = {cfg_netname}" if cfg_netname else ""
|
||||
cfg_netkey_str = f"\n passphrase = {cfg_netkey}" if cfg_netkey else ""
|
||||
cfg_identity_str = f"\n transport_identity = {cfg_identity}"
|
||||
info["config_entry"] = f"[[{cfg_name}]]\n type = {connection_interface}\n enabled = yes\n {remote_str} = {cfg_remote}\n target_port = {cfg_port}{cfg_identity_str}{cfg_netname_str}{cfg_netkey_str}"
|
||||
|
||||
if interface_type == "I2PInterface":
|
||||
info["reachable_on"] = unpacked[REACHABLE_ON]
|
||||
cfg_name = info["name"]
|
||||
cfg_remote = info["reachable_on"]
|
||||
cfg_identity = info["transport_id"]
|
||||
cfg_netname = info["ifac_netname"] if "ifac_netname" in info else None
|
||||
cfg_netkey = info["ifac_netkey"] if "ifac_netkey" in info else None
|
||||
cfg_netname_str = f"\n network_name = {cfg_netname}" if cfg_netname else ""
|
||||
cfg_netkey_str = f"\n passphrase = {cfg_netkey}" if cfg_netkey else ""
|
||||
cfg_identity_str = f"\n transport_identity = {cfg_identity}"
|
||||
info["config_entry"] = f"[[{cfg_name}]]\n type = I2PInterface\n enabled = yes\n peers = {cfg_remote}{cfg_identity_str}{cfg_netname_str}{cfg_netkey_str}"
|
||||
|
||||
if interface_type == "RNodeInterface":
|
||||
info["frequency"] = unpacked[FREQUENCY]
|
||||
info["bandwidth"] = unpacked[BANDWIDTH]
|
||||
info["sf"] = unpacked[SPREADINGFACTOR]
|
||||
info["cr"] = unpacked[CODINGRATE]
|
||||
cfg_name = info["name"]
|
||||
cfg_frequency = info["frequency"]
|
||||
cfg_bandwidth = info["bandwidth"]
|
||||
cfg_sf = info["sf"]
|
||||
cfg_cr = info["cr"]
|
||||
cfg_identity = info["transport_id"]
|
||||
cfg_netname = info["ifac_netname"] if "ifac_netname" in info else None
|
||||
cfg_netkey = info["ifac_netkey"] if "ifac_netkey" in info else None
|
||||
cfg_netname_str = f"\n network_name = {cfg_netname}" if cfg_netname else ""
|
||||
cfg_netkey_str = f"\n passphrase = {cfg_netkey}" if cfg_netkey else ""
|
||||
cfg_identity_str = f"\n transport_identity = {cfg_identity}"
|
||||
info["config_entry"] = f"[[{cfg_name}]]\n type = RNodeInterface\n enabled = yes\n port = \n frequency = {cfg_frequency}\n bandwidth = {cfg_bandwidth}\n spreadingfactor = {cfg_sf}\n codingrate = {cfg_cr}\n txpower = {cfg_netname_str}{cfg_netkey_str}"
|
||||
|
||||
if interface_type == "WeaveInterface":
|
||||
info["frequency"] = unpacked[FREQUENCY]
|
||||
info["bandwidth"] = unpacked[BANDWIDTH]
|
||||
info["channel"] = unpacked[CHANNEL]
|
||||
info["modulation"] = unpacked[MODULATION]
|
||||
cfg_name = info["name"]
|
||||
cfg_identity = info["transport_id"]
|
||||
cfg_netname = info["ifac_netname"] if "ifac_netname" in info else None
|
||||
cfg_netkey = info["ifac_netkey"] if "ifac_netkey" in info else None
|
||||
cfg_netname_str = f"\n network_name = {cfg_netname}" if cfg_netname else ""
|
||||
cfg_netkey_str = f"\n passphrase = {cfg_netkey}" if cfg_netkey else ""
|
||||
cfg_identity_str = f"\n transport_identity = {cfg_identity}"
|
||||
info["config_entry"] = f"[[{cfg_name}]]\n type = WeaveInterface\n enabled = yes\n port = {cfg_netname_str}{cfg_netkey_str}"
|
||||
|
||||
if interface_type == "KISSInterface":
|
||||
info["frequency"] = unpacked[FREQUENCY]
|
||||
info["bandwidth"] = unpacked[BANDWIDTH]
|
||||
info["modulation"] = unpacked[MODULATION]
|
||||
cfg_name = info["name"]
|
||||
cfg_frequency = info["frequency"]
|
||||
cfg_bandwidth = info["bandwidth"]
|
||||
cfg_modulation = info["modulation"]
|
||||
cfg_identity = info["transport_id"]
|
||||
cfg_netname = info["ifac_netname"] if "ifac_netname" in info else None
|
||||
cfg_netkey = info["ifac_netkey"] if "ifac_netkey" in info else None
|
||||
cfg_netname_str = f"\n network_name = {cfg_netname}" if cfg_netname else ""
|
||||
cfg_netkey_str = f"\n passphrase = {cfg_netkey}" if cfg_netkey else ""
|
||||
cfg_identity_str = f"\n transport_identity = {cfg_identity}"
|
||||
info["config_entry"] = f"[[{cfg_name}]]\n type = KISSInterface\n enabled = yes\n port = \n # Frequency: {cfg_frequency}\n # Bandwidth: {cfg_bandwidth}\n # Modulation: {cfg_modulation}{cfg_identity_str}{cfg_netname_str}{cfg_netkey_str}"
|
||||
|
||||
discovery_hash_material = info["transport_id"]+info["name"]
|
||||
info["discovery_hash"] = RNS.Identity.full_hash(discovery_hash_material.encode("utf-8"))
|
||||
|
||||
if self.callback and callable(self.callback): self.callback(info)
|
||||
|
||||
except Exception as e:
|
||||
RNS.log(f"An error occurred while trying to decode discovered interface. The contained exception was: {e}", RNS.LOG_ERROR)
|
||||
|
||||
class InterfaceDiscovery():
|
||||
THRESHOLD_UNKNOWN = 24*60*60
|
||||
THRESHOLD_STALE = 3*24*60*60
|
||||
THRESHOLD_REMOVE = 7*24*60*60
|
||||
|
||||
MONITOR_INTERVAL = 5
|
||||
DETACH_THRESHOLD = 12
|
||||
|
||||
STATUS_STALE = 0
|
||||
STATUS_UNKNOWN = 100
|
||||
STATUS_AVAILABLE = 1000
|
||||
STATUS_CODE_MAP = {"available": STATUS_AVAILABLE, "unknown": STATUS_UNKNOWN, "stale": STATUS_STALE}
|
||||
AUTOCONNECT_TYPES = ["BackboneInterface", "TCPServerInterface"]
|
||||
|
||||
def __init__(self, required_value=InterfaceAnnouncer.DEFAULT_STAMP_VALUE, callback=None, discover_interfaces=True):
|
||||
if not required_value: required_value = InterfaceAnnouncer.DEFAULT_STAMP_VALUE
|
||||
|
||||
self.required_value = required_value
|
||||
self.discovery_callback = callback
|
||||
self.rns_instance = RNS.Reticulum.get_instance()
|
||||
self.monitored_interfaces = []
|
||||
self.monitoring_autoconnects = False
|
||||
self.monitor_interval = self.MONITOR_INTERVAL
|
||||
self.detach_threshold = self.DETACH_THRESHOLD
|
||||
|
||||
if not self.rns_instance: raise SystemError("Attempt to start interface discovery listener without an active RNS instance")
|
||||
self.storagepath = os.path.join(RNS.Reticulum.storagepath, "discovery", "interfaces")
|
||||
if not os.path.isdir(self.storagepath): os.makedirs(self.storagepath)
|
||||
|
||||
if discover_interfaces:
|
||||
self.handler = InterfaceAnnounceHandler(callback=self.interface_discovered, required_value=self.required_value)
|
||||
RNS.Transport.register_announce_handler(self.handler)
|
||||
threading.Thread(target=self.connect_discovered, daemon=True).start()
|
||||
|
||||
def list_discovered_interfaces(self):
|
||||
now = time.time()
|
||||
discovered_interfaces = []
|
||||
discovery_sources = RNS.Reticulum.interface_discovery_sources()
|
||||
for filename in os.listdir(self.storagepath):
|
||||
try:
|
||||
filepath = os.path.join(self.storagepath, filename)
|
||||
with open(filepath, "rb") as f: info = msgpack.unpackb(f.read())
|
||||
should_remove = False
|
||||
heard_delta = now-info["last_heard"]
|
||||
|
||||
if heard_delta > self.THRESHOLD_REMOVE: should_remove = True
|
||||
elif discovery_sources and not "network_id" in info: should_remove = True
|
||||
elif discovery_sources and not bytes.fromhex(info["network_id"]) in discovery_sources: should_remove = True
|
||||
|
||||
if should_remove:
|
||||
os.unlink(filepath)
|
||||
continue
|
||||
|
||||
else:
|
||||
if heard_delta > self.THRESHOLD_STALE: info["status"] = "stale"
|
||||
elif heard_delta > self.THRESHOLD_UNKNOWN: info["status"] = "unknown"
|
||||
else: info["status"] = "available"
|
||||
|
||||
info["status_code"] = self.STATUS_CODE_MAP[info["status"]]
|
||||
discovered_interfaces.append(info)
|
||||
|
||||
except Exception as e:
|
||||
RNS.log(f"Error while loading discovered interface data: {e}", RNS.LOG_ERROR)
|
||||
RNS.log(f"The interface data file {os.path.join(self.storagepath, filename)} may be corrupt", RNS.LOG_ERROR)
|
||||
RNS.trace_exception(e)
|
||||
|
||||
discovered_interfaces.sort(key=lambda info: (info["status_code"], info["value"], info["last_heard"]), reverse=True)
|
||||
return discovered_interfaces
|
||||
|
||||
def interface_discovered(self, info):
|
||||
try:
|
||||
name = info["name"]
|
||||
value = info["value"]
|
||||
interface_type = info["type"]
|
||||
discovery_hash = info["discovery_hash"]
|
||||
hops = info["hops"]; ms = "" if hops == 1 else "s"
|
||||
filename = RNS.hexrep(discovery_hash, delimit=False)
|
||||
filepath = os.path.join(self.storagepath, filename)
|
||||
RNS.log(f"Discovered {interface_type} {hops} hop{ms} away with stamp value {value}: {name}", RNS.LOG_DEBUG)
|
||||
if not os.path.isfile(filepath):
|
||||
try:
|
||||
with open(filepath, "wb") as f:
|
||||
info["discovered"] = info["received"]
|
||||
info["last_heard"] = info["received"]
|
||||
info["heard_count"] = 0
|
||||
f.write(msgpack.packb(info))
|
||||
|
||||
except Exception as e:
|
||||
RNS.log(f"Error while persisting discovered interface data: {e}", RNS.LOG_ERROR)
|
||||
RNS.trace_exception(e)
|
||||
return
|
||||
|
||||
else:
|
||||
discovered = None
|
||||
heard_count = None
|
||||
try:
|
||||
with open(filepath, "rb") as f:
|
||||
last_info = msgpack.unpackb(f.read())
|
||||
discovered = last_info["discovered"]
|
||||
heard_count = last_info["heard_count"]
|
||||
|
||||
if discovered == None: discovered = info["discovered"]
|
||||
if heard_count == None: heard_count = 0
|
||||
|
||||
with open(filepath, "wb") as f:
|
||||
info["discovered"] = discovered
|
||||
info["last_heard"] = info["received"]
|
||||
info["heard_count"] = heard_count+1
|
||||
f.write(msgpack.packb(info))
|
||||
|
||||
except Exception as e:
|
||||
RNS.log(f"Error while persisting discovered interface data: {e}", RNS.LOG_ERROR)
|
||||
RNS.trace_exception(e)
|
||||
return
|
||||
|
||||
except Exception as e:
|
||||
RNS.log(f"Error processing discovered interface data: {e}", RNS.LOG_ERROR)
|
||||
RNS.trace_exception(e)
|
||||
return
|
||||
|
||||
self.autoconnect(info)
|
||||
|
||||
try:
|
||||
if self.discovery_callback and callable(self.discovery_callback): self.discovery_callback(info)
|
||||
except Exception as e: RNS.log(f"Error while processing external interface discovery callback: {e}", RNS.LOG_ERROR)
|
||||
|
||||
def monitor_interface(self, interface):
|
||||
if not interface in self.monitored_interfaces:
|
||||
self.monitored_interfaces.append(interface)
|
||||
|
||||
if not self.monitoring_autoconnects:
|
||||
self.monitoring_autoconnects = True
|
||||
threading.Thread(target=self.__monitor_job, daemon=True).start()
|
||||
|
||||
def __monitor_job(self):
|
||||
while self.monitoring_autoconnects:
|
||||
time.sleep(self.monitor_interval)
|
||||
detached_interfaces = []
|
||||
online_interfaces = 0
|
||||
for interface in self.monitored_interfaces:
|
||||
try:
|
||||
if interface.online:
|
||||
online_interfaces += 1
|
||||
if hasattr(interface, "autoconnect_down") and interface.autoconnect_down != None:
|
||||
RNS.log(f"Auto-discovered interface {interface} reconnected")
|
||||
interface.autoconnect_down = None
|
||||
|
||||
else:
|
||||
if not hasattr(interface, "autoconnect_down") or interface.autoconnect_down == None:
|
||||
RNS.log(f"Auto-discovered interface {interface} disconnected", RNS.LOG_DEBUG)
|
||||
interface.autoconnect_down = time.time()
|
||||
|
||||
else:
|
||||
down_for = time.time()-interface.autoconnect_down
|
||||
if down_for >= self.detach_threshold:
|
||||
RNS.log(f"Auto-discovered interface {interface} has been down for {RNS.prettytime(down_for)}, detaching", RNS.LOG_DEBUG)
|
||||
detached_interfaces.append(interface)
|
||||
|
||||
except Exception as e:
|
||||
RNS.log(f"Error while checking auto-connected interface state for {interface}: {e}", RNS.LOG_ERROR)
|
||||
|
||||
if online_interfaces >= RNS.Reticulum.max_autoconnected_interfaces():
|
||||
for interface in RNS.Transport.interfaces:
|
||||
if hasattr(interface, "bootstrap_only") and interface.bootstrap_only == True:
|
||||
RNS.log(f"Tearing down bootstrap-only {interface} since target connected auto-discovered interface count has been reached", RNS.LOG_INFO)
|
||||
if not interface in detached_interfaces: detached_interfaces.append(interface)
|
||||
|
||||
if online_interfaces == 0:
|
||||
if self.bootstrap_interface_count() == 0:
|
||||
RNS.log(f"No auto-discovered interfaces connected, re-enabling bootstrap interfaces", RNS.LOG_NOTICE)
|
||||
for config in RNS.Reticulum.get_instance().bootstrap_configs:
|
||||
RNS.Reticulum.get_instance()._synthesize_interface(config, config["name"])
|
||||
|
||||
for interface in detached_interfaces:
|
||||
try: self.teardown_interface(interface)
|
||||
except Exception as e:
|
||||
RNS.log(f"Error while de-registering auto-connected interface from transport: {e}", RNS.LOG_ERROR)
|
||||
|
||||
def teardown_interface(self, interface):
|
||||
interface.detach()
|
||||
if interface in RNS.Transport.interfaces: RNS.Transport.interfaces.remove(interface)
|
||||
if interface in self.monitored_interfaces: self.monitored_interfaces.remove(interface)
|
||||
|
||||
def autoconnect_count(self):
|
||||
return len([i for i in RNS.Transport.interfaces if hasattr(i, "autoconnect_hash")])
|
||||
|
||||
def bootstrap_interface_count(self):
|
||||
return len([i for i in RNS.Transport.interfaces if hasattr(i, "bootstrap_only") and i.bootstrap_only == True])
|
||||
|
||||
def connect_discovered(self):
|
||||
if RNS.Reticulum.should_autoconnect_discovered_interfaces():
|
||||
try:
|
||||
discovered_interfaces = self.list_discovered_interfaces()
|
||||
for info in discovered_interfaces:
|
||||
if self.autoconnect_count() >= RNS.Reticulum.max_autoconnected_interfaces(): break
|
||||
self.autoconnect(info)
|
||||
|
||||
except Exception as e:
|
||||
RNS.log(f"Error while reconnecting discovered interfaces: {e}", RNS.LOG_ERROR)
|
||||
|
||||
def autoconnect(self, info):
|
||||
try:
|
||||
if RNS.Reticulum.should_autoconnect_discovered_interfaces():
|
||||
autoconnected_count = self.autoconnect_count()
|
||||
if autoconnected_count < RNS.Reticulum.max_autoconnected_interfaces():
|
||||
interface_type = info["type"]
|
||||
if interface_type in self.AUTOCONNECT_TYPES:
|
||||
endpoint_specifier = ""
|
||||
if "reachable_on" in info: endpoint_specifier += str(info["reachable_on"])
|
||||
if "port" in info: endpoint_specifier += ":"+str(info["port"])
|
||||
endpoint_hash = RNS.Identity.full_hash(endpoint_specifier.encode("utf-8"))
|
||||
exists = False
|
||||
for interface in RNS.Transport.interfaces:
|
||||
if hasattr(interface, "autoconnect_hash") and interface.autoconnect_hash == endpoint_hash:
|
||||
exists = True
|
||||
break
|
||||
|
||||
else:
|
||||
dest_match = "reachable_on" in info and hasattr(interface, "target_ip") and interface.target_ip == info["reachable_on"]
|
||||
port_match = not "port" in info or (hasattr(interface, "target_port") and "port" in info and interface.target_port == info["port"])
|
||||
b32d_match = "reachable_on" in info and hasattr(interface, "b32") and interface.b32 == info["reachable_on"]
|
||||
|
||||
if (dest_match and port_match) or b32d_match:
|
||||
exists = True
|
||||
break
|
||||
|
||||
if exists: RNS.log(f"Discovered {interface_type} already exists, not auto-connecting", RNS.LOG_DEBUG)
|
||||
else:
|
||||
if interface_type == "TCPClientInterface":
|
||||
RNS.log(f"Your operating system does not support the Backbone interface type, and must degrade to using TCPClientInterface instead", RNS.LOG_WARNING)
|
||||
RNS.log(f"Auto-connecting discovered TCPClient interfaces is not yet implemented, aborting auto-connect", RNS.LOG_WARNING)
|
||||
RNS.log(f"You can obtain the configuration entry and add this interface manually instead using rnstatus -D", RNS.LOG_WARNING)
|
||||
return
|
||||
|
||||
if interface_type == "I2PInterface":
|
||||
RNS.log(f"Auto-connecting discovered I2P interfaces is not yet implemented, aborting auto-connect", RNS.LOG_WARNING)
|
||||
RNS.log(f"You can obtain the configuration entry and add this interface manually instead using rnstatus -D", RNS.LOG_WARNING)
|
||||
return
|
||||
|
||||
interface_name = info["name"]
|
||||
RNS.log(f"Auto-connecting discovered {interface_type} {interface_name}")
|
||||
config_entry = info["config_entry"]
|
||||
interface_config = {}
|
||||
interface_config["name"] = f"{interface_name}"
|
||||
ifac_netname = info["ifac_netname"] if "ifac_netname" in info else None
|
||||
ifac_netkey = info["ifac_netkey"] if "ifac_netkey" in info else None
|
||||
interface = None
|
||||
|
||||
if interface_type == "BackboneInterface":
|
||||
from RNS.Interfaces import BackboneInterface
|
||||
interface_config["target_host"] = info["reachable_on"]
|
||||
interface_config["target_port"] = info["port"]
|
||||
interface = BackboneInterface.BackboneClientInterface(RNS.Transport, interface_config)
|
||||
|
||||
if interface:
|
||||
interface.autoconnect_hash = endpoint_hash
|
||||
interface.autoconnect_source = info["network_id"]
|
||||
RNS.Reticulum.get_instance()._add_interface(interface, ifac_netname=ifac_netname, ifac_netkey=ifac_netkey, configured_bitrate=5E6)
|
||||
self.monitor_interface(interface)
|
||||
|
||||
except Exception as e:
|
||||
RNS.log(f"Error while auto-connecting discovered interface: {e}", RNS.LOG_ERROR)
|
||||
RNS.trace_exception(e)
|
||||
|
||||
class BlackholeUpdater():
|
||||
INITIAL_WAIT = 20
|
||||
JOB_INTERVAL = 60
|
||||
UPDATE_INTERVAL = 1*60*60
|
||||
SOURCE_TIMEOUT = 25
|
||||
|
||||
def __init__(self):
|
||||
self.last_updates = {}
|
||||
self.should_run = False
|
||||
self.job_interval = self.JOB_INTERVAL
|
||||
self.update_lock = threading.Lock()
|
||||
|
||||
def start(self):
|
||||
if not self.should_run:
|
||||
source_count = len(RNS.Reticulum.blackhole_sources())
|
||||
ms = "" if source_count == 1 else "s"
|
||||
RNS.log(f"Starting blackhole updater with {source_count} source{ms}", RNS.LOG_DEBUG)
|
||||
self.should_run = True
|
||||
threading.Thread(target=self.job, daemon=True).start()
|
||||
|
||||
def stop(self): self.should_run = False
|
||||
|
||||
def update_link_established(self, link):
|
||||
remote_identity = link.get_remote_identity()
|
||||
RNS.log(f"Link established for blackhole list update from {RNS.prettyhexrep(remote_identity.hash)}", RNS.LOG_DEBUG)
|
||||
receipt = link.request("/list")
|
||||
while not receipt.concluded(): time.sleep(0.2)
|
||||
response = receipt.get_response()
|
||||
link.teardown()
|
||||
|
||||
if type(response) == dict: blackhole_list = response
|
||||
else: blackhole_list = None
|
||||
|
||||
if blackhole_list:
|
||||
added = 0
|
||||
for identity_hash in blackhole_list:
|
||||
entry = blackhole_list[identity_hash]
|
||||
if not identity_hash in RNS.Transport.blackholed_identities:
|
||||
RNS.Transport.blackholed_identities[identity_hash] = entry
|
||||
added += 1
|
||||
|
||||
if added > 0:
|
||||
spec = "identity" if added == 1 else "identities"
|
||||
RNS.log(f"Added {added} blackholed {spec} from {RNS.prettyhexrep(remote_identity.hash)}", RNS.LOG_DEBUG)
|
||||
|
||||
try:
|
||||
sourcelistpath = os.path.join(RNS.Reticulum.blackholepath, RNS.hexrep(remote_identity.hash, delimit=False))
|
||||
tmppath = f"{sourcelistpath}.tmp"
|
||||
with open(tmppath, "wb") as f: f.write(msgpack.packb(blackhole_list))
|
||||
if os.path.isfile(sourcelistpath): os.unlink(sourcelistpath)
|
||||
os.rename(tmppath, sourcelistpath)
|
||||
|
||||
except Exception as e:
|
||||
RNS.log(f"Error while persisting blackhole list from {RNS.prettyhexrep(remote_identity.hash)}: {e}", RNS.LOG_ERROR)
|
||||
|
||||
RNS.log(f"Blackhole list update from {RNS.prettyhexrep(remote_identity.hash)} completed", RNS.LOG_DEBUG)
|
||||
|
||||
def job(self):
|
||||
time.sleep(self.INITIAL_WAIT)
|
||||
while self.should_run:
|
||||
try:
|
||||
now = time.time()
|
||||
for identity_hash in RNS.Reticulum.blackhole_sources():
|
||||
if identity_hash in self.last_updates: last_update = self.last_updates[identity_hash]
|
||||
else: last_update = 0
|
||||
|
||||
if now > last_update+self.UPDATE_INTERVAL:
|
||||
try:
|
||||
destination_hash = RNS.Destination.hash_from_name_and_identity("rnstransport.info.blackhole", identity_hash)
|
||||
RNS.log(f"Attempting blackhole list update from {RNS.prettyhexrep(identity_hash)}...", RNS.LOG_DEBUG)
|
||||
if not RNS.Transport.await_path(destination_hash): RNS.log(f"No path available for blackhole list update from {RNS.prettyhexrep(identity_hash)}, retrying later", RNS.LOG_VERBOSE)
|
||||
else:
|
||||
remote_identity = RNS.Identity.recall(destination_hash)
|
||||
destination = RNS.Destination(remote_identity, RNS.Destination.OUT, RNS.Destination.SINGLE, "rnstransport", "info", "blackhole")
|
||||
RNS.Link(destination, established_callback=self.update_link_established)
|
||||
self.last_updates[identity_hash] = time.time()
|
||||
|
||||
except Exception as e:
|
||||
RNS.log(f"Error while establishing link for blackhole list update from {RNS.prettyhexrep(identity_hash)}: {e}", RNS.LOG_ERROR)
|
||||
|
||||
except Exception as e:
|
||||
RNS.log(f"Error in blackhole list updater job: {e}", RNS.LOG_ERROR)
|
||||
RNS.trace_exception(e)
|
||||
|
||||
time.sleep(self.job_interval)
|
||||
@@ -430,6 +430,11 @@ class Identity:
|
||||
announced_identity = Identity(create_keys=False)
|
||||
announced_identity.load_public_key(public_key)
|
||||
|
||||
if len(RNS.Transport.blackholed_identities) > 0:
|
||||
if announced_identity.hash in RNS.Transport.blackholed_identities:
|
||||
RNS.log(f"Invalidated and dropped announce from blackholed identity {RNS.prettyhexrep(announced_identity.hash)}", RNS.LOG_EXTREME)
|
||||
return False
|
||||
|
||||
if announced_identity.pub != None and announced_identity.validate(signature, signed_data):
|
||||
if only_validate_signature:
|
||||
del announced_identity
|
||||
|
||||
@@ -500,6 +500,8 @@ class RNodeInterface(Interface):
|
||||
self.r_csma_cw_max = None
|
||||
self.r_current_rssi = None
|
||||
self.r_noise_floor = None
|
||||
self.r_interference = None
|
||||
self.r_interference_l = None
|
||||
self.r_temperature = None
|
||||
|
||||
self.r_battery_state = RNodeInterface.BATTERY_STATE_UNKNOWN
|
||||
@@ -1310,10 +1312,12 @@ class RNodeInterface(Interface):
|
||||
self.r_channel_load_long = cul/100.0
|
||||
self.r_current_rssi = crs-RNodeInterface.RSSI_OFFSET
|
||||
self.r_noise_floor = nfl-RNodeInterface.RSSI_OFFSET
|
||||
|
||||
if ntf == 0xFF:
|
||||
self.r_interference = None
|
||||
else:
|
||||
self.r_interference = ntf-RNodeInterface.RSSI_OFFSET
|
||||
self.r_interference_l = [time.time(), self.r_interference]
|
||||
|
||||
if self.r_interference != None:
|
||||
RNS.log(f"{self} Radio detected interference at {self.r_interference} dBm", RNS.LOG_DEBUG)
|
||||
|
||||
@@ -138,11 +138,12 @@ class AutoInterface(Interface):
|
||||
|
||||
self.outbound_udp_socket = None
|
||||
|
||||
self.announce_rate_target = None
|
||||
self.announce_interval = AutoInterface.ANNOUNCE_INTERVAL
|
||||
self.peer_job_interval = AutoInterface.PEER_JOB_INTERVAL
|
||||
self.peering_timeout = AutoInterface.PEERING_TIMEOUT
|
||||
self.multicast_echo_timeout = AutoInterface.MCAST_ECHO_TIMEOUT
|
||||
self.announce_rate_target = None
|
||||
self.announce_interval = AutoInterface.ANNOUNCE_INTERVAL
|
||||
self.peer_job_interval = AutoInterface.PEER_JOB_INTERVAL
|
||||
self.peering_timeout = AutoInterface.PEERING_TIMEOUT
|
||||
self.multicast_echo_timeout = AutoInterface.MCAST_ECHO_TIMEOUT
|
||||
self.reverse_peering_interval = self.announce_interval*3.25
|
||||
|
||||
# Increase peering timeout on Android, due to potential
|
||||
# low-power modes implemented on many chipsets.
|
||||
@@ -169,6 +170,8 @@ class AutoInterface(Interface):
|
||||
else:
|
||||
self.discovery_port = discovery_port
|
||||
|
||||
self.unicast_discovery_port = self.discovery_port+1
|
||||
|
||||
if multicast_address_type == None:
|
||||
self.multicast_address_type = AutoInterface.MULTICAST_TEMPORARY_ADDRESS_TYPE
|
||||
elif str(multicast_address_type).lower() == "temporary":
|
||||
@@ -244,33 +247,48 @@ class AutoInterface(Interface):
|
||||
if link_local_addr == None:
|
||||
RNS.log(str(self)+" No link-local IPv6 address configured for "+str(ifname)+", skipping interface", RNS.LOG_EXTREME)
|
||||
else:
|
||||
mcast_addr = self.mcast_discovery_address
|
||||
RNS.log(str(self)+" Creating multicast discovery listener on "+str(ifname)+" with address "+str(mcast_addr), RNS.LOG_EXTREME)
|
||||
RNS.log(str(self)+" Creating unicast discovery listener on "+str(ifname)+" with address "+str(link_local_addr), RNS.LOG_EXTREME)
|
||||
|
||||
# Struct with interface index
|
||||
if_struct = struct.pack("I", self.interface_name_to_index(ifname))
|
||||
|
||||
# Set up multicast socket
|
||||
# Set up unicast discovery socket
|
||||
unicast_discovery_socket = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
|
||||
unicast_discovery_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
|
||||
if hasattr(socket, "SO_REUSEPORT"): unicast_discovery_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
|
||||
|
||||
# Bind unicast discovery socket
|
||||
if RNS.vendor.platformutils.is_windows():
|
||||
# Windows throws "[WinError 10049] The requested address is not valid in its context"
|
||||
# when trying to use the multicast address as host, or when providing interface index
|
||||
# passing an empty host appears to work, but probably not exactly how we want it to...
|
||||
unicast_discovery_socket.bind(('', self.unicast_discovery_port))
|
||||
|
||||
else:
|
||||
addr_info = socket.getaddrinfo(link_local_addr+"%"+ifname, self.unicast_discovery_port, socket.AF_INET6, socket.SOCK_DGRAM)
|
||||
unicast_discovery_socket.bind(addr_info[0][4])
|
||||
|
||||
mcast_addr = self.mcast_discovery_address
|
||||
RNS.log(str(self)+" Creating multicast discovery listener on "+str(ifname)+" with address "+str(mcast_addr), RNS.LOG_EXTREME)
|
||||
|
||||
# Set up multicast discovery socket
|
||||
discovery_socket = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
|
||||
discovery_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
|
||||
if hasattr(socket, "SO_REUSEPORT"):
|
||||
discovery_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
|
||||
if hasattr(socket, "SO_REUSEPORT"): discovery_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
|
||||
discovery_socket.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_MULTICAST_IF, if_struct)
|
||||
|
||||
# Join multicast group
|
||||
mcast_group = socket.inet_pton(socket.AF_INET6, mcast_addr) + if_struct
|
||||
discovery_socket.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_JOIN_GROUP, mcast_group)
|
||||
|
||||
# Bind socket
|
||||
# Bind multicast socket
|
||||
if RNS.vendor.platformutils.is_windows():
|
||||
|
||||
# window throws "[WinError 10049] The requested address is not valid in its context"
|
||||
# Windows throws "[WinError 10049] The requested address is not valid in its context"
|
||||
# when trying to use the multicast address as host, or when providing interface index
|
||||
# passing an empty host appears to work, but probably not exactly how we want it to...
|
||||
discovery_socket.bind(('', self.discovery_port))
|
||||
|
||||
else:
|
||||
|
||||
if self.discovery_scope == AutoInterface.SCOPE_LINK:
|
||||
addr_info = socket.getaddrinfo(mcast_addr+"%"+ifname, self.discovery_port, socket.AF_INET6, socket.SOCK_DGRAM)
|
||||
else:
|
||||
@@ -278,12 +296,13 @@ class AutoInterface(Interface):
|
||||
|
||||
discovery_socket.bind(addr_info[0][4])
|
||||
|
||||
# Set up thread for discovery packets
|
||||
# Set up thread for multicast discovery packets
|
||||
def discovery_loop(): self.discovery_handler(discovery_socket, ifname)
|
||||
|
||||
thread = threading.Thread(target=discovery_loop)
|
||||
thread.daemon = True
|
||||
thread.start()
|
||||
thread = threading.Thread(target=discovery_loop, daemon=True).start()
|
||||
|
||||
# Set up thread for unicast discovery packets
|
||||
def unicast_discovery_loop(): self.discovery_handler(unicast_discovery_socket, ifname, announce=False)
|
||||
thread = threading.Thread(target=unicast_discovery_loop, daemon=True).start()
|
||||
|
||||
suitable_interfaces += 1
|
||||
|
||||
@@ -331,13 +350,13 @@ class AutoInterface(Interface):
|
||||
self.online = True
|
||||
self.final_init_done = True
|
||||
|
||||
def discovery_handler(self, socket, ifname):
|
||||
def announce_loop():
|
||||
self.announce_handler(ifname)
|
||||
|
||||
thread = threading.Thread(target=announce_loop)
|
||||
thread.daemon = True
|
||||
thread.start()
|
||||
def discovery_handler(self, socket, ifname, announce=True):
|
||||
def announce_loop(): self.announce_handler(ifname)
|
||||
|
||||
if announce:
|
||||
thread = threading.Thread(target=announce_loop)
|
||||
thread.daemon = True
|
||||
thread.start()
|
||||
|
||||
while True:
|
||||
data, ipv6_src = socket.recvfrom(1024)
|
||||
@@ -371,6 +390,18 @@ class AutoInterface(Interface):
|
||||
spawned_interface.teardown()
|
||||
RNS.log(str(self)+" removed peer "+str(peer_addr)+" on "+str(removed_peer[0]), RNS.LOG_DEBUG)
|
||||
|
||||
# Send reverse peering packets
|
||||
for peer_addr in self.peers:
|
||||
try:
|
||||
peer = self.peers[peer_addr]
|
||||
ifname = peer[0]
|
||||
last_outbound = peer[2]
|
||||
if now > last_outbound+self.reverse_peering_interval:
|
||||
self.reverse_announce(ifname, peer_addr)
|
||||
peer[2] = time.time()
|
||||
except Exception as e:
|
||||
RNS.log(f"Error while sending reverse peering packet to {peer_addr}: {e}", RNS.LOG_ERROR)
|
||||
|
||||
for ifname in self.adopted_interfaces:
|
||||
# Check that the link-local address has not changed
|
||||
try:
|
||||
@@ -443,6 +474,20 @@ class AutoInterface(Interface):
|
||||
self.peer_announce(ifname)
|
||||
time.sleep(self.announce_interval)
|
||||
|
||||
def reverse_announce(self, ifname, peer_addr):
|
||||
try:
|
||||
link_local_address = self.adopted_interfaces[ifname]
|
||||
discovery_token = RNS.Identity.full_hash(self.group_id+link_local_address.encode("utf-8"))
|
||||
announce_socket = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
|
||||
addr_info = socket.getaddrinfo(f"{peer_addr}%{ifname}", self.unicast_discovery_port, socket.AF_INET6, socket.SOCK_DGRAM)
|
||||
|
||||
ifis = struct.pack("I", self.interface_name_to_index(ifname))
|
||||
announce_socket.sendto(discovery_token, addr_info[0][4])
|
||||
announce_socket.close()
|
||||
|
||||
except Exception as e:
|
||||
RNS.log(f"Could not send reverse peering packet to {peer_addr} on {ifname}: {e}", RNS.LOG_ERROR)
|
||||
|
||||
def peer_announce(self, ifname):
|
||||
try:
|
||||
link_local_address = self.adopted_interfaces[ifname]
|
||||
@@ -480,7 +525,7 @@ class AutoInterface(Interface):
|
||||
|
||||
else:
|
||||
if not addr in self.peers:
|
||||
self.peers[addr] = [ifname, time.time()]
|
||||
self.peers[addr] = [ifname, time.time(), time.time()]
|
||||
|
||||
spawned_interface = AutoInterfacePeer(self, addr, ifname)
|
||||
spawned_interface.OUT = self.OUT
|
||||
@@ -518,7 +563,7 @@ class AutoInterface(Interface):
|
||||
if addr in self.spawned_interfaces:
|
||||
self.spawned_interfaces[addr].detach()
|
||||
self.spawned_interfaces[addr].teardown()
|
||||
self.spawned_interfaces.pop(spawned_interface)
|
||||
if addr in self.spawned_interfaces: self.spawned_interfaces.pop(addr)
|
||||
self.spawned_interfaces[addr] = spawned_interface
|
||||
|
||||
RNS.log(str(self)+" added peer "+str(addr)+" on "+str(ifname), RNS.LOG_DEBUG)
|
||||
@@ -526,28 +571,18 @@ class AutoInterface(Interface):
|
||||
self.refresh_peer(addr)
|
||||
|
||||
def refresh_peer(self, addr):
|
||||
try:
|
||||
self.peers[addr][1] = time.time()
|
||||
except Exception as e:
|
||||
RNS.log(f"An error occurred while refreshing peer {addr} on {self}: {e}", RNS.LOG_ERROR)
|
||||
try: self.peers[addr][1] = time.time()
|
||||
except Exception as e: RNS.log(f"An error occurred while refreshing peer {addr} on {self}: {e}", RNS.LOG_ERROR)
|
||||
|
||||
def process_incoming(self, data, addr=None):
|
||||
if self.online and addr in self.spawned_interfaces:
|
||||
self.spawned_interfaces[addr].process_incoming(data, addr)
|
||||
|
||||
def process_outgoing(self,data):
|
||||
pass
|
||||
def process_outgoing(self, data): pass
|
||||
|
||||
# Until per-device sub-interfacing is implemented,
|
||||
# ingress limiting should be disabled on AutoInterface
|
||||
def should_ingress_limit(self):
|
||||
return False
|
||||
def detach(self): self.online = False
|
||||
|
||||
def detach(self):
|
||||
self.online = False
|
||||
|
||||
def __str__(self):
|
||||
return "AutoInterface["+self.name+"]"
|
||||
def __str__(self): return f"AutoInterface[{self.name}]"
|
||||
|
||||
class AutoInterfacePeer(Interface):
|
||||
|
||||
@@ -602,12 +637,10 @@ class AutoInterfacePeer(Interface):
|
||||
|
||||
def teardown(self):
|
||||
if not self.detached:
|
||||
RNS.log("The interface "+str(self)+" experienced an unrecoverable error and is being torn down.", RNS.LOG_ERROR)
|
||||
if RNS.Reticulum.panic_on_interface_error:
|
||||
RNS.panic()
|
||||
RNS.log(f"The interface {self} experienced an unrecoverable error and is being torn down.", RNS.LOG_ERROR)
|
||||
if RNS.Reticulum.panic_on_interface_error: RNS.panic()
|
||||
|
||||
else:
|
||||
RNS.log("The interface "+str(self)+" is being torn down.", RNS.LOG_VERBOSE)
|
||||
else: RNS.log(f"The interface {self} is being torn down.", RNS.LOG_VERBOSE)
|
||||
|
||||
self.online = False
|
||||
self.OUT = False
|
||||
@@ -618,13 +651,7 @@ class AutoInterfacePeer(Interface):
|
||||
except Exception as e:
|
||||
RNS.log(f"Could not remove {self} from parent interface on detach. The contained exception was: {e}", RNS.LOG_ERROR)
|
||||
|
||||
if self in RNS.Transport.interfaces:
|
||||
RNS.Transport.interfaces.remove(self)
|
||||
|
||||
# Until per-device sub-interfacing is implemented,
|
||||
# ingress limiting should be disabled on AutoInterface
|
||||
def should_ingress_limit(self):
|
||||
return False
|
||||
if self in RNS.Transport.interfaces: RNS.Transport.interfaces.remove(self)
|
||||
|
||||
class AutoInterfaceHandler(socketserver.BaseRequestHandler):
|
||||
def __init__(self, callback, *args, **keys):
|
||||
|
||||
@@ -127,6 +127,7 @@ class BackboneInterface(Interface):
|
||||
self.detached = False
|
||||
self.mode = RNS.Interfaces.Interface.Interface.MODE_FULL
|
||||
self.spawned_interfaces = []
|
||||
self.supports_discovery = True
|
||||
|
||||
if bindport == None:
|
||||
raise SystemError(f"No TCP port configured for interface \"{name}\"")
|
||||
@@ -407,7 +408,9 @@ class BackboneInterface(Interface):
|
||||
if hasattr(listener_socket, "shutdown"):
|
||||
if callable(listener_socket.shutdown):
|
||||
try: listener_socket.shutdown(socket.SHUT_RDWR)
|
||||
except Exception as e: RNS.log("Error while shutting down socket for "+str(self)+": "+str(e), RNS.LOG_ERROR)
|
||||
except Exception as e:
|
||||
if str(e).endswith("Transport endpoint is not connected"): pass
|
||||
else: RNS.log("Error while shutting down socket for "+str(self)+": "+str(e), RNS.LOG_ERROR)
|
||||
|
||||
def __str__(self):
|
||||
if ":" in self.bind_ip:
|
||||
@@ -522,7 +525,9 @@ class BackboneClientInterface(Interface):
|
||||
|
||||
try:
|
||||
if self.socket != None: self.socket.shutdown(socket.SHUT_RDWR)
|
||||
except Exception as e: RNS.log("Error while shutting down socket for "+str(self)+": "+str(e), RNS.LOG_ERROR)
|
||||
except Exception as e:
|
||||
if str(e).endswith("Transport endpoint is not connected"): pass
|
||||
else: RNS.log("Error while shutting down socket for "+str(self)+": "+str(e), RNS.LOG_ERROR)
|
||||
|
||||
try:
|
||||
if self.socket != None: self.socket.close()
|
||||
@@ -579,7 +584,7 @@ class BackboneClientInterface(Interface):
|
||||
if not self.reconnecting:
|
||||
self.reconnecting = True
|
||||
attempts = 0
|
||||
while not self.online:
|
||||
while not self.online and not self.detached:
|
||||
time.sleep(BackboneClientInterface.RECONNECT_WAIT)
|
||||
attempts += 1
|
||||
|
||||
@@ -592,6 +597,8 @@ class BackboneClientInterface(Interface):
|
||||
except Exception as e:
|
||||
RNS.log("Connection attempt for "+str(self)+" failed: "+str(e), RNS.LOG_DEBUG)
|
||||
|
||||
if not self.online: return
|
||||
|
||||
if not self.never_connected:
|
||||
RNS.log("Reconnected socket for "+str(self)+".", RNS.LOG_INFO)
|
||||
|
||||
|
||||
@@ -880,6 +880,7 @@ class I2PInterface(Interface):
|
||||
self.ifac_size = ifac_size
|
||||
self.ifac_netname = ifac_netname
|
||||
self.ifac_netkey = ifac_netkey
|
||||
self.supports_discovery = True
|
||||
|
||||
self.online = False
|
||||
|
||||
|
||||
@@ -84,6 +84,10 @@ class Interface:
|
||||
self.bitrate = 62500
|
||||
self.HW_MTU = None
|
||||
|
||||
self.supports_discovery = False
|
||||
self.discoverable = False
|
||||
self.last_discovery_announce = 0
|
||||
self.bootstrap_only = False
|
||||
self.parent_interface = None
|
||||
self.spawned_interfaces = None
|
||||
self.tunnel_id = None
|
||||
|
||||
@@ -185,7 +185,7 @@ class RNodeInterface(Interface):
|
||||
else:
|
||||
ble_name = ble_string
|
||||
|
||||
if port.lower().startswith(tcp_uri_scheme):
|
||||
elif port.lower().startswith(tcp_uri_scheme):
|
||||
force_tcp = True
|
||||
tcp_string = port[len(tcp_uri_scheme):]
|
||||
port = None
|
||||
@@ -276,6 +276,8 @@ class RNodeInterface(Interface):
|
||||
self.r_csma_cw_max = None
|
||||
self.r_current_rssi = None
|
||||
self.r_noise_floor = None
|
||||
self.r_interference = None
|
||||
self.r_interference_l = None
|
||||
|
||||
self.r_battery_state = RNodeInterface.BATTERY_STATE_UNKNOWN
|
||||
self.r_battery_percent = 0
|
||||
@@ -294,6 +296,7 @@ class RNodeInterface(Interface):
|
||||
self.flow_control = flow_control
|
||||
self.interface_ready = False
|
||||
self.announce_rate_target = None
|
||||
self.supports_discovery = True
|
||||
|
||||
if force_ble or self.ble_addr != None or self.ble_name != None: self.use_ble = True
|
||||
if force_tcp or self.tcp_host != None: self.use_tcp = True
|
||||
@@ -943,16 +946,35 @@ class RNodeInterface(Interface):
|
||||
self.r_channel_load_long = cul/100.0
|
||||
self.r_current_rssi = crs-RNodeInterface.RSSI_OFFSET
|
||||
self.r_noise_floor = nfl-RNodeInterface.RSSI_OFFSET
|
||||
|
||||
# TODO: Remove debug
|
||||
# interference_log_threshold = 10
|
||||
# if ntf == 0xFF:
|
||||
# self.r_interference = None
|
||||
# if self.r_noise_floor != None:
|
||||
# # Filter potential false interference events due to LNA recalibration
|
||||
# if self.r_interference_l != None:
|
||||
# if self.r_interference_l[1] < self.r_noise_floor+interference_log_threshold:
|
||||
# self.r_interference_l = None
|
||||
# else:
|
||||
# if self.r_noise_floor != None:
|
||||
# interference = ntf-RNodeInterface.RSSI_OFFSET
|
||||
# # Filter potential false interference events due to LNA recalibration
|
||||
# if interference > self.r_noise_floor+interference_log_threshold:
|
||||
# self.r_interference = ntf-RNodeInterface.RSSI_OFFSET
|
||||
# self.r_interference_l = [time.time(), self.r_interference]
|
||||
|
||||
if ntf == 0xFF:
|
||||
self.r_interference = None
|
||||
else:
|
||||
self.r_interference = ntf-RNodeInterface.RSSI_OFFSET
|
||||
self.r_interference_l = [time.time(), self.r_interference]
|
||||
|
||||
if self.r_interference != None:
|
||||
RNS.log(f"{self} Radio detected interference at {self.r_interference} dBm", RNS.LOG_DEBUG)
|
||||
|
||||
# TODO: Remove debug
|
||||
# RNS.log(f"RSSI: {self.r_current_rssi}, Noise floor: {self.r_noise_floor}, Interference: {self.r_interference}", RNS.LOG_EXTREME)
|
||||
# RNS.log(f"RSSI: {self.r_current_rssi}, Noise floor: {self.r_noise_floor}, Interference: {self.r_interference}", RNS.LOG_DEBUG)
|
||||
elif (command == KISS.CMD_STAT_PHYPRM):
|
||||
if (byte == KISS.FESC):
|
||||
escape = True
|
||||
|
||||
@@ -107,8 +107,13 @@ class TCPClientInterface(Interface):
|
||||
i2p_tunneled = c.as_bool("i2p_tunneled") if "i2p_tunneled" in c else False
|
||||
connect_timeout = c.as_int("connect_timeout") if "connect_timeout" in c else None
|
||||
max_reconnect_tries = c.as_int("max_reconnect_tries") if "max_reconnect_tries" in c else None
|
||||
fixed_mtu = c.as_int("fixed_mtu") if "fixed_mtu" in c else None
|
||||
if fixed_mtu:
|
||||
if fixed_mtu < RNS.Reticulum.MTU: raise ValueError(f"Configured MTU of {fixed_mtu} bytes is too small")
|
||||
self.AUTOCONFIGURE_MTU = False
|
||||
self.FIXED_MTU = True
|
||||
|
||||
self.HW_MTU = TCPInterface.HW_MTU
|
||||
self.HW_MTU = TCPInterface.HW_MTU if not fixed_mtu else fixed_mtu
|
||||
self.IN = True
|
||||
self.OUT = False
|
||||
self.socket = None
|
||||
@@ -126,10 +131,9 @@ class TCPClientInterface(Interface):
|
||||
self.mode = RNS.Interfaces.Interface.Interface.MODE_FULL
|
||||
self.bitrate = TCPClientInterface.BITRATE_GUESS
|
||||
|
||||
if max_reconnect_tries == None:
|
||||
self.max_reconnect_tries = TCPClientInterface.RECONNECT_MAX_TRIES
|
||||
else:
|
||||
self.max_reconnect_tries = max_reconnect_tries
|
||||
self.supports_discovery = True
|
||||
if max_reconnect_tries == None: self.max_reconnect_tries = TCPClientInterface.RECONNECT_MAX_TRIES
|
||||
else: self.max_reconnect_tries = max_reconnect_tries
|
||||
|
||||
if connected_socket != None:
|
||||
self.receives = True
|
||||
@@ -508,6 +512,7 @@ class TCPServerInterface(Interface):
|
||||
if port != None:
|
||||
bindport = port
|
||||
|
||||
self.supports_discovery = True
|
||||
self.HW_MTU = TCPInterface.HW_MTU
|
||||
|
||||
self.online = False
|
||||
|
||||
@@ -99,6 +99,12 @@ class WDCL():
|
||||
if not RNS.vendor.platformutils.is_android():
|
||||
if port == None: raise ValueError("No port specified")
|
||||
|
||||
self.supports_discovery = True
|
||||
self.discovery_frequency = None
|
||||
self.discovery_bandwidth = None
|
||||
self.discovery_channel = None
|
||||
self.discovery_modulation = None
|
||||
|
||||
self.switch_identity = owner.switch_identity
|
||||
self.switch_id = self.switch_identity.sig_pub_bytes[-4:]
|
||||
self.switch_pub_bytes = self.switch_identity.sig_pub_bytes
|
||||
@@ -991,9 +997,6 @@ class WeaveInterface(Interface):
|
||||
def process_outgoing(self,data):
|
||||
pass
|
||||
|
||||
def should_ingress_limit(self):
|
||||
return False
|
||||
|
||||
def detach(self):
|
||||
self._online = False
|
||||
|
||||
@@ -1086,6 +1089,3 @@ class WeaveInterfacePeer(Interface):
|
||||
|
||||
if self in RNS.Transport.interfaces:
|
||||
RNS.Transport.interfaces.remove(self)
|
||||
|
||||
def should_ingress_limit(self):
|
||||
return False
|
||||
@@ -935,7 +935,8 @@ class Link:
|
||||
request_id = RNS.Identity.truncated_hash(packed_request)
|
||||
request_data = unpacked_request
|
||||
|
||||
self.handle_request(request_id, request_data)
|
||||
def job(): self.handle_request(request_id, request_data)
|
||||
threading.Thread(target=job, daemon=True).start()
|
||||
else:
|
||||
RNS.log("Incoming request resource failed with status: "+RNS.hexrep([resource.status]), RNS.LOG_DEBUG)
|
||||
|
||||
@@ -1036,7 +1037,8 @@ class Link:
|
||||
packed_request = self.decrypt(packet.data)
|
||||
if packed_request != None:
|
||||
unpacked_request = umsgpack.unpackb(packed_request)
|
||||
self.handle_request(request_id, unpacked_request)
|
||||
def job(): self.handle_request(request_id, unpacked_request)
|
||||
threading.Thread(target=job, daemon=True).start()
|
||||
self.__update_phy_stats(packet, query_shared=True)
|
||||
except Exception as e:
|
||||
RNS.log("Error occurred while handling request. The contained exception was: "+str(e), RNS.LOG_ERROR)
|
||||
@@ -1049,7 +1051,8 @@ class Link:
|
||||
request_id = unpacked_response[0]
|
||||
response_data = unpacked_response[1]
|
||||
transfer_size = len(umsgpack.packb(response_data))-2
|
||||
self.handle_response(request_id, response_data, transfer_size, transfer_size)
|
||||
def job(): self.handle_response(request_id, response_data, transfer_size, transfer_size)
|
||||
threading.Thread(target=job, daemon=True).start()
|
||||
self.__update_phy_stats(packet, query_shared=True)
|
||||
except Exception as e:
|
||||
RNS.log("Error occurred while handling response. The contained exception was: "+str(e), RNS.LOG_ERROR)
|
||||
@@ -1085,17 +1088,14 @@ class Link:
|
||||
pending_request.started_at = time.time()
|
||||
pending_request.response_resource_progress(response_resource)
|
||||
|
||||
elif self.resource_strategy == Link.ACCEPT_NONE:
|
||||
pass
|
||||
elif self.resource_strategy == Link.ACCEPT_NONE: pass
|
||||
elif self.resource_strategy == Link.ACCEPT_APP:
|
||||
if self.callbacks.resource != None:
|
||||
try:
|
||||
resource_advertisement = RNS.ResourceAdvertisement.unpack(packet.plaintext)
|
||||
resource_advertisement.link = self
|
||||
if self.callbacks.resource(resource_advertisement):
|
||||
RNS.Resource.accept(packet, self.callbacks.resource_concluded)
|
||||
else:
|
||||
RNS.Resource.reject(packet)
|
||||
if self.callbacks.resource(resource_advertisement): RNS.Resource.accept(packet, self.callbacks.resource_concluded)
|
||||
else: RNS.Resource.reject(packet)
|
||||
except Exception as e:
|
||||
RNS.log("Error while executing resource accept callback from "+str(self)+". The contained exception was: "+str(e), RNS.LOG_ERROR)
|
||||
elif self.resource_strategy == Link.ACCEPT_ALL:
|
||||
@@ -1181,7 +1181,8 @@ class Link:
|
||||
resource_hash = packet.data[0:RNS.Identity.HASHLENGTH//8]
|
||||
for resource in self.outgoing_resources:
|
||||
if resource_hash == resource.hash:
|
||||
resource.validate_proof(packet.data)
|
||||
def job(): resource.validate_proof(packet.data)
|
||||
threading.Thread(target=job, daemon=True).start()
|
||||
self.__update_phy_stats(packet, query_shared=True)
|
||||
|
||||
self.watchdog_lock = False
|
||||
@@ -1482,14 +1483,12 @@ class RequestReceipt():
|
||||
self.packet_receipt.callbacks.delivery(self.packet_receipt)
|
||||
|
||||
if self.callbacks.progress != None:
|
||||
try:
|
||||
self.callbacks.progress(self)
|
||||
try: self.callbacks.progress(self)
|
||||
except Exception as e:
|
||||
RNS.log("Error while executing response progress callback from "+str(self)+". The contained exception was: "+str(e), RNS.LOG_ERROR)
|
||||
|
||||
if self.callbacks.response != None:
|
||||
try:
|
||||
self.callbacks.response(self)
|
||||
try: self.callbacks.response(self)
|
||||
except Exception as e:
|
||||
RNS.log("Error while executing response received callback from "+str(self)+". The contained exception was: "+str(e), RNS.LOG_ERROR)
|
||||
|
||||
|
||||
@@ -289,11 +289,9 @@ class Packet:
|
||||
self.destination.tx += 1
|
||||
self.destination.txbytes += len(self.data)
|
||||
|
||||
if not self.packed:
|
||||
self.pack()
|
||||
if not self.packed: self.pack()
|
||||
|
||||
if RNS.Transport.outbound(self):
|
||||
return self.receipt
|
||||
if RNS.Transport.outbound(self): return self.receipt
|
||||
else:
|
||||
RNS.log("No interfaces could process the outbound packet", RNS.LOG_ERROR)
|
||||
self.sent = False
|
||||
|
||||
@@ -882,7 +882,7 @@ class Resource:
|
||||
|
||||
if self.received_count == self.total_parts and not self.assembly_lock:
|
||||
self.assembly_lock = True
|
||||
self.assemble()
|
||||
threading.Thread(target=self.assemble, daemon=True).start()
|
||||
elif self.outstanding_parts == 0:
|
||||
# TODO: Figure out if there is a mathematically
|
||||
# optimal way to adjust windows
|
||||
@@ -1093,7 +1093,8 @@ class Resource:
|
||||
if self.callback != None:
|
||||
try:
|
||||
self.link.resource_concluded(self)
|
||||
self.callback(self)
|
||||
def job(): self.callback(self)
|
||||
threading.Thread(target=job, daemon=True).start()
|
||||
except Exception as e:
|
||||
RNS.log("Error while executing callbacks on resource reject from "+str(self)+". The contained exception was: "+str(e), RNS.LOG_ERROR)
|
||||
|
||||
|
||||
@@ -49,17 +49,34 @@ fetch_jail = None
|
||||
save_path = None
|
||||
show_phy_rates = False
|
||||
allowed_identity_hashes = []
|
||||
identity = None
|
||||
|
||||
def prepare_identity(identity_path):
|
||||
global identity
|
||||
if identity_path == None:
|
||||
identity_path = RNS.Reticulum.identitypath+"/"+APP_NAME
|
||||
|
||||
if os.path.isfile(identity_path):
|
||||
identity = RNS.Identity.from_file(identity_path)
|
||||
if identity == None:
|
||||
RNS.log(f"Could not load identity for rncp. The identity file at \"{identity_path}\" may be corrupt or unreadable.", RNS.LOG_ERROR)
|
||||
RNS.exit(2)
|
||||
|
||||
if identity == None:
|
||||
RNS.log("No valid saved identity found, creating new...", RNS.LOG_INFO)
|
||||
identity = RNS.Identity()
|
||||
identity.to_file(identity_path)
|
||||
|
||||
REQ_FETCH_NOT_ALLOWED = 0xF0
|
||||
|
||||
es = " "
|
||||
erase_str = "\33[2K\r"
|
||||
|
||||
def listen(configdir, verbosity = 0, quietness = 0, allowed = [], display_identity = False,
|
||||
def listen(configdir, identitypath = None, verbosity = 0, quietness = 0, allowed = [], display_identity = False,
|
||||
limit = None, disable_auth = None, fetch_allowed = False, no_compress=False,
|
||||
jail = None, save = None, announce = False, allow_overwrite=False):
|
||||
|
||||
global allow_all, allow_fetch, allowed_identity_hashes, fetch_jail, save_path
|
||||
global allow_all, allow_fetch, allowed_identity_hashes, fetch_jail, save_path, identity
|
||||
global fetch_auto_compress, allow_overwrite_on_receive
|
||||
|
||||
allow_fetch = fetch_allowed
|
||||
@@ -90,14 +107,7 @@ def listen(configdir, verbosity = 0, quietness = 0, allowed = [], display_identi
|
||||
|
||||
RNS.log("Saving received files in \""+save_path+"\"", RNS.LOG_VERBOSE)
|
||||
|
||||
identity_path = RNS.Reticulum.identitypath+"/"+APP_NAME
|
||||
if os.path.isfile(identity_path):
|
||||
identity = RNS.Identity.from_file(identity_path)
|
||||
|
||||
if identity == None:
|
||||
RNS.log("No valid saved identity found, creating new...", RNS.LOG_INFO)
|
||||
identity = RNS.Identity()
|
||||
identity.to_file(identity_path)
|
||||
prepare_identity(identitypath)
|
||||
|
||||
destination = RNS.Destination(identity, RNS.Destination.IN, RNS.Destination.SINGLE, APP_NAME, "receive")
|
||||
|
||||
@@ -345,8 +355,8 @@ def sender_progress(resource):
|
||||
resource_done = True
|
||||
|
||||
link = None
|
||||
def fetch(configdir, verbosity = 0, quietness = 0, destination = None, file = None, timeout = RNS.Transport.PATH_REQUEST_TIMEOUT, silent=False, phy_rates=False, save=None, allow_overwrite=False):
|
||||
global current_resource, resource_done, link, speed, show_phy_rates, save_path, allow_overwrite_on_receive
|
||||
def fetch(configdir, identitypath = None, verbosity = 0, quietness = 0, destination = None, file = None, timeout = RNS.Transport.PATH_REQUEST_TIMEOUT, silent=False, phy_rates=False, save=None, allow_overwrite=False):
|
||||
global current_resource, resource_done, link, speed, show_phy_rates, save_path, allow_overwrite_on_receive, identity
|
||||
targetloglevel = 3+verbosity-quietness
|
||||
show_phy_rates = phy_rates
|
||||
allow_overwrite_on_receive = allow_overwrite
|
||||
@@ -377,19 +387,8 @@ def fetch(configdir, verbosity = 0, quietness = 0, destination = None, file = No
|
||||
|
||||
reticulum = RNS.Reticulum(configdir=configdir, loglevel=targetloglevel)
|
||||
|
||||
identity_path = RNS.Reticulum.identitypath+"/"+APP_NAME
|
||||
if os.path.isfile(identity_path):
|
||||
identity = RNS.Identity.from_file(identity_path)
|
||||
if identity == None:
|
||||
RNS.log("Could not load identity for rncp. The identity file at \""+str(identity_path)+"\" may be corrupt or unreadable.", RNS.LOG_ERROR)
|
||||
RNS.exit(2)
|
||||
else:
|
||||
identity = None
|
||||
|
||||
if identity == None:
|
||||
RNS.log("No valid saved identity found, creating new...", RNS.LOG_INFO)
|
||||
identity = RNS.Identity()
|
||||
identity.to_file(identity_path)
|
||||
prepare_identity(identitypath)
|
||||
|
||||
if not RNS.Transport.has_path(destination_hash):
|
||||
RNS.Transport.request_path(destination_hash)
|
||||
@@ -614,8 +613,8 @@ def fetch(configdir, verbosity = 0, quietness = 0, destination = None, file = No
|
||||
RNS.exit(0)
|
||||
|
||||
|
||||
def send(configdir, verbosity = 0, quietness = 0, destination = None, file = None, timeout = RNS.Transport.PATH_REQUEST_TIMEOUT, silent=False, phy_rates=False, no_compress=False):
|
||||
global current_resource, resource_done, link, speed, show_phy_rates, phy_got_total, phy_speed
|
||||
def send(configdir, identitypath = None, verbosity = 0, quietness = 0, destination = None, file = None, timeout = RNS.Transport.PATH_REQUEST_TIMEOUT, silent=False, phy_rates=False, no_compress=False):
|
||||
global current_resource, resource_done, link, speed, show_phy_rates, phy_got_total, phy_speed, identity
|
||||
targetloglevel = 3+verbosity-quietness
|
||||
show_phy_rates = phy_rates
|
||||
|
||||
@@ -643,19 +642,8 @@ def send(configdir, verbosity = 0, quietness = 0, destination = None, file = Non
|
||||
|
||||
reticulum = RNS.Reticulum(configdir=configdir, loglevel=targetloglevel)
|
||||
|
||||
identity_path = RNS.Reticulum.identitypath+"/"+APP_NAME
|
||||
if os.path.isfile(identity_path):
|
||||
identity = RNS.Identity.from_file(identity_path)
|
||||
if identity == None:
|
||||
RNS.log("Could not load identity for rncp. The identity file at \""+str(identity_path)+"\" may be corrupt or unreadable.", RNS.LOG_ERROR)
|
||||
RNS.exit(2)
|
||||
else:
|
||||
identity = None
|
||||
|
||||
if identity == None:
|
||||
RNS.log("No valid saved identity found, creating new...", RNS.LOG_INFO)
|
||||
identity = RNS.Identity()
|
||||
identity.to_file(identity_path)
|
||||
prepare_identity(identitypath)
|
||||
|
||||
if not RNS.Transport.has_path(destination_hash):
|
||||
RNS.Transport.request_path(destination_hash)
|
||||
@@ -822,6 +810,7 @@ def main():
|
||||
parser.add_argument('-a', metavar="allowed_hash", dest="allowed", action='append', help="allow this identity (or add in ~/.rncp/allowed_identities)", type=str)
|
||||
parser.add_argument('-n', '--no-auth', action='store_true', default=False, help="accept requests from anyone")
|
||||
parser.add_argument('-p', '--print-identity', action='store_true', default=False, help="print identity and destination info and exit")
|
||||
parser.add_argument('-i', metavar="identity", action='store', dest="identity", default=None, help="path to identity to use", type=str)
|
||||
parser.add_argument("-w", action="store", metavar="seconds", type=float, help="sender timeout before giving up", default=RNS.Transport.PATH_REQUEST_TIMEOUT)
|
||||
parser.add_argument('-P', '--phy-rates', action='store_true', default=False, help="display physical layer transfer rates")
|
||||
# parser.add_argument("--limit", action="store", metavar="files", type=float, help="maximum number of files to accept", default=None)
|
||||
@@ -832,6 +821,7 @@ def main():
|
||||
if args.listen or args.print_identity:
|
||||
listen(
|
||||
configdir = args.config,
|
||||
identitypath = args.identity,
|
||||
verbosity=args.verbose,
|
||||
quietness=args.quiet,
|
||||
allowed = args.allowed,
|
||||
@@ -850,6 +840,7 @@ def main():
|
||||
if args.destination != None and args.file != None:
|
||||
fetch(
|
||||
configdir = args.config,
|
||||
identitypath = args.identity,
|
||||
verbosity = args.verbose,
|
||||
quietness = args.quiet,
|
||||
destination = args.destination,
|
||||
@@ -868,6 +859,7 @@ def main():
|
||||
elif args.destination != None and args.file != None:
|
||||
send(
|
||||
configdir = args.config,
|
||||
identitypath = args.identity,
|
||||
verbosity = args.verbose,
|
||||
quietness = args.quiet,
|
||||
destination = args.destination,
|
||||
|
||||
@@ -56,7 +56,7 @@ def main():
|
||||
parser.add_argument('-v', '--verbose', action='count', default=0)
|
||||
parser.add_argument('-q', '--quiet', action='count', default=0)
|
||||
parser.add_argument("--exampleconfig", action='store_true', default=False, help="print verbose configuration example to stdout and exit")
|
||||
parser.add_argument("--version", action="version", version="ir {version}".format(version=__version__))
|
||||
parser.add_argument("--version", action="version", version="rnir {version}".format(version=__version__))
|
||||
|
||||
args = parser.parse_args()
|
||||
|
||||
@@ -75,8 +75,5 @@ def main():
|
||||
print("")
|
||||
exit()
|
||||
|
||||
__example_rns_config__ = '''# This is an example Identity Resolver file.
|
||||
'''
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
|
||||
@@ -49,9 +49,9 @@ import RNS
|
||||
RNS.logtimefmt = "%H:%M:%S"
|
||||
RNS.compact_log_fmt = True
|
||||
|
||||
program_version = "2.4.0"
|
||||
eth_addr = "0xFDabC71AC4c0C78C95aDDDe3B4FA19d6273c5E73"
|
||||
btc_addr = "35G9uWVzrpJJibzUwpNUQGQNFzLirhrYAH"
|
||||
program_version = "2.5.0"
|
||||
eth_addr = "0x91C421DdfB8a30a49A71d63447ddb54cEBe3465E"
|
||||
btc_addr = "bc1pgqgu8h8xvj4jtafslq396v7ju7hkgymyrzyqft4llfslz5vp99psqfk3a6"
|
||||
xmr_addr = "87HcDx6jRSkMQ9nPRd5K9hGGpZLn2s7vWETjMaVM5KfV4TD36NcYa8J8WSxhTSvBzzFpqDwp2fg5GX2moZ7VAP9QMZCZGET"
|
||||
|
||||
rnode = None
|
||||
@@ -1185,8 +1185,8 @@ class RNode():
|
||||
print(" Always use a firmware downloaded as binaries or compiled from source")
|
||||
print(" from one of the following locations:")
|
||||
print(" ")
|
||||
print(" https://unsigned.io/rnode")
|
||||
print(" https://github.com/markqvist/rnode_firmware")
|
||||
print(" https://github.com/liberatedsystems/RNode_Firmware_CE")
|
||||
print(" ")
|
||||
print(" You can reflash and bootstrap this device to a verifiable state")
|
||||
print(" by using this utility. It is recommended to do so NOW!")
|
||||
@@ -1228,7 +1228,7 @@ class RNode():
|
||||
|
||||
selected_version = None
|
||||
selected_hash = None
|
||||
firmware_version_url = "https://unsigned.io/firmware/latest/?v="+program_version+"&variant="
|
||||
firmware_version_url = "https://github.com/markqvist/rnode_firmware/releases/latest/download/release.json"
|
||||
fallback_firmware_version_url = "https://github.com/markqvist/rnode_firmware/releases/latest/download/release.json"
|
||||
def ensure_firmware_file(fw_filename):
|
||||
global selected_version, selected_hash, upd_nocheck
|
||||
@@ -1269,9 +1269,15 @@ def ensure_firmware_file(fw_filename):
|
||||
try:
|
||||
# if custom firmware url, download latest release
|
||||
if selected_version == None and fw_url == None:
|
||||
version_url = firmware_version_url+fw_filename
|
||||
RNS.log("Retrieving latest version info from "+version_url)
|
||||
urlretrieve(firmware_version_url+fw_filename, UPD_DIR+"/"+fw_filename+".version.latest")
|
||||
urlretrieve(firmware_version_url, UPD_DIR+"/release_info.json")
|
||||
import json
|
||||
with open(UPD_DIR+"/release_info.json", "rb") as rif:
|
||||
rdat = json.loads(rif.read())
|
||||
variant = rdat[fw_filename]
|
||||
with open(UPD_DIR+"/"+fw_filename+".version.latest", "wb") as verf:
|
||||
inf_str = str(variant["version"])+" "+str(variant["hash"])
|
||||
verf.write(inf_str.encode("utf-8"))
|
||||
|
||||
else:
|
||||
if fw_url != None:
|
||||
if selected_version == None:
|
||||
@@ -1542,13 +1548,14 @@ def main():
|
||||
args = parser.parse_args()
|
||||
|
||||
def print_donation_block():
|
||||
print(" Ethereum : "+eth_addr)
|
||||
print(" Bitcoin : "+btc_addr)
|
||||
print(" Monero : "+xmr_addr)
|
||||
print(" Ko-Fi : https://ko-fi.com/markqvist")
|
||||
print(" Ethereum : "+eth_addr)
|
||||
print(" Bitcoin : "+btc_addr)
|
||||
print(" Monero : "+xmr_addr)
|
||||
print(" Ko-Fi : https://ko-fi.com/markqvist")
|
||||
print(" LiberaPay : https://liberapay.com/reticulum")
|
||||
print("")
|
||||
print(" Info : https://unsigned.io/")
|
||||
print(" Code : https://github.com/markqvist")
|
||||
print(" Info : https://reticulum.network")
|
||||
print(" Code : https://github.com/markqvist")
|
||||
|
||||
if args.version:
|
||||
print("rnodeconf "+program_version)
|
||||
|
||||
@@ -39,7 +39,8 @@ import argparse
|
||||
from RNS._version import __version__
|
||||
|
||||
remote_link = None
|
||||
def connect_remote(destination_hash, auth_identity, timeout, no_output = False):
|
||||
output_rst_str = "\r \r"
|
||||
def connect_remote(destination_hash, auth_identity, timeout, no_output = False, purpose="management"):
|
||||
global remote_link, reticulum
|
||||
if not RNS.Transport.has_path(destination_hash):
|
||||
if not no_output:
|
||||
@@ -51,7 +52,7 @@ def connect_remote(destination_hash, auth_identity, timeout, no_output = False):
|
||||
time.sleep(0.1)
|
||||
if time.time() - pr_time > timeout:
|
||||
if not no_output:
|
||||
print("\r \r", end="")
|
||||
print(output_rst_str, end="")
|
||||
print("Path request timed out")
|
||||
exit(12)
|
||||
|
||||
@@ -60,98 +61,210 @@ def connect_remote(destination_hash, auth_identity, timeout, no_output = False):
|
||||
def remote_link_closed(link):
|
||||
if link.teardown_reason == RNS.Link.TIMEOUT:
|
||||
if not no_output:
|
||||
print("\r \r", end="")
|
||||
print(output_rst_str, end="")
|
||||
print("The link timed out, exiting now")
|
||||
elif link.teardown_reason == RNS.Link.DESTINATION_CLOSED:
|
||||
if not no_output:
|
||||
print("\r \r", end="")
|
||||
print(output_rst_str, end="")
|
||||
print("The link was closed by the server, exiting now")
|
||||
else:
|
||||
if not no_output:
|
||||
print("\r \r", end="")
|
||||
print(output_rst_str, end="")
|
||||
print("Link closed unexpectedly, exiting now")
|
||||
exit(10)
|
||||
|
||||
def remote_link_established(link):
|
||||
global remote_link
|
||||
link.identify(auth_identity)
|
||||
if purpose == "management": link.identify(auth_identity)
|
||||
remote_link = link
|
||||
|
||||
if not no_output:
|
||||
print("\r \r", end="")
|
||||
print(output_rst_str, end="")
|
||||
print("Establishing link with remote transport instance...", end=" ")
|
||||
sys.stdout.flush()
|
||||
|
||||
remote_destination = RNS.Destination(remote_identity, RNS.Destination.OUT, RNS.Destination.SINGLE, "rnstransport", "remote", "management")
|
||||
if purpose == "management": remote_destination = RNS.Destination(remote_identity, RNS.Destination.OUT, RNS.Destination.SINGLE, "rnstransport", "remote", "management")
|
||||
elif purpose == "blackhole": remote_destination = RNS.Destination(remote_identity, RNS.Destination.OUT, RNS.Destination.SINGLE, "rnstransport", "info", "blackhole")
|
||||
link = RNS.Link(remote_destination)
|
||||
link.set_link_established_callback(remote_link_established)
|
||||
link.set_link_closed_callback(remote_link_closed)
|
||||
|
||||
def parse_hash(input_str):
|
||||
dest_len = (RNS.Reticulum.TRUNCATED_HASHLENGTH//8)*2
|
||||
if len(input_str) != dest_len: raise ValueError("Hash length is invalid, must be {hex} hexadecimal characters ({byte} bytes).".format(hex=dest_len, byte=dest_len//2))
|
||||
try:
|
||||
hash_bytes = bytes.fromhex(input_str)
|
||||
return hash_bytes
|
||||
except Exception as e: raise ValueError("Invalid hash entered. Check your input.")
|
||||
|
||||
def program_setup(configdir, table, rates, drop, destination_hexhash, verbosity, timeout, drop_queues,
|
||||
drop_via, max_hops, remote=None, management_identity=None, remote_timeout=RNS.Transport.PATH_REQUEST_TIMEOUT,
|
||||
no_output=False, json=False):
|
||||
blackholed=False, blackhole=False, unblackhole=False, blackhole_duration=None, blackhole_reason=None,
|
||||
remote_blackhole_list=False, remote_blackhole_list_filter=None, no_output=False, json=False):
|
||||
|
||||
global remote_link, reticulum
|
||||
reticulum = RNS.Reticulum(configdir = configdir, loglevel = 3+verbosity)
|
||||
if remote:
|
||||
try:
|
||||
dest_len = (RNS.Reticulum.TRUNCATED_HASHLENGTH//8)*2
|
||||
if len(remote) != dest_len:
|
||||
raise ValueError("Destination length is invalid, must be {hex} hexadecimal characters ({byte} bytes).".format(hex=dest_len, byte=dest_len//2))
|
||||
if len(remote) != dest_len: raise ValueError("Destination length is invalid, must be {hex} hexadecimal characters ({byte} bytes).".format(hex=dest_len, byte=dest_len//2))
|
||||
try:
|
||||
identity_hash = bytes.fromhex(remote)
|
||||
remote_hash = RNS.Destination.hash_from_name_and_identity("rnstransport.remote.management", identity_hash)
|
||||
except Exception as e:
|
||||
raise ValueError("Invalid destination entered. Check your input.")
|
||||
except Exception as e: raise ValueError("Invalid destination entered. Check your input.")
|
||||
|
||||
identity = RNS.Identity.from_file(os.path.expanduser(management_identity))
|
||||
if identity == None:
|
||||
raise ValueError("Could not load management identity from "+str(management_identity))
|
||||
if identity == None: raise ValueError("Could not load management identity from "+str(management_identity))
|
||||
|
||||
try:
|
||||
connect_remote(remote_hash, identity, remote_timeout, no_output)
|
||||
except Exception as e:
|
||||
raise e
|
||||
try: connect_remote(remote_hash, identity, remote_timeout, no_output)
|
||||
except Exception as e: raise e
|
||||
|
||||
except Exception as e:
|
||||
print(str(e))
|
||||
exit(20)
|
||||
|
||||
while remote_link == None:
|
||||
time.sleep(0.1)
|
||||
while remote_link == None: time.sleep(0.1)
|
||||
|
||||
if blackholed or remote_blackhole_list:
|
||||
blackholed_list = None
|
||||
if blackholed:
|
||||
if remote_link:
|
||||
if not no_output:
|
||||
print(output_rst_str, end="")
|
||||
print("Listing blackholed identities on remote instances not yet implemented")
|
||||
exit(255)
|
||||
|
||||
if table:
|
||||
try: blackholed_list = reticulum.get_blackholed_identities()
|
||||
except Exception as e:
|
||||
print(f"Could not get blackholed identities from RNS instance: {e}")
|
||||
exit(20)
|
||||
|
||||
elif remote_blackhole_list:
|
||||
try: identity_hash = parse_hash(destination_hexhash)
|
||||
except Exception as e:
|
||||
print(f"{e}")
|
||||
exit(20)
|
||||
|
||||
remote_hash = RNS.Destination.hash_from_name_and_identity("rnstransport.info.blackhole", identity_hash)
|
||||
connect_remote(remote_hash, None, remote_timeout, no_output, purpose="blackhole")
|
||||
while remote_link == None: time.sleep(0.1)
|
||||
|
||||
if not no_output:
|
||||
print(output_rst_str, end="")
|
||||
print("Sending request...", end=" ")
|
||||
sys.stdout.flush()
|
||||
receipt = remote_link.request("/list")
|
||||
while not receipt.concluded(): time.sleep(0.1)
|
||||
response = receipt.get_response()
|
||||
if type(response) == dict:
|
||||
blackholed_list = response
|
||||
print(output_rst_str, end="")
|
||||
else:
|
||||
if not no_output:
|
||||
print(output_rst_str, end="")
|
||||
print("The remote request failed.")
|
||||
exit(10)
|
||||
|
||||
else:
|
||||
print(f"Nowhere to fetch blackhole list from")
|
||||
exit(255)
|
||||
|
||||
if not blackholed_list:
|
||||
print("No blackholed identity data available")
|
||||
exit(20)
|
||||
|
||||
else:
|
||||
rmlen = 64
|
||||
def trunc(input_str):
|
||||
if len(input_str) <= rmlen: return input_str
|
||||
else: return f"{input_str[:rmlen-1]}…"
|
||||
|
||||
try:
|
||||
now = time.time()
|
||||
for identity_hash in blackholed_list:
|
||||
until = blackholed_list[identity_hash]["until"]
|
||||
reason = blackholed_list[identity_hash]["reason"]
|
||||
source = blackholed_list[identity_hash]["source"]
|
||||
until_str = f"for {RNS.prettytime(max(0, until-now))}" if until else "indefinitely"
|
||||
reason_str = f" ({trunc(reason)})" if reason else ""
|
||||
by_str = f" by {RNS.prettyhexrep(source)}" if source != RNS.Transport.identity.hash else ""
|
||||
filter_str = f"{RNS.prettyhexrep(identity_hash)} {until_str} {reason_str} {by_str}"
|
||||
|
||||
if not remote_blackhole_list:
|
||||
if destination_hexhash and not destination_hexhash in filter_str: continue
|
||||
else:
|
||||
if remote_blackhole_list_filter and not remote_blackhole_list_filter in filter_str: continue
|
||||
|
||||
print(f"{RNS.prettyhexrep(identity_hash)} blackholed {until_str}{reason_str}{by_str}")
|
||||
|
||||
except Exception as e:
|
||||
print(f"Error while displaying collected blackhole data: {e}")
|
||||
exit(20)
|
||||
|
||||
elif blackhole:
|
||||
if remote_link:
|
||||
if not no_output:
|
||||
print(output_rst_str, end="")
|
||||
print("Blackholing identity on remote instances not yet implemented")
|
||||
exit(255)
|
||||
|
||||
try:
|
||||
identity_hash = parse_hash(destination_hexhash)
|
||||
until = time.time()+blackhole_duration*60*60 if blackhole_duration else None
|
||||
result = reticulum.blackhole_identity(identity_hash, until=until, reason=blackhole_reason)
|
||||
if result == True: print(f"Blackholed identity {destination_hexhash}")
|
||||
elif result == None: print(f"Identity {destination_hexhash} already blackholed")
|
||||
else: print(f"Could not blackhole identity {destination_hexhash}")
|
||||
|
||||
except Exception as e:
|
||||
print(f"Could not blackhole identity: {e}")
|
||||
exit(20)
|
||||
|
||||
elif unblackhole:
|
||||
if remote_link:
|
||||
if not no_output:
|
||||
print(output_rst_str, end="")
|
||||
print("Blackholing identity on remote instances not yet implemented")
|
||||
exit(255)
|
||||
|
||||
try:
|
||||
identity_hash = parse_hash(destination_hexhash)
|
||||
result = reticulum.unblackhole_identity(identity_hash)
|
||||
if result == True: print(f"Lifted blackhole for identity {destination_hexhash}")
|
||||
elif result == None: print(f"Identity {destination_hexhash} not blackholed")
|
||||
else: print(f"Could not unblackhole identity {destination_hexhash}")
|
||||
|
||||
except Exception as e:
|
||||
print(f"Could not unblackhole identity: {e}")
|
||||
exit(20)
|
||||
|
||||
elif table:
|
||||
destination_hash = None
|
||||
if destination_hexhash != None:
|
||||
try:
|
||||
dest_len = (RNS.Reticulum.TRUNCATED_HASHLENGTH//8)*2
|
||||
if len(destination_hexhash) != dest_len:
|
||||
raise ValueError("Destination length is invalid, must be {hex} hexadecimal characters ({byte} bytes).".format(hex=dest_len, byte=dest_len//2))
|
||||
try:
|
||||
destination_hash = bytes.fromhex(destination_hexhash)
|
||||
except Exception as e:
|
||||
raise ValueError("Invalid destination entered. Check your input.")
|
||||
if len(destination_hexhash) != dest_len: raise ValueError("Destination length is invalid, must be {hex} hexadecimal characters ({byte} bytes).".format(hex=dest_len, byte=dest_len//2))
|
||||
try: destination_hash = bytes.fromhex(destination_hexhash)
|
||||
except Exception as e: raise ValueError("Invalid destination entered. Check your input.")
|
||||
except Exception as e:
|
||||
print(str(e))
|
||||
sys.exit(1)
|
||||
|
||||
if not remote_link:
|
||||
table = sorted(reticulum.get_path_table(max_hops=max_hops), key=lambda e: (e["interface"], e["hops"]) )
|
||||
if not remote_link: table = sorted(reticulum.get_path_table(max_hops=max_hops), key=lambda e: (e["interface"], e["hops"]) )
|
||||
else:
|
||||
if not no_output:
|
||||
print("\r \r", end="")
|
||||
print(output_rst_str, end="")
|
||||
print("Sending request...", end=" ")
|
||||
sys.stdout.flush()
|
||||
receipt = remote_link.request("/path", data = ["table", destination_hash, max_hops])
|
||||
while not receipt.concluded():
|
||||
time.sleep(0.1)
|
||||
while not receipt.concluded(): time.sleep(0.1)
|
||||
response = receipt.get_response()
|
||||
if response:
|
||||
table = response
|
||||
print("\r \r", end="")
|
||||
print(output_rst_str, end="")
|
||||
else:
|
||||
if not no_output:
|
||||
print("\r \r", end="")
|
||||
print(output_rst_str, end="")
|
||||
print("The remote request failed. Likely authentication failure.")
|
||||
exit(10)
|
||||
|
||||
@@ -160,20 +273,18 @@ def program_setup(configdir, table, rates, drop, destination_hexhash, verbosity,
|
||||
import json
|
||||
for p in table:
|
||||
for k in p:
|
||||
if isinstance(p[k], bytes):
|
||||
p[k] = RNS.hexrep(p[k], delimit=False)
|
||||
if isinstance(p[k], bytes): p[k] = RNS.hexrep(p[k], delimit=False)
|
||||
|
||||
print(json.dumps(table))
|
||||
exit()
|
||||
|
||||
else:
|
||||
for path in table:
|
||||
if destination_hash == None or destination_hash == path["hash"]:
|
||||
displayed += 1
|
||||
exp_str = RNS.timestamp_str(path["expires"])
|
||||
if path["hops"] == 1:
|
||||
m_str = " "
|
||||
else:
|
||||
m_str = "s"
|
||||
if path["hops"] == 1: m_str = " "
|
||||
else: m_str = "s"
|
||||
print(RNS.prettyhexrep(path["hash"])+" is "+str(path["hops"])+" hop"+m_str+" away via "+RNS.prettyhexrep(path["via"])+" on "+path["interface"]+" expires "+RNS.timestamp_str(path["expires"]))
|
||||
|
||||
if destination_hash != None and displayed == 0:
|
||||
@@ -185,21 +296,17 @@ def program_setup(configdir, table, rates, drop, destination_hexhash, verbosity,
|
||||
if destination_hexhash != None:
|
||||
try:
|
||||
dest_len = (RNS.Reticulum.TRUNCATED_HASHLENGTH//8)*2
|
||||
if len(destination_hexhash) != dest_len:
|
||||
raise ValueError("Destination length is invalid, must be {hex} hexadecimal characters ({byte} bytes).".format(hex=dest_len, byte=dest_len//2))
|
||||
try:
|
||||
destination_hash = bytes.fromhex(destination_hexhash)
|
||||
except Exception as e:
|
||||
raise ValueError("Invalid destination entered. Check your input.")
|
||||
if len(destination_hexhash) != dest_len: raise ValueError("Destination length is invalid, must be {hex} hexadecimal characters ({byte} bytes).".format(hex=dest_len, byte=dest_len//2))
|
||||
try: destination_hash = bytes.fromhex(destination_hexhash)
|
||||
except Exception as e: raise ValueError("Invalid destination entered. Check your input.")
|
||||
except Exception as e:
|
||||
print(str(e))
|
||||
sys.exit(1)
|
||||
|
||||
if not remote_link:
|
||||
table = reticulum.get_rate_table()
|
||||
if not remote_link: table = reticulum.get_rate_table()
|
||||
else:
|
||||
if not no_output:
|
||||
print("\r \r", end="")
|
||||
print(output_rst_str, end="")
|
||||
print("Sending request...", end=" ")
|
||||
sys.stdout.flush()
|
||||
receipt = remote_link.request("/path", data = ["rates", destination_hash])
|
||||
@@ -208,10 +315,10 @@ def program_setup(configdir, table, rates, drop, destination_hexhash, verbosity,
|
||||
response = receipt.get_response()
|
||||
if response:
|
||||
table = response
|
||||
print("\r \r", end="")
|
||||
print(output_rst_str, end="")
|
||||
else:
|
||||
if not no_output:
|
||||
print("\r \r", end="")
|
||||
print(output_rst_str, end="")
|
||||
print("The remote request failed. Likely authentication failure.")
|
||||
exit(10)
|
||||
|
||||
@@ -220,15 +327,12 @@ def program_setup(configdir, table, rates, drop, destination_hexhash, verbosity,
|
||||
import json
|
||||
for p in table:
|
||||
for k in p:
|
||||
if isinstance(p[k], bytes):
|
||||
p[k] = RNS.hexrep(p[k], delimit=False)
|
||||
if isinstance(p[k], bytes): p[k] = RNS.hexrep(p[k], delimit=False)
|
||||
|
||||
print(json.dumps(table))
|
||||
exit()
|
||||
else:
|
||||
if len(table) == 0:
|
||||
print("No information available")
|
||||
|
||||
if len(table) == 0: print("No information available")
|
||||
else:
|
||||
displayed = 0
|
||||
for entry in table:
|
||||
@@ -274,7 +378,7 @@ def program_setup(configdir, table, rates, drop, destination_hexhash, verbosity,
|
||||
elif drop_queues:
|
||||
if remote_link:
|
||||
if not no_output:
|
||||
print("\r \r", end="")
|
||||
print(output_rst_str, end="")
|
||||
print("Dropping announce queues on remote instances not yet implemented")
|
||||
exit(255)
|
||||
|
||||
@@ -284,24 +388,20 @@ def program_setup(configdir, table, rates, drop, destination_hexhash, verbosity,
|
||||
elif drop:
|
||||
if remote_link:
|
||||
if not no_output:
|
||||
print("\r \r", end="")
|
||||
print(output_rst_str, end="")
|
||||
print("Dropping path on remote instances not yet implemented")
|
||||
exit(255)
|
||||
|
||||
try:
|
||||
dest_len = (RNS.Reticulum.TRUNCATED_HASHLENGTH//8)*2
|
||||
if len(destination_hexhash) != dest_len:
|
||||
raise ValueError("Destination length is invalid, must be {hex} hexadecimal characters ({byte} bytes).".format(hex=dest_len, byte=dest_len//2))
|
||||
try:
|
||||
destination_hash = bytes.fromhex(destination_hexhash)
|
||||
except Exception as e:
|
||||
raise ValueError("Invalid destination entered. Check your input.")
|
||||
if len(destination_hexhash) != dest_len: raise ValueError("Destination length is invalid, must be {hex} hexadecimal characters ({byte} bytes).".format(hex=dest_len, byte=dest_len//2))
|
||||
try: destination_hash = bytes.fromhex(destination_hexhash)
|
||||
except Exception as e: raise ValueError("Invalid destination entered. Check your input.")
|
||||
except Exception as e:
|
||||
print(str(e))
|
||||
sys.exit(1)
|
||||
|
||||
if reticulum.drop_path(destination_hash):
|
||||
print("Dropped path to "+RNS.prettyhexrep(destination_hash))
|
||||
if reticulum.drop_path(destination_hash): print("Dropped path to "+RNS.prettyhexrep(destination_hash))
|
||||
else:
|
||||
print("Unable to drop path to "+RNS.prettyhexrep(destination_hash)+". Does it exist?")
|
||||
sys.exit(1)
|
||||
@@ -309,24 +409,20 @@ def program_setup(configdir, table, rates, drop, destination_hexhash, verbosity,
|
||||
elif drop_via:
|
||||
if remote_link:
|
||||
if not no_output:
|
||||
print("\r \r", end="")
|
||||
print(output_rst_str, end="")
|
||||
print("Dropping all paths via specific transport instance on remote instances yet not implemented")
|
||||
exit(255)
|
||||
|
||||
try:
|
||||
dest_len = (RNS.Reticulum.TRUNCATED_HASHLENGTH//8)*2
|
||||
if len(destination_hexhash) != dest_len:
|
||||
raise ValueError("Destination length is invalid, must be {hex} hexadecimal characters ({byte} bytes).".format(hex=dest_len, byte=dest_len//2))
|
||||
try:
|
||||
destination_hash = bytes.fromhex(destination_hexhash)
|
||||
except Exception as e:
|
||||
raise ValueError("Invalid destination entered. Check your input.")
|
||||
if len(destination_hexhash) != dest_len: raise ValueError("Destination length is invalid, must be {hex} hexadecimal characters ({byte} bytes).".format(hex=dest_len, byte=dest_len//2))
|
||||
try: destination_hash = bytes.fromhex(destination_hexhash)
|
||||
except Exception as e: raise ValueError("Invalid destination entered. Check your input.")
|
||||
except Exception as e:
|
||||
print(str(e))
|
||||
sys.exit(1)
|
||||
|
||||
if reticulum.drop_all_via(destination_hash):
|
||||
print("Dropped all paths via "+RNS.prettyhexrep(destination_hash))
|
||||
if reticulum.drop_all_via(destination_hash): print("Dropped all paths via "+RNS.prettyhexrep(destination_hash))
|
||||
else:
|
||||
print("Unable to drop paths via "+RNS.prettyhexrep(destination_hash)+". Does the transport instance exist?")
|
||||
sys.exit(1)
|
||||
@@ -334,18 +430,15 @@ def program_setup(configdir, table, rates, drop, destination_hexhash, verbosity,
|
||||
else:
|
||||
if remote_link:
|
||||
if not no_output:
|
||||
print("\r \r", end="")
|
||||
print(output_rst_str, end="")
|
||||
print("Requesting paths on remote instances not implemented")
|
||||
exit(255)
|
||||
|
||||
try:
|
||||
dest_len = (RNS.Reticulum.TRUNCATED_HASHLENGTH//8)*2
|
||||
if len(destination_hexhash) != dest_len:
|
||||
raise ValueError("Destination length is invalid, must be {hex} hexadecimal characters ({byte} bytes).".format(hex=dest_len, byte=dest_len//2))
|
||||
try:
|
||||
destination_hash = bytes.fromhex(destination_hexhash)
|
||||
except Exception as e:
|
||||
raise ValueError("Invalid destination entered. Check your input.")
|
||||
if len(destination_hexhash) != dest_len: raise ValueError("Destination length is invalid, must be {hex} hexadecimal characters ({byte} bytes).".format(hex=dest_len, byte=dest_len//2))
|
||||
try: destination_hash = bytes.fromhex(destination_hexhash)
|
||||
except Exception as e: raise ValueError("Invalid destination entered. Check your input.")
|
||||
except Exception as e:
|
||||
print(str(e))
|
||||
sys.exit(1)
|
||||
@@ -374,166 +467,57 @@ def program_setup(configdir, table, rates, drop, destination_hexhash, verbosity,
|
||||
next_hop = RNS.prettyhexrep(next_hop_bytes)
|
||||
next_hop_interface = reticulum.get_next_hop_if_name(destination_hash)
|
||||
|
||||
if hops != 1:
|
||||
ms = "s"
|
||||
else:
|
||||
ms = ""
|
||||
if hops != 1: ms = "s"
|
||||
else: ms = ""
|
||||
|
||||
print("\rPath found, destination "+RNS.prettyhexrep(destination_hash)+" is "+str(hops)+" hop"+ms+" away via "+next_hop+" on "+next_hop_interface)
|
||||
else:
|
||||
print("\r \rPath not found")
|
||||
sys.exit(1)
|
||||
|
||||
|
||||
|
||||
def main():
|
||||
try:
|
||||
parser = argparse.ArgumentParser(description="Reticulum Path Discovery Utility")
|
||||
|
||||
parser.add_argument("--config",
|
||||
action="store",
|
||||
default=None,
|
||||
help="path to alternative Reticulum config directory",
|
||||
type=str
|
||||
)
|
||||
|
||||
parser.add_argument(
|
||||
"--version",
|
||||
action="version",
|
||||
version="rnpath {version}".format(version=__version__)
|
||||
)
|
||||
|
||||
parser.add_argument(
|
||||
"-t",
|
||||
"--table",
|
||||
action="store_true",
|
||||
help="show all known paths",
|
||||
default=False
|
||||
)
|
||||
|
||||
parser.add_argument(
|
||||
"-m",
|
||||
"--max",
|
||||
action="store",
|
||||
metavar="hops",
|
||||
type=int,
|
||||
help="maximum hops to filter path table by",
|
||||
default=None
|
||||
)
|
||||
|
||||
parser.add_argument(
|
||||
"-r",
|
||||
"--rates",
|
||||
action="store_true",
|
||||
help="show announce rate info",
|
||||
default=False
|
||||
)
|
||||
|
||||
parser.add_argument(
|
||||
"-d",
|
||||
"--drop",
|
||||
action="store_true",
|
||||
help="remove the path to a destination",
|
||||
default=False
|
||||
)
|
||||
|
||||
parser.add_argument(
|
||||
"-D",
|
||||
"--drop-announces",
|
||||
action="store_true",
|
||||
help="drop all queued announces",
|
||||
default=False
|
||||
)
|
||||
|
||||
parser.add_argument(
|
||||
"-x", "--drop-via",
|
||||
action="store_true",
|
||||
help="drop all paths via specified transport instance",
|
||||
default=False
|
||||
)
|
||||
|
||||
parser.add_argument(
|
||||
"-w",
|
||||
action="store",
|
||||
metavar="seconds",
|
||||
type=float,
|
||||
help="timeout before giving up",
|
||||
default=RNS.Transport.PATH_REQUEST_TIMEOUT
|
||||
)
|
||||
|
||||
parser.add_argument(
|
||||
"-R",
|
||||
action="store",
|
||||
metavar="hash",
|
||||
help="transport identity hash of remote instance to manage",
|
||||
default=None,
|
||||
type=str
|
||||
)
|
||||
|
||||
parser.add_argument(
|
||||
"-i",
|
||||
action="store",
|
||||
metavar="path",
|
||||
help="path to identity used for remote management",
|
||||
default=None,
|
||||
type=str
|
||||
)
|
||||
|
||||
parser.add_argument(
|
||||
"-W",
|
||||
action="store",
|
||||
metavar="seconds",
|
||||
type=float,
|
||||
help="timeout before giving up on remote queries",
|
||||
default=RNS.Transport.PATH_REQUEST_TIMEOUT
|
||||
)
|
||||
|
||||
parser.add_argument(
|
||||
"-j",
|
||||
"--json",
|
||||
action="store_true",
|
||||
help="output in JSON format",
|
||||
default=False
|
||||
)
|
||||
|
||||
parser.add_argument(
|
||||
"destination",
|
||||
nargs="?",
|
||||
default=None,
|
||||
help="hexadecimal hash of the destination",
|
||||
type=str
|
||||
)
|
||||
|
||||
parser = argparse.ArgumentParser(description="Reticulum Path Management Utility")
|
||||
parser.add_argument("--config", action="store", default=None, help="path to alternative Reticulum config directory", type=str)
|
||||
parser.add_argument("--version", action="version", version="rnpath {version}".format(version=__version__))
|
||||
parser.add_argument("-t", "--table", action="store_true", help="show all known paths", default=False)
|
||||
parser.add_argument("-m", "--max", action="store", metavar="hops", type=int, help="maximum hops to filter path table by", default=None)
|
||||
parser.add_argument("-r", "--rates", action="store_true", help="show announce rate info", default=False)
|
||||
parser.add_argument("-d", "--drop", action="store_true", help="remove the path to a destination", default=False)
|
||||
parser.add_argument("-D", "--drop-announces", action="store_true", help="drop all queued announces", default=False)
|
||||
parser.add_argument("-x", "--drop-via", action="store_true", help="drop all paths via specified transport instance", default=False)
|
||||
parser.add_argument("-w", action="store", metavar="seconds", type=float, help="timeout before giving up", default=RNS.Transport.PATH_REQUEST_TIMEOUT)
|
||||
parser.add_argument("-R", action="store", metavar="hash", help="transport identity hash of remote instance to manage", default=None, type=str)
|
||||
parser.add_argument("-i", action="store", metavar="path", help="path to identity used for remote management", default=None, type=str)
|
||||
parser.add_argument("-W", action="store", metavar="seconds", type=float, help="timeout before giving up on remote queries", default=RNS.Transport.PATH_REQUEST_TIMEOUT)
|
||||
parser.add_argument("-b", "--blackholed", action="store_true", help="list blackholed identities", default=False)
|
||||
parser.add_argument("-B", "--blackhole", action="store_true", help="blackhole identity", default=False)
|
||||
parser.add_argument("-U", "--unblackhole", action="store_true", help="unblackhole identity", default=False)
|
||||
parser.add_argument( "--duration", action="store", type=float, help="duration of blackhole enforcement in hours", default=None)
|
||||
parser.add_argument( "--reason", action="store", type=str, help="reason for blackholing identity", default=None)
|
||||
parser.add_argument("-p", "--blackholed-list", action="store_true", help="view published blackhole list for remote transport instance", default=False)
|
||||
parser.add_argument("-j", "--json", action="store_true", help="output in JSON format", default=False)
|
||||
parser.add_argument("destination", nargs="?", default=None, help="hexadecimal hash of the destination", type=str)
|
||||
parser.add_argument("list_filter", nargs="?", default=None, help="filter for remote blackhole list view", type=str)
|
||||
parser.add_argument('-v', '--verbose', action='count', default=0)
|
||||
|
||||
args = parser.parse_args()
|
||||
|
||||
if args.config:
|
||||
configarg = args.config
|
||||
else:
|
||||
configarg = None
|
||||
if args.config: configarg = args.config
|
||||
else: configarg = None
|
||||
|
||||
if not args.drop_announces and not args.table and not args.rates and not args.destination and not args.drop_via:
|
||||
if not args.drop_announces and not args.table and not args.rates and not args.destination and not args.drop_via and not args.blackholed:
|
||||
print("")
|
||||
parser.print_help()
|
||||
print("")
|
||||
else:
|
||||
program_setup(
|
||||
configdir = configarg,
|
||||
table = args.table,
|
||||
rates = args.rates,
|
||||
drop = args.drop,
|
||||
destination_hexhash = args.destination,
|
||||
verbosity = args.verbose,
|
||||
timeout = args.w,
|
||||
drop_queues = args.drop_announces,
|
||||
drop_via = args.drop_via,
|
||||
max_hops = args.max,
|
||||
remote=args.R,
|
||||
management_identity=args.i,
|
||||
remote_timeout=args.W,
|
||||
json=args.json,
|
||||
)
|
||||
program_setup(configdir = configarg, table = args.table, rates = args.rates, drop = args.drop, destination_hexhash = args.destination,
|
||||
verbosity = args.verbose, timeout = args.w, drop_queues = args.drop_announces, drop_via = args.drop_via, max_hops = args.max,
|
||||
remote=args.R, management_identity=args.i, remote_timeout=args.W, blackholed=args.blackholed, blackhole=args.blackhole,
|
||||
unblackhole=args.unblackhole, blackhole_duration=args.duration, blackhole_reason=args.reason, remote_blackhole_list=args.blackholed_list,
|
||||
remote_blackhole_list_filter=args.list_filter, json=args.json)
|
||||
|
||||
sys.exit(0)
|
||||
|
||||
except KeyboardInterrupt:
|
||||
@@ -543,38 +527,23 @@ def main():
|
||||
def pretty_date(time=False):
|
||||
from datetime import datetime
|
||||
now = datetime.now()
|
||||
if type(time) is int:
|
||||
diff = now - datetime.fromtimestamp(time)
|
||||
elif isinstance(time,datetime):
|
||||
diff = now - time
|
||||
elif not time:
|
||||
diff = now - now
|
||||
if type(time) is int: diff = now - datetime.fromtimestamp(time)
|
||||
elif isinstance(time,datetime): diff = now - time
|
||||
elif not time: diff = now - now
|
||||
second_diff = diff.seconds
|
||||
day_diff = diff.days
|
||||
if day_diff < 0:
|
||||
return ''
|
||||
if day_diff < 0: return ''
|
||||
if day_diff == 0:
|
||||
if second_diff < 10:
|
||||
return str(second_diff) + " seconds"
|
||||
if second_diff < 60:
|
||||
return str(second_diff) + " seconds"
|
||||
if second_diff < 120:
|
||||
return "1 minute"
|
||||
if second_diff < 3600:
|
||||
return str(int(second_diff / 60)) + " minutes"
|
||||
if second_diff < 7200:
|
||||
return "an hour"
|
||||
if second_diff < 86400:
|
||||
return str(int(second_diff / 3600)) + " hours"
|
||||
if day_diff == 1:
|
||||
return "1 day"
|
||||
if day_diff < 7:
|
||||
return str(day_diff) + " days"
|
||||
if day_diff < 31:
|
||||
return str(int(day_diff / 7)) + " weeks"
|
||||
if day_diff < 365:
|
||||
return str(int(day_diff / 30)) + " months"
|
||||
if second_diff < 10: return str(second_diff) + " seconds"
|
||||
if second_diff < 60: return str(second_diff) + " seconds"
|
||||
if second_diff < 120: return "1 minute"
|
||||
if second_diff < 3600: return str(int(second_diff / 60)) + " minutes"
|
||||
if second_diff < 7200: return "an hour"
|
||||
if second_diff < 86400: return str(int(second_diff / 3600)) + " hours"
|
||||
if day_diff == 1: return "1 day"
|
||||
if day_diff < 7: return str(day_diff) + " days"
|
||||
if day_diff < 31: return str(int(day_diff / 7)) + " weeks"
|
||||
if day_diff < 365: return str(int(day_diff / 30)) + " months"
|
||||
return str(int(day_diff / 365)) + " years"
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
if __name__ == "__main__": main()
|
||||
@@ -0,0 +1,78 @@
|
||||
#!/usr/bin/env python3
|
||||
|
||||
# Reticulum License
|
||||
#
|
||||
# Copyright (c) 2016-2025 Mark Qvist
|
||||
#
|
||||
# Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
# of this software and associated documentation files (the "Software"), to deal
|
||||
# in the Software without restriction, including without limitation the rights
|
||||
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||
# copies of the Software, and to permit persons to whom the Software is
|
||||
# furnished to do so, subject to the following conditions:
|
||||
#
|
||||
# - The Software shall not be used in any kind of system which includes amongst
|
||||
# its functions the ability to purposefully do harm to human beings.
|
||||
#
|
||||
# - The Software shall not be used, directly or indirectly, in the creation of
|
||||
# an artificial intelligence, machine learning or language model training
|
||||
# dataset, including but not limited to any use that contributes to the
|
||||
# training or development of such a model or algorithm.
|
||||
#
|
||||
# - The above copyright notice and this permission notice shall be included in
|
||||
# all copies or substantial portions of the Software.
|
||||
#
|
||||
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||
# SOFTWARE.
|
||||
|
||||
import RNS
|
||||
import argparse
|
||||
import time
|
||||
|
||||
from RNS._version import __version__
|
||||
|
||||
def program_setup(configdir, verbosity = 0, quietness = 0, service = False):
|
||||
targetverbosity = verbosity-quietness
|
||||
|
||||
if service:
|
||||
targetlogdest = RNS.LOG_FILE
|
||||
targetverbosity = None
|
||||
else:
|
||||
targetlogdest = RNS.LOG_STDOUT
|
||||
|
||||
reticulum = RNS.Reticulum(configdir=configdir, verbosity=targetverbosity, logdest=targetlogdest)
|
||||
exit(0)
|
||||
|
||||
def main():
|
||||
try:
|
||||
parser = argparse.ArgumentParser(description="Reticulum Meta Package Manager")
|
||||
parser.add_argument("--config", action="store", default=None, help="path to alternative Reticulum config directory", type=str)
|
||||
parser.add_argument('-v', '--verbose', action='count', default=0)
|
||||
parser.add_argument('-q', '--quiet', action='count', default=0)
|
||||
parser.add_argument("--exampleconfig", action='store_true', default=False, help="print verbose configuration example to stdout and exit")
|
||||
parser.add_argument("--version", action="version", version="rnpkg {version}".format(version=__version__))
|
||||
|
||||
args = parser.parse_args()
|
||||
|
||||
if args.exampleconfig:
|
||||
print(__example_rnpkg_config__)
|
||||
exit()
|
||||
|
||||
if args.config: configarg = args.config
|
||||
else: configarg = None
|
||||
|
||||
program_setup(configdir = configarg, verbosity=args.verbose, quietness=args.quiet)
|
||||
|
||||
except KeyboardInterrupt:
|
||||
print("")
|
||||
exit()
|
||||
|
||||
__example_rnpkg_config__ = '''# This is an example package manager configuration file.
|
||||
'''
|
||||
|
||||
if __name__ == "__main__": main()
|
||||
@@ -160,6 +160,55 @@ instance_name = default
|
||||
# remote_management_allowed = 9fb6d773498fb3feda407ed8ef2c3229, 2d882c5586e548d79b5af27bca1776dc
|
||||
|
||||
|
||||
# For easier management, discovery and configuration of
|
||||
# networks with many individual transport instances,
|
||||
# you can specify a network identity to be used across
|
||||
# a set of instances. If sending interface discovery
|
||||
# announces, these will all be signed by the specified
|
||||
# network identity, and other nodes discovering your
|
||||
# interfaces will be able to identify that they belong
|
||||
# to the same network, even though they exist on different
|
||||
# transport nodes.
|
||||
|
||||
# network_identity = ~/.reticulum/storage/identity/network
|
||||
|
||||
|
||||
# You can configure whether Reticulum should discover
|
||||
# available interfaces from other Transport Instances over
|
||||
# the network. If this option is enabled, Reticulum will
|
||||
# collect interface information discovered from the network.
|
||||
|
||||
# discover_interfaces = No
|
||||
|
||||
|
||||
# If you only want to discover interfaces from specific
|
||||
# networks, you can provide a list of network identities
|
||||
# from which to discover interfaces. If this option is not
|
||||
# provided, interfaces will be discovered from all transport
|
||||
# instances on all connected networks.
|
||||
|
||||
# interface_discovery_sources = 78616ff7c4b8d3886d67d494b440f333, cb127015e13aa6ea1e0a606cdc9123d0
|
||||
|
||||
|
||||
# It is possible to automatically bring up and connect new
|
||||
# interfaces discovered over the network. This option is
|
||||
# disabled by default, but allows you to specify a maximum
|
||||
# number of discovered interfaces to automatically connect.
|
||||
# Additionally, if this option is enabled, Reticulum will
|
||||
# also try to autoconnect available auto-discovered inter-
|
||||
# faces on startup, up to the maximum number specified.
|
||||
|
||||
# autoconnect_discovered_interfaces = 0
|
||||
|
||||
|
||||
# To prevent interface discovery spamming, a valid crypto-
|
||||
# graphic stamp is required per announced interface. You
|
||||
# can configure the minimum required value to accept as
|
||||
# valid for discovered interfaces.
|
||||
|
||||
# required_discovery_value = 14
|
||||
|
||||
|
||||
# You can configure Reticulum to panic and forcibly close
|
||||
# if an unrecoverable interface error occurs, such as the
|
||||
# hardware device for an interface disappearing. This is
|
||||
@@ -180,6 +229,26 @@ instance_name = default
|
||||
# respond_to_probes = No
|
||||
|
||||
|
||||
# You can publish your local list of blackholed identities
|
||||
# for other transport instances to use for automatic,
|
||||
# network-wide blackhole management.
|
||||
|
||||
# publish_blackhole = No
|
||||
|
||||
# List of remote transport identities from which to auto-
|
||||
# matically source lists of blackholed identities.
|
||||
#
|
||||
# If you're connecting to a large external network, you
|
||||
# can use one or more external blackhole list to block
|
||||
# spammy and excessive announces onto your network. This
|
||||
# funtionality is especially useful if you're hosting public
|
||||
# entrypoints or gateways. The list source below provides a
|
||||
# functional example, but better, more timely maintained
|
||||
# lists probably exist in the community.
|
||||
|
||||
# blackhole_sources = 521c87a83afb8f29e4455e77930b973b
|
||||
|
||||
|
||||
[logging]
|
||||
# Valid log levels are 0 through 7:
|
||||
# 0: Log only critical information
|
||||
|
||||
@@ -35,6 +35,7 @@ import os
|
||||
import sys
|
||||
import time
|
||||
import argparse
|
||||
import io
|
||||
|
||||
from RNS._version import __version__
|
||||
|
||||
@@ -141,14 +142,12 @@ def get_remote_status(destination_hash, include_lstats, identity, no_output=Fals
|
||||
|
||||
return request_result
|
||||
|
||||
def program_setup(configdir, dispall=False, verbosity=0, name_filter=None, json=False, astats=False,
|
||||
lstats=False, sorting=None, sort_reverse=False, remote=None, management_identity=None,
|
||||
remote_timeout=RNS.Transport.PATH_REQUEST_TIMEOUT, must_exit=True, rns_instance=None, traffic_totals=False):
|
||||
|
||||
if remote:
|
||||
require_shared = False
|
||||
else:
|
||||
require_shared = True
|
||||
def program_setup(configdir, dispall=False, verbosity=0, name_filter=None, json=False, astats=False, lstats=False, sorting=None, sort_reverse=False,
|
||||
remote=None, management_identity=None, remote_timeout=RNS.Transport.PATH_REQUEST_TIMEOUT, must_exit=True, rns_instance=None,
|
||||
traffic_totals=False, discovered_interfaces=False, config_entries=False):
|
||||
|
||||
if remote: require_shared = False
|
||||
else: require_shared = True
|
||||
|
||||
try:
|
||||
if rns_instance:
|
||||
@@ -159,13 +158,145 @@ def program_setup(configdir, dispall=False, verbosity=0, name_filter=None, json=
|
||||
|
||||
except Exception as e:
|
||||
print("No shared RNS instance available to get status from")
|
||||
if must_exit:
|
||||
exit(1)
|
||||
else:
|
||||
return
|
||||
if must_exit: exit(1)
|
||||
else: return
|
||||
|
||||
link_count = None
|
||||
stats = None
|
||||
|
||||
details = False
|
||||
if config_entries:
|
||||
discovered_interfaces = True
|
||||
details = True
|
||||
|
||||
if discovered_interfaces:
|
||||
if_discovery = RNS.Discovery.InterfaceDiscovery(discover_interfaces=False)
|
||||
ifs = if_discovery.list_discovered_interfaces()
|
||||
print("")
|
||||
|
||||
if json:
|
||||
import json
|
||||
for i in ifs:
|
||||
for e in i:
|
||||
if isinstance(i[e], bytes): i[e] = RNS.hexrep(i[e], delimit=False)
|
||||
|
||||
print(json.dumps(ifs))
|
||||
|
||||
else:
|
||||
filtered_ifs = []
|
||||
for i in ifs:
|
||||
name = i["name"]
|
||||
if not name_filter or name_filter.lower() in name.lower(): filtered_ifs.append(i)
|
||||
|
||||
if details:
|
||||
for idx, i in enumerate(filtered_ifs):
|
||||
try:
|
||||
name = i["name"]
|
||||
if_type = i["type"]
|
||||
status = i["status"]
|
||||
|
||||
if status == "available": status_display = "Available"
|
||||
elif status == "unknown": status_display = "Unknown"
|
||||
elif status == "stale": status_display = "Stale"
|
||||
else: status_display = status
|
||||
|
||||
now = time.time()
|
||||
dago = now-i["discovered"]
|
||||
hago = now-i["last_heard"]
|
||||
discovered_display = f"{RNS.prettytime(dago, compact=True)} ago"
|
||||
last_heard_display = f"{RNS.prettytime(hago, compact=True)} ago"
|
||||
transport_str = "Enabled" if i["transport"] else "Disabled"
|
||||
|
||||
if i["latitude"] is not None and i["longitude"] is not None:
|
||||
lat = round(i["latitude"], 4)
|
||||
lon = round(i["longitude"], 4)
|
||||
if i["height"] != None: height = ", "+str(i["height"])+"m h"
|
||||
else: height = ""
|
||||
location = f"{lat}, {lon}{height}"
|
||||
else: location = "Unknown"
|
||||
|
||||
transport_id = None
|
||||
network = None
|
||||
if "transport_id" in i: transport_id = i["transport_id"]
|
||||
if "transport_id" in i and "network_id" in i and i["transport_id"] != i["network_id"]:
|
||||
network = i["network_id"]
|
||||
|
||||
if idx > 0: print("\n"+"="*32+"\n")
|
||||
if network: print(f"Network ID : {network}")
|
||||
if transport_id: print(f"Transport ID : {transport_id}")
|
||||
|
||||
print(f"Name : {name}")
|
||||
print(f"Type : {if_type}")
|
||||
print(f"Status : {status_display}")
|
||||
print(f"Transport : {transport_str}")
|
||||
print(f"Distance : {i['hops']} hop{'' if i['hops'] == 1 else 's'}")
|
||||
print(f"Discovered : {discovered_display}")
|
||||
print(f"Last Heard : {last_heard_display}")
|
||||
print(f"Location : {location}")
|
||||
|
||||
if "frequency" in i: print(f"Frequency : {i['frequency']:,} Hz")
|
||||
if "bandwidth" in i: print(f"Bandwidth : {i['bandwidth']:,} Hz")
|
||||
if "sf" in i: print(f"Sprd. Factor : {i['sf']}")
|
||||
if "cr" in i: print(f"Coding Rate : {i['cr']}")
|
||||
if "modulation" in i: print(f"Modulation : {i['modulation']}")
|
||||
if "reachable_on" in i: print(f"Address : {i['reachable_on']}:{i['port']}")
|
||||
|
||||
print(f"Stamp Value : {i['value']}")
|
||||
|
||||
print(f"\nConfiguration Entry:")
|
||||
config_lines = i["config_entry"].split('\n')
|
||||
for line in config_lines: print(f" {line}")
|
||||
|
||||
except Exception as e:
|
||||
pass
|
||||
|
||||
else:
|
||||
print(f"{'Name':<25} {'Type':<12} {'Status':<12} {'Last Heard':<12} {'Value':<8} {'Location':<15}")
|
||||
print("-" * 89)
|
||||
|
||||
for i in filtered_ifs:
|
||||
try:
|
||||
name = i["name"][:24] + "…" if len(i["name"]) > 24 else i["name"]
|
||||
|
||||
if_type = i["type"].replace("Interface", "")
|
||||
|
||||
status = i["status"]
|
||||
if status == "available": status_display = "✓ Available"
|
||||
elif status == "unknown": status_display = "? Unknown"
|
||||
elif status == "stale": status_display = "× Stale"
|
||||
else: status_display = status
|
||||
|
||||
now = time.time()
|
||||
last_heard = i["last_heard"]
|
||||
diff = now - last_heard
|
||||
|
||||
if diff < 60: last_heard_display = "Just now"
|
||||
elif diff < 3600:
|
||||
mins = int(diff / 60)
|
||||
last_heard_display = f"{mins}m ago"
|
||||
elif diff < 86400:
|
||||
hours = int(diff / 3600)
|
||||
last_heard_display = f"{hours}h ago"
|
||||
else:
|
||||
days = int(diff / 86400)
|
||||
last_heard_display = f"{days}d ago"
|
||||
|
||||
value = str(i["value"])
|
||||
|
||||
if i["latitude"] is not None and i["longitude"] is not None:
|
||||
lat = round(i["latitude"], 4)
|
||||
lon = round(i["longitude"], 4)
|
||||
location = f"{lat}, {lon}"
|
||||
else: location = "N/A"
|
||||
|
||||
print(f"{name:<25} {if_type:<12} {status_display:<12} {last_heard_display:<12} {value:<8} {location:<15}")
|
||||
|
||||
except Exception as e:
|
||||
pass
|
||||
|
||||
if must_exit: exit(0)
|
||||
else: return
|
||||
|
||||
if remote:
|
||||
try:
|
||||
if management_identity is None:
|
||||
@@ -190,25 +321,19 @@ def program_setup(configdir, dispall=False, verbosity=0, name_filter=None, json=
|
||||
stats, link_count = remote_status
|
||||
except Exception as e:
|
||||
raise e
|
||||
|
||||
|
||||
except Exception as e:
|
||||
print(str(e))
|
||||
if must_exit:
|
||||
exit(20)
|
||||
else:
|
||||
return
|
||||
if must_exit: exit(20)
|
||||
else: return
|
||||
|
||||
else:
|
||||
if lstats:
|
||||
try:
|
||||
link_count = reticulum.get_link_count()
|
||||
except Exception as e:
|
||||
pass
|
||||
try: link_count = reticulum.get_link_count()
|
||||
except Exception as e: pass
|
||||
|
||||
try:
|
||||
stats = reticulum.get_interface_stats()
|
||||
except Exception as e:
|
||||
pass
|
||||
try: stats = reticulum.get_interface_stats()
|
||||
except Exception as e: pass
|
||||
|
||||
if stats != None:
|
||||
if json:
|
||||
@@ -225,10 +350,8 @@ def program_setup(configdir, dispall=False, verbosity=0, name_filter=None, json=
|
||||
i[k] = RNS.hexrep(i[k], delimit=False)
|
||||
|
||||
print(json.dumps(stats))
|
||||
if must_exit:
|
||||
exit()
|
||||
else:
|
||||
return
|
||||
if must_exit: exit()
|
||||
else: return
|
||||
|
||||
interfaces = stats["interfaces"]
|
||||
if sorting != None and isinstance(sorting, str):
|
||||
@@ -254,7 +377,7 @@ def program_setup(configdir, dispall=False, verbosity=0, name_filter=None, json=
|
||||
if sorting == "held":
|
||||
interfaces.sort(key=lambda i: i["held_announces"], reverse=not sort_reverse)
|
||||
|
||||
|
||||
|
||||
for ifstat in interfaces:
|
||||
name = ifstat["name"]
|
||||
|
||||
@@ -312,6 +435,9 @@ def program_setup(configdir, dispall=False, verbosity=0, name_filter=None, json=
|
||||
|
||||
print(" {n}".format(n=ifstat["name"]))
|
||||
|
||||
if "autoconnect_source" in ifstat and ifstat["autoconnect_source"] != None:
|
||||
print(" Source : Auto-connect via <{ns}>".format(ns=ifstat["autoconnect_source"]))
|
||||
|
||||
if "ifac_netname" in ifstat and ifstat["ifac_netname"] != None:
|
||||
print(" Network : {nn}".format(nn=ifstat["ifac_netname"]))
|
||||
|
||||
@@ -327,10 +453,20 @@ def program_setup(configdir, dispall=False, verbosity=0, name_filter=None, json=
|
||||
print(" Rate : {ss}".format(ss=speed_str(ifstat["bitrate"])))
|
||||
|
||||
if "noise_floor" in ifstat:
|
||||
if ifstat["noise_floor"] != None:
|
||||
print(" Noise Fl. : {nfl} dBm".format(nfl=str(ifstat["noise_floor"])))
|
||||
if not "interference" in ifstat: nstr = ""
|
||||
else:
|
||||
print(" Noise Fl. : Unknown")
|
||||
nf = ifstat["interference"]
|
||||
lstr = ", no interference"
|
||||
if "interference_last_ts" in ifstat and "interference_last_dbm" in ifstat:
|
||||
lago = time.time()-ifstat["interference_last_ts"]
|
||||
ldbm = ifstat["interference_last_dbm"]
|
||||
lstr = f"\n Intrfrnc. : {ldbm} dBm {RNS.prettytime(lago, compact=True)} ago"
|
||||
|
||||
|
||||
nstr = f"\n Intrfrnc. : {nf} dBm" if nf else lstr
|
||||
|
||||
if ifstat["noise_floor"] != None: print(" Noise Fl. : {nfl} dBm{ntr}".format(nfl=str(ifstat["noise_floor"]), ntr=nstr))
|
||||
else: print(" Noise Fl. : Unknown")
|
||||
|
||||
if "cpu_load" in ifstat:
|
||||
if ifstat["cpu_load"] != None: print(" CPU load : {v} %".format(v=str(ifstat["cpu_load"])))
|
||||
@@ -354,7 +490,7 @@ def program_setup(configdir, dispall=False, verbosity=0, name_filter=None, json=
|
||||
|
||||
if "airtime_short" in ifstat and "airtime_long" in ifstat:
|
||||
print(" Airtime : {ats}% (15s), {atl}% (1h)".format(ats=str(ifstat["airtime_short"]),atl=str(ifstat["airtime_long"])))
|
||||
|
||||
|
||||
if "channel_load_short" in ifstat and "channel_load_long" in ifstat:
|
||||
print(" Ch. Load : {ats}% (15s), {atl}% (1h)".format(ats=str(ifstat["channel_load_short"]),atl=str(ifstat["channel_load_long"])))
|
||||
|
||||
@@ -379,7 +515,7 @@ def program_setup(configdir, dispall=False, verbosity=0, name_filter=None, json=
|
||||
if "ifac_signature" in ifstat and ifstat["ifac_signature"] != None:
|
||||
sigstr = "<…"+RNS.hexrep(ifstat["ifac_signature"][-5:], delimit=False)+">"
|
||||
print(" Access : {nb}-bit IFAC by {sig}".format(nb=ifstat["ifac_size"]*8, sig=sigstr))
|
||||
|
||||
|
||||
if "i2p_b32" in ifstat and ifstat["i2p_b32"] != None:
|
||||
print(" I2P B32 : {ep}".format(ep=str(ifstat["i2p_b32"])))
|
||||
|
||||
@@ -389,14 +525,14 @@ def program_setup(configdir, dispall=False, verbosity=0, name_filter=None, json=
|
||||
print(" Queued : {np} announce".format(np=aqn))
|
||||
else:
|
||||
print(" Queued : {np} announces".format(np=aqn))
|
||||
|
||||
|
||||
if astats and "held_announces" in ifstat and ifstat["held_announces"] != None and ifstat["held_announces"] > 0:
|
||||
aqn = ifstat["held_announces"]
|
||||
if aqn == 1:
|
||||
print(" Held : {np} announce".format(np=aqn))
|
||||
else:
|
||||
print(" Held : {np} announces".format(np=aqn))
|
||||
|
||||
|
||||
if astats and "incoming_announce_frequency" in ifstat and ifstat["incoming_announce_frequency"] != None:
|
||||
print(" Announces : {iaf}↑".format(iaf=RNS.prettyfrequency(ifstat["outgoing_announce_frequency"])))
|
||||
print(" {iaf}↓".format(iaf=RNS.prettyfrequency(ifstat["incoming_announce_frequency"])))
|
||||
@@ -414,7 +550,7 @@ def program_setup(configdir, dispall=False, verbosity=0, name_filter=None, json=
|
||||
if "rxs" in ifstat and "txs" in ifstat:
|
||||
rxstat += " "+RNS.prettyspeed(ifstat["rxs"])
|
||||
txstat += " "+RNS.prettyspeed(ifstat["txs"])
|
||||
|
||||
|
||||
print(f" Traffic : {txstat}\n {rxstat}")
|
||||
|
||||
lstr = ""
|
||||
@@ -440,6 +576,8 @@ def program_setup(configdir, dispall=False, verbosity=0, name_filter=None, json=
|
||||
|
||||
if "transport_id" in stats and stats["transport_id"] != None:
|
||||
print("\n Transport Instance "+RNS.prettyhexrep(stats["transport_id"])+" running")
|
||||
if "network_id" in stats and stats["network_id"] != None:
|
||||
print(" Network Identity "+RNS.prettyhexrep(stats["network_id"]))
|
||||
if "probe_responder" in stats and stats["probe_responder"] != None:
|
||||
print(" Probe responder at "+RNS.prettyhexrep(stats["probe_responder"])+ " active")
|
||||
if "transport_uptime" in stats and stats["transport_uptime"] != None:
|
||||
@@ -449,7 +587,7 @@ def program_setup(configdir, dispall=False, verbosity=0, name_filter=None, json=
|
||||
print(f"\n{lstr}")
|
||||
|
||||
print("")
|
||||
|
||||
|
||||
else:
|
||||
if not remote:
|
||||
print("Could not get RNS status")
|
||||
@@ -466,125 +604,67 @@ def main(must_exit=True, rns_instance=None):
|
||||
parser.add_argument("--config", action="store", default=None, help="path to alternative Reticulum config directory", type=str)
|
||||
parser.add_argument("--version", action="version", version="rnstatus {version}".format(version=__version__))
|
||||
|
||||
parser.add_argument(
|
||||
"-a",
|
||||
"--all",
|
||||
action="store_true",
|
||||
help="show all interfaces",
|
||||
default=False
|
||||
)
|
||||
|
||||
parser.add_argument(
|
||||
"-A",
|
||||
"--announce-stats",
|
||||
action="store_true",
|
||||
help="show announce stats",
|
||||
default=False
|
||||
)
|
||||
|
||||
parser.add_argument(
|
||||
"-l",
|
||||
"--link-stats",
|
||||
action="store_true",
|
||||
help="show link stats",
|
||||
default=False,
|
||||
)
|
||||
|
||||
parser.add_argument(
|
||||
"-t",
|
||||
"--totals",
|
||||
action="store_true",
|
||||
help="display traffic totals",
|
||||
default=False,
|
||||
)
|
||||
|
||||
parser.add_argument(
|
||||
"-s",
|
||||
"--sort",
|
||||
action="store",
|
||||
help="sort interfaces by [rate, traffic, rx, tx, rxs, txs, announces, arx, atx, held]",
|
||||
default=None,
|
||||
type=str
|
||||
)
|
||||
|
||||
parser.add_argument(
|
||||
"-r",
|
||||
"--reverse",
|
||||
action="store_true",
|
||||
help="reverse sorting",
|
||||
default=False,
|
||||
)
|
||||
|
||||
parser.add_argument(
|
||||
"-j",
|
||||
"--json",
|
||||
action="store_true",
|
||||
help="output in JSON format",
|
||||
default=False
|
||||
)
|
||||
|
||||
parser.add_argument(
|
||||
"-R",
|
||||
action="store",
|
||||
metavar="hash",
|
||||
help="transport identity hash of remote instance to get status from",
|
||||
default=None,
|
||||
type=str
|
||||
)
|
||||
|
||||
parser.add_argument(
|
||||
"-i",
|
||||
action="store",
|
||||
metavar="path",
|
||||
help="path to identity used for remote management",
|
||||
default=None,
|
||||
type=str
|
||||
)
|
||||
|
||||
parser.add_argument(
|
||||
"-w",
|
||||
action="store",
|
||||
metavar="seconds",
|
||||
type=float,
|
||||
help="timeout before giving up on remote queries",
|
||||
default=RNS.Transport.PATH_REQUEST_TIMEOUT
|
||||
)
|
||||
|
||||
parser.add_argument("-a", "--all", action="store_true", help="show all interfaces", default=False)
|
||||
parser.add_argument("-A", "--announce-stats", action="store_true", help="show announce stats", default=False)
|
||||
parser.add_argument("-l", "--link-stats", action="store_true", help="show link stats", default=False)
|
||||
parser.add_argument("-t", "--totals", action="store_true", help="display traffic totals", default=False)
|
||||
parser.add_argument("-s", "--sort", action="store", help="sort interfaces by [rate, traffic, rx, tx, rxs, txs, announces, arx, atx, held]", default=None, type=str)
|
||||
parser.add_argument("-r", "--reverse", action="store_true", help="reverse sorting", default=False)
|
||||
parser.add_argument("-j", "--json", action="store_true", help="output in JSON format", default=False)
|
||||
parser.add_argument("-R", action="store", metavar="hash", help="transport identity hash of remote instance to get status from", default=None, type=str)
|
||||
parser.add_argument("-i", action="store", metavar="path", help="path to identity used for remote management", default=None, type=str)
|
||||
parser.add_argument("-w", action="store", metavar="seconds", type=float, help="timeout before giving up on remote queries", default=RNS.Transport.PATH_REQUEST_TIMEOUT)
|
||||
parser.add_argument("-d", "--discovered", action="store_true", help="list discovered interfaces", default=False)
|
||||
parser.add_argument("-D", action="store_true", help="show details and config entries for discovered interfaces", default=False)
|
||||
parser.add_argument("-m", "--monitor", action="store_true", help="continuously monitor status", default=False)
|
||||
parser.add_argument("-I", "--monitor-interval", action="store", metavar="seconds", type=float, help="refresh interval for monitor mode (default: 1)", default=1.0)
|
||||
parser.add_argument('-v', '--verbose', action='count', default=0)
|
||||
|
||||
parser.add_argument("filter", nargs="?", default=None, help="only display interfaces with names including filter", type=str)
|
||||
|
||||
|
||||
args = parser.parse_args()
|
||||
|
||||
if args.config:
|
||||
configarg = args.config
|
||||
else:
|
||||
configarg = None
|
||||
if args.config: configarg = args.config
|
||||
else: configarg = None
|
||||
|
||||
program_setup(
|
||||
configdir = configarg,
|
||||
dispall = args.all,
|
||||
verbosity=args.verbose,
|
||||
name_filter=args.filter,
|
||||
json=args.json,
|
||||
astats=args.announce_stats,
|
||||
lstats=args.link_stats,
|
||||
sorting=args.sort,
|
||||
sort_reverse=args.reverse,
|
||||
remote=args.R,
|
||||
management_identity=args.i,
|
||||
remote_timeout=args.w,
|
||||
must_exit=must_exit,
|
||||
rns_instance=rns_instance,
|
||||
traffic_totals=args.totals,
|
||||
)
|
||||
if args.monitor:
|
||||
if args.R: require_shared = False
|
||||
else: require_shared = True
|
||||
|
||||
try: reticulum = RNS.Reticulum(configdir=configarg, loglevel=3+args.verbose, require_shared_instance=require_shared)
|
||||
except Exception as e:
|
||||
print("No shared RNS instance available to get status from")
|
||||
exit(1)
|
||||
|
||||
while True:
|
||||
buffer = io.StringIO()
|
||||
old_stdout = sys.stdout
|
||||
sys.stdout = buffer
|
||||
|
||||
try:
|
||||
program_setup(configdir = configarg, dispall = args.all, verbosity=args.verbose, name_filter=args.filter, json=args.json,
|
||||
astats=args.announce_stats, lstats=args.link_stats, sorting=args.sort, sort_reverse=args.reverse, remote=args.R,
|
||||
management_identity=args.i, remote_timeout=args.w, must_exit=False, rns_instance=reticulum, traffic_totals=args.totals,
|
||||
discovered_interfaces=args.discovered, config_entries=args.D)
|
||||
|
||||
finally:
|
||||
sys.stdout = old_stdout
|
||||
|
||||
output = buffer.getvalue()
|
||||
print("\033[H\033[2J", end="")
|
||||
print(output, end="", flush=True)
|
||||
|
||||
time.sleep(args.monitor_interval)
|
||||
|
||||
else:
|
||||
program_setup(configdir = configarg, dispall = args.all, verbosity=args.verbose, name_filter=args.filter, json=args.json,
|
||||
astats=args.announce_stats, lstats=args.link_stats, sorting=args.sort, sort_reverse=args.reverse, remote=args.R,
|
||||
management_identity=args.i, remote_timeout=args.w, must_exit=must_exit, rns_instance=rns_instance, traffic_totals=args.totals,
|
||||
discovered_interfaces=args.discovered, config_entries=args.D)
|
||||
|
||||
except KeyboardInterrupt:
|
||||
print("")
|
||||
if must_exit:
|
||||
exit()
|
||||
else:
|
||||
return
|
||||
if must_exit: exit()
|
||||
else: return
|
||||
|
||||
def speed_str(num, suffix='bps'):
|
||||
units = ['','k','M','G','T','P','E','Z']
|
||||
|
||||
@@ -44,6 +44,7 @@ from .Link import Link, RequestReceipt
|
||||
from .Channel import MessageBase
|
||||
from .Buffer import Buffer, RawChannelReader, RawChannelWriter
|
||||
from .Transport import Transport
|
||||
from .Discovery import InterfaceAnnouncer
|
||||
from .Destination import Destination
|
||||
from .Packet import Packet
|
||||
from .Packet import PacketReceipt
|
||||
@@ -142,7 +143,9 @@ def log(msg, level=3, _override_destination = False, pt=False):
|
||||
with logging_lock:
|
||||
if (logdest == LOG_STDOUT or _always_override_destination or _override_destination):
|
||||
if not threading.main_thread().is_alive(): return
|
||||
else: print(logstring)
|
||||
else:
|
||||
try: print(logstring)
|
||||
except: pass
|
||||
|
||||
elif (logdest == LOG_FILE and logfile != None):
|
||||
try:
|
||||
|
||||
@@ -1 +1 @@
|
||||
__version__ = "1.0.3"
|
||||
__version__ = "1.1.2"
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Sphinx build info version 1
|
||||
# This file records the configuration used when building these files. When it is not found, a full rebuild will be done.
|
||||
config: 42d644626d484631388dca045ac26048
|
||||
config: 15d60a54b9d9d7255478b81211ab235e
|
||||
tags: 645f666f9bcd5a90fca523b33c5a78b7
|
||||
|
||||
|
After Width: | Height: | Size: 24 KiB |
|
After Width: | Height: | Size: 47 KiB |
|
After Width: | Height: | Size: 37 KiB |
|
After Width: | Height: | Size: 121 KiB |
|
After Width: | Height: | Size: 46 KiB |
|
After Width: | Height: | Size: 81 KiB |
@@ -8,7 +8,7 @@ scenarios.
|
||||
|
||||
|
||||
Standalone Reticulum Installation
|
||||
=============================================
|
||||
=================================
|
||||
If you simply want to install Reticulum and related utilities on a system,
|
||||
the easiest way is via the ``pip`` package manager:
|
||||
|
||||
@@ -66,106 +66,10 @@ compiled packages available.
|
||||
Try Using a Reticulum-based Program
|
||||
=============================================
|
||||
|
||||
If you simply want to try using a program built with Reticulum, a few different
|
||||
programs exist that allow basic communication and a range of other useful functions,
|
||||
If you simply want to try using a program built with Reticulum, a :ref:`range of different
|
||||
programs <software-main>` exist that allow basic communication and a various other useful functions,
|
||||
even over extremely low-bandwidth Reticulum networks.
|
||||
|
||||
These programs will let you get a feel for how Reticulum works. They have been designed
|
||||
to run well over networks based on LoRa or packet radio, but can also be used over fast
|
||||
links, such as local WiFi, wired Ethernet, the Internet, or any combination.
|
||||
|
||||
As such, it is easy to get started experimenting, without having to set up any radio
|
||||
transceivers or infrastructure just to try it out. Launching the programs on separate
|
||||
devices connected to the same WiFi network is enough to get started, and physical
|
||||
radio interfaces can then be added later.
|
||||
|
||||
Remote Shell
|
||||
^^^^^^^^^^^^
|
||||
|
||||
The `rnsh <https://github.com/acehoss/rnsh>`_ program lets you establish fully interactive
|
||||
remote shell sessions over Reticulum. It also allows you to pipe any program to or from a
|
||||
remote system, and is similar to how ``ssh`` works. The ``rnsh`` is very efficient, and
|
||||
can facilitate fully interactive shell sessions, even over extremely low-bandwidth links,
|
||||
such as LoRa or packet radio.
|
||||
|
||||
Nomad Network
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
The terminal-based program `Nomad Network <https://github.com/markqvist/nomadnet>`_
|
||||
provides a complete encrypted communications suite built with Reticulum. It features
|
||||
encrypted messaging (both direct and delayed-delivery for offline users), file sharing,
|
||||
and has a built-in text-browser and page server with support for dynamically rendered pages,
|
||||
user authentication and more.
|
||||
|
||||
.. image:: screenshots/nomadnet_3.png
|
||||
:target: _images/nomadnet_3.png
|
||||
|
||||
`Nomad Network <https://github.com/markqvist/nomadnet>`_ is a user-facing client
|
||||
for the messaging and information-sharing protocol
|
||||
`LXMF <https://github.com/markqvist/lxmf>`_, another project built with Reticulum.
|
||||
|
||||
You can install Nomad Network via pip:
|
||||
|
||||
.. code::
|
||||
|
||||
# Install ...
|
||||
pip install nomadnet
|
||||
|
||||
# ... and run
|
||||
nomadnet
|
||||
|
||||
.. note::
|
||||
If this is the very first time you use ``pip`` to install a program
|
||||
on your system, you might need to reboot your system for your program to become
|
||||
available. If you get a "command not found" error or similar when running the
|
||||
program, reboot your system and try again. In some cases, you may even need to
|
||||
manually add the ``pip`` install path to your ``PATH`` environment variable.
|
||||
|
||||
Sideband
|
||||
^^^^^^^^
|
||||
|
||||
If you would rather use a program with a graphical user interface, you can take
|
||||
a look at `Sideband <https://unsigned.io/sideband>`_, which is available for Android,
|
||||
Linux, macOS and Windows.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. image:: screenshots/sideband_devices.webp
|
||||
:align: center
|
||||
:target: _images/sideband_devices.webp
|
||||
|
||||
.. only:: latex
|
||||
|
||||
.. image:: screenshots/sideband_devices.png
|
||||
:align: center
|
||||
:target: _images/sideband_devices.png
|
||||
|
||||
Sideband allows you to communicate with other people or LXMF-compatible
|
||||
systems over Reticulum networks using LoRa, Packet Radio, WiFi, I2P, Encrypted QR
|
||||
Paper Messages, or anything else Reticulum supports. It also interoperates with
|
||||
the Nomad Network program.
|
||||
|
||||
MeshChat
|
||||
^^^^^^^^
|
||||
|
||||
The `Reticulum MeshChat <https://github.com/liamcottle/reticulum-meshchat>`_ application
|
||||
is a user-friendly LXMF client for Linux, macOS and Windows, that also includes a Nomad Network
|
||||
page browser and other interesting functionality.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. image:: screenshots/meshchat_1.webp
|
||||
:align: center
|
||||
:target: _images/meshchat_1.webp
|
||||
|
||||
.. only:: latex
|
||||
|
||||
.. image:: screenshots/meshchat_1.png
|
||||
:align: center
|
||||
:target: _images/meshchat_1.png
|
||||
|
||||
Reticulum MeshChat is of course also compatible with Sideband and Nomad Network, or
|
||||
any other LXMF client.
|
||||
|
||||
Using the Included Utilities
|
||||
=============================================
|
||||
@@ -214,94 +118,108 @@ network just using the default (:ref:`AutoInterface<interfaces-auto>`) configura
|
||||
|
||||
Possibly, the examples in the config file are enough to get you started. If
|
||||
you want more information, you can read the :ref:`Building Networks<networks-main>`
|
||||
and :ref:`Interfaces<interfaces-main>` chapters of this manual.
|
||||
|
||||
Connecting Reticulum Instances Over the Internet
|
||||
================================================
|
||||
Reticulum currently offers three interfaces suitable for connecting instances over the Internet: :ref:`Backbone<interfaces-backbone>`, :ref:`TCP<interfaces-tcps>`
|
||||
and :ref:`I2P<interfaces-i2p>`. Each interface offers a different set of features, and Reticulum
|
||||
users should carefully choose the interface which best suites their needs.
|
||||
|
||||
The ``TCPServerInterface`` allows users to host an instance accessible over TCP/IP. This
|
||||
method is generally faster, lower latency, and more energy efficient than using ``I2PInterface``,
|
||||
however it also leaks more data about the server host.
|
||||
|
||||
The ``BackboneInterface`` is a very fast and efficient interface type available on POSIX operating
|
||||
systems, designed to handle many hundreds of connections simultaneously with low memory, processing
|
||||
and I/O overhead. It is fully compatible with the TCP-based interface types.
|
||||
|
||||
TCP connections reveal the IP address of both your instance and the server to anyone who can
|
||||
inspect the connection. Someone could use this information to determine your location or identity. Adversaries
|
||||
inspecting your packets may be able to record packet metadata like time of transmission and packet size.
|
||||
Even though Reticulum encrypts traffic, TCP does not, so an adversary may be able to use
|
||||
packet inspection to learn that a system is running Reticulum, and what other IP addresses connect to it.
|
||||
Hosting a publicly reachable instance over TCP also requires a publicly reachable IP address,
|
||||
which most Internet connections don't offer anymore.
|
||||
|
||||
The ``I2PInterface`` routes messages through the `Invisible Internet Protocol
|
||||
(I2P) <https://geti2p.net/en/>`_. To use this interface, users must also run an I2P daemon in
|
||||
parallel to ``rnsd``. For always-on I2P nodes it is recommended to use `i2pd <https://i2pd.website/>`_.
|
||||
|
||||
By default, I2P will encrypt and mix all traffic sent over the Internet, and
|
||||
hide both the sender and receiver Reticulum instance IP addresses. Running an I2P node
|
||||
will also relay other I2P user's encrypted packets, which will use extra
|
||||
bandwidth and compute power, but also makes timing attacks and other forms of
|
||||
deep-packet-inspection much more difficult.
|
||||
|
||||
I2P also allows users to host globally available Reticulum instances from non-public IP's and behind firewalls and NAT.
|
||||
|
||||
In general it is recommended to use an I2P node if you want to host a publicly accessible
|
||||
instance, while preserving anonymity. If you care more about performance, and a slightly
|
||||
easier setup, use TCP.
|
||||
and :ref:`Interfaces<interfaces-main>` chapters of this manual, but most importantly,
|
||||
start with reading the next section, :ref:`Bootstrapping Connectivity<bootstrapping-connectivity>`,
|
||||
as this provides the most essential understanding of how to ensure reliable
|
||||
connectivity with a minimum of maintenance.
|
||||
|
||||
|
||||
Connect to the Public Testnet
|
||||
===========================================
|
||||
.. _bootstrapping-connectivity:
|
||||
|
||||
An experimental public testnet has been made accessible by volunteers in the community. You
|
||||
can find interface definitions for adding to your ``.reticulum/config`` file on the
|
||||
`Reticulum Website <https://reticulum.network/connect.html>`_ or the
|
||||
`Community Wiki <https://github.com/markqvist/Reticulum/wiki/Community-Node-List>`_
|
||||
Bootstrapping Connectivity
|
||||
==========================
|
||||
|
||||
You can connect your devices or instances to one or more of these to gain access to any
|
||||
Reticulum networks they are physically connected to. Simply add one or more interface
|
||||
snippets to your config file in the ``[interface]`` section, like in the example below:
|
||||
Reticulum is not a service you subscribe to, nor is it a single global network you "join". It is a *networking stack*; a toolkit for building communications systems that align with your specific values, requirements, and operational environment. The way you choose to connect to other Reticulum peers is entirely your own choice.
|
||||
|
||||
.. code:: ini
|
||||
One of the most powerful aspects of Reticulum is that it provides a multitude of tools to establish, maintain, and optimize connectivity. You can use these tools in isolation or combine them in complex configurations to achieve a vast array of goals.
|
||||
|
||||
# TCP/IP interface to the BetweenTheBorders Hub (community-provided)
|
||||
[[RNS Testnet BetweenTheBorders]]
|
||||
type = TCPClientInterface
|
||||
enabled = yes
|
||||
target_host = reticulum.betweentheborders.com
|
||||
target_port = 4242
|
||||
Whether your aim is to create a completely private, air-gapped network for your family; to build a resilient community mesh that survives infrastructure collapse; to connect far and wide to as many nodes as possible; or simply to maintain a reliable, encrypted link to a specific organization you care about, Reticulum provides the mechanisms to make it happen.
|
||||
|
||||
There is no "right" or "wrong" way to build a Reticulum network, and you don't need to be a network engineer just to get started. If the information flows in the way you intend, and your privacy and security requirements are met, your configuration is a success. Reticulum is designed to make the most challenging and difficult scenarios attainable, even when other networking technologies fail.
|
||||
|
||||
|
||||
Finding Your Way
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
When you first start using Reticulum, you need a way to obtain connectivity with the peers you want to communicate with - the process of *bootstrapping connectivity*.
|
||||
|
||||
.. important::
|
||||
|
||||
A common mistake in modern networking is the reliance on a few centralized, hard-coded entrypoints. If every user simply connects to the same list of public IP addresses found on a website, the network becomes brittle, centralized, and ultimately fails to deliver on the promise of decentralization and resilience. You have a responsibility here.
|
||||
|
||||
Reticulum encourages the approach of *organic growth*. Instead of relying on permanent static connections to distant servers, you can use temporary bootstrap connections to continously *discover* more relevant or local infrastructure. Once discovered, your system can automatically form stronger, more direct links to these peers, and discard the temporary bootstrap links. This results in a web of connections that are geographically relevant, resilient and efficient.
|
||||
|
||||
It *is* possible to simply add a few public entrypoints to the ``[interfaces]`` section of your Reticulum configuration and be connected, but a better option is to enable :ref:`interface discovery<using-interface_discovery>` and either manually select relevant, local interfaces, or enable discovered interface auto-connection.
|
||||
|
||||
A relevant option in this context is the :ref:`bootstrap only<interfaces-options>` interface option. This is an automated tool for better distributing connectivity. By enabling interface discovery and auto-connection, and marking an interface as ``bootstrap_only``, you tell Reticulum to use that interface primarliy to find connectivity options, and then disconnect it once sufficient entrypoints have been discovered. This helps create a network topology that favors locality and resilience over the simple centralization caused by using only a few static entrypoints.
|
||||
|
||||
Good places to find interface definitions for bootstrapping connectivity are websites like
|
||||
`directory.rns.recipes <https://directory.rns.recipes/>`_ and `rmap.world <https://rmap.world/>`_.
|
||||
|
||||
|
||||
Build Personal Infrastructure
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
You do not need a datacenter to be a meaningful part of the Reticulum ecosystem. In fact, the most important nodes in the network are often the smallest ones.
|
||||
|
||||
We strongly encourage everyone, even home users, to think in terms of building **personal infrastructure**. Don't connect every phone, tablet, and computer in your house directly to a public internet gateway. Instead, repurpose an old computer, a Raspberry Pi, or a supported router to act as your own, personal **Transport Node**:
|
||||
|
||||
* Your local Transport Node sits in your home, connected to your WiFi and perhaps a radio interface (like an RNode).
|
||||
* You configure this node with a ``bootstrap_only`` interface (perhaps a TCP tunnel to a wider network) and enable interface discovery.
|
||||
* While you sleep, work, or cook, your node listens to the network. It discovers other local community members, validates their Network Identities, and automatically establishes direct links.
|
||||
* Your personal devices now connect to your *local* node, which is integrated into a living, breathing local mesh. Your traffic flows through local paths provided by other real people in the community rather than bouncing off a distant server.
|
||||
|
||||
**Don't wait for others to build the networks you want to see**. Every network is important, perhaps even most so those that support individual families and persons. Once enough of this personal, local infrastructure exist, connecting them directly to each other, without traversing the public Internet, becomes inevitable.
|
||||
|
||||
|
||||
Mixing Strategies
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
There is no requirement to commit to a single strategy. The most robust setups often mix static, dynamic, and discovered interfaces.
|
||||
|
||||
* **Static Interfaces:** You maintain a permanent interface to a trusted friend or organization using a static configuration.
|
||||
* **Bootstrap Links:** You connect a ``bootstrap_only`` interface to a public gateway on the Internet to scan for new connectable peers or to regain connectivity if your other interfaces fail.
|
||||
* **Local Wide-Area Connectivity:** You run a ``RNodeInterface`` on a shared frequency, giving you completely self-sovereign and private wide-area access to both your own network and other Reticulum peers globally, without any "service providers" being able to control or monitor how you interact with people.
|
||||
|
||||
By combining these methods, you create a system that is secure against single points of failure, adaptable to changing network conditions, and better integrated into your physical and social reality.
|
||||
|
||||
|
||||
Network Health & Responsibility
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
As you participate in the wider networks you discover and build, you will inevitably encounter peers that are misconfigured, malicious, or simply broken. To protect your resources and those of your local peers, you can utilize the :ref:`Blackhole Management<using-blackhole_management>` system.
|
||||
|
||||
Whether you manually block a spamming identity or subscribe to a blackhole list maintained by a trusted Network Identity, these tools help ensure that *your* transport capacity is used for what *you* consider legitimate communication. This keeps your local segment efficient and contributes to the health of the wider network.
|
||||
|
||||
|
||||
Contributing to the Global Ret
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you have the means to host a stable node with a public IP address, consider becoming a :ref:`Public Entrypoint<hosting-entrypoints>`. By :ref:`publishing your interface as discoverable<interfaces-discoverable>`, you provide a potential connection point for others, helping the network grow and reach new areas.
|
||||
|
||||
For guidelines on how to properly configure a public entrypoint, refer to the :ref:`Hosting Public Entrypoints<hosting-entrypoints>` section.
|
||||
|
||||
Connect to the Distributed Backbone
|
||||
===================================
|
||||
|
||||
A global, distributed backbone of Reticulum Transport Nodes is being run by volunteers from around the world. This network constitutes a heterogenous collection of both public and private nodes that form an uncoordinated, voluntary inter-networking backbone that currently provides global transport and internetworking capabilities for Reticulum.
|
||||
|
||||
As a good starting point, you can find interface definitions for connecting your own networks to this backbone on websites such as `directory.rns.recipes <https://directory.rns.recipes/>`_ and `rmap.world <https://rmap.world/>`_.
|
||||
|
||||
.. tip::
|
||||
Ideally, set up a Reticulum Transport Node that your own devices can reach locally, and then
|
||||
connect that transport node to a couple of public entrypoints. This will provide efficient
|
||||
connections and redundancy in case any of them go down.
|
||||
Don't rely on just a single connection to the distributed backbone for everyday use. It is much better to have several redundant connections configured, and enable the interface discovery options, so your nodes can continously discover peering opportunities as the network evolves. Refer to the :ref:`Bootstrapping Connectivity<bootstrapping-connectivity>` section to understand the options.
|
||||
|
||||
Many other Reticulum instances are connecting to this testnet, and you can also join it
|
||||
via other entry points if you know them. There is absolutely no control over the network
|
||||
topography, usage or what types of instances connect. It will also occasionally be used
|
||||
to test various failure scenarios, and there are no availability or service guarantees.
|
||||
Expect weird things to happen on this network, as people experiment and try out things.
|
||||
|
||||
.. warning::
|
||||
It probably goes without saying, but *don't use the testnet entry-points as
|
||||
hardcoded or default interfaces in any applications you ship to users*. When
|
||||
shipping applications, the best practice is to provide your own default
|
||||
connectivity solutions, if needed and applicable, or in most cases, simply
|
||||
leave it up to the user which networks to connect to, and how.
|
||||
|
||||
.. _hosting-entrypoints:
|
||||
|
||||
Hosting Public Entrypoints
|
||||
===========================================
|
||||
==========================
|
||||
|
||||
If you want to host a public (or private) entry-point to a Reticulum network over the
|
||||
Internet, this section offers some helpful pointers. You will need a machine, physical or
|
||||
virtual with a public IP address, that can be reached by other devices on the Internet.
|
||||
If you want to help build a strong global interconnection backbone, you can host a public (or private) entry-point to a Reticulum network over the
|
||||
Internet. This section offers some helpful pointers. Once you have set up your public entrypoint, it is a great idea to :ref:`make it discoverable over Reticulum<interfaces-discoverable>`.
|
||||
|
||||
You will need a machine, physical or virtual with a public IP address, that can be reached by other devices on the Internet.
|
||||
|
||||
The most efficient and performant way to host a connectable entry-point supporting many
|
||||
users is to use the ``BackboneInterface``. This interface type is fully compatible with
|
||||
@@ -347,8 +265,47 @@ If you are hosting an entry-point on an operating system that does not support
|
||||
``BackboneInterface``, you can use ``TCPServerInterface`` instead, although it will
|
||||
not be as performant.
|
||||
|
||||
|
||||
Connecting Reticulum Instances Over the Internet
|
||||
================================================
|
||||
Reticulum currently offers three interfaces suitable for connecting instances over the Internet: :ref:`Backbone<interfaces-backbone>`, :ref:`TCP<interfaces-tcps>`
|
||||
and :ref:`I2P<interfaces-i2p>`. Each interface offers a different set of features, and Reticulum
|
||||
users should carefully choose the interface which best suites their needs.
|
||||
|
||||
The ``TCPServerInterface`` allows users to host an instance accessible over TCP/IP. This
|
||||
method is generally faster, lower latency, and more energy efficient than using ``I2PInterface``,
|
||||
however it also leaks more data about the server host.
|
||||
|
||||
The ``BackboneInterface`` is a very fast and efficient interface type available on POSIX operating
|
||||
systems, designed to handle thousands of connections simultaneously with low memory, processing
|
||||
and I/O overhead. It is fully compatible with the TCP-based interface types.
|
||||
|
||||
TCP connections reveal the IP address of both your instance and the server to anyone who can
|
||||
inspect the connection. Someone could use this information to determine your location or identity. Adversaries
|
||||
inspecting your packets may be able to record packet metadata like time of transmission and packet size.
|
||||
Even though Reticulum encrypts traffic, TCP does not, so an adversary may be able to use
|
||||
packet inspection to learn that a system is running Reticulum, and what other IP addresses connect to it.
|
||||
Hosting a publicly reachable instance over TCP also requires a publicly reachable IP address,
|
||||
which most Internet connections don't offer anymore.
|
||||
|
||||
The ``I2PInterface`` routes messages through the `Invisible Internet Protocol
|
||||
(I2P) <https://geti2p.net/en/>`_. To use this interface, users must also run an I2P daemon in
|
||||
parallel to ``rnsd``. For always-on I2P nodes it is recommended to use `i2pd <https://i2pd.website/>`_.
|
||||
|
||||
By default, I2P will encrypt and mix all traffic sent over the Internet, and
|
||||
hide both the sender and receiver Reticulum instance IP addresses. Running an I2P node
|
||||
will also relay other I2P user's encrypted packets, which will use extra
|
||||
bandwidth and compute power, but also makes timing attacks and other forms of
|
||||
deep-packet-inspection much more difficult.
|
||||
|
||||
I2P also allows users to host globally available Reticulum instances from non-public IP's and behind firewalls and NAT.
|
||||
|
||||
In general it is recommended to use an I2P node if you want to host a publicly accessible
|
||||
instance, while preserving anonymity. If you care more about performance, and a slightly
|
||||
easier setup, use TCP.
|
||||
|
||||
Adding Radio Interfaces
|
||||
==============================================
|
||||
=======================
|
||||
Once you have Reticulum installed and working, you can add radio interfaces with
|
||||
any compatible hardware you have available. Reticulum supports a wide range of radio
|
||||
hardware, and if you already have any available, it is very likely that it will
|
||||
@@ -360,24 +317,22 @@ cheaply build an :ref:`RNode<rnode-main>`, which is a general-purpose long-range
|
||||
digital radio transceiver, that integrates easily with Reticulum.
|
||||
|
||||
To build one yourself requires installing a custom firmware on a supported LoRa
|
||||
development board with an auto-install script. Please see the :ref:`Communications Hardware<hardware-main>`
|
||||
chapter for a guide. If you prefer purchasing a ready-made unit, you can refer to the
|
||||
:ref:`list of suppliers<rnode-suppliers>`. For more information on RNode, you can also
|
||||
refer to these additional external resources:
|
||||
development board with an auto-install script or web-based flasher.
|
||||
Please see the :ref:`Communications Hardware<hardware-main>` chapter for a guide.
|
||||
If you prefer purchasing a ready-made unit, you can refer to the
|
||||
:ref:`list of suppliers<rnode-suppliers>`.
|
||||
|
||||
* `How To Make Your Own RNodes <https://unsigned.io/how-to-make-your-own-rnodes/>`_
|
||||
* `Installing RNode Firmware on Compatible LoRa Devices <https://unsigned.io/installing-rnode-firmware-on-supported-devices/>`_
|
||||
* `Private, Secure and Uncensorable Messaging Over a LoRa Mesh <https://unsigned.io/private-messaging-over-lora/>`_
|
||||
* `RNode Firmware <https://github.com/markqvist/RNode_Firmware/>`_
|
||||
Other radio-based hardware interfaces are being developed and made available by
|
||||
the broader Reticulum community. You can find more information on such topics
|
||||
over Reticulum-based information sharing systems.
|
||||
|
||||
If you have communications hardware that is not already supported by any of the
|
||||
:ref:`existing interface types<interfaces-main>`, but you think would be suitable for use with Reticulum,
|
||||
you are welcome to head over to the `GitHub discussion pages <https://github.com/markqvist/Reticulum/discussions>`_
|
||||
and propose adding an interface for the hardware.
|
||||
:ref:`existing interface types<interfaces-main>`, it is easy to write (and potentially
|
||||
publish) a :ref:`custom interface module<interfaces-custom>` that makes it compatible with Reticulum.
|
||||
|
||||
|
||||
Creating and Using Custom Interfaces
|
||||
===========================================
|
||||
====================================
|
||||
|
||||
While Reticulum includes a flexible and broad range of built-in interfaces, these
|
||||
will not cover every conceivable type of communications hardware that Reticulum
|
||||
@@ -404,54 +359,10 @@ ready to import and use RNS in your own programs. The next step will most
|
||||
likely be to look at some :ref:`Example Programs<examples-main>`.
|
||||
|
||||
The entire Reticulum API is documented in the :ref:`API Reference<api-main>`
|
||||
chapter of this manual.
|
||||
chapter of this manual. Before diving in, it's probably a good idea to read
|
||||
this manual in full, but at least start with the :ref:`Understanding Reticulum<understanding-main>` chapter.
|
||||
|
||||
|
||||
Participate in Reticulum Development
|
||||
==============================================
|
||||
If you want to participate in the development of Reticulum and associated
|
||||
utilities, you'll want to get the latest source from GitHub. In that case,
|
||||
don't use pip, but try this recipe:
|
||||
|
||||
.. code:: shell
|
||||
|
||||
# Install dependencies
|
||||
pip install cryptography pyserial
|
||||
|
||||
# Clone repository
|
||||
git clone https://github.com/markqvist/Reticulum.git
|
||||
|
||||
# Move into Reticulum folder and symlink library to examples folder
|
||||
cd Reticulum
|
||||
ln -s ../RNS ./Examples/
|
||||
|
||||
# Run an example
|
||||
python Examples/Echo.py -s
|
||||
|
||||
# Unless you've manually created a config file, Reticulum will do so now,
|
||||
# and immediately exit. Make any necessary changes to the file:
|
||||
nano ~/.reticulum/config
|
||||
|
||||
# ... and launch the example again.
|
||||
python Examples/Echo.py -s
|
||||
|
||||
# You can now repeat the process on another computer,
|
||||
# and run the same example with -h to get command line options.
|
||||
python Examples/Echo.py -h
|
||||
|
||||
# Run the example in client mode to "ping" the server.
|
||||
# Replace the hash below with the actual destination hash of your server.
|
||||
python Examples/Echo.py 174a64852a75682259ad8b921b8bf416
|
||||
|
||||
# Have a look at another example
|
||||
python Examples/Filetransfer.py -h
|
||||
|
||||
When you have experimented with the basic examples, it's time to go read the
|
||||
:ref:`Understanding Reticulum<understanding-main>` chapter. Before submitting
|
||||
your first pull request, it is probably a good idea to introduce yourself on
|
||||
the `disucssion forum on GitHub <https://github.com/markqvist/Reticulum/discussions>`_,
|
||||
or ask one of the developers or maintainers for a good place to start.
|
||||
|
||||
.. _install-guides:
|
||||
|
||||
Platform-Specific Install Notes
|
||||
|
||||
@@ -20,6 +20,7 @@ to participate in the development of Reticulum itself.
|
||||
|
||||
whatis
|
||||
gettingstartedfast
|
||||
software
|
||||
using
|
||||
understanding
|
||||
hardware
|
||||
|
||||
@@ -356,6 +356,7 @@ software-based soundmodems. To do this, use the ``kiss_framing`` option:
|
||||
kiss_framing = True
|
||||
target_host = 127.0.0.1
|
||||
target_port = 8001
|
||||
fixed_mtu = 500
|
||||
|
||||
**Caution!** Only use the KISS framing option when connecting to external devices
|
||||
and programs like soundmodems and similar over TCP. When using the
|
||||
@@ -364,6 +365,9 @@ never enable ``kiss_framing``, since this will disable internal reliability and
|
||||
recovery mechanisms that greatly improves performance over unreliable and
|
||||
intermittent TCP links.
|
||||
|
||||
For KISS devices that need only supports a particular MTU, you can use the
|
||||
``fixed_mtu`` option.
|
||||
|
||||
.. note::
|
||||
The TCP interfaces support tunneling over I2P, but to do so reliably,
|
||||
you must use the i2p_tunneled option:
|
||||
@@ -907,6 +911,213 @@ beaconing functionality described above.
|
||||
# small internal packet buffer.
|
||||
flow_control = false
|
||||
|
||||
.. _interfaces-discoverable:
|
||||
|
||||
Discoverable Interfaces
|
||||
=======================
|
||||
|
||||
Reticulum includes a powerful system for publishing your local interfaces to the wider network, allowing other peers to :ref:`discover, validate, and automatically connect to them<using-interface_discovery>`. This feature is particularly useful for creating decentralized networks where peers can dynamically find entrypoints, such as public Internet gateways or local radio access points, without relying on static configuration files or centralized directories.
|
||||
|
||||
When an interface is made **discoverable**, your Reticulum instance will periodically broadcast an announce packet containing the connection details and parameters required for other peers to establish a connection. These announces are propagated over the network using the standard Reticulum announce mechanism using the ``rnstransport.discovery.interface`` destination type.
|
||||
|
||||
.. note::
|
||||
To use the interface discovery functionality, the ``LXMF`` module must be installed in your Python environment. You can install it using pip:
|
||||
|
||||
.. code:: sh
|
||||
|
||||
pip install lxmf
|
||||
|
||||
|
||||
Enabling Discovery
|
||||
------------------
|
||||
|
||||
Interface discovery is enabled on a per-interface basis. To make a specific interface discoverable, you must add the ``discoverable`` option to that interface's configuration block and set it to ``yes``.
|
||||
|
||||
.. code:: ini
|
||||
|
||||
[[My Public Gateway]]
|
||||
type = BackboneInterface
|
||||
...
|
||||
discoverable = yes
|
||||
|
||||
Once enabled, Reticulum will automatically handle the generation, signing, stamping, and broadcasting of the discovery announces. It is not *required* to enable Transport to publish interface discovery information, but for most use cases where you want others to connect to you, you will likely want ``enable_transport`` set to ``yes`` in the ``[reticulum]`` section of your configuration.
|
||||
|
||||
|
||||
Discovery Parameters
|
||||
--------------------
|
||||
|
||||
When ``discoverable`` is enabled, a variety of additional options become available to control how the interface is presented to the network. These parameters allow you to fine-tune the metadata, security requirements, and visibility of your interface.
|
||||
|
||||
**Basic Metadata**
|
||||
|
||||
``discovery_name``
|
||||
A human-readable name for the interface. This name will be displayed to users on remote systems when they list discovered interfaces. If not specified, the interface name (the section header) will be used.
|
||||
|
||||
``announce_interval``
|
||||
The interval in minutes between successive discovery announces for this interface. Default is 360 minutes (6 hours). For stable, long-running infrastructure, higher intervals (12 to 22 hours) are usually sufficient and reduce network load. Minimum allowed value is 5 minutes (but expect to have your announces throttled if using intervals below one hour).
|
||||
|
||||
**Connectivity Specification**
|
||||
|
||||
``reachable_on``
|
||||
Specifies the address that remote peers should use to connect to this interface.
|
||||
|
||||
* For TCP and Backbone interfaces, this is typically the public IP address or hostname. Do not include the port, this is fetched automatically from the interface.
|
||||
* For I2P interfaces, this is usually the I2P ``b32`` address. This value is fetched automatically from the ``I2PInterface`` once it is up and connected to the I2P network, so you should not set this manually, unless you absolutely know what you're doing.
|
||||
|
||||
**Dynamic Resolution:** This option also accepts a path to an external executable script or binary. If a path is provided, Reticulum will execute the script and use its ``stdout`` as the reachability address. This is useful for devices behind dynamic DNS, NATs, or complex cloud environments where the external IP is not known locally. The script must simply print the address to stdout and exit.
|
||||
|
||||
.. note::
|
||||
When using an executable script for ``reachable_on``, Reticulum expects the script to output only the IP address or hostname to ``stdout``, followed by a newline character. Any additional output or errors may cause the resolution to fail. Ensure the script has executable permissions and is robust against temporary network failures.
|
||||
|
||||
A minimal example of a script that resolves the externally available, public IP of an internet-connected system could look like this:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
#!/bin/bash
|
||||
curl -s ip.me
|
||||
exit $?
|
||||
|
||||
On a real system, you should make the script robust enough to deal with intermittent Internet or service failures, such that the script *always* returns a sensible value, or if not possible at least exits with a non-zero exit return code, so Reticulum knows the output is invalid.
|
||||
|
||||
**Security & Cost**
|
||||
|
||||
``discovery_stamp_value``
|
||||
Defines the proof-of-work difficulty for the cryptographic stamp included in the announce. This value acts as a cost barrier to prevent network flooding. The default value is ``14``. Increasing this value makes it computationally more expensive to generate an announce, which can be useful to prevent spam on very large networks, but it also increases CPU load on your system when generating announces. Stamps are cached, and only generated if interface information changes, or at instance restart. If you have the computational resources, it is generally advisable to use as high a stamp value as possible.
|
||||
|
||||
**Privacy & Encryption**
|
||||
|
||||
``discovery_encrypt``
|
||||
If set to ``yes``, the discovery announce payload will be encrypted. To decrypt the announce, remote peers must possess the *network identity* configured for your instance (see ``network_identity`` in the ``[reticulum]`` section). This allows you to publish private interfaces that are only discoverable to specific trusted networks.
|
||||
|
||||
.. important::
|
||||
If you enable ``discovery_encrypt`` but do not configure a valid ``network_identity`` in the ``[reticulum]`` section of your configuration, Reticulum will abort the interface discovery announce. Encryption requires a valid network identity key to function.
|
||||
|
||||
``publish_ifac``
|
||||
If set to ``yes``, the Interface Access Code (IFAC) name and passphrase for this interface will be included in the discovery announce. This allows peers to automatically configure the correct authentication parameters when connecting to the interface.
|
||||
|
||||
**Physical Location**
|
||||
|
||||
``latitude``, ``longitude``, ``height``
|
||||
Optional physical coordinates for the interface. These are useful for mapping discovered interfaces geographically or for clients to automatically select the nearest access point. Coordinates should be in decimal degrees, height in meters.
|
||||
|
||||
**Radio Parameters**
|
||||
|
||||
For physical radio interfaces like ``RNodeInterface`` or ``KISSInterface``, the following optional parameters allow you to broadcast the operating frequency and characteristics, allowing clients to verify compatibility before connecting:
|
||||
|
||||
``discovery_frequency``
|
||||
The operating frequency in Hz. Auto-configured on RNode interfaces. Necessary on KISS-based radio interfaces and ``TCPClientInterfaces`` connecting to radio modems.
|
||||
|
||||
``discovery_bandwidth``
|
||||
The signal bandwidth in Hz. Auto-configured on RNode interfaces. Useful on KISS-based radio interfaces and ``TCPClientInterfaces`` connecting to radio modems.
|
||||
|
||||
``discovery_modulation``
|
||||
The modulation type or scheme. Auto-configured on RNode interfaces, but highly advisable to include on other radio-based interfaces.
|
||||
|
||||
|
||||
Interface Modes
|
||||
---------------
|
||||
|
||||
When you enable discovery on an interface, Reticulum enforces certain interface modes to ensure the interface is actually useful for remote peers.
|
||||
|
||||
If an interface is configured as ``discoverable``, but its mode is not explicitly set to ``gateway`` (for server-style interfaces like ``BackboneInterface`` or ``TCPServerInterface``) or ``access_point`` (for radio interfaces like ``RNodeInterface``), Reticulum will automatically configure the appropriate mode and log a notice.
|
||||
|
||||
For example, if you enable discovery on a ``RNodeInterface`` without specifying the mode, Reticulum will automatically set it to ``access_point`` mode.
|
||||
|
||||
Security Considerations
|
||||
-----------------------
|
||||
|
||||
When making interfaces discoverable, you are effectively broadcasting an invitation to connect to your system. It is important to understand the security implications of the configuration options you choose.
|
||||
|
||||
**Publishing Credentials**
|
||||
|
||||
If you enable ``publish_ifac = yes``, your interface's authentication passphrase will be included in the announce. If you are operating a public network and want anyone to connect, this is acceptable. However, if you wish to restrict access to a specific group of users, you **must** enable ``discovery_encrypt = yes``. This ensures that only peers possessing the correct ``network_identity`` can decode the passphrase.
|
||||
|
||||
**Topology Exposure**
|
||||
|
||||
A discoverable interface announces its presence, location (if configured), and capabilities to the network. Even if the connection details are encrypted, the *fact* that a connectable node exists within a certain network becomes public information. In high-security or scenarios requiring operational secrecy, consider the implications of advertising your infrastructure's existence.
|
||||
|
||||
Example Configuration
|
||||
---------------------
|
||||
|
||||
Below is an example configuration for a public backbone gateway. This configuration publishes a high-value, publicly discoverable interface, that anyone can connect to.
|
||||
|
||||
.. code:: ini
|
||||
|
||||
[[My Public Gateway]]
|
||||
type = BackboneInterface
|
||||
mode = gateway
|
||||
listen_on = 0.0.0.0
|
||||
port = 4242
|
||||
|
||||
# Enable Discovery
|
||||
discoverable = yes
|
||||
|
||||
# Interface Details
|
||||
discovery_name = Region A Public Entrypoint
|
||||
announce_interval = 720
|
||||
|
||||
# Use external script to resolve dynamic IP
|
||||
reachable_on = /usr/local/bin/get_external_ip.sh
|
||||
|
||||
# Generate high stamp value
|
||||
discovery_stamp_value = 24
|
||||
|
||||
# Optional location data
|
||||
latitude = 51.99714
|
||||
longitude = -0.74195
|
||||
height = 15
|
||||
|
||||
The next example create an encrypted discovery-enabled interface, requiring a specific network identity to decode, and includes IFAC credentials for seamless authentication.
|
||||
|
||||
.. code:: ini
|
||||
|
||||
[[My Private Gateway]]
|
||||
type = BackboneInterface
|
||||
mode = gateway
|
||||
listen_on = 0.0.0.0
|
||||
port = 5858
|
||||
network_name = internal_1
|
||||
passphrase = Mevpekyafshak5Wr
|
||||
|
||||
# Enable Discovery
|
||||
discoverable = yes
|
||||
|
||||
# Interface Details
|
||||
discovery_name = Region A Private Backbone
|
||||
announce_interval = 720
|
||||
|
||||
# Use external script to resolve dynamic IP
|
||||
reachable_on = /usr/local/bin/get_external_ip.sh
|
||||
|
||||
# Target stamp value
|
||||
discovery_stamp_value = 22
|
||||
|
||||
# Encrypt announces for our network only
|
||||
discovery_encrypt = yes
|
||||
|
||||
# Include credentials so trusted
|
||||
# peers can connect automatically
|
||||
publish_ifac = yes
|
||||
|
||||
# Optional location data
|
||||
latitude = 34.06915
|
||||
longitude = -118.44318
|
||||
height = 15
|
||||
|
||||
In the ``[reticulum]`` section of your configuration, you would define the network identity used for encryption as follows:
|
||||
|
||||
.. code:: ini
|
||||
|
||||
[reticulum]
|
||||
...
|
||||
# The identity used to sign/encrypt discovery announces
|
||||
network_identity = ~/.reticulum/storage/identities/my_network_identity
|
||||
...
|
||||
|
||||
With these configuration options applied, your Reticulum instance will actively participate in the network's discovery ecosystem. Other peers running Reticulum with discovery enabled will be able to see your interface, validate its cryptographic stamp, and (depending on their configuration) automatically connect to it.
|
||||
|
||||
For information on how to use these discovered interfaces and configure your system to auto-connect to them, refer to the :ref:`Discovering Interfaces<using-interface_discovery>` chapter.
|
||||
|
||||
.. _interfaces-options:
|
||||
|
||||
Common Interface Options
|
||||
@@ -987,6 +1198,15 @@ These can be used to control various aspects of interface behaviour.
|
||||
option, to set the interface speed in *bits per second*.
|
||||
|
||||
|
||||
* | The ``bootstrap_only`` option designates an interface as a temporary
|
||||
bridge for initial connectivity. If this option is enabled, the
|
||||
interface will be monitored and automatically detached once the
|
||||
number of auto-connected interfaces reaches the limit configured by
|
||||
``autoconnect_discovered_interfaces``. This is particularly useful
|
||||
for using a slow or expensive connection (such as a single LoRa
|
||||
link or a remote TCP tunnel) solely to discover better local
|
||||
infrastructure, which then supersedes the bootstrap interface.
|
||||
|
||||
.. _interfaces-modes:
|
||||
|
||||
Interface Modes
|
||||
|
||||
@@ -4,17 +4,47 @@
|
||||
Building Networks
|
||||
*****************
|
||||
|
||||
This chapter will provide you with the knowledge needed to build networks with
|
||||
Reticulum, which can often be easier than using traditional stacks, since you
|
||||
don't have to worry about coordinating addresses, subnets and routing for an
|
||||
This chapter will provide you with the high-level knowledge needed to build networks with
|
||||
Reticulum. It will not, however tell you all you need to know to succesfully
|
||||
design and configure every kind of network you can imagine. For this, you will
|
||||
most likely need to read this manual in its entirity, invest significant time
|
||||
into experimenting with the stack, and learning functionality intuitively.
|
||||
|
||||
Still, after reading this chapter, you should be well equipped to *start* that
|
||||
journey. While Reticulum is **fundamentally different** compared to other
|
||||
networking technologies, it can often be easier than using traditional stacks.
|
||||
If you've built networks before, you will probably have to forget, or at least
|
||||
temporarily ignore, a lot of things at this point. It will all makes sense in
|
||||
the end though. Hopefully.
|
||||
|
||||
If you're used to protocols like IP, let's at least start with some relief:
|
||||
You don't have to worry about coordinating addresses, subnets and routing for an
|
||||
entire network that you might not know how will evolve in the future. With
|
||||
Reticulum, you can simply add more segments to your network when it becomes
|
||||
necessary, and Reticulum will handle the convergence of the entire network
|
||||
automatically.
|
||||
automatically. There's plenty more neat aspects like that to Reticulum, but
|
||||
we're getting ahead of ourselves. Let's cover the basics first.
|
||||
|
||||
Concepts & Overview
|
||||
--------------------
|
||||
|
||||
Before you start building your own networks, it's important to understand the
|
||||
fundamental principles that distinguish Reticulum networks from traditional
|
||||
networking approaches. These principles shape how you design your network,
|
||||
what trade-offs you encounter, and what capabilities you can rely on.
|
||||
|
||||
Reticulum is not a single network you "join", it is a toolkit for *creating* networks.
|
||||
You decide what mediums to use, how nodes connect, what trust boundaries exist,
|
||||
and what the network's purpose is. Reticulum provides the cryptographic foundation,
|
||||
the transport mechanisms, and the convergence algorithms that make your design
|
||||
workable. You provide the intent and the structure.
|
||||
|
||||
This approach offers tremendous flexibility, but it requires thinking in terms of
|
||||
different abstractions than those used in conventional networking.
|
||||
|
||||
Introductory Considerations
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
There are important points that need to be kept in mind when building networks
|
||||
with Reticulum:
|
||||
|
||||
@@ -31,6 +61,11 @@ with Reticulum:
|
||||
interconnect with much larger and higher bandwidth networks without issue.
|
||||
Reticulum automatically manages the flow of information to and from various
|
||||
network segments, and when bandwidth is limited, local traffic is prioritised.
|
||||
You will, however, need to configure your interfaces correctly. If you tell
|
||||
Reticulum to pass all announce traffic from a gigabit link to a LoRa interfaces,
|
||||
it will try as best as possible to comply with this, while still respecting
|
||||
bandwidth limits, but you *will* waste a lot of precious bandwidth and airtime,
|
||||
and your LoRa network will not work very well.
|
||||
|
||||
* | Reticulum provides sender/initiator anonymity by default. There is no way
|
||||
to filter traffic or discriminate it based on the source of the traffic.
|
||||
@@ -89,81 +124,227 @@ Any number of interfaces can be configured, and Reticulum will automatically
|
||||
decide which are suitable to use in any given situation, depending on where
|
||||
traffic needs to flow.
|
||||
|
||||
Example Scenarios
|
||||
-----------------
|
||||
Destinations, Not Addresses
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This section illustrates a few example scenarios, and how they would, in general
|
||||
terms, be planned, implemented and configured.
|
||||
In traditional networking, addresses are allocated from a managed space. If you want to
|
||||
communicate with another node, you need to know its address, and that address
|
||||
must be unique within the network segment. This requires coordination, either
|
||||
through manual assignment, DHCP servers, or other allocation mechanisms.
|
||||
|
||||
Interconnected LoRa Sites
|
||||
=========================
|
||||
Reticulum replaces addresses with **destinations**. A destination is identified by a 16-byte
|
||||
hash (128 bits) derived from a SHA-256 hash of the destination's identifying
|
||||
characteristics. This hash serves as the address on the network. On the network, it
|
||||
is represented in binary, but when displayed to human users, it will usually look something like
|
||||
this ``<13425ec15b621c1d928589718000d814>``.
|
||||
|
||||
An organisation wants to provide communication and information services to it's
|
||||
members, which are located mainly in three separate areas. Three suitable hill-top
|
||||
locations are found, where the organisation can install equipment: Site A, B and C.
|
||||
The critical difference is that *any node can generate as many destinations as it
|
||||
needs, without coordination*. A destination's uniqueness is guaranteed by the
|
||||
collision resistance of SHA-256 and the inclusion of the node's public key in the
|
||||
hash calculation. Two nodes can both use the destination name
|
||||
``messenger.user.inbox``, but they will have different destination hashes because
|
||||
their public keys differ. Both can coexist on the same network without conflict.
|
||||
|
||||
Since the amount of data that needs to be exchanged between users is mainly text-
|
||||
based, the bandwidth requirements are low, and LoRa radios are chosen to connect
|
||||
users to the network.
|
||||
This has profound implications for network design:
|
||||
|
||||
Due to the hill-top locations found, there is radio line-of-sight between site A
|
||||
and B, and also between site B and C. Because of this, the organisation does not
|
||||
need to use the Internet to interconnect the sites, but purchases four Point-to-Point
|
||||
WiFi based radios for interconnecting the sites.
|
||||
* **No address allocation planning:** You never need to reserve address ranges,
|
||||
plan subnets, or coordinate with other network operators. Nodes simply generate
|
||||
destinations and announce them.
|
||||
|
||||
At each site, a Raspberry Pi is installed to function as a gateway. A LoRa radio
|
||||
is connected to the Pi with a USB cable, and the WiFi radio is connected to the
|
||||
Ethernet port of the Pi. At site B, two WiFi radios are needed to be able to reach
|
||||
both site A and site C, so an extra Ethernet adapter is connected to the Pi in
|
||||
this location.
|
||||
* **Global portability:** A destination is not tied to a physical location or
|
||||
network segment. A node can move its destinations across interfaces, mediums,
|
||||
or even between entirely separate Reticulum networks simply by sending an
|
||||
announce on the new medium.
|
||||
|
||||
Once the hardware has been installed, Reticulum is installed on all the Pis, and at
|
||||
site A and C, one interface is added for the LoRa radio, as well as one for the WiFi
|
||||
radio. At site B, an interface for the LoRa radio, and one interface for each WiFi
|
||||
radio is added to the Reticulum configuration file. The transport node option is
|
||||
enabled in the configuration of all three gateways.
|
||||
* **Implicit authentication:** Because destinations are bound to public keys,
|
||||
communication to a destination is inherently cryptographically authenticated.
|
||||
Only the holder of the corresponding private key can decrypt and respond to
|
||||
traffic addressed to that destination. This also makes application-level
|
||||
authentication *much* simpler, since it can directly use the foundational
|
||||
identity verification built into the core networking layer.
|
||||
|
||||
The network is now operational, and ready to serve users across all three areas.
|
||||
The organisation prepares a LoRa radio that is supplied to the end users, along
|
||||
with a Reticulum configuration file, that contains the right parameters for
|
||||
communicating with the LoRa radios installed at the gateway sites.
|
||||
* **Identity abstraction:** A single Reticulum Identity can create multiple
|
||||
destinations. This allows a single entity (a person, a device, a service) to
|
||||
present multiple endpoints without needing multiple cryptographic keypairs.
|
||||
|
||||
Once users connect to the network, anyone will be able to communicate with anyone
|
||||
else across all three sites.
|
||||
|
||||
Bridging Over the Internet
|
||||
==========================
|
||||
Transport Nodes and Instances
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
As the organisation grows, several new communities form in places too far away
|
||||
from the core network to be reachable over WiFi links. New gateways similar to those
|
||||
previously installed are set up for the new communities at the new sites D and E, but
|
||||
they are islanded from the core network, and only serve the local users.
|
||||
Reticulum distinguishes between two types of nodes: **Instances**
|
||||
and **Transport Nodes**. Every node running Reticulum is an Instance, but not
|
||||
every Instance is a Transport Node.
|
||||
|
||||
After investigating the options, it is found that it is possible to install an
|
||||
Internet connection at site A, and an interface on the Internet connection is
|
||||
configured for Reticulum on the Raspberry Pi at site A.
|
||||
A **Reticulum Instance** is any system running the Reticulum stack. It can create
|
||||
destinations, send and receive packets, establish links, and communicate with
|
||||
other nodes. It can also host destinations that are connectable for *anyone* else
|
||||
in the network. This means you can easily host globally available services from
|
||||
any location, including your home or office. Network-wide, global connectivity
|
||||
for all destinations is guaranteed, as long as there is *some* physical way to
|
||||
actually transport the packets. Instances are the default state and are appropriate for most end-user devices,
|
||||
such as phones, laptops, sensors, or any device that primarily consumes network services.
|
||||
|
||||
A member of the organisation at site D, named Dori, is willing to help by sharing
|
||||
the Internet connection she already has in her home, and is able to leave a Raspberry
|
||||
Pi running. A new Reticulum interface is configured on her Pi, connecting to the newly
|
||||
enabled Internet interface on the gateway at site A. Dori is now connected to both
|
||||
the nodes at her own local site (through the hill-top LoRa gateway), and all the
|
||||
combined users of sites A, B and C. She then enables transport on her node, and
|
||||
traffic from site D can now reach everyone at site A, B and C, and vice versa.
|
||||
A **Transport Node** is an Instance that has been explicitly configured to
|
||||
participate in network-wide transport. Transport nodes forward packets across
|
||||
hops, propagate announces, maintain path tables, and serve path requests on
|
||||
behalf of other nodes. When a destination sends an announce, Transport Nodes
|
||||
receive it, remember the path, and rebroadcast it to other interfaces. When a node
|
||||
needs to reach a destination it doesn't have a path for, Transport Nodes help
|
||||
resolve the path through the network.
|
||||
|
||||
Growth and Convergence
|
||||
======================
|
||||
Even devices hosting services or serving content should probably just be configured
|
||||
as instances, and themselves connect to wider networks via a Transport Node.
|
||||
In some situations, this may not be practical though, and as an example, it is
|
||||
entirely viable to host a personal Transport Node on a Raspberry Pi, while it
|
||||
is at the same time running an LXMF propagation node, and hosting your personal
|
||||
site or files over Reticulum.
|
||||
|
||||
As the organisation grows, more gateways are added to keep up with the growing user
|
||||
base. Some local gateways even add VHF radios and packet modems to reach outlying users
|
||||
and communities that are out of reach for the LoRa radios and WiFi backhauls.
|
||||
The distinction is important. **Not** every node should be a Transport Node:
|
||||
|
||||
As more sites, gateways and users are connected, the amount of coordination required
|
||||
is kept to a minimum. If one community wants to add connectivity to the next one
|
||||
over, it can simply be done without having to involve everyone or coordinate address
|
||||
space or routing tables.
|
||||
* **Resource consumption:** Transport nodes maintain path tables, process
|
||||
announces, and forward traffic. This requires memory and CPU resources that
|
||||
may be limited on low-powered devices.
|
||||
|
||||
With the added geographical coverage, the operators at site A one day find that
|
||||
the original internet bridged interfaces are no longer utilised. The network has
|
||||
converged to be completely self-connected, and the sites that were once poorly
|
||||
connected outliers are now an integral part of the network.
|
||||
* **Stability requirements:** Transport nodes contribute to network convergence.
|
||||
If Transport Nodes frequently go offline, path tables become stale and
|
||||
convergence suffers. Stable, always-on nodes make better Transport Nodes.
|
||||
|
||||
* **Bandwidth considerations:** Transport nodes process and rebroadcast network
|
||||
maintenance traffic. On very low-bandwidth mediums, having too many Transport
|
||||
Nodes will consume capacity that should be used for actual data.
|
||||
|
||||
In practice, a network typically has a relatively small number of Transport Nodes
|
||||
strategically placed to provide coverage and connectivity. End-user devices run
|
||||
as Instances, connecting through nearby Transport Nodes to reach the wider network.
|
||||
This pattern mirrors traditional networking where routers forward traffic while
|
||||
end hosts simply consume connectivity, but with the crucial difference that any
|
||||
node *can* become a router if needed, and the decision is yours to make based on
|
||||
your network's requirements.
|
||||
|
||||
Transport nodes also function as distributed cryptographic keystores. When a
|
||||
destination announces itself, Transport Nodes cache the public key and destination
|
||||
information. Other nodes can request unknown public keys from the network, and
|
||||
Transport Nodes respond with the cached information. This eliminates the need for
|
||||
a central directory service while ensuring that public keys remain available
|
||||
throughout the network.
|
||||
|
||||
Trustless Networking
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Traditional network security models assume high levels of trust at
|
||||
specific layers. You might trust your ISP to deliver packets without inspection,
|
||||
or trust your VPN provider to handle your traffic, or trust the network
|
||||
administrator to configure firewalls appropriately. These trust relationships
|
||||
create vulnerabilities and dependencies.
|
||||
|
||||
Reticulum is designed to function in **open, trustless environments**. This
|
||||
means the protocol makes no assumptions about the trustworthiness of the network
|
||||
infrastructure, the other participants, or the transport mediums. Every aspect
|
||||
of communication is secured cryptographically:
|
||||
|
||||
* **Traffic encryption:** All traffic to single destinations is encrypted using
|
||||
ephemeral keys.
|
||||
|
||||
* **Source anonymity:** Reticulum packets do not include source addresses.
|
||||
An observer intercepting a packet cannot determine who sent it, only who it is
|
||||
addressed to (unless IFAC is enabled, in which case nothing can be determined).
|
||||
This provides initiator anonymity by default.
|
||||
|
||||
* **Path verification:** The announce mechanism includes cryptographic signatures that
|
||||
prove the authenticity of destination announcements.
|
||||
|
||||
* **Unforgeable delivery confirmations:** When a destination proves receipt of a
|
||||
packet, the proof is signed with the destination's identity key. This prevents
|
||||
false acknowledgments and ensures reliable delivery verification.
|
||||
|
||||
* **Interface authentication:** When using Interface Access Codes (IFAC), packets
|
||||
on authenticated interfaces carry signatures derived from a shared secret. Only
|
||||
nodes with the correct network name and passphrase can generate valid packets, allowing creation
|
||||
of virtual private networks on shared mediums.
|
||||
|
||||
The trustless design has important consequences for network design:
|
||||
|
||||
* **Open-access networks are viable:** You can build networks that anyone can
|
||||
join without pre-approval. Because traffic is encrypted and authenticated end-
|
||||
to-end, participants cannot interfere with each other's private communication,
|
||||
even if they share the same transport infrastructure.
|
||||
|
||||
* **No traffic inspection or prioritization:** Because traffic contents and
|
||||
sources are opaque to intermediate nodes, there is no mechanism for filtering,
|
||||
prioritizing, or throttling traffic based on its type or origin. All traffic
|
||||
is treated equally. From a neutrality perspective, this is a feature.
|
||||
|
||||
* **Adversarial resilience:** The network can operate even if some nodes are
|
||||
malicious or controlled by adversaries. While a malicious Transport Node could
|
||||
refuse to forward certain traffic or drop packets, it cannot decrypt, modify,
|
||||
or impersonate legitimate traffic. Redundant paths and multiple Transport Nodes
|
||||
mitigate the impact of malicious nodes.
|
||||
|
||||
Of course, you can also create closed networks. Interface Access
|
||||
Codes allow you to restrict participation on specific interfaces. Network
|
||||
Identities enable you to verify that discovered interfaces belong to trusted
|
||||
operators. Blackhole management lets you block malicious identities. Reticulum
|
||||
provides both the tools for open networks and the controls for closed ones. The
|
||||
choice is yours based on your requirements.
|
||||
|
||||
|
||||
Heterogeneous Connectivity
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
In conventional networking, mixing different transport mediums typically requires
|
||||
gateways, translation layers, and careful configuration. A WiFi network doesn't
|
||||
natively interoperate with a packet radio network without additional infrastructure,
|
||||
and you can't just download a car over a serial port, or send an encrypted message
|
||||
in a QR code.
|
||||
|
||||
Reticulum treats **heterogeneity as a core premise**. The protocol is designed
|
||||
to seamlessly mix mediums with vastly different characteristics:
|
||||
|
||||
* **Bandwidth:** LoRa links operating at a few hundred bits per second can
|
||||
interconnect with gigabit Ethernet backbones. Reticulum automatically manages
|
||||
the flow of information, prioritizing local traffic on slow segments while
|
||||
allowing global convergence.
|
||||
|
||||
* **Latency:** Satellite links with multi-second latency can coexist with local
|
||||
links measured in milliseconds. The transport system handles timing, asynchronous
|
||||
delivery and retransmissions transparently.
|
||||
|
||||
* **Topology:** Point-to-point microwave links, broadcast radio networks,
|
||||
switched Ethernet fabrics, and virtual tunnels over the Internet can all be
|
||||
part of the same Reticulum network.
|
||||
|
||||
* **Reliability:** Intermittent connections that come and go (such as mobile
|
||||
devices or opportunistic radio contacts) can participate alongside always-on
|
||||
infrastructure. Reticulum gracefully handles link loss and reconnection.
|
||||
|
||||
This heterogeneity is achieved through several design elements:
|
||||
|
||||
* **Expandable, medium-agnostic interface system:** Reticulum communicates with the physical
|
||||
world through interface modules. Adding support for a new medium is a matter
|
||||
of implementing an interface class. The protocol itself remains unchanged.
|
||||
|
||||
* **Interface modes:** Different modes (``full``, ``gateway``, ``access_point``,
|
||||
``roaming``, ``boundary``) allow you to configure how interfaces interact with
|
||||
the wider network based on their characteristics and role.
|
||||
|
||||
* **Announce propagation rules:** Announces are forwarded between interfaces
|
||||
according to rules that account for bandwidth limitations and interface modes.
|
||||
Slow segments are not overwhelmed by traffic from fast segments.
|
||||
|
||||
* **Local traffic prioritization:** When bandwidth is constrained, Reticulum
|
||||
prioritizes announces for nearby destinations. This ensures that local
|
||||
connectivity remains functional even when global convergence is incomplete.
|
||||
|
||||
For network designers, this means you are free to use whatever mediums are
|
||||
available, affordable, or appropriate for your situation. You might use LoRa for
|
||||
wide-area low-bandwidth coverage, WiFi for local high-capacity links, I2P for
|
||||
anonymous Internet connectivity, and Ethernet for infrastructure backhauls, all
|
||||
within the same network. Reticulum handles the translation and coordination
|
||||
automatically.
|
||||
|
||||
The key design consideration is not whether different mediums can work together
|
||||
(they can), but **how** they should work together based on your goals. A node
|
||||
with multiple interfaces spanning heterogeneous mediums needs to be configured
|
||||
with appropriate interface modes so that traffic flows efficiently. A gateway
|
||||
connecting a slow LoRa segment to a fast Internet backbone should be configured
|
||||
differently than a mobile device roaming between radio cells.
|
||||
@@ -0,0 +1,355 @@
|
||||
.. _software-main:
|
||||
|
||||
************************
|
||||
Programs Using Reticulum
|
||||
************************
|
||||
|
||||
This chapter provides a non-exhaustive list of notable programs, systems and application-layer
|
||||
protocols that have been built using Reticulum.
|
||||
|
||||
These programs will let you get a feel for how Reticulum works. Most of them have been designed
|
||||
to run well even over slow networks based on LoRa or packet radio, but all can also be used over fast
|
||||
links, such as local WiFi, wired Ethernet, the Internet, or any combination.
|
||||
|
||||
As such, it is easy to get started experimenting, without having to set up any radio
|
||||
transceivers or infrastructure just to try it out. Launching the programs on separate
|
||||
devices connected to the same WiFi network is enough to get started, and physical
|
||||
radio interfaces can then be added later.
|
||||
|
||||
Programs & Utilities
|
||||
====================
|
||||
|
||||
Many different applications using Reticulum already exist, serving a wide variety of purposes
|
||||
from day-to-day communication and information sharing to systems administration and tackling
|
||||
advanced networking and communications challenges.
|
||||
|
||||
Development of Reticulum-based applications and systems is ongoing, so consider this list
|
||||
a non-exhaustive starting point of *some* of the options available. With a bit of searching,
|
||||
primarily over Reticulum itself, you will find many more interesting things.
|
||||
|
||||
Remote Shell
|
||||
^^^^^^^^^^^^
|
||||
|
||||
The `rnsh <https://github.com/acehoss/rnsh>`_ program lets you establish fully interactive
|
||||
remote shell sessions over Reticulum. It also allows you to pipe any program to or from a
|
||||
remote system, and is similar to how ``ssh`` works. The ``rnsh`` program is very efficient, and
|
||||
can facilitate fully interactive shell sessions, even over extremely low-bandwidth links,
|
||||
such as LoRa or packet radio.
|
||||
|
||||
In addition to the default, fully interactive terminal mode,
|
||||
for extremely limited links, ``rnsh`` offers line-interactive mode, allowing you to interact
|
||||
with remote systems, even when link throughput is counted in a few hundreds of bits per second.
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\newpage
|
||||
|
||||
Nomad Network
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
The terminal-based program `Nomad Network <https://github.com/markqvist/nomadnet>`_
|
||||
provides a complete encrypted communications suite built with Reticulum. It features
|
||||
encrypted messaging (both direct and delayed-delivery for offline users), file sharing,
|
||||
and has a built-in text-browser and page server with support for dynamically rendered pages,
|
||||
user authentication and more.
|
||||
|
||||
.. image:: screenshots/nomadnet_3.png
|
||||
:target: https://github.com/markqvist/nomadnet
|
||||
|
||||
`Nomad Network <https://github.com/markqvist/nomadnet>`_ is a user-facing client
|
||||
for the messaging and information-sharing protocol LXMF.
|
||||
|
||||
RNS Page Node
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
`RNS Page Node <https://git.quad4.io/RNS-Things/rns-page-node>`_ is a simple way to serve pages and files to any other Nomad Network compatible client. Drop-in replacement for NomadNet nodes that primarily serve pages and files.
|
||||
|
||||
|
||||
Retipedia
|
||||
^^^^^^^^^
|
||||
|
||||
You can host the entirity of Wikipedia (or any ``.zim``) file to other Nomad Network clients using `Retipedia <https://github.com/RFnexus/Retipedia>`_.
|
||||
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\newpage
|
||||
|
||||
Sideband
|
||||
^^^^^^^^
|
||||
|
||||
If you would rather use an LXMF client with a graphical user interface, you can take
|
||||
a look at `Sideband <https://unsigned.io/sideband>`_, which is available for Android,
|
||||
Linux, macOS and Windows. Sideband is an advanced LXMF and LXST client, and a multi-purpose Reticulum
|
||||
utility, with features and functionality targeted at advanced users.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. image:: screenshots/sideband_devices.webp
|
||||
:align: center
|
||||
:target: https://unsigned.io/sideband
|
||||
|
||||
.. only:: latex
|
||||
|
||||
.. image:: screenshots/sideband_devices.png
|
||||
:align: center
|
||||
:target: https://unsigned.io/sideband
|
||||
|
||||
Sideband allows you to communicate with other people or LXMF-compatible
|
||||
systems over Reticulum networks using LoRa, Packet Radio, WiFi, I2P, Encrypted QR
|
||||
Paper Messages, or anything else Reticulum supports.
|
||||
|
||||
It also interoperates with all other LXMF clients, and provides advanced features such as voice messaging,
|
||||
real-time voice calls, file attachments, private telemetry sharing, and a full
|
||||
plugin system for expandability.
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\newpage
|
||||
|
||||
MeshChatX
|
||||
^^^^^^^^
|
||||
|
||||
A `Reticulum MeshChat fork from the future <https://git.quad4.io/RNS-Things/MeshChatX>`_, with the goal of providing everything you need for Reticulum, LXMF, and LXST in one beautiful and feature-rich application. This project is separate from the original Reticulum MeshChat project, and is not affiliated with the original project.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. image:: screenshots/meshchatx.webp
|
||||
:align: center
|
||||
:target: https://git.quad4.io/RNS-Things/MeshChatX
|
||||
|
||||
.. only:: latex
|
||||
|
||||
.. image:: screenshots/meshchatx.png
|
||||
:align: center
|
||||
:target: https://git.quad4.io/RNS-Things/MeshChatX
|
||||
|
||||
|
||||
Features include full LXST support, custom voicemail, phonebook, contact sharing, and ringtone support, multi-identity handling, modern UI/UX, offline documentation, expanded tools, page archiving, integrated maps and improved application security.
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\newpage
|
||||
|
||||
MeshChat
|
||||
^^^^^^^^
|
||||
|
||||
The `Reticulum MeshChat <https://github.com/liamcottle/reticulum-meshchat>`_ application
|
||||
is a user-friendly LXMF client for Linux, macOS and Windows, that also includes a Nomad Network
|
||||
page browser and other interesting functionality.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. image:: screenshots/meshchat_1.webp
|
||||
:align: center
|
||||
:target: https://github.com/liamcottle/reticulum-meshchat
|
||||
|
||||
.. only:: latex
|
||||
|
||||
.. image:: screenshots/meshchat_1.png
|
||||
:align: center
|
||||
:target: https://github.com/liamcottle/reticulum-meshchat
|
||||
|
||||
Reticulum MeshChat is of course also compatible with Sideband and Nomad Network, or
|
||||
any other LXMF client.
|
||||
|
||||
Columba
|
||||
^^^^^^^
|
||||
|
||||
`Columba <https://github.com/torlando-tech/columba/>`_ is a simple and familiar LXMF
|
||||
messaging app Android, built with a native Android interface and Material Design 3.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. image:: screenshots/columba.webp
|
||||
:align: center
|
||||
:width: 25%
|
||||
:target: https://github.com/torlando-tech/columba/
|
||||
|
||||
.. only:: latex
|
||||
|
||||
.. image:: screenshots/columba.png
|
||||
:align: center
|
||||
:width: 25%
|
||||
:target: https://github.com/torlando-tech/columba/
|
||||
|
||||
While still in early and very active development, it is of course also compatible
|
||||
with all other LXMF clients, and allows you to message seamlessly with anyone else
|
||||
using LXMF.
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\newpage
|
||||
|
||||
Reticulum Relay Chat
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
`Reticulum Relay Chat <https://rrc.kc1awv.net/>`_ is a live chat system built on top of the Reticulum Network Stack. It exists to let people talk to each other in real time over Reticulum without dragging in message databases, synchronization engines, or architectural commitments they did not ask for.
|
||||
|
||||
The `rrcd <https://github.com/kc1awv/rrcd>`_ program provides a functional, reference RRC hub-server daemon implementation. RRC user clients include `rrc-gui <https://github.com/kc1awv/rrc-gui>`_ and `rrc-web <https://github.com/kc1awv/rrc-web>`_.
|
||||
|
||||
RRC is closer in spirit to IRC than to modern “everything platforms.” You connect, you join a room, you talk, and then you leave. If you were present, you saw the conversation. If you were not, the conversation did not wait for you. This is not an accident. This is the entire design.
|
||||
|
||||
RetiBBS
|
||||
^^^^^^^
|
||||
|
||||
`RetiBBS <https://github.com/kc1awv/RetiBBS>`_ is a bulletin board system implementation for Reticulum networks.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. image:: screenshots/retibbs.webp
|
||||
:align: center
|
||||
:target: https://github.com/kc1awv/RetiBBS
|
||||
|
||||
.. only:: latex
|
||||
|
||||
.. image:: screenshots/retibbs.png
|
||||
:align: center
|
||||
:target: https://github.com/kc1awv/RetiBBS
|
||||
|
||||
RetiBBS allows users to communicate through message boards in a secure manner.
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\newpage
|
||||
|
||||
RBrowser
|
||||
^^^^^^^^
|
||||
|
||||
The `rBrowser <https://github.com/fr33n0w/rBrowser>`_ program is a cross-platoform, standalone, web-based browser for exploring NomadNetwork Nodes over Reticulum Network. It automatically discovers NomadNet nodes through network announces and provides a user-friendly interface for browsing distributed content with Micron markup support.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. image:: screenshots/rbrowser.webp
|
||||
:align: center
|
||||
:target: https://github.com/fr33n0w/rBrowser
|
||||
|
||||
.. only:: latex
|
||||
|
||||
.. image:: screenshots/rbrowser.png
|
||||
:align: center
|
||||
:target: https://github.com/fr33n0w/rBrowser
|
||||
|
||||
Includes useful features like automatic listening for announce, adding nodes to favorites, browsing and rendering any kind of NomadNet links, downloading files from remote nodes, a unique local NomadNet Search Engine and more.
|
||||
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\newpage
|
||||
|
||||
Reticulum Network Telephone
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The ``rnphone`` program, included as part of the `LXST <https://github.com/markqvist/LXST>`_ package is a command-line Reticulum telephone utility and daemon, that allows building physical, hardware telephones for LXST and Reticulum, as well as simply performing calls via the command line.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. image:: screenshots/rnphone.webp
|
||||
:align: center
|
||||
:target: https://github.com/markqvist/LXST
|
||||
|
||||
.. only:: latex
|
||||
|
||||
.. image:: screenshots/rnphone.jpg
|
||||
:align: center
|
||||
:target: https://github.com/markqvist/LXST
|
||||
|
||||
It supports interfacing directly with hardware peripherals such as GPIO keypads and LCD displays, providing a modular system for building secure hardware telephones.
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\newpage
|
||||
|
||||
LXST Phone
|
||||
^^^^^^^^^^
|
||||
|
||||
The `LXST Phone <https://github.com/kc1awv/lxst_phone>`_ program is a cross-platform desktop application for performing LXST voice calls over Reticulum.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. image:: screenshots/lxst_phone.webp
|
||||
:align: center
|
||||
:target: https://github.com/kc1awv/lxst_phone
|
||||
|
||||
.. only:: latex
|
||||
|
||||
.. image:: screenshots/lxst_phone.png
|
||||
:align: center
|
||||
:target: https://github.com/kc1awv/lxst_phone
|
||||
|
||||
It supports various advanced features such as SAS verification, peer blocking, rate limiting, encrypted call history storage and contact management.
|
||||
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\newpage
|
||||
|
||||
LXMFy
|
||||
^^^^^
|
||||
|
||||
`LXMFy <https://lxmfy.quad4.io/>`_ is a comprehensive and advanced bot creation framework for LXMF, that allows building any kind of automation or bot system running over LXMF and Reticulum. `Bot implementations exist <https://github.com/lxmfy/awesome-lxmfy-bots>`_ for Home Assistant control, LLM integrations, and various other purposes.
|
||||
|
||||
|
||||
LXMF Interactive Client
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
`LXMF Interactive Client <https://github.com/fr33n0w/lxmf-cli>`_ is a feature-rich, terminal-based LXMF messaging client with many advanced features and an extensible plugin architecture.
|
||||
|
||||
RNS FileSync
|
||||
^^^^^^^^^^^^
|
||||
|
||||
The `RNS FileSync <https://git.quad4.io/RNS-Things/RNS-Filesync>`_ program enables automatic file synchronization between devices without requiring central servers, internet connectivity, or cloud services. It works over any network medium supported by Reticulum, including radio, LoRa, WiFi, or the internet, making it ideal for off-grid, privacy-focused, and resilient file sharing.
|
||||
|
||||
|
||||
Micron Parser JS
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
`Micron Parser JS <https://github.com/RFnexus/micron-parser-js>`_ is the JavaScript-based parser for the Micron markup language, that most web-based Nomad Network browsers use. If you want to make utilities or tools that display Micron pages, this library is essential.
|
||||
|
||||
|
||||
RNMon
|
||||
^^^^^
|
||||
|
||||
`RNMon <https://github.com/lbatalha/rnmon>`_ is a monitoring daemon designed to monitor the status of multiple RNS applications and push the metrics to an InfluxDB instance over the influx line protocol.
|
||||
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\newpage
|
||||
|
||||
Protocols
|
||||
=========
|
||||
|
||||
A number of standard protocols have emerged through real-world usage and testing in the Reticulum community. While you may sometimes want to use completely custom protocols and implementations when writing Reticulum-based software, using these protocols provides application developers with an easy way to implement advanced functionality quickly and effortlessly. Using them also ensures compatibility and interoperability between many different client applications, creating an open communications ecosystem where users are free to choose the applications that suit their needs, while remaining connected to everyone else.
|
||||
|
||||
LXMF
|
||||
^^^^
|
||||
|
||||
`LXMF <https://github.com/markqvist/lxmf>`_ is a simple and flexible messaging format and delivery protocol that allows a wide variety of applications, while using as little bandwidth as possible. It offers zero-conf message routing, end-to-end encryption and Forward Secrecy, and can be transported over any kind of medium that Reticulum supports.
|
||||
|
||||
LXMF is efficient enough that it can deliver messages over extremely low-bandwidth systems such as packet radio or LoRa. Encrypted LXMF messages can also be encoded as QR-codes or text-based URIs, allowing completely analog paper message transport.
|
||||
|
||||
Using Propagation Nodes, LXMF also offer a way to store and forward messages to users or endpoints that are not directly reachable at the time of message emission.
|
||||
|
||||
LXST
|
||||
^^^^
|
||||
|
||||
`LXST <https://github.com/markqvist/lxst>`_ is a simple and flexible real-time streaming format and delivery protocol that allows a wide variety of applications, while using as little bandwidth as possible. It is built on top of Reticulum and offers zero-conf stream routing, end-to-end encryption and Forward Secrecy, and can be transported over any kind of medium that Reticulum supports. It currently powers real-time voice and telephony applications over Reticulum.
|
||||
|
||||
RRC
|
||||
^^^
|
||||
|
||||
The `Reticulum Relay Chat <https://rrc.kc1awv.net/>`_ protocol, is a live chat system built on top of the Reticulum Network Stack. It exists to provide near real-time group communication without dragging in message history databases, federation machinery, or architectural guilt.
|
||||
|
||||
RRC is intentionally simple. It does not pretend to be email, a mailbox, or a distributed archive. It behaves more like a conversation in a room. If you were there, you heard it. If you were not, you did not. That is not a bug, that is the point.
|
||||
|
||||
Interface Modules & Connectivity Resources
|
||||
==========================================
|
||||
|
||||
This section provides a list of various community-provided interface modules, guides and resources for creating Reticulum networks over special or challenging mediums.
|
||||
|
||||
* Custom interface module for running `RNS over HTTP <https://git.quad4.io/RNS-Things/RNS-over-HTTP>`_
|
||||
* Guide for running `Reticulum over ICMP <https://github.com/matvik22000/rns-over-icmp>`_ using ``PipeInterface``
|
||||
* Guide for running `Reticulum over DNS <https://github.com/markqvist/Reticulum/discussions/1002>`_ with Iodine
|
||||
* Guide for running `Reticulum over HF radio <https://github.com/RFnexus/reticulum-over-hf>`_
|
||||
* `Modem73 <https://github.com/RFnexus/modem73>`_ is a KISS TNC OFDM modem frontend that can be used with Reticulum
|
||||
@@ -16,12 +16,12 @@ Donations are gratefully accepted via the following channels:
|
||||
Monero:
|
||||
84FpY1QbxHcgdseePYNmhTHcrgMX4nFfBYtz2GKYToqHVVhJp8Eaw1Z1EedRnKD19b3B8NiLCGVxzKV17UMmmeEsCrPyA5w
|
||||
|
||||
Ethereum:
|
||||
0x81F7B979fEa6134bA9FD5c701b3501A2e61E897a
|
||||
|
||||
Bitcoin:
|
||||
3CPmacGm34qYvR6XWLVEJmi2aNe3PZqUuq
|
||||
bc1pgqgu8h8xvj4jtafslq396v7ju7hkgymyrzyqft4llfslz5vp99psqfk3a6
|
||||
|
||||
Ethereum:
|
||||
0x91C421DdfB8a30a49A71d63447ddb54cEBe3465E
|
||||
|
||||
Liberapay:
|
||||
https://liberapay.com/Reticulum/
|
||||
|
||||
@@ -33,15 +33,28 @@ organisation? Make them a reality quickly by sponsoring their implementation.
|
||||
|
||||
Provide Feedback
|
||||
================
|
||||
All feedback on the usage, functioning and potential dysfunctioning of any and
|
||||
Feedback on the usage, functioning and potential dysfunctioning of any and
|
||||
all components of the system is very valuable to the continued development and
|
||||
improvement of Reticulum.
|
||||
improvement of Reticulum. But...
|
||||
|
||||
.. warning::
|
||||
|
||||
**Think before you speak**. As time has shown, over 80% of the "feedback",
|
||||
"bug reports" and "advice" the Reticulum project has received has been
|
||||
irrelevant noise, stemming from erroneous assumptions, misunderstanding the
|
||||
foundational functionality or philosophy behind the system, or simply
|
||||
the malinformed (but overly opinionated) personal preferences of individual
|
||||
drive-by architects. This wastes the time of everyone involved.
|
||||
|
||||
The Reticulum project is not a public teahouse for serving the attention
|
||||
needs of random bypassers, but a highly complex system engineered and
|
||||
refined over more than a decade, designed to provide communication and
|
||||
connectivity guarantees in highly adversarial environments.
|
||||
|
||||
If you want to voice your opinion, it better be well-informed, and we
|
||||
expect you to have a comprehensive and solid foundation for your points
|
||||
of view. Everything else will be ignored.
|
||||
|
||||
Absolutely no automated analytics, telemetry, error
|
||||
reporting or statistics is collected and reported by Reticulum under any
|
||||
circumstances, so we rely on old-fashioned human feedback.
|
||||
|
||||
Contribute Code
|
||||
===============
|
||||
Join us on `the GitHub repository <https://github.com/markqvist/reticulum>`_ to
|
||||
report issues, suggest functionality and contribute code to Reticulum.
|
||||
|
||||
@@ -13,9 +13,8 @@ reference implementation and API reference. That being said, this chapter is an
|
||||
understanding how Reticulum works from a high-level perspective, along with the general principles of
|
||||
Reticulum, and how to apply them when creating your own networks or software.
|
||||
|
||||
After reading this document, you should be well-equipped to understand how a Reticulum network
|
||||
operates, what it can achieve, and how you can use it yourself. If you want to help out with the
|
||||
development, this is also the place to start, since it will provide a pretty clear overview of the
|
||||
After reading this chapter, you should be well-equipped to understand how a Reticulum network
|
||||
operates, what it can achieve, and how you can use it yourself. This chapter also seeks to provide an overview of the
|
||||
sentiments and the philosophy behind Reticulum, what problems it seeks to solve, and how it
|
||||
approaches those solutions.
|
||||
|
||||
@@ -117,7 +116,7 @@ Reticulum uses the singular concept of *destinations*. Any application using Ret
|
||||
networking stack will need to create one or more destinations to receive data, and know the
|
||||
destinations it needs to send data to.
|
||||
|
||||
All destinations in Reticulum are _represented_ as a 16 byte hash. This hash is derived from truncating a full
|
||||
All destinations in Reticulum are *represented* as a 16 byte hash. This hash is derived from truncating a full
|
||||
SHA-256 hash of identifying characteristics of the destination. To users, the destination addresses
|
||||
will be displayed as 16 hexadecimal bytes, like this example: ``<13425ec15b621c1d928589718000d814>``.
|
||||
|
||||
@@ -141,7 +140,7 @@ ratchets on a per-destination basis. The multi-hop transport, coordination, veri
|
||||
layers are fully autonomous and also based on elliptic curve cryptography.
|
||||
|
||||
Reticulum also offers symmetric key encryption for group-oriented communications, as well as
|
||||
unencrypted packets for local broadcast purposes.
|
||||
unencrypted packets (for local broadcast purposes **only**).
|
||||
|
||||
Reticulum can connect to a variety of interfaces such as radio modems, data radios and serial ports,
|
||||
and offers the possibility to easily tunnel Reticulum traffic over IP links such as the Internet or
|
||||
@@ -401,11 +400,10 @@ any transport node receiving it, but according to some specific rules:
|
||||
to be transmitted, the newest announce is discarded. If the newest announce contains different
|
||||
application specific data, it will replace the old announce.
|
||||
|
||||
Once an announce has reached a node in the network, any other node in direct contact with that
|
||||
node will be able to reach the destination the announce originated from, simply by sending a packet
|
||||
addressed to that destination. Any node with knowledge of the announce will be able to direct the
|
||||
packet towards the destination by looking up the next node with the shortest amount of hops to the
|
||||
destination.
|
||||
Once an announce has reached a transport node in the network, any other node in direct contact with that
|
||||
transport node will be able to reach the destination the announce originated from, simply by sending a packet
|
||||
addressed to that destination. Any transport node with knowledge of the announce will be able to direct the
|
||||
packet towards the destination by looking up the most efficient next node to the destination.
|
||||
|
||||
According to these rules, an announce will propagate throughout the network in a predictable way,
|
||||
and make the announced destination reachable in a short amount of time. Fast networks that have the
|
||||
@@ -414,6 +412,17 @@ new destinations. Slower segments of such networks might take a bit longer to ga
|
||||
the wide and fast networks they are connected to, but can still do so over time, while prioritising full
|
||||
and quickly converging end-to-end connectivity for their local, slower segments.
|
||||
|
||||
.. tip::
|
||||
|
||||
Even very slow networks, that simply don't have the capacity to ever reach *full* convergence
|
||||
will generally still be able to reach **any other destination on any connected segments**, since
|
||||
interconnecting transport nodes will prioritize announces into the slower segments that are
|
||||
actually requested by nodes on these.
|
||||
|
||||
This means that slow, low-capacity or low-resource segments **don't** need to have full network
|
||||
knowledge, since paths can always be recursively resolved from other segments that do have
|
||||
knowledge about them.
|
||||
|
||||
In general, even extremely complex networks, that utilize the maximum 128 hops will converge to full
|
||||
end-to-end connectivity in about one minute, given there is enough bandwidth available to process
|
||||
the required amount of announces.
|
||||
@@ -424,7 +433,7 @@ Reaching the Destination
|
||||
------------------------
|
||||
|
||||
In networks with changing topology and trustless connectivity, nodes need a way to establish
|
||||
*verified connectivity* with each other. Since the network is assumed to be trustless, Reticulum
|
||||
*verified connectivity* with each other. Since the underlying network mediums are assumed to be trustless, Reticulum
|
||||
must provide a way to guarantee that the peer you are communicating with is actually who you
|
||||
expect. Reticulum offers two ways to do this.
|
||||
|
||||
@@ -435,7 +444,7 @@ For exchanges of small amounts of information, Reticulum offers the *Packet* API
|
||||
an ECDH key exchange with the destination's public key (or ratchet key, if available), and encrypt the information.
|
||||
|
||||
* | It is important to note that this key exchange does not require any network traffic. The sender already
|
||||
knows the public key of the destination from an earlier received *announce*, and can thus perform the ECDH
|
||||
knows the public key of the destination from an earlier received announce, and can thus perform the ECDH
|
||||
key exchange locally, before sending the packet.
|
||||
|
||||
* | The public part of the newly generated ephemeral key-pair is included with the encrypted token, and sent
|
||||
@@ -461,14 +470,14 @@ For exchanges of small amounts of information, Reticulum offers the *Packet* API
|
||||
|
||||
For exchanges of larger amounts of data, or when longer sessions of bidirectional communication is desired, Reticulum offers the *Link* API. To establish a *link*, the following process is employed:
|
||||
|
||||
* | First, the node that wishes to establish a link will send out a special packet, that
|
||||
* | First, the node that wishes to establish a link will send out a *link request* packet, that
|
||||
traverses the network and locates the desired destination. Along the way, the Transport Nodes that
|
||||
forward the packet will take note of this *link request*.
|
||||
forward the packet will take note of this *link request*, and mark it as pending.
|
||||
|
||||
* | Second, if the destination accepts the *link request* , it will send back a packet that proves the
|
||||
authenticity of its identity (and the receipt of the link request) to the initiating node. All
|
||||
nodes that initially forwarded the packet will also be able to verify this proof, and thus
|
||||
accept the validity of the *link* throughout the network.
|
||||
accept the validity of the *link* throughout the network. The link is now marked as *established*.
|
||||
|
||||
* | When the validity of the *link* has been accepted by forwarding nodes, these nodes will
|
||||
remember the *link* , and it can subsequently be used by referring to a hash representing it.
|
||||
@@ -560,9 +569,10 @@ an arbitrary number of hops, where information will be exchanged between two nod
|
||||
*link proof* to perform it's own Diffie Hellman Key Exchange and derive the symmetric key
|
||||
that is used to encrypt the channel. Information can now be exchanged reliably and securely.
|
||||
|
||||
.. note::
|
||||
|
||||
It’s important to note that this methodology ensures that the source of the request does not need to
|
||||
reveal any identifying information about itself. The link initiator remains completely anonymous.
|
||||
It’s important to note that this methodology ensures that the source of the request does not need to
|
||||
reveal any identifying information about itself. **The link initiator remains completely anonymous**.
|
||||
|
||||
When using *links*, Reticulum will automatically verify all data sent over the link, and can also
|
||||
automate retransmissions if *Resources* are used.
|
||||
@@ -585,6 +595,82 @@ the transfer, integrity verification and reassembling the data on the other end.
|
||||
of codes to reliably transfer any amount of data. They can be used to transfer data stored in memory,
|
||||
or stream data directly from files.
|
||||
|
||||
.. _understanding-network_identities:
|
||||
|
||||
Network Identities
|
||||
==================
|
||||
|
||||
In Reticulum, every peer and application utilizes a cryptographic **Identity** to verify authenticity and establish encrypted channels. While standard identities are typically used to represent a single user, device, or service, Reticulum introduces the concept of a **Network Identity** to represent a logical group of nodes or an entire community infrastructure.
|
||||
|
||||
A Network Identity is, at its core, a standard Reticulum Identity keyset. However, its purpose and usage differ from a personal identity. Instead of identifying a single entity, a Network Identity acts as a shared credential that federates multiple independent Transport Instances under a single, verifiable administrative domain.
|
||||
|
||||
|
||||
Conceptual Overview
|
||||
-------------------
|
||||
|
||||
You can think of a standard Reticulum Identity as a self-sovereign, privately created passport for a single person. A Network Identity, conversely, is akin to a cryptographic flag, or a charter that flies over a fleet of ships. It signifies that while the ships may operate independently and be physically distant, they belong to the same organization, follow the same protocols, and are expected to act in concert.
|
||||
|
||||
When you configure a Network Identity on one or more of your nodes, you are effectively declaring that these nodes constitute a specific "network" within a broader Reticulum mesh. This allows other peers to recognize interfaces not just as "a node named Alice", but as "a gateway belonging to The Eastern Ret Of Freedom".
|
||||
|
||||
|
||||
Current Usage
|
||||
-------------
|
||||
|
||||
At present, the primary function of a Network Identity is within the :ref:`Interface Discovery<using-interface_discovery>` system.
|
||||
|
||||
When a Transport Instance broadcasts a discovery announce for an interface, it can optionally sign that announce with a Network Identity, instead of just its local transport identity. Remote peers receiving the announce can then verify the signature. This provides functionality for two important distinctions:
|
||||
|
||||
1. **Authenticity:** It proves that the interface was published by an operator who possesses the private key for that Network Identity.
|
||||
2. **Trust Boundaries:** It allows users to configure their systems to only accept and connect to interfaces that belong to specific Network Identities, effectively creating "whitelisted" zones of trusted infrastructure.
|
||||
|
||||
.. note::
|
||||
If you enable encryption on your discovery announces, the Network Identity is used as the shared secret. Only peers who have been explicitly provided with the Network Identity's full keyset (and have it configured locally) will be able to decrypt and utilize the connection details.
|
||||
|
||||
This functionality will be expanded in the future, so that peers with delegated keys can be allowed to decrypt discovery announces without holding the root network key. Currently, the functionality is sufficient for sharing interface information privately where you control all nodes that must decrypt the discovered interfaces.
|
||||
|
||||
|
||||
Future Implications
|
||||
-------------------
|
||||
|
||||
While the current implementation focuses on interface discovery, the concept of Network Identities serves as the foundational building block for future Reticulum features designed to support large-scale, organic mesh formation.
|
||||
|
||||
As the ecosystem evolves, Network Identities will facilitate:
|
||||
|
||||
* **Distributed Name Resolution:** A system where networks can publish name-to-identity mappings, allowing human-readable names to resolve without centralized servers.
|
||||
* **Service Publishing:** Networks will be able to announce specific capabilities, services, or information endpoints available publicly or to their members.
|
||||
* **Inter-Network Federation:** Trust relationships between different networks, allowing for seamless but managed flow of traffic and information across distinct administrative boundaries.
|
||||
* **Distributed Blackhole Management:** A reputation-based system for blackhole list distribution, where trusted Network Identities can sign and publish lists of blackholed identities. This allows communities to collaboratively enforce security standards and filter spam or malicious identities across the parts of the wider mesh that they are responsible for.
|
||||
|
||||
By adopting the use of Network Identities now, you are preparing your infrastructure to be compatible with this future functionality.
|
||||
|
||||
|
||||
Creating and Using a Network Identity
|
||||
-------------------------------------
|
||||
|
||||
Since a Network Identity is simply a standard Reticulum Identity, you create one using the built-in tools.
|
||||
|
||||
1. **Generate the Identity:**
|
||||
Use the ``rnid`` utility to generate a new identity file that will serve as your Network Identity.
|
||||
|
||||
.. code:: sh
|
||||
|
||||
$ rnid -g ~/.reticulum/storage/identities/my_network
|
||||
|
||||
2. **Distribute the Public Key:**
|
||||
The public key must be distributed to any Transport Instance that needs to verify your network's announces and discovery information. By default, if your node is set up to use a network identity, this happens automatically (using the standard announce mechanism).
|
||||
|
||||
3. **Configure Instances:**
|
||||
In the ``[reticulum]`` section of the configuration file on every node within your network, point the ``network_identity`` option to the file you created.
|
||||
|
||||
.. code:: ini
|
||||
|
||||
[reticulum]
|
||||
...
|
||||
network_identity = ~/.reticulum/storage/identities/my_network
|
||||
...
|
||||
|
||||
Once configured, your instances will automatically utilize this identity for signing discovery announces (and potentially decrypting network-private information), presenting a unified front to the wider network.
|
||||
|
||||
.. _understanding-referencesystem:
|
||||
|
||||
Reference Setup
|
||||
@@ -624,18 +710,20 @@ into the future. The current Reference System Setup is as follows:
|
||||
* **Interface Device**
|
||||
A data radio consisting of a LoRa radio module, and a microcontroller with open source
|
||||
firmware, that can connect to host devices via USB. It operates in either the 430, 868 or 900
|
||||
MHz frequency bands. More details can be found on the `RNode Page <https://unsigned.io/rnode>`_.
|
||||
MHz frequency bands. More details can be found on the `RNode Page <https://github.com/markqvist/rnode_firmware>`_.
|
||||
* **Host Device**
|
||||
Any computer device running Linux and Python. A Raspberry Pi with a Debian based OS is
|
||||
recommended.
|
||||
a good place to start, but anything can be used.
|
||||
* **Software Stack**
|
||||
The most recently released Python Implementation of Reticulum, running on a Debian based
|
||||
The most recently released Python Implementation of Reticulum, running on a Linux-based
|
||||
operating system.
|
||||
|
||||
To avoid confusion, it is very important to note, that the reference interface device **does not**
|
||||
use the LoRaWAN standard, but uses a custom MAC layer on top of the plain LoRa modulation! As such, you will
|
||||
need a plain LoRa radio module connected to an controller with the correct firmware. Full details on how to
|
||||
get or make such a device is available on the `RNode Page <https://unsigned.io/rnode>`_.
|
||||
.. note::
|
||||
|
||||
To avoid confusion, it is very important to note, that the reference interface device **does not**
|
||||
use the LoRaWAN standard, but uses a custom MAC layer on top of the plain LoRa modulation! As such, you will
|
||||
need a plain LoRa radio module connected to a controller with the correct firmware. Full details on how to
|
||||
get or make such a device is available on the `RNode Page <https://github.com/markqvist/rnode_firmware>`_.
|
||||
|
||||
With the current reference setup, it should be possible to get on a Reticulum network for around 100$
|
||||
even if you have none of the hardware already, and need to purchase everything.
|
||||
@@ -649,16 +737,16 @@ Protocol Specifics
|
||||
==================
|
||||
|
||||
This chapter will detail protocol specific information that is essential to the implementation of
|
||||
Reticulum, but non critical in understanding how the protocol works on a general level. It should be
|
||||
Reticulum, but non-critical in understanding how the protocol works on a general level. It should be
|
||||
treated more as a reference than as essential reading.
|
||||
|
||||
|
||||
Packet Prioritisation
|
||||
---------------------
|
||||
|
||||
Currently, Reticulum is completely priority-agnostic regarding general traffic. All traffic is handled
|
||||
on a first-come, first-serve basis. Announce re-transmission are handled according to the re-transmission
|
||||
times and priorities described earlier in this chapter.
|
||||
Currently, Reticulum is completely priority-agnostic regarding *general* traffic. All traffic is handled
|
||||
on a first-come, first-serve basis. Announce re-transmission and other maintenance traffic is handled
|
||||
according to the re-transmission times and priorities described earlier in this chapter.
|
||||
|
||||
|
||||
Interface Access Codes
|
||||
@@ -666,8 +754,8 @@ Interface Access Codes
|
||||
|
||||
Reticulum can create named virtual networks, and networks that are only accessible by knowing a preshared
|
||||
passphrase. The configuration of this is detailed in the :ref:`Common Interface Options<interfaces-options>`
|
||||
section. To implement these feature, Reticulum uses the concept of Interface Access Codes, that are calculated
|
||||
and verified per packet.
|
||||
section. To implement this feature, Reticulum uses the concept of Interface Access Codes, that are calculated
|
||||
and verified per-packet.
|
||||
|
||||
An interface with a named virtual network or passphrase authentication enabled will derive a shared Ed25519
|
||||
signing identity, and for every outbound packet generate a signature of the entire packet. This signature is
|
||||
@@ -912,6 +1000,11 @@ with the OpenSSL backend being *much* faster. The most important consequence how
|
||||
potential loss of security by using primitives that has not seen the same amount of scrutiny,
|
||||
testing and review as those from OpenSSL.
|
||||
|
||||
Using the normal RNS installation procedures, it is not possible to install Reticulum on a
|
||||
system without the required OpenSSL primitives being available, and if they are not, they will
|
||||
be resolved and installed as a dependency. It is only possible to use the pure-python primitives
|
||||
by manually specifying this, for example by using the ``rnspure`` package.
|
||||
|
||||
.. warning::
|
||||
If you want to use the internal pure-python primitives, it is **highly advisable** that you
|
||||
have a good understanding of the risks that this pose, and make an informed decision on whether
|
||||
|
||||
@@ -338,8 +338,8 @@ Filter output to only show some interfaces:
|
||||
.. code:: text
|
||||
|
||||
usage: rnstatus [-h] [--config CONFIG] [--version] [-a] [-A]
|
||||
[-l] [-s SORT] [-r] [-j] [-R hash] [-i path]
|
||||
[-w seconds] [-v] [filter]
|
||||
[-l] [-t] [-s SORT] [-r] [-j] [-R hash] [-i path]
|
||||
[-w seconds] [-d] [-D] [-m] [-I seconds] [-v] [filter]
|
||||
|
||||
Reticulum Network Stack Status
|
||||
|
||||
@@ -353,12 +353,19 @@ Filter output to only show some interfaces:
|
||||
-a, --all show all interfaces
|
||||
-A, --announce-stats show announce stats
|
||||
-l, --link-stats show link stats
|
||||
-s SORT, --sort SORT sort interfaces by [rate, traffic, rx, tx, announces, arx, atx, held]
|
||||
-t, --totals display traffic totals
|
||||
-s, --sort SORT sort interfaces by [rate, traffic, rx, tx, rxs, txs,
|
||||
announces, arx, atx, held]
|
||||
-r, --reverse reverse sorting
|
||||
-j, --json output in JSON format
|
||||
-R hash transport identity hash of remote instance to get status from (requires -i)
|
||||
-R hash transport identity hash of remote instance to get status from
|
||||
-i path path to identity used for remote management
|
||||
-w seconds timeout before giving up on remote queries
|
||||
-d, --discovered list discovered interfaces
|
||||
-D show details and config entries for discovered interfaces
|
||||
-m, --monitor continuously monitor status
|
||||
-I, --monitor-interval seconds
|
||||
refresh interval for monitor mode (default: 1)
|
||||
-v, --verbose
|
||||
|
||||
|
||||
@@ -463,6 +470,7 @@ Decrypt a file using the Reticulum Identity it was encrypted for:
|
||||
-B, --base32 Use base32-encoded input and output
|
||||
--version show program's version number and exit
|
||||
|
||||
.. _utility-rnpath:
|
||||
|
||||
The rnpath Utility
|
||||
====================
|
||||
@@ -484,21 +492,23 @@ Resolve path to a destination:
|
||||
|
||||
.. code:: text
|
||||
|
||||
usage: rnpath [-h] [--config CONFIG] [--version] [-t] [-m hops]
|
||||
[-r] [-d] [-D] [-x] [-w seconds] [-R hash] [-i path]
|
||||
[-W seconds] [-j] [-v] [destination]
|
||||
usage: rnpath [-h] [--config CONFIG] [--version] [-t] [-m hops] [-r] [-d] [-D]
|
||||
[-x] [-w seconds] [-R hash] [-i path] [-W seconds] [-b] [-B] [-U]
|
||||
[--duration DURATION] [--reason REASON] [-p] [-j] [-v]
|
||||
[destination] [list_filter]
|
||||
|
||||
Reticulum Path Discovery Utility
|
||||
Reticulum Path Management Utility
|
||||
|
||||
positional arguments:
|
||||
destination hexadecimal hash of the destination
|
||||
list_filter filter for remote blackhole list view
|
||||
|
||||
options:
|
||||
-h, --help show this help message and exit
|
||||
--config CONFIG path to alternative Reticulum config directory
|
||||
--version show program's version number and exit
|
||||
-t, --table show all known paths
|
||||
-m hops, --max hops maximum hops to filter path table by
|
||||
-m, --max hops maximum hops to filter path table by
|
||||
-r, --rates show announce rate info
|
||||
-d, --drop remove the path to a destination
|
||||
-D, --drop-announces drop all queued announces
|
||||
@@ -507,6 +517,13 @@ Resolve path to a destination:
|
||||
-R hash transport identity hash of remote instance to manage
|
||||
-i path path to identity used for remote management
|
||||
-W seconds timeout before giving up on remote queries
|
||||
-b, --blackholed list blackholed identities
|
||||
-B, --blackhole blackhole identity
|
||||
-U, --unblackhole unblackhole identity
|
||||
--duration DURATION duration of blackhole enforcement in hours
|
||||
--reason REASON reason for blackholing identity
|
||||
-p, --blackholed-list
|
||||
view published blackhole list for remote transport instance
|
||||
-j, --json output in JSON format
|
||||
-v, --verbose
|
||||
|
||||
@@ -619,13 +636,20 @@ Or fetch a file from the remote system:
|
||||
|
||||
$ rncp --fetch ~/path/to/file.tgz 73cbd378bb0286ed11a707c13447bb1e
|
||||
|
||||
The default identity file is stored in ``~/.reticulum/identities/rncp``, but you can use
|
||||
another one, which will be created if it does not already exist
|
||||
|
||||
.. code:: text
|
||||
|
||||
$ rncp ~/path/to/file.tgz 73cbd378bb0286ed11a707c13447bb1e -i /path/to/identity
|
||||
|
||||
**All Command-Line Options**
|
||||
|
||||
.. code:: text
|
||||
|
||||
usage: rncp [-h] [--config path] [-v] [-q] [-S] [-l] [-F] [-f]
|
||||
[-j path] [-b seconds] [-a allowed_hash] [-n] [-p]
|
||||
[-w seconds] [--version] [file] [destination]
|
||||
[-i identity] [-w seconds] [--version] [file] [destination]
|
||||
|
||||
Reticulum File Transfer Utility
|
||||
|
||||
@@ -650,6 +674,7 @@ Or fetch a file from the remote system:
|
||||
-a allowed_hash allow this identity (or add in ~/.rncp/allowed_identities)
|
||||
-n, --no-auth accept requests from anyone
|
||||
-p, --print-identity print identity and destination info and exit
|
||||
-i identity path to identity to use
|
||||
-w seconds sender timeout before giving up
|
||||
-P, --phy-rates display physical layer transfer rates
|
||||
--version show program's version number and exit
|
||||
@@ -810,6 +835,104 @@ to create and provision new :ref:`RNodes<rnode-main>` from any supported hardwar
|
||||
For more information on how to create your own RNodes, please read the :ref:`Creating RNodes<rnode-creating>`
|
||||
section of this manual.
|
||||
|
||||
.. _using-interface_discovery:
|
||||
Discovering Interfaces
|
||||
----------------------
|
||||
|
||||
Reticulum includes built-in functionality for discovering connectable interfaces over Reticulum itself. This is particularly useful in situations where you want to do one or more of the following:
|
||||
|
||||
* Discover connectable entrypoints available on the Internet
|
||||
* Find connectable radio access points in the physical world
|
||||
* Maintain connectivity to RNS instances with unknown or changing IP addresses
|
||||
|
||||
Discovered interfaces can be **auto-connected** by Reticulum, which makes it possible to create setups where an arbitrary interface can act simply as a bootstrap connection, that can be torn down again once more suitable interfaces have been discovered and connected.
|
||||
|
||||
The interface discovery mechanism uses announces sent over Reticulum itself, and supports both publicly readable interfaces and private, encrypted discovery, that can only be decoded by specified *network identities*. It is also possible to specify which network identities should be considered valid sources for discovered interfaces, so that interfaces published by unknown entities are ignored.
|
||||
|
||||
.. note::
|
||||
A *network identity* is a normal Reticulum identity keyset that can be used by
|
||||
one or more transport nodes to identify them as belonging to the same overall
|
||||
network. In the context of interface discovery, this makes it easy to manage
|
||||
connecting to only the particular networks you care about, even if those networks
|
||||
utilize many individual physical transport node.
|
||||
|
||||
This also makes it convenient to auto-connect discovered interfaces only for networks you have some level of trust in.
|
||||
|
||||
For information on how to make your interfaces discoverable, see the :ref:`Discoverable Interfaces<interfaces-discoverable>` chapter of this manual. The current section will focus on how to actually *discover and connect to* interfaces available on the network.
|
||||
|
||||
In its most basic form, enabling interface discovery is as simple as setting ``discover_interfaces`` to ``true`` in your Reticulum config:
|
||||
|
||||
.. code:: text
|
||||
|
||||
[reticulum]
|
||||
...
|
||||
discover_interfaces = yes
|
||||
...
|
||||
|
||||
Once this option is enabled, your RNS instance will start listening for interface discovery announces, and store them for later use or inspection. You can list discovered interfaces with the ``rnstatus`` utility:
|
||||
|
||||
.. code:: text
|
||||
|
||||
$ rnstatus -d
|
||||
|
||||
Name Type Status Last Heard Value Location
|
||||
-------------------------------------------------------------------------
|
||||
Sideband Hub Backbone ✓ Available 1h ago 16 46.2316, 6.0536
|
||||
RNS Amsterdam Backbone ✓ Available 32m ago 16 52.3865, 4.9037
|
||||
|
||||
|
||||
You can view more detailed information about discovered interfaces, including configuration snippets for pasting directly into your ``[interfaces]`` config, by using the ``rnstatus -D`` option:
|
||||
|
||||
.. code:: text
|
||||
|
||||
$ rnstatus -D sideband
|
||||
|
||||
Transport ID : 521c87a83afb8f29e4455e77930b973b
|
||||
Name : Sideband Hub
|
||||
Type : BackboneInterface
|
||||
Status : Available
|
||||
Transport : Enabled
|
||||
Distance : 2 hops
|
||||
Discovered : 9h and 40m ago
|
||||
Last Heard : 1h and 15m ago
|
||||
Location : 46.2316, 6.0536
|
||||
Address : sideband.connect.reticulum.network:7822
|
||||
Stamp Value : 16
|
||||
|
||||
Configuration Entry:
|
||||
[[Sideband Hub]]
|
||||
type = BackboneInterface
|
||||
enabled = yes
|
||||
remote = sideband.connect.reticulum.network
|
||||
target_port = 7822
|
||||
transport_identity = 521c87a83afb8f29e4455e77930b973b
|
||||
|
||||
In addition to providing local interface discovery information and control, the ``rnstatus`` utility can export discovered interface data in machine-readable JSON format using the ``rnstatus -d --json`` option. This can be useful for exporting the data to external applications such as status pages, access point maps and similar.
|
||||
|
||||
To control what sources are considered valid for discovered sources, additional
|
||||
configuration options can be specified for the interface discovery system.
|
||||
|
||||
* The ``interface_discovery_sources`` option is a list of the network or transport identities from which interfaces will be accepted. If this option is set, all others will be ignored. If this option is not set, discovered interfaces will be accepted from any source, but are still subject to stamp value requirements.
|
||||
|
||||
* The ``required_discovery_value`` options specifies the minimum stamp value required for the interface announce to be considered valid. To make it computationally difficult to spam the network with a large number of defunct or malicious interfaces, each announced interface requires a valid cryptographical stamp, of configurable difficulty value.
|
||||
|
||||
* The ``autoconnect_discovered_interfaces`` value defaults to ``0``, and specifies the maximum number of discovered interfaces that should be auto-connected at any given time. If set to a number greater than ``0``, Reticulum automatically manages discovered interface connections, and will bring discovered interfaces up and down based on availability. You can at any time add discovered interfaces to your configuration manually, to persistently keep them available.
|
||||
|
||||
* The ``network_identity`` option specifies the *network identity* for this RNS instance. This identity is used both to sign (and potentially encrypt) *outgoing* interface discovery announces, and to decrypt incoming discovery information.
|
||||
|
||||
The configuration snippet below contains an example of setting these additional configuration options:
|
||||
|
||||
.. code:: text
|
||||
|
||||
[reticulum]
|
||||
...
|
||||
discover_interfaces = yes
|
||||
interface_discovery_sources = 521c87a83afb8f29e4455e77930b973b
|
||||
required_discovery_value = 16
|
||||
autoconnect_discovered_interfaces = 3
|
||||
network_identity = ~/.reticulum/storage/identities/my_network
|
||||
...
|
||||
|
||||
Remote Management
|
||||
-----------------
|
||||
|
||||
@@ -835,6 +958,130 @@ in the Reticulum configuration file:
|
||||
|
||||
For a complete example configuration, you can run ``rnsd --exampleconfig``.
|
||||
|
||||
.. _using-blackhole_management:
|
||||
|
||||
Blackhole Management
|
||||
--------------------
|
||||
|
||||
Reticulum networks are fundamentally permissionless and open, allowing anyone with a compatible interface to participate. While this openness is essential for a resilient and decentralized network, it also exposes the network to potential abuse, such as peers flooding the network with excessive announce broadcasts or other forms of resource exhaustion.
|
||||
|
||||
The **Blackhole** system provides tools to help manage this problem. It allows operators and individual users to block specific identities at the Transport layer, preventing them from propagating announces through your node, and for other nodes to reach them through your network.
|
||||
|
||||
.. important::
|
||||
|
||||
There is fundamentally **no way** to *globally* block or censor any identity or destination in Reticulum networks. The blackhole functionality will prevent announces from (and traffic to) all destinations associated with the blackholed identity *on your own network segments only*.
|
||||
|
||||
This provides users and operators with control over what they want to allow *on their own network segments*, but there is no way to globally censor or remove an identity, as long as *someone* is willing to provide transport for it.
|
||||
|
||||
This functionality serves a dual purpose:
|
||||
|
||||
* **For Individual Users:** It offers a simple way to maintain a quiet and efficient local network by manually blocking spammy or unwanted peers.
|
||||
* **For Network Operators:** It enables the creation of federated, community-wide security standards. By publishing and sharing blackhole lists, operators can protect large infrastructures and distribute spam filtering rules across the mesh without manual intervention.
|
||||
|
||||
|
||||
Local Blackhole Management
|
||||
==========================
|
||||
|
||||
The most immediate way to manage unwanted identities is through manual configuration using the ``rnpath`` utility. This allows you to instantly block or unblock specific identities on your local Transport Instance.
|
||||
|
||||
**Blackholing an Identity**
|
||||
|
||||
To block an identity, use the ``-B`` (or ``--blackhole``) flag followed by the identity hash. You can optionally specify a duration and a reason, which are useful for logging and future reference.
|
||||
|
||||
.. code:: text
|
||||
|
||||
$ rnpath -B 3a4f8b9c1d2e3f4g5h6i7j8k9l0m1n2o
|
||||
|
||||
You can also add a duration (in hours) and a reason:
|
||||
|
||||
.. code:: text
|
||||
|
||||
$ rnpath -B 3a4f8b9c1d2e3f4g5h6i7j8k9l0m1n2o --duration 24 --reason "Excessive announces"
|
||||
|
||||
**Lifting Blackholes**
|
||||
|
||||
To remove an identity from the blackhole, use the ``-U`` (or ``--unblackhole``) flag:
|
||||
|
||||
.. code:: text
|
||||
|
||||
$ rnpath -U 3a4f8b9c1d2e3f4g5h6i7j8k9l0m1n2o
|
||||
|
||||
**Viewing the Blackhole List**
|
||||
|
||||
To see all identities currently blackholed on your local instance, use the ``-b`` (or ``--blackholed``) flag:
|
||||
|
||||
.. code:: text
|
||||
|
||||
$ rnpath -b
|
||||
|
||||
<3a4f8b9c1d2e3f4g5h6i7j8k9l0m1n2o> blackholed for 23h, 56m (Excessive announces)
|
||||
<399ea050ce0eed1816c300bcb0840938> blackholed indefinitely (Announce spam)
|
||||
<d56a4fa02c0a77b3575935aedd90bdb2> blackholed indefinitely (Announce spam)
|
||||
<2b9ec651326d9bc274119054c70fb75e> blackholed indefinitely (Announce spam)
|
||||
<1178a8f1fad405bf2ad153bf5036bdfd> blackholed indefinitely (Announce spam)
|
||||
|
||||
|
||||
|
||||
Automated List Sourcing
|
||||
=======================
|
||||
|
||||
Manually blocking identities is effective for immediate threats, but maintaining an up-to-date blocklist for a large network is impractical. Reticulum supports **automated list sourcing**, allowing your node to subscribe to blackhole lists maintained by trusted peers, or a central authority you manage yourself.
|
||||
|
||||
.. warning::
|
||||
**Verify Before Subscribing!** Subscribing to a blackhole source is a powerful action that grants that source the ability to dictate who you can communicate with. Before adding a source to your configuration, verify that the maintainer aligns with your usage policy and values. Blindly subscribing to untrusted lists could inadvertently block legitimate peers or essential services.
|
||||
|
||||
When enabled, your Transport Instance will periodically (approximately once per hour) connect to configured sources, retrieve their latest blackhole lists, and automatically merge them into your local blocklist. This provides "set-and-forget" protection for both individual users and large networks.
|
||||
|
||||
**Configuration**
|
||||
|
||||
To enable automated sourcing, add the ``blackhole_sources`` option to the ``[reticulum]`` section of your configuration file. This option accepts a comma-separated list of Transport Identity hashes that you trust to provide valid blackhole lists.
|
||||
|
||||
.. code:: ini
|
||||
|
||||
[reticulum]
|
||||
...
|
||||
# Automatically fetch blackhole lists from these trusted sources
|
||||
blackhole_sources = 521c87a83afb8f29e4455e77930b973b, 68a4aa91ac350c4087564e8a69f84e86
|
||||
...
|
||||
|
||||
**How It Works**
|
||||
|
||||
1. When enabled, the ``BlackholeUpdater`` service runs in the background.
|
||||
2. For every identity hash listed in ``blackhole_sources``, it attempts to establish a temporary link to its associated``rnstransport.info.blackhole`` destination.
|
||||
3. It requests the ``/list`` path, which returns a dictionary of blackholed identities and their associated metadata.
|
||||
4. The received list is merged with your local ``blackholed_identities`` database.
|
||||
5. The lists are persisted to disk, ensuring they survive restarts.
|
||||
|
||||
.. note::
|
||||
You can verify the external lists you are subscribed to, and their contents, without importing them by using ``rnpath -p``. See the :ref:`rnpath utility documentation<utility-rnpath>` for details on querying remote blackhole lists.
|
||||
|
||||
|
||||
Publishing Blackhole Lists
|
||||
==========================
|
||||
|
||||
If you are operating a public gateway, a community hub, or simply wish to share your blackhole list with others, you can configure your instance to act as a blackhole list publisher. This allows other nodes to subscribe to *your* definitions of unwanted traffic.
|
||||
|
||||
**Enabling Publishing**
|
||||
|
||||
To publish your local blackhole list, enable the ``publish_blackhole`` option in the ``[reticulum]`` section:
|
||||
|
||||
.. code:: ini
|
||||
|
||||
[reticulum]
|
||||
...
|
||||
publish_blackhole = yes
|
||||
...
|
||||
|
||||
When this is enabled, your Transport Instance will register a request handler at ``rnstransport.info.blackhole``. Any peer that connects to this destination and requests ``/list`` will receive the complete set of identities currently present in your local blackhole database.
|
||||
|
||||
**Federation and Trust**
|
||||
|
||||
The blackhole system relies on the trust relationship between the subscriber and the publisher. By subscribing to a source, you are implicitly trusting that source to only block identities that are genuinely detrimental to the network.
|
||||
|
||||
As the ecosystem matures, this system is designed to integrate with **Network Identities**. This allows communities to verify that a published blackhole list is actually provided by a specific network or organization with a certain level of reputation and trustworthiness, adding a layer of cryptographic trust to the federation process. This prevents malicious actors from publishing fake lists intended to censor legitimate traffic.
|
||||
|
||||
For operators, this creates a scalable model where maintaining a single high-quality blocklist can protect thousands of downstream peers, drastically reducing the administrative.
|
||||
|
||||
Improving System Configuration
|
||||
------------------------------
|
||||
|
||||
|
||||
@@ -178,6 +178,8 @@ Reticulum implements a range of generalised interface types that covers the comm
|
||||
|
||||
* Or to quickly create interfaces with custom hardware
|
||||
|
||||
* Anything else using :ref:`custom interface modules<interfaces-custom>` written in Python
|
||||
|
||||
For a full list and more details, see the :ref:`Supported Interfaces<interfaces-main>` chapter.
|
||||
|
||||
|
||||
@@ -186,6 +188,4 @@ Caveat Emptor
|
||||
Reticulum is an experimental networking stack, and should be considered as
|
||||
such. While it has been built with cryptography best-practices very foremost in
|
||||
mind, it has not yet been externally security audited, and there could very well be
|
||||
privacy-breaking bugs. To be considered secure, Reticulum needs a thorough
|
||||
security review by independent cryptographers and security researchers. If you
|
||||
want to help out with this, or can help sponsor an audit, please do get in touch.
|
||||
privacy-breaking bugs.
|
||||
@@ -1,5 +1,5 @@
|
||||
const DOCUMENTATION_OPTIONS = {
|
||||
VERSION: '1.0.3',
|
||||
VERSION: '1.1.1',
|
||||
LANGUAGE: 'en',
|
||||
COLLAPSE_INDEX: false,
|
||||
BUILDER: 'html',
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
<link rel="prefetch" href="_static/rns_logo_512.png" as="image">
|
||||
|
||||
<!-- Generated with Sphinx 8.2.3 and Furo 2025.09.25.dev1 -->
|
||||
<title>Code Examples - Reticulum Network Stack 1.0.3 documentation</title>
|
||||
<title>Code Examples - Reticulum Network Stack 1.1.1 documentation</title>
|
||||
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=d111a655" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/styles/furo.css?v=580074bf" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/copybutton.css?v=76b2166b" />
|
||||
@@ -180,7 +180,7 @@
|
||||
</label>
|
||||
</div>
|
||||
<div class="header-center">
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.0.3 documentation</div></a>
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.1.1 documentation</div></a>
|
||||
</div>
|
||||
<div class="header-right">
|
||||
<div class="theme-toggle-container theme-toggle-header">
|
||||
@@ -204,7 +204,7 @@
|
||||
<img class="sidebar-logo" src="_static/rns_logo_512.png" alt="Logo"/>
|
||||
</div>
|
||||
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.0.3 documentation</span>
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.1.1 documentation</span>
|
||||
|
||||
</a><form class="sidebar-search-container" method="get" action="search.html" role="search">
|
||||
<input class="sidebar-search" placeholder="Search" name="q" aria-label="Search">
|
||||
@@ -3660,7 +3660,7 @@ will be fully on-par with natively included interfaces, including all supported
|
||||
|
||||
</aside>
|
||||
</div>
|
||||
</div><script src="_static/documentation_options.js?v=baaebd52"></script>
|
||||
</div><script src="_static/documentation_options.js?v=58fbf978"></script>
|
||||
<script src="_static/doctools.js?v=9bcbadda"></script>
|
||||
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
|
||||
<script src="_static/scripts/furo.js?v=46bd48cc"></script>
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
<link rel="prefetch" href="_static/rns_logo_512.png" as="image">
|
||||
|
||||
<!-- Generated with Sphinx 8.2.3 and Furo 2025.09.25.dev1 -->
|
||||
<title>An Explanation of Reticulum for Human Beings - Reticulum Network Stack 1.0.3 documentation</title>
|
||||
<title>An Explanation of Reticulum for Human Beings - Reticulum Network Stack 1.1.1 documentation</title>
|
||||
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=d111a655" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/styles/furo.css?v=580074bf" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/copybutton.css?v=76b2166b" />
|
||||
@@ -180,7 +180,7 @@
|
||||
</label>
|
||||
</div>
|
||||
<div class="header-center">
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.0.3 documentation</div></a>
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.1.1 documentation</div></a>
|
||||
</div>
|
||||
<div class="header-right">
|
||||
<div class="theme-toggle-container theme-toggle-header">
|
||||
@@ -204,7 +204,7 @@
|
||||
<img class="sidebar-logo" src="_static/rns_logo_512.png" alt="Logo"/>
|
||||
</div>
|
||||
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.0.3 documentation</span>
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.1.1 documentation</span>
|
||||
|
||||
</a><form class="sidebar-search-container" method="get" action="search.html" role="search">
|
||||
<input class="sidebar-search" placeholder="Search" name="q" aria-label="Search">
|
||||
@@ -291,7 +291,7 @@
|
||||
|
||||
</aside>
|
||||
</div>
|
||||
</div><script src="_static/documentation_options.js?v=baaebd52"></script>
|
||||
</div><script src="_static/documentation_options.js?v=58fbf978"></script>
|
||||
<script src="_static/doctools.js?v=9bcbadda"></script>
|
||||
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
|
||||
<script src="_static/scripts/furo.js?v=46bd48cc"></script>
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
<meta name="color-scheme" content="light dark"><link rel="index" title="Index" href="#"><link rel="search" title="Search" href="search.html">
|
||||
<link rel="prefetch" href="_static/rns_logo_512.png" as="image">
|
||||
|
||||
<!-- Generated with Sphinx 8.2.3 and Furo 2025.09.25.dev1 --><title>Index - Reticulum Network Stack 1.0.3 documentation</title>
|
||||
<!-- Generated with Sphinx 8.2.3 and Furo 2025.09.25.dev1 --><title>Index - Reticulum Network Stack 1.1.1 documentation</title>
|
||||
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=d111a655" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/styles/furo.css?v=580074bf" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/copybutton.css?v=76b2166b" />
|
||||
@@ -178,7 +178,7 @@
|
||||
</label>
|
||||
</div>
|
||||
<div class="header-center">
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.0.3 documentation</div></a>
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.1.1 documentation</div></a>
|
||||
</div>
|
||||
<div class="header-right">
|
||||
<div class="theme-toggle-container theme-toggle-header">
|
||||
@@ -202,7 +202,7 @@
|
||||
<img class="sidebar-logo" src="_static/rns_logo_512.png" alt="Logo"/>
|
||||
</div>
|
||||
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.0.3 documentation</span>
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.1.1 documentation</span>
|
||||
|
||||
</a><form class="sidebar-search-container" method="get" action="search.html" role="search">
|
||||
<input class="sidebar-search" placeholder="Search" name="q" aria-label="Search">
|
||||
@@ -213,6 +213,7 @@
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="whatis.html">What is Reticulum?</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstartedfast.html">Getting Started Fast</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="software.html">Programs Using Reticulum</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="using.html">Using Reticulum on Your System</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="understanding.html">Understanding Reticulum</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="hardware.html">Communications Hardware</a></li>
|
||||
@@ -284,15 +285,17 @@
|
||||
</li>
|
||||
<li><a href="reference.html#RNS.RawChannelReader.add_ready_callback">add_ready_callback() (RNS.RawChannelReader method)</a>
|
||||
</li>
|
||||
</ul></td>
|
||||
<td style="width: 33%; vertical-align: top;"><ul>
|
||||
<li><a href="reference.html#RNS.Resource.advertise">advertise() (RNS.Resource method)</a>
|
||||
</li>
|
||||
</ul></td>
|
||||
<td style="width: 33%; vertical-align: top;"><ul>
|
||||
<li><a href="reference.html#RNS.Destination.announce">announce() (RNS.Destination method)</a>
|
||||
</li>
|
||||
<li><a href="reference.html#RNS.Reticulum.ANNOUNCE_CAP">ANNOUNCE_CAP (RNS.Reticulum attribute)</a>
|
||||
</li>
|
||||
<li><a href="reference.html#RNS.Destination.app_and_aspects_from_name">app_and_aspects_from_name() (RNS.Destination static method)</a>
|
||||
</li>
|
||||
<li><a href="reference.html#RNS.Transport.await_path">await_path() (RNS.Transport static method)</a>
|
||||
</li>
|
||||
</ul></td>
|
||||
</tr></table>
|
||||
@@ -301,6 +304,10 @@
|
||||
<section id="B" class="genindex-section">
|
||||
<h2>B</h2>
|
||||
<table style="width: 100%" class="indextable genindextable"><tr>
|
||||
<td style="width: 33%; vertical-align: top;"><ul>
|
||||
<li><a href="reference.html#RNS.Reticulum.blackhole_sources">blackhole_sources() (RNS.Reticulum static method)</a>
|
||||
</li>
|
||||
</ul></td>
|
||||
<td style="width: 33%; vertical-align: top;"><ul>
|
||||
<li><a href="reference.html#RNS.Buffer">Buffer (class in RNS)</a>
|
||||
</li>
|
||||
@@ -517,10 +524,12 @@
|
||||
<li><a href="reference.html#RNS.Link.identify">identify() (RNS.Link method)</a>
|
||||
</li>
|
||||
<li><a href="reference.html#RNS.Identity">Identity (class in RNS)</a>
|
||||
</li>
|
||||
<li><a href="reference.html#RNS.Link.inactive_for">inactive_for() (RNS.Link method)</a>
|
||||
</li>
|
||||
</ul></td>
|
||||
<td style="width: 33%; vertical-align: top;"><ul>
|
||||
<li><a href="reference.html#RNS.Link.inactive_for">inactive_for() (RNS.Link method)</a>
|
||||
<li><a href="reference.html#RNS.Reticulum.interface_discovery_sources">interface_discovery_sources() (RNS.Reticulum static method)</a>
|
||||
</li>
|
||||
<li><a href="reference.html#RNS.Resource.is_compressed">is_compressed() (RNS.Resource method)</a>
|
||||
</li>
|
||||
@@ -618,13 +627,15 @@
|
||||
</li>
|
||||
<li><a href="reference.html#RNS.Packet">Packet (class in RNS)</a>
|
||||
</li>
|
||||
</ul></td>
|
||||
<td style="width: 33%; vertical-align: top;"><ul>
|
||||
<li><a href="reference.html#RNS.PacketReceipt">PacketReceipt (class in RNS)</a>
|
||||
</li>
|
||||
</ul></td>
|
||||
<td style="width: 33%; vertical-align: top;"><ul>
|
||||
<li><a href="reference.html#RNS.Transport.PATHFINDER_M">PATHFINDER_M (RNS.Transport attribute)</a>
|
||||
</li>
|
||||
<li><a href="reference.html#RNS.Packet.PLAIN_MDU">PLAIN_MDU (RNS.Packet attribute)</a>
|
||||
</li>
|
||||
<li><a href="reference.html#RNS.Reticulum.publish_blackhole_enabled">publish_blackhole_enabled() (RNS.Reticulum static method)</a>
|
||||
</li>
|
||||
</ul></td>
|
||||
</tr></table>
|
||||
@@ -669,6 +680,8 @@
|
||||
<li><a href="reference.html#RNS.Transport.request_path">request_path() (RNS.Transport static method)</a>
|
||||
</li>
|
||||
<li><a href="reference.html#RNS.RequestReceipt">RequestReceipt (class in RNS)</a>
|
||||
</li>
|
||||
<li><a href="reference.html#RNS.Reticulum.required_discovery_value">required_discovery_value() (RNS.Reticulum static method)</a>
|
||||
</li>
|
||||
<li><a href="reference.html#RNS.Packet.resend">resend() (RNS.Packet method)</a>
|
||||
</li>
|
||||
@@ -819,7 +832,7 @@
|
||||
|
||||
</aside>
|
||||
</div>
|
||||
</div><script src="_static/documentation_options.js?v=baaebd52"></script>
|
||||
</div><script src="_static/documentation_options.js?v=58fbf978"></script>
|
||||
<script src="_static/doctools.js?v=9bcbadda"></script>
|
||||
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
|
||||
<script src="_static/scripts/furo.js?v=46bd48cc"></script>
|
||||
|
||||
@@ -3,11 +3,11 @@
|
||||
<head><meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width,initial-scale=1">
|
||||
<meta name="color-scheme" content="light dark"><meta name="viewport" content="width=device-width, initial-scale=1" />
|
||||
<link rel="index" title="Index" href="genindex.html"><link rel="search" title="Search" href="search.html"><link rel="next" title="Using Reticulum on Your System" href="using.html"><link rel="prev" title="What is Reticulum?" href="whatis.html">
|
||||
<link rel="index" title="Index" href="genindex.html"><link rel="search" title="Search" href="search.html"><link rel="next" title="Programs Using Reticulum" href="software.html"><link rel="prev" title="What is Reticulum?" href="whatis.html">
|
||||
<link rel="prefetch" href="_static/rns_logo_512.png" as="image">
|
||||
|
||||
<!-- Generated with Sphinx 8.2.3 and Furo 2025.09.25.dev1 -->
|
||||
<title>Getting Started Fast - Reticulum Network Stack 1.0.3 documentation</title>
|
||||
<title>Getting Started Fast - Reticulum Network Stack 1.1.1 documentation</title>
|
||||
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=d111a655" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/styles/furo.css?v=580074bf" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/copybutton.css?v=76b2166b" />
|
||||
@@ -180,7 +180,7 @@
|
||||
</label>
|
||||
</div>
|
||||
<div class="header-center">
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.0.3 documentation</div></a>
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.1.1 documentation</div></a>
|
||||
</div>
|
||||
<div class="header-right">
|
||||
<div class="theme-toggle-container theme-toggle-header">
|
||||
@@ -204,7 +204,7 @@
|
||||
<img class="sidebar-logo" src="_static/rns_logo_512.png" alt="Logo"/>
|
||||
</div>
|
||||
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.0.3 documentation</span>
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.1.1 documentation</span>
|
||||
|
||||
</a><form class="sidebar-search-container" method="get" action="search.html" role="search">
|
||||
<input class="sidebar-search" placeholder="Search" name="q" aria-label="Search">
|
||||
@@ -215,6 +215,7 @@
|
||||
<ul class="current">
|
||||
<li class="toctree-l1"><a class="reference internal" href="whatis.html">What is Reticulum?</a></li>
|
||||
<li class="toctree-l1 current current-page"><a class="current reference internal" href="#">Getting Started Fast</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="software.html">Programs Using Reticulum</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="using.html">Using Reticulum on Your System</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="understanding.html">Understanding Reticulum</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="hardware.html">Communications Hardware</a></li>
|
||||
@@ -310,75 +311,9 @@ compiled packages available.</p>
|
||||
</section>
|
||||
<section id="try-using-a-reticulum-based-program">
|
||||
<h2>Try Using a Reticulum-based Program<a class="headerlink" href="#try-using-a-reticulum-based-program" title="Link to this heading">¶</a></h2>
|
||||
<p>If you simply want to try using a program built with Reticulum, a few different
|
||||
programs exist that allow basic communication and a range of other useful functions,
|
||||
<p>If you simply want to try using a program built with Reticulum, a <a class="reference internal" href="software.html#software-main"><span class="std std-ref">range of different
|
||||
programs</span></a> exist that allow basic communication and a various other useful functions,
|
||||
even over extremely low-bandwidth Reticulum networks.</p>
|
||||
<p>These programs will let you get a feel for how Reticulum works. They have been designed
|
||||
to run well over networks based on LoRa or packet radio, but can also be used over fast
|
||||
links, such as local WiFi, wired Ethernet, the Internet, or any combination.</p>
|
||||
<p>As such, it is easy to get started experimenting, without having to set up any radio
|
||||
transceivers or infrastructure just to try it out. Launching the programs on separate
|
||||
devices connected to the same WiFi network is enough to get started, and physical
|
||||
radio interfaces can then be added later.</p>
|
||||
<section id="remote-shell">
|
||||
<h3>Remote Shell<a class="headerlink" href="#remote-shell" title="Link to this heading">¶</a></h3>
|
||||
<p>The <a class="reference external" href="https://github.com/acehoss/rnsh">rnsh</a> program lets you establish fully interactive
|
||||
remote shell sessions over Reticulum. It also allows you to pipe any program to or from a
|
||||
remote system, and is similar to how <code class="docutils literal notranslate"><span class="pre">ssh</span></code> works. The <code class="docutils literal notranslate"><span class="pre">rnsh</span></code> is very efficient, and
|
||||
can facilitate fully interactive shell sessions, even over extremely low-bandwidth links,
|
||||
such as LoRa or packet radio.</p>
|
||||
</section>
|
||||
<section id="nomad-network">
|
||||
<h3>Nomad Network<a class="headerlink" href="#nomad-network" title="Link to this heading">¶</a></h3>
|
||||
<p>The terminal-based program <a class="reference external" href="https://github.com/markqvist/nomadnet">Nomad Network</a>
|
||||
provides a complete encrypted communications suite built with Reticulum. It features
|
||||
encrypted messaging (both direct and delayed-delivery for offline users), file sharing,
|
||||
and has a built-in text-browser and page server with support for dynamically rendered pages,
|
||||
user authentication and more.</p>
|
||||
<a class="reference external image-reference" href="_images/nomadnet_3.png"><img alt="_images/nomadnet_3.png" src="_images/nomadnet_3.png" />
|
||||
</a>
|
||||
<p><a class="reference external" href="https://github.com/markqvist/nomadnet">Nomad Network</a> is a user-facing client
|
||||
for the messaging and information-sharing protocol
|
||||
<a class="reference external" href="https://github.com/markqvist/lxmf">LXMF</a>, another project built with Reticulum.</p>
|
||||
<p>You can install Nomad Network via pip:</p>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="c1"># Install ...</span>
|
||||
<span class="n">pip</span> <span class="n">install</span> <span class="n">nomadnet</span>
|
||||
|
||||
<span class="c1"># ... and run</span>
|
||||
<span class="n">nomadnet</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
<div class="admonition note">
|
||||
<p class="admonition-title">Note</p>
|
||||
<p>If this is the very first time you use <code class="docutils literal notranslate"><span class="pre">pip</span></code> to install a program
|
||||
on your system, you might need to reboot your system for your program to become
|
||||
available. If you get a “command not found” error or similar when running the
|
||||
program, reboot your system and try again. In some cases, you may even need to
|
||||
manually add the <code class="docutils literal notranslate"><span class="pre">pip</span></code> install path to your <code class="docutils literal notranslate"><span class="pre">PATH</span></code> environment variable.</p>
|
||||
</div>
|
||||
</section>
|
||||
<section id="sideband">
|
||||
<h3>Sideband<a class="headerlink" href="#sideband" title="Link to this heading">¶</a></h3>
|
||||
<p>If you would rather use a program with a graphical user interface, you can take
|
||||
a look at <a class="reference external" href="https://unsigned.io/sideband">Sideband</a>, which is available for Android,
|
||||
Linux, macOS and Windows.</p>
|
||||
<a class="reference external image-reference" href="_images/sideband_devices.webp"><img alt="_images/sideband_devices.webp" class="align-center" src="_images/sideband_devices.webp" />
|
||||
</a>
|
||||
<p>Sideband allows you to communicate with other people or LXMF-compatible
|
||||
systems over Reticulum networks using LoRa, Packet Radio, WiFi, I2P, Encrypted QR
|
||||
Paper Messages, or anything else Reticulum supports. It also interoperates with
|
||||
the Nomad Network program.</p>
|
||||
</section>
|
||||
<section id="meshchat">
|
||||
<h3>MeshChat<a class="headerlink" href="#meshchat" title="Link to this heading">¶</a></h3>
|
||||
<p>The <a class="reference external" href="https://github.com/liamcottle/reticulum-meshchat">Reticulum MeshChat</a> application
|
||||
is a user-friendly LXMF client for Linux, macOS and Windows, that also includes a Nomad Network
|
||||
page browser and other interesting functionality.</p>
|
||||
<a class="reference external image-reference" href="_images/meshchat_1.webp"><img alt="_images/meshchat_1.webp" class="align-center" src="_images/meshchat_1.webp" />
|
||||
</a>
|
||||
<p>Reticulum MeshChat is of course also compatible with Sideband and Nomad Network, or
|
||||
any other LXMF client.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="using-the-included-utilities">
|
||||
<h2>Using the Included Utilities<a class="headerlink" href="#using-the-included-utilities" title="Link to this heading">¶</a></h2>
|
||||
@@ -418,81 +353,77 @@ other device on your local WiFi will then be able to connect to this wider Retic
|
||||
network just using the default (<a class="reference internal" href="interfaces.html#interfaces-auto"><span class="std std-ref">AutoInterface</span></a>) configuration.</p>
|
||||
<p>Possibly, the examples in the config file are enough to get you started. If
|
||||
you want more information, you can read the <a class="reference internal" href="networks.html#networks-main"><span class="std std-ref">Building Networks</span></a>
|
||||
and <a class="reference internal" href="interfaces.html#interfaces-main"><span class="std std-ref">Interfaces</span></a> chapters of this manual.</p>
|
||||
and <a class="reference internal" href="interfaces.html#interfaces-main"><span class="std std-ref">Interfaces</span></a> chapters of this manual, but most importantly,
|
||||
start with reading the next section, <a class="reference internal" href="#bootstrapping-connectivity"><span class="std std-ref">Bootstrapping Connectivity</span></a>,
|
||||
as this provides the most essential understanding of how to ensure reliable
|
||||
connectivity with a minimum of maintenance.</p>
|
||||
</section>
|
||||
<section id="connecting-reticulum-instances-over-the-internet">
|
||||
<h2>Connecting Reticulum Instances Over the Internet<a class="headerlink" href="#connecting-reticulum-instances-over-the-internet" title="Link to this heading">¶</a></h2>
|
||||
<p>Reticulum currently offers three interfaces suitable for connecting instances over the Internet: <a class="reference internal" href="interfaces.html#interfaces-backbone"><span class="std std-ref">Backbone</span></a>, <a class="reference internal" href="interfaces.html#interfaces-tcps"><span class="std std-ref">TCP</span></a>
|
||||
and <a class="reference internal" href="interfaces.html#interfaces-i2p"><span class="std std-ref">I2P</span></a>. Each interface offers a different set of features, and Reticulum
|
||||
users should carefully choose the interface which best suites their needs.</p>
|
||||
<p>The <code class="docutils literal notranslate"><span class="pre">TCPServerInterface</span></code> allows users to host an instance accessible over TCP/IP. This
|
||||
method is generally faster, lower latency, and more energy efficient than using <code class="docutils literal notranslate"><span class="pre">I2PInterface</span></code>,
|
||||
however it also leaks more data about the server host.</p>
|
||||
<p>The <code class="docutils literal notranslate"><span class="pre">BackboneInterface</span></code> is a very fast and efficient interface type available on POSIX operating
|
||||
systems, designed to handle many hundreds of connections simultaneously with low memory, processing
|
||||
and I/O overhead. It is fully compatible with the TCP-based interface types.</p>
|
||||
<p>TCP connections reveal the IP address of both your instance and the server to anyone who can
|
||||
inspect the connection. Someone could use this information to determine your location or identity. Adversaries
|
||||
inspecting your packets may be able to record packet metadata like time of transmission and packet size.
|
||||
Even though Reticulum encrypts traffic, TCP does not, so an adversary may be able to use
|
||||
packet inspection to learn that a system is running Reticulum, and what other IP addresses connect to it.
|
||||
Hosting a publicly reachable instance over TCP also requires a publicly reachable IP address,
|
||||
which most Internet connections don’t offer anymore.</p>
|
||||
<p>The <code class="docutils literal notranslate"><span class="pre">I2PInterface</span></code> routes messages through the <a class="reference external" href="https://geti2p.net/en/">Invisible Internet Protocol
|
||||
(I2P)</a>. To use this interface, users must also run an I2P daemon in
|
||||
parallel to <code class="docutils literal notranslate"><span class="pre">rnsd</span></code>. For always-on I2P nodes it is recommended to use <a class="reference external" href="https://i2pd.website/">i2pd</a>.</p>
|
||||
<p>By default, I2P will encrypt and mix all traffic sent over the Internet, and
|
||||
hide both the sender and receiver Reticulum instance IP addresses. Running an I2P node
|
||||
will also relay other I2P user’s encrypted packets, which will use extra
|
||||
bandwidth and compute power, but also makes timing attacks and other forms of
|
||||
deep-packet-inspection much more difficult.</p>
|
||||
<p>I2P also allows users to host globally available Reticulum instances from non-public IP’s and behind firewalls and NAT.</p>
|
||||
<p>In general it is recommended to use an I2P node if you want to host a publicly accessible
|
||||
instance, while preserving anonymity. If you care more about performance, and a slightly
|
||||
easier setup, use TCP.</p>
|
||||
</section>
|
||||
<section id="connect-to-the-public-testnet">
|
||||
<h2>Connect to the Public Testnet<a class="headerlink" href="#connect-to-the-public-testnet" title="Link to this heading">¶</a></h2>
|
||||
<p>An experimental public testnet has been made accessible by volunteers in the community. You
|
||||
can find interface definitions for adding to your <code class="docutils literal notranslate"><span class="pre">.reticulum/config</span></code> file on the
|
||||
<a class="reference external" href="https://reticulum.network/connect.html">Reticulum Website</a> or the
|
||||
<a class="reference external" href="https://github.com/markqvist/Reticulum/wiki/Community-Node-List">Community Wiki</a></p>
|
||||
<p>You can connect your devices or instances to one or more of these to gain access to any
|
||||
Reticulum networks they are physically connected to. Simply add one or more interface
|
||||
snippets to your config file in the <code class="docutils literal notranslate"><span class="pre">[interface]</span></code> section, like in the example below:</p>
|
||||
<div class="highlight-ini notranslate"><div class="highlight"><pre><span></span><span class="c1"># TCP/IP interface to the BetweenTheBorders Hub (community-provided)</span>
|
||||
<span class="k">[[RNS Testnet BetweenTheBorders]]</span>
|
||||
<span class="w"> </span><span class="na">type</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">TCPClientInterface</span>
|
||||
<span class="w"> </span><span class="na">enabled</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">yes</span>
|
||||
<span class="w"> </span><span class="na">target_host</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">reticulum.betweentheborders.com</span>
|
||||
<span class="w"> </span><span class="na">target_port</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">4242</span>
|
||||
</pre></div>
|
||||
<section id="bootstrapping-connectivity">
|
||||
<span id="id1"></span><h2>Bootstrapping Connectivity<a class="headerlink" href="#bootstrapping-connectivity" title="Link to this heading">¶</a></h2>
|
||||
<p>Reticulum is not a service you subscribe to, nor is it a single global network you “join”. It is a <em>networking stack</em>; a toolkit for building communications systems that align with your specific values, requirements, and operational environment. The way you choose to connect to other Reticulum peers is entirely your own choice.</p>
|
||||
<p>One of the most powerful aspects of Reticulum is that it provides a multitude of tools to establish, maintain, and optimize connectivity. You can use these tools in isolation or combine them in complex configurations to achieve a vast array of goals.</p>
|
||||
<p>Whether your aim is to create a completely private, air-gapped network for your family; to build a resilient community mesh that survives infrastructure collapse; to connect far and wide to as many nodes as possible; or simply to maintain a reliable, encrypted link to a specific organization you care about, Reticulum provides the mechanisms to make it happen.</p>
|
||||
<p>There is no “right” or “wrong” way to build a Reticulum network, and you don’t need to be a network engineer just to get started. If the information flows in the way you intend, and your privacy and security requirements are met, your configuration is a success. Reticulum is designed to make the most challenging and difficult scenarios attainable, even when other networking technologies fail.</p>
|
||||
<section id="finding-your-way">
|
||||
<h3>Finding Your Way<a class="headerlink" href="#finding-your-way" title="Link to this heading">¶</a></h3>
|
||||
<p>When you first start using Reticulum, you need a way to obtain connectivity with the peers you want to communicate with - the process of <em>bootstrapping connectivity</em>.</p>
|
||||
<div class="admonition important">
|
||||
<p class="admonition-title">Important</p>
|
||||
<p>A common mistake in modern networking is the reliance on a few centralized, hard-coded entrypoints. If every user simply connects to the same list of public IP addresses found on a website, the network becomes brittle, centralized, and ultimately fails to deliver on the promise of decentralization and resilience. You have a responsibility here.</p>
|
||||
</div>
|
||||
<p>Reticulum encourages the approach of <em>organic growth</em>. Instead of relying on permanent static connections to distant servers, you can use temporary bootstrap connections to continously <em>discover</em> more relevant or local infrastructure. Once discovered, your system can automatically form stronger, more direct links to these peers, and discard the temporary bootstrap links. This results in a web of connections that are geographically relevant, resilient and efficient.</p>
|
||||
<p>It <em>is</em> possible to simply add a few public entrypoints to the <code class="docutils literal notranslate"><span class="pre">[interfaces]</span></code> section of your Reticulum configuration and be connected, but a better option is to enable <a class="reference internal" href="using.html#using-interface-discovery"><span class="std std-ref">interface discovery</span></a> and either manually select relevant, local interfaces, or enable discovered interface auto-connection.</p>
|
||||
<p>A relevant option in this context is the <a class="reference internal" href="interfaces.html#interfaces-options"><span class="std std-ref">bootstrap only</span></a> interface option. This is an automated tool for better distributing connectivity. By enabling interface discovery and auto-connection, and marking an interface as <code class="docutils literal notranslate"><span class="pre">bootstrap_only</span></code>, you tell Reticulum to use that interface primarliy to find connectivity options, and then disconnect it once sufficient entrypoints have been discovered. This helps create a network topology that favors locality and resilience over the simple centralization caused by using only a few static entrypoints.</p>
|
||||
<p>Good places to find interface definitions for bootstrapping connectivity are websites like
|
||||
<a class="reference external" href="https://directory.rns.recipes/">directory.rns.recipes</a> and <a class="reference external" href="https://rmap.world/">rmap.world</a>.</p>
|
||||
</section>
|
||||
<section id="build-personal-infrastructure">
|
||||
<h3>Build Personal Infrastructure<a class="headerlink" href="#build-personal-infrastructure" title="Link to this heading">¶</a></h3>
|
||||
<p>You do not need a datacenter to be a meaningful part of the Reticulum ecosystem. In fact, the most important nodes in the network are often the smallest ones.</p>
|
||||
<p>We strongly encourage everyone, even home users, to think in terms of building <strong>personal infrastructure</strong>. Don’t connect every phone, tablet, and computer in your house directly to a public internet gateway. Instead, repurpose an old computer, a Raspberry Pi, or a supported router to act as your own, personal <strong>Transport Node</strong>:</p>
|
||||
<ul class="simple">
|
||||
<li><p>Your local Transport Node sits in your home, connected to your WiFi and perhaps a radio interface (like an RNode).</p></li>
|
||||
<li><p>You configure this node with a <code class="docutils literal notranslate"><span class="pre">bootstrap_only</span></code> interface (perhaps a TCP tunnel to a wider network) and enable interface discovery.</p></li>
|
||||
<li><p>While you sleep, work, or cook, your node listens to the network. It discovers other local community members, validates their Network Identities, and automatically establishes direct links.</p></li>
|
||||
<li><p>Your personal devices now connect to your <em>local</em> node, which is integrated into a living, breathing local mesh. Your traffic flows through local paths provided by other real people in the community rather than bouncing off a distant server.</p></li>
|
||||
</ul>
|
||||
<p><strong>Don’t wait for others to build the networks you want to see</strong>. Every network is important, perhaps even most so those that support individual families and persons. Once enough of this personal, local infrastructure exist, connecting them directly to each other, without traversing the public Internet, becomes inevitable.</p>
|
||||
</section>
|
||||
<section id="mixing-strategies">
|
||||
<h3>Mixing Strategies<a class="headerlink" href="#mixing-strategies" title="Link to this heading">¶</a></h3>
|
||||
<p>There is no requirement to commit to a single strategy. The most robust setups often mix static, dynamic, and discovered interfaces.</p>
|
||||
<ul class="simple">
|
||||
<li><p><strong>Static Interfaces:</strong> You maintain a permanent interface to a trusted friend or organization using a static configuration.</p></li>
|
||||
<li><p><strong>Bootstrap Links:</strong> You connect a <code class="docutils literal notranslate"><span class="pre">bootstrap_only</span></code> interface to a public gateway on the Internet to scan for new connectable peers or to regain connectivity if your other interfaces fail.</p></li>
|
||||
<li><p><strong>Local Wide-Area Connectivity:</strong> You run a <code class="docutils literal notranslate"><span class="pre">RNodeInterface</span></code> on a shared frequency, giving you completely self-sovereign and private wide-area access to both your own network and other Reticulum peers globally, without any “service providers” being able to control or monitor how you interact with people.</p></li>
|
||||
</ul>
|
||||
<p>By combining these methods, you create a system that is secure against single points of failure, adaptable to changing network conditions, and better integrated into your physical and social reality.</p>
|
||||
</section>
|
||||
<section id="network-health-responsibility">
|
||||
<h3>Network Health & Responsibility<a class="headerlink" href="#network-health-responsibility" title="Link to this heading">¶</a></h3>
|
||||
<p>As you participate in the wider networks you discover and build, you will inevitably encounter peers that are misconfigured, malicious, or simply broken. To protect your resources and those of your local peers, you can utilize the <a class="reference internal" href="using.html#using-blackhole-management"><span class="std std-ref">Blackhole Management</span></a> system.</p>
|
||||
<p>Whether you manually block a spamming identity or subscribe to a blackhole list maintained by a trusted Network Identity, these tools help ensure that <em>your</em> transport capacity is used for what <em>you</em> consider legitimate communication. This keeps your local segment efficient and contributes to the health of the wider network.</p>
|
||||
</section>
|
||||
<section id="contributing-to-the-global-ret">
|
||||
<h3>Contributing to the Global Ret<a class="headerlink" href="#contributing-to-the-global-ret" title="Link to this heading">¶</a></h3>
|
||||
<p>If you have the means to host a stable node with a public IP address, consider becoming a <a class="reference internal" href="#hosting-entrypoints"><span class="std std-ref">Public Entrypoint</span></a>. By <a class="reference internal" href="interfaces.html#interfaces-discoverable"><span class="std std-ref">publishing your interface as discoverable</span></a>, you provide a potential connection point for others, helping the network grow and reach new areas.</p>
|
||||
<p>For guidelines on how to properly configure a public entrypoint, refer to the <a class="reference internal" href="#hosting-entrypoints"><span class="std std-ref">Hosting Public Entrypoints</span></a> section.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="connect-to-the-distributed-backbone">
|
||||
<h2>Connect to the Distributed Backbone<a class="headerlink" href="#connect-to-the-distributed-backbone" title="Link to this heading">¶</a></h2>
|
||||
<p>A global, distributed backbone of Reticulum Transport Nodes is being run by volunteers from around the world. This network constitutes a heterogenous collection of both public and private nodes that form an uncoordinated, voluntary inter-networking backbone that currently provides global transport and internetworking capabilities for Reticulum.</p>
|
||||
<p>As a good starting point, you can find interface definitions for connecting your own networks to this backbone on websites such as <a class="reference external" href="https://directory.rns.recipes/">directory.rns.recipes</a> and <a class="reference external" href="https://rmap.world/">rmap.world</a>.</p>
|
||||
<div class="admonition tip">
|
||||
<p class="admonition-title">Tip</p>
|
||||
<p>Ideally, set up a Reticulum Transport Node that your own devices can reach locally, and then
|
||||
connect that transport node to a couple of public entrypoints. This will provide efficient
|
||||
connections and redundancy in case any of them go down.</p>
|
||||
</div>
|
||||
<p>Many other Reticulum instances are connecting to this testnet, and you can also join it
|
||||
via other entry points if you know them. There is absolutely no control over the network
|
||||
topography, usage or what types of instances connect. It will also occasionally be used
|
||||
to test various failure scenarios, and there are no availability or service guarantees.
|
||||
Expect weird things to happen on this network, as people experiment and try out things.</p>
|
||||
<div class="admonition warning">
|
||||
<p class="admonition-title">Warning</p>
|
||||
<p>It probably goes without saying, but <em>don’t use the testnet entry-points as
|
||||
hardcoded or default interfaces in any applications you ship to users</em>. When
|
||||
shipping applications, the best practice is to provide your own default
|
||||
connectivity solutions, if needed and applicable, or in most cases, simply
|
||||
leave it up to the user which networks to connect to, and how.</p>
|
||||
<p>Don’t rely on just a single connection to the distributed backbone for everyday use. It is much better to have several redundant connections configured, and enable the interface discovery options, so your nodes can continously discover peering opportunities as the network evolves. Refer to the <a class="reference internal" href="#bootstrapping-connectivity"><span class="std std-ref">Bootstrapping Connectivity</span></a> section to understand the options.</p>
|
||||
</div>
|
||||
</section>
|
||||
<section id="hosting-public-entrypoints">
|
||||
<h2>Hosting Public Entrypoints<a class="headerlink" href="#hosting-public-entrypoints" title="Link to this heading">¶</a></h2>
|
||||
<p>If you want to host a public (or private) entry-point to a Reticulum network over the
|
||||
Internet, this section offers some helpful pointers. You will need a machine, physical or
|
||||
virtual with a public IP address, that can be reached by other devices on the Internet.</p>
|
||||
<span id="hosting-entrypoints"></span><h2>Hosting Public Entrypoints<a class="headerlink" href="#hosting-public-entrypoints" title="Link to this heading">¶</a></h2>
|
||||
<p>If you want to help build a strong global interconnection backbone, you can host a public (or private) entry-point to a Reticulum network over the
|
||||
Internet. This section offers some helpful pointers. Once you have set up your public entrypoint, it is a great idea to <a class="reference internal" href="interfaces.html#interfaces-discoverable"><span class="std std-ref">make it discoverable over Reticulum</span></a>.</p>
|
||||
<p>You will need a machine, physical or virtual with a public IP address, that can be reached by other devices on the Internet.</p>
|
||||
<p>The most efficient and performant way to host a connectable entry-point supporting many
|
||||
users is to use the <code class="docutils literal notranslate"><span class="pre">BackboneInterface</span></code>. This interface type is fully compatible with
|
||||
the <code class="docutils literal notranslate"><span class="pre">TCPClientInterface</span></code> and <code class="docutils literal notranslate"><span class="pre">TCPServerInterface</span></code> types, but much faster and uses
|
||||
@@ -532,6 +463,37 @@ to your entry-point.</p>
|
||||
<code class="docutils literal notranslate"><span class="pre">BackboneInterface</span></code>, you can use <code class="docutils literal notranslate"><span class="pre">TCPServerInterface</span></code> instead, although it will
|
||||
not be as performant.</p>
|
||||
</section>
|
||||
<section id="connecting-reticulum-instances-over-the-internet">
|
||||
<h2>Connecting Reticulum Instances Over the Internet<a class="headerlink" href="#connecting-reticulum-instances-over-the-internet" title="Link to this heading">¶</a></h2>
|
||||
<p>Reticulum currently offers three interfaces suitable for connecting instances over the Internet: <a class="reference internal" href="interfaces.html#interfaces-backbone"><span class="std std-ref">Backbone</span></a>, <a class="reference internal" href="interfaces.html#interfaces-tcps"><span class="std std-ref">TCP</span></a>
|
||||
and <a class="reference internal" href="interfaces.html#interfaces-i2p"><span class="std std-ref">I2P</span></a>. Each interface offers a different set of features, and Reticulum
|
||||
users should carefully choose the interface which best suites their needs.</p>
|
||||
<p>The <code class="docutils literal notranslate"><span class="pre">TCPServerInterface</span></code> allows users to host an instance accessible over TCP/IP. This
|
||||
method is generally faster, lower latency, and more energy efficient than using <code class="docutils literal notranslate"><span class="pre">I2PInterface</span></code>,
|
||||
however it also leaks more data about the server host.</p>
|
||||
<p>The <code class="docutils literal notranslate"><span class="pre">BackboneInterface</span></code> is a very fast and efficient interface type available on POSIX operating
|
||||
systems, designed to handle thousands of connections simultaneously with low memory, processing
|
||||
and I/O overhead. It is fully compatible with the TCP-based interface types.</p>
|
||||
<p>TCP connections reveal the IP address of both your instance and the server to anyone who can
|
||||
inspect the connection. Someone could use this information to determine your location or identity. Adversaries
|
||||
inspecting your packets may be able to record packet metadata like time of transmission and packet size.
|
||||
Even though Reticulum encrypts traffic, TCP does not, so an adversary may be able to use
|
||||
packet inspection to learn that a system is running Reticulum, and what other IP addresses connect to it.
|
||||
Hosting a publicly reachable instance over TCP also requires a publicly reachable IP address,
|
||||
which most Internet connections don’t offer anymore.</p>
|
||||
<p>The <code class="docutils literal notranslate"><span class="pre">I2PInterface</span></code> routes messages through the <a class="reference external" href="https://geti2p.net/en/">Invisible Internet Protocol
|
||||
(I2P)</a>. To use this interface, users must also run an I2P daemon in
|
||||
parallel to <code class="docutils literal notranslate"><span class="pre">rnsd</span></code>. For always-on I2P nodes it is recommended to use <a class="reference external" href="https://i2pd.website/">i2pd</a>.</p>
|
||||
<p>By default, I2P will encrypt and mix all traffic sent over the Internet, and
|
||||
hide both the sender and receiver Reticulum instance IP addresses. Running an I2P node
|
||||
will also relay other I2P user’s encrypted packets, which will use extra
|
||||
bandwidth and compute power, but also makes timing attacks and other forms of
|
||||
deep-packet-inspection much more difficult.</p>
|
||||
<p>I2P also allows users to host globally available Reticulum instances from non-public IP’s and behind firewalls and NAT.</p>
|
||||
<p>In general it is recommended to use an I2P node if you want to host a publicly accessible
|
||||
instance, while preserving anonymity. If you care more about performance, and a slightly
|
||||
easier setup, use TCP.</p>
|
||||
</section>
|
||||
<section id="adding-radio-interfaces">
|
||||
<h2>Adding Radio Interfaces<a class="headerlink" href="#adding-radio-interfaces" title="Link to this heading">¶</a></h2>
|
||||
<p>Once you have Reticulum installed and working, you can add radio interfaces with
|
||||
@@ -543,20 +505,16 @@ work with Reticulum. For information on how to configure this, see the
|
||||
cheaply build an <a class="reference internal" href="hardware.html#rnode-main"><span class="std std-ref">RNode</span></a>, which is a general-purpose long-range
|
||||
digital radio transceiver, that integrates easily with Reticulum.</p>
|
||||
<p>To build one yourself requires installing a custom firmware on a supported LoRa
|
||||
development board with an auto-install script. Please see the <a class="reference internal" href="hardware.html#hardware-main"><span class="std std-ref">Communications Hardware</span></a>
|
||||
chapter for a guide. If you prefer purchasing a ready-made unit, you can refer to the
|
||||
<span class="xref std std-ref">list of suppliers</span>. For more information on RNode, you can also
|
||||
refer to these additional external resources:</p>
|
||||
<ul class="simple">
|
||||
<li><p><a class="reference external" href="https://unsigned.io/how-to-make-your-own-rnodes/">How To Make Your Own RNodes</a></p></li>
|
||||
<li><p><a class="reference external" href="https://unsigned.io/installing-rnode-firmware-on-supported-devices/">Installing RNode Firmware on Compatible LoRa Devices</a></p></li>
|
||||
<li><p><a class="reference external" href="https://unsigned.io/private-messaging-over-lora/">Private, Secure and Uncensorable Messaging Over a LoRa Mesh</a></p></li>
|
||||
<li><p><a class="reference external" href="https://github.com/markqvist/RNode_Firmware/">RNode Firmware</a></p></li>
|
||||
</ul>
|
||||
development board with an auto-install script or web-based flasher.
|
||||
Please see the <a class="reference internal" href="hardware.html#hardware-main"><span class="std std-ref">Communications Hardware</span></a> chapter for a guide.
|
||||
If you prefer purchasing a ready-made unit, you can refer to the
|
||||
<span class="xref std std-ref">list of suppliers</span>.</p>
|
||||
<p>Other radio-based hardware interfaces are being developed and made available by
|
||||
the broader Reticulum community. You can find more information on such topics
|
||||
over Reticulum-based information sharing systems.</p>
|
||||
<p>If you have communications hardware that is not already supported by any of the
|
||||
<a class="reference internal" href="interfaces.html#interfaces-main"><span class="std std-ref">existing interface types</span></a>, but you think would be suitable for use with Reticulum,
|
||||
you are welcome to head over to the <a class="reference external" href="https://github.com/markqvist/Reticulum/discussions">GitHub discussion pages</a>
|
||||
and propose adding an interface for the hardware.</p>
|
||||
<a class="reference internal" href="interfaces.html#interfaces-main"><span class="std std-ref">existing interface types</span></a>, it is easy to write (and potentially
|
||||
publish) a <a class="reference internal" href="interfaces.html#interfaces-custom"><span class="std std-ref">custom interface module</span></a> that makes it compatible with Reticulum.</p>
|
||||
</section>
|
||||
<section id="creating-and-using-custom-interfaces">
|
||||
<h2>Creating and Using Custom Interfaces<a class="headerlink" href="#creating-and-using-custom-interfaces" title="Link to this heading">¶</a></h2>
|
||||
@@ -579,50 +537,8 @@ started is to install the latest release of Reticulum via pip:</p>
|
||||
ready to import and use RNS in your own programs. The next step will most
|
||||
likely be to look at some <a class="reference internal" href="examples.html#examples-main"><span class="std std-ref">Example Programs</span></a>.</p>
|
||||
<p>The entire Reticulum API is documented in the <a class="reference internal" href="reference.html#api-main"><span class="std std-ref">API Reference</span></a>
|
||||
chapter of this manual.</p>
|
||||
</section>
|
||||
<section id="participate-in-reticulum-development">
|
||||
<h2>Participate in Reticulum Development<a class="headerlink" href="#participate-in-reticulum-development" title="Link to this heading">¶</a></h2>
|
||||
<p>If you want to participate in the development of Reticulum and associated
|
||||
utilities, you’ll want to get the latest source from GitHub. In that case,
|
||||
don’t use pip, but try this recipe:</p>
|
||||
<div class="highlight-shell notranslate"><div class="highlight"><pre><span></span><span class="c1"># Install dependencies</span>
|
||||
pip<span class="w"> </span>install<span class="w"> </span>cryptography<span class="w"> </span>pyserial
|
||||
|
||||
<span class="c1"># Clone repository</span>
|
||||
git<span class="w"> </span>clone<span class="w"> </span>https://github.com/markqvist/Reticulum.git
|
||||
|
||||
<span class="c1"># Move into Reticulum folder and symlink library to examples folder</span>
|
||||
<span class="nb">cd</span><span class="w"> </span>Reticulum
|
||||
ln<span class="w"> </span>-s<span class="w"> </span>../RNS<span class="w"> </span>./Examples/
|
||||
|
||||
<span class="c1"># Run an example</span>
|
||||
python<span class="w"> </span>Examples/Echo.py<span class="w"> </span>-s
|
||||
|
||||
<span class="c1"># Unless you've manually created a config file, Reticulum will do so now,</span>
|
||||
<span class="c1"># and immediately exit. Make any necessary changes to the file:</span>
|
||||
nano<span class="w"> </span>~/.reticulum/config
|
||||
|
||||
<span class="c1"># ... and launch the example again.</span>
|
||||
python<span class="w"> </span>Examples/Echo.py<span class="w"> </span>-s
|
||||
|
||||
<span class="c1"># You can now repeat the process on another computer,</span>
|
||||
<span class="c1"># and run the same example with -h to get command line options.</span>
|
||||
python<span class="w"> </span>Examples/Echo.py<span class="w"> </span>-h
|
||||
|
||||
<span class="c1"># Run the example in client mode to "ping" the server.</span>
|
||||
<span class="c1"># Replace the hash below with the actual destination hash of your server.</span>
|
||||
python<span class="w"> </span>Examples/Echo.py<span class="w"> </span>174a64852a75682259ad8b921b8bf416
|
||||
|
||||
<span class="c1"># Have a look at another example</span>
|
||||
python<span class="w"> </span>Examples/Filetransfer.py<span class="w"> </span>-h
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>When you have experimented with the basic examples, it’s time to go read the
|
||||
<a class="reference internal" href="understanding.html#understanding-main"><span class="std std-ref">Understanding Reticulum</span></a> chapter. Before submitting
|
||||
your first pull request, it is probably a good idea to introduce yourself on
|
||||
the <a class="reference external" href="https://github.com/markqvist/Reticulum/discussions">disucssion forum on GitHub</a>,
|
||||
or ask one of the developers or maintainers for a good place to start.</p>
|
||||
chapter of this manual. Before diving in, it’s probably a good idea to read
|
||||
this manual in full, but at least start with the <a class="reference internal" href="understanding.html#understanding-main"><span class="std std-ref">Understanding Reticulum</span></a> chapter.</p>
|
||||
</section>
|
||||
<section id="platform-specific-install-notes">
|
||||
<span id="install-guides"></span><h2>Platform-Specific Install Notes<a class="headerlink" href="#platform-specific-install-notes" title="Link to this heading">¶</a></h2>
|
||||
@@ -946,12 +862,12 @@ All other available modules will still be loaded when needed.</p>
|
||||
<footer>
|
||||
|
||||
<div class="related-pages">
|
||||
<a class="next-page" href="using.html">
|
||||
<a class="next-page" href="software.html">
|
||||
<div class="page-info">
|
||||
<div class="context">
|
||||
<span>Next</span>
|
||||
</div>
|
||||
<div class="title">Using Reticulum on Your System</div>
|
||||
<div class="title">Programs Using Reticulum</div>
|
||||
</div>
|
||||
<svg class="furo-related-icon"><use href="#svg-arrow-right"></use></svg>
|
||||
</a>
|
||||
@@ -1000,22 +916,23 @@ All other available modules will still be loaded when needed.</p>
|
||||
<li><a class="reference internal" href="#resolving-dependency-installation-issues">Resolving Dependency & Installation Issues</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#try-using-a-reticulum-based-program">Try Using a Reticulum-based Program</a><ul>
|
||||
<li><a class="reference internal" href="#remote-shell">Remote Shell</a></li>
|
||||
<li><a class="reference internal" href="#nomad-network">Nomad Network</a></li>
|
||||
<li><a class="reference internal" href="#sideband">Sideband</a></li>
|
||||
<li><a class="reference internal" href="#meshchat">MeshChat</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#try-using-a-reticulum-based-program">Try Using a Reticulum-based Program</a></li>
|
||||
<li><a class="reference internal" href="#using-the-included-utilities">Using the Included Utilities</a></li>
|
||||
<li><a class="reference internal" href="#creating-a-network-with-reticulum">Creating a Network With Reticulum</a></li>
|
||||
<li><a class="reference internal" href="#connecting-reticulum-instances-over-the-internet">Connecting Reticulum Instances Over the Internet</a></li>
|
||||
<li><a class="reference internal" href="#connect-to-the-public-testnet">Connect to the Public Testnet</a></li>
|
||||
<li><a class="reference internal" href="#bootstrapping-connectivity">Bootstrapping Connectivity</a><ul>
|
||||
<li><a class="reference internal" href="#finding-your-way">Finding Your Way</a></li>
|
||||
<li><a class="reference internal" href="#build-personal-infrastructure">Build Personal Infrastructure</a></li>
|
||||
<li><a class="reference internal" href="#mixing-strategies">Mixing Strategies</a></li>
|
||||
<li><a class="reference internal" href="#network-health-responsibility">Network Health & Responsibility</a></li>
|
||||
<li><a class="reference internal" href="#contributing-to-the-global-ret">Contributing to the Global Ret</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#connect-to-the-distributed-backbone">Connect to the Distributed Backbone</a></li>
|
||||
<li><a class="reference internal" href="#hosting-public-entrypoints">Hosting Public Entrypoints</a></li>
|
||||
<li><a class="reference internal" href="#connecting-reticulum-instances-over-the-internet">Connecting Reticulum Instances Over the Internet</a></li>
|
||||
<li><a class="reference internal" href="#adding-radio-interfaces">Adding Radio Interfaces</a></li>
|
||||
<li><a class="reference internal" href="#creating-and-using-custom-interfaces">Creating and Using Custom Interfaces</a></li>
|
||||
<li><a class="reference internal" href="#develop-a-program-with-reticulum">Develop a Program with Reticulum</a></li>
|
||||
<li><a class="reference internal" href="#participate-in-reticulum-development">Participate in Reticulum Development</a></li>
|
||||
<li><a class="reference internal" href="#platform-specific-install-notes">Platform-Specific Install Notes</a><ul>
|
||||
<li><a class="reference internal" href="#android">Android</a></li>
|
||||
<li><a class="reference internal" href="#arm64">ARM64</a></li>
|
||||
@@ -1040,7 +957,7 @@ All other available modules will still be loaded when needed.</p>
|
||||
|
||||
</aside>
|
||||
</div>
|
||||
</div><script src="_static/documentation_options.js?v=baaebd52"></script>
|
||||
</div><script src="_static/documentation_options.js?v=58fbf978"></script>
|
||||
<script src="_static/doctools.js?v=9bcbadda"></script>
|
||||
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
|
||||
<script src="_static/scripts/furo.js?v=46bd48cc"></script>
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
<link rel="prefetch" href="_static/rns_logo_512.png" as="image">
|
||||
|
||||
<!-- Generated with Sphinx 8.2.3 and Furo 2025.09.25.dev1 -->
|
||||
<title>Communications Hardware - Reticulum Network Stack 1.0.3 documentation</title>
|
||||
<title>Communications Hardware - Reticulum Network Stack 1.1.1 documentation</title>
|
||||
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=d111a655" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/styles/furo.css?v=580074bf" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/copybutton.css?v=76b2166b" />
|
||||
@@ -180,7 +180,7 @@
|
||||
</label>
|
||||
</div>
|
||||
<div class="header-center">
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.0.3 documentation</div></a>
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.1.1 documentation</div></a>
|
||||
</div>
|
||||
<div class="header-right">
|
||||
<div class="theme-toggle-container theme-toggle-header">
|
||||
@@ -204,7 +204,7 @@
|
||||
<img class="sidebar-logo" src="_static/rns_logo_512.png" alt="Logo"/>
|
||||
</div>
|
||||
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.0.3 documentation</span>
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.1.1 documentation</span>
|
||||
|
||||
</a><form class="sidebar-search-container" method="get" action="search.html" role="search">
|
||||
<input class="sidebar-search" placeholder="Search" name="q" aria-label="Search">
|
||||
@@ -671,7 +671,7 @@ can be used with Reticulum. This includes virtual software modems such as
|
||||
|
||||
</aside>
|
||||
</div>
|
||||
</div><script src="_static/documentation_options.js?v=baaebd52"></script>
|
||||
</div><script src="_static/documentation_options.js?v=58fbf978"></script>
|
||||
<script src="_static/doctools.js?v=9bcbadda"></script>
|
||||
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
|
||||
<script src="_static/scripts/furo.js?v=46bd48cc"></script>
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
<link rel="prefetch" href="_static/rns_logo_512.png" as="image">
|
||||
|
||||
<!-- Generated with Sphinx 8.2.3 and Furo 2025.09.25.dev1 -->
|
||||
<title>Reticulum Network Stack 1.0.3 documentation</title>
|
||||
<title>Reticulum Network Stack 1.1.1 documentation</title>
|
||||
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=d111a655" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/styles/furo.css?v=580074bf" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/copybutton.css?v=76b2166b" />
|
||||
@@ -180,7 +180,7 @@
|
||||
</label>
|
||||
</div>
|
||||
<div class="header-center">
|
||||
<a href="#"><div class="brand">Reticulum Network Stack 1.0.3 documentation</div></a>
|
||||
<a href="#"><div class="brand">Reticulum Network Stack 1.1.1 documentation</div></a>
|
||||
</div>
|
||||
<div class="header-right">
|
||||
<div class="theme-toggle-container theme-toggle-header">
|
||||
@@ -204,7 +204,7 @@
|
||||
<img class="sidebar-logo" src="_static/rns_logo_512.png" alt="Logo"/>
|
||||
</div>
|
||||
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.0.3 documentation</span>
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.1.1 documentation</span>
|
||||
|
||||
</a><form class="sidebar-search-container" method="get" action="search.html" role="search">
|
||||
<input class="sidebar-search" placeholder="Search" name="q" aria-label="Search">
|
||||
@@ -215,6 +215,7 @@
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="whatis.html">What is Reticulum?</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstartedfast.html">Getting Started Fast</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="software.html">Programs Using Reticulum</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="using.html">Using Reticulum on Your System</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="understanding.html">Understanding Reticulum</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="hardware.html">Communications Hardware</a></li>
|
||||
@@ -281,22 +282,23 @@ to participate in the development of Reticulum itself.</p>
|
||||
<li class="toctree-l3"><a class="reference internal" href="gettingstartedfast.html#resolving-dependency-installation-issues">Resolving Dependency & Installation Issues</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstartedfast.html#try-using-a-reticulum-based-program">Try Using a Reticulum-based Program</a><ul>
|
||||
<li class="toctree-l3"><a class="reference internal" href="gettingstartedfast.html#remote-shell">Remote Shell</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="gettingstartedfast.html#nomad-network">Nomad Network</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="gettingstartedfast.html#sideband">Sideband</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="gettingstartedfast.html#meshchat">MeshChat</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstartedfast.html#try-using-a-reticulum-based-program">Try Using a Reticulum-based Program</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstartedfast.html#using-the-included-utilities">Using the Included Utilities</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstartedfast.html#creating-a-network-with-reticulum">Creating a Network With Reticulum</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstartedfast.html#connecting-reticulum-instances-over-the-internet">Connecting Reticulum Instances Over the Internet</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstartedfast.html#connect-to-the-public-testnet">Connect to the Public Testnet</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstartedfast.html#bootstrapping-connectivity">Bootstrapping Connectivity</a><ul>
|
||||
<li class="toctree-l3"><a class="reference internal" href="gettingstartedfast.html#finding-your-way">Finding Your Way</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="gettingstartedfast.html#build-personal-infrastructure">Build Personal Infrastructure</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="gettingstartedfast.html#mixing-strategies">Mixing Strategies</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="gettingstartedfast.html#network-health-responsibility">Network Health & Responsibility</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="gettingstartedfast.html#contributing-to-the-global-ret">Contributing to the Global Ret</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstartedfast.html#connect-to-the-distributed-backbone">Connect to the Distributed Backbone</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstartedfast.html#hosting-public-entrypoints">Hosting Public Entrypoints</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstartedfast.html#connecting-reticulum-instances-over-the-internet">Connecting Reticulum Instances Over the Internet</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstartedfast.html#adding-radio-interfaces">Adding Radio Interfaces</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstartedfast.html#creating-and-using-custom-interfaces">Creating and Using Custom Interfaces</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstartedfast.html#develop-a-program-with-reticulum">Develop a Program with Reticulum</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstartedfast.html#participate-in-reticulum-development">Participate in Reticulum Development</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstartedfast.html#platform-specific-install-notes">Platform-Specific Install Notes</a><ul>
|
||||
<li class="toctree-l3"><a class="reference internal" href="gettingstartedfast.html#android">Android</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="gettingstartedfast.html#arm64">ARM64</a></li>
|
||||
@@ -312,6 +314,37 @@ to participate in the development of Reticulum itself.</p>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstartedfast.html#pure-python-reticulum">Pure-Python Reticulum</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="software.html">Programs Using Reticulum</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="software.html#programs-utilities">Programs & Utilities</a><ul>
|
||||
<li class="toctree-l3"><a class="reference internal" href="software.html#remote-shell">Remote Shell</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="software.html#nomad-network">Nomad Network</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="software.html#rns-page-node">RNS Page Node</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="software.html#retipedia">Retipedia</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="software.html#sideband">Sideband</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="software.html#meshchatx">MeshChatX</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="software.html#meshchat">MeshChat</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="software.html#columba">Columba</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="software.html#reticulum-relay-chat">Reticulum Relay Chat</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="software.html#retibbs">RetiBBS</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="software.html#rbrowser">RBrowser</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="software.html#reticulum-network-telephone">Reticulum Network Telephone</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="software.html#lxst-phone">LXST Phone</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="software.html#lxmfy">LXMFy</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="software.html#lxmf-interactive-client">LXMF Interactive Client</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="software.html#rns-filesync">RNS FileSync</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="software.html#micron-parser-js">Micron Parser JS</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="software.html#rnmon">RNMon</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="software.html#protocols">Protocols</a><ul>
|
||||
<li class="toctree-l3"><a class="reference internal" href="software.html#lxmf">LXMF</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="software.html#id17">LXST</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="software.html#rrc">RRC</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="software.html#interface-modules-connectivity-resources">Interface Modules & Connectivity Resources</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="using.html">Using Reticulum on Your System</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="using.html#configuration-data">Configuration & Data</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="using.html#included-utility-programs">Included Utility Programs</a><ul>
|
||||
@@ -325,7 +358,14 @@ to participate in the development of Reticulum itself.</p>
|
||||
<li class="toctree-l3"><a class="reference internal" href="using.html#the-rnodeconf-utility">The rnodeconf Utility</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="using.html#discovering-interfaces">Discovering Interfaces</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="using.html#remote-management">Remote Management</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="using.html#blackhole-management">Blackhole Management</a><ul>
|
||||
<li class="toctree-l3"><a class="reference internal" href="using.html#local-blackhole-management">Local Blackhole Management</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="using.html#automated-list-sourcing">Automated List Sourcing</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="using.html#publishing-blackhole-lists">Publishing Blackhole Lists</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="using.html#improving-system-configuration">Improving System Configuration</a><ul>
|
||||
<li class="toctree-l3"><a class="reference internal" href="using.html#fixed-serial-port-names">Fixed Serial Port Names</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="using.html#reticulum-as-a-system-service">Reticulum as a System Service</a></li>
|
||||
@@ -350,6 +390,13 @@ to participate in the development of Reticulum itself.</p>
|
||||
<li class="toctree-l3"><a class="reference internal" href="understanding.html#resources">Resources</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="understanding.html#network-identities">Network Identities</a><ul>
|
||||
<li class="toctree-l3"><a class="reference internal" href="understanding.html#conceptual-overview">Conceptual Overview</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="understanding.html#current-usage">Current Usage</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="understanding.html#future-implications">Future Implications</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="understanding.html#creating-and-using-a-network-identity">Creating and Using a Network Identity</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="understanding.html#reference-setup">Reference Setup</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="understanding.html#protocol-specifics">Protocol Specifics</a><ul>
|
||||
<li class="toctree-l3"><a class="reference internal" href="understanding.html#packet-prioritisation">Packet Prioritisation</a></li>
|
||||
@@ -394,18 +441,27 @@ to participate in the development of Reticulum itself.</p>
|
||||
<li class="toctree-l2"><a class="reference internal" href="interfaces.html#pipe-interface">Pipe Interface</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="interfaces.html#kiss-interface">KISS Interface</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="interfaces.html#ax-25-kiss-interface">AX.25 KISS Interface</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="interfaces.html#discoverable-interfaces">Discoverable Interfaces</a><ul>
|
||||
<li class="toctree-l3"><a class="reference internal" href="interfaces.html#enabling-discovery">Enabling Discovery</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="interfaces.html#discovery-parameters">Discovery Parameters</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="interfaces.html#interface-modes">Interface Modes</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="interfaces.html#security-considerations">Security Considerations</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="interfaces.html#example-configuration">Example Configuration</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="interfaces.html#common-interface-options">Common Interface Options</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="interfaces.html#interface-modes">Interface Modes</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="interfaces.html#interfaces-modes">Interface Modes</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="interfaces.html#announce-rate-control">Announce Rate Control</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="interfaces.html#new-destination-rate-limiting">New Destination Rate Limiting</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="networks.html">Building Networks</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="networks.html#concepts-overview">Concepts & Overview</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="networks.html#example-scenarios">Example Scenarios</a><ul>
|
||||
<li class="toctree-l3"><a class="reference internal" href="networks.html#interconnected-lora-sites">Interconnected LoRa Sites</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="networks.html#bridging-over-the-internet">Bridging Over the Internet</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="networks.html#growth-and-convergence">Growth and Convergence</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="networks.html#concepts-overview">Concepts & Overview</a><ul>
|
||||
<li class="toctree-l3"><a class="reference internal" href="networks.html#introductory-considerations">Introductory Considerations</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="networks.html#destinations-not-addresses">Destinations, Not Addresses</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="networks.html#transport-nodes-and-instances">Transport Nodes and Instances</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="networks.html#trustless-networking">Trustless Networking</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="networks.html#heterogeneous-connectivity">Heterogeneous Connectivity</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
@@ -413,7 +469,6 @@ to participate in the development of Reticulum itself.</p>
|
||||
<li class="toctree-l1"><a class="reference internal" href="support.html">Support Reticulum</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="support.html#donations">Donations</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="support.html#provide-feedback">Provide Feedback</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="support.html#contribute-code">Contribute Code</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Code Examples</a><ul>
|
||||
@@ -520,7 +575,7 @@ to participate in the development of Reticulum itself.</p>
|
||||
|
||||
</aside>
|
||||
</div>
|
||||
</div><script src="_static/documentation_options.js?v=baaebd52"></script>
|
||||
</div><script src="_static/documentation_options.js?v=58fbf978"></script>
|
||||
<script src="_static/doctools.js?v=9bcbadda"></script>
|
||||
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
|
||||
<script src="_static/scripts/furo.js?v=46bd48cc"></script>
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
<link rel="prefetch" href="_static/rns_logo_512.png" as="image">
|
||||
|
||||
<!-- Generated with Sphinx 8.2.3 and Furo 2025.09.25.dev1 -->
|
||||
<title>Configuring Interfaces - Reticulum Network Stack 1.0.3 documentation</title>
|
||||
<title>Configuring Interfaces - Reticulum Network Stack 1.1.1 documentation</title>
|
||||
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=d111a655" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/styles/furo.css?v=580074bf" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/copybutton.css?v=76b2166b" />
|
||||
@@ -180,7 +180,7 @@
|
||||
</label>
|
||||
</div>
|
||||
<div class="header-center">
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.0.3 documentation</div></a>
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.1.1 documentation</div></a>
|
||||
</div>
|
||||
<div class="header-right">
|
||||
<div class="theme-toggle-container theme-toggle-header">
|
||||
@@ -204,7 +204,7 @@
|
||||
<img class="sidebar-logo" src="_static/rns_logo_512.png" alt="Logo"/>
|
||||
</div>
|
||||
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.0.3 documentation</span>
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.1.1 documentation</span>
|
||||
|
||||
</a><form class="sidebar-search-container" method="get" action="search.html" role="search">
|
||||
<input class="sidebar-search" placeholder="Search" name="q" aria-label="Search">
|
||||
@@ -562,6 +562,7 @@ software-based soundmodems. To do this, use the <code class="docutils literal no
|
||||
<span class="w"> </span><span class="na">kiss_framing</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">True</span>
|
||||
<span class="w"> </span><span class="na">target_host</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">127.0.0.1</span>
|
||||
<span class="w"> </span><span class="na">target_port</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">8001</span>
|
||||
<span class="w"> </span><span class="na">fixed_mtu</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">500</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
<p><strong>Caution!</strong> Only use the KISS framing option when connecting to external devices
|
||||
@@ -570,6 +571,8 @@ and programs like soundmodems and similar over TCP. When using the
|
||||
never enable <code class="docutils literal notranslate"><span class="pre">kiss_framing</span></code>, since this will disable internal reliability and
|
||||
recovery mechanisms that greatly improves performance over unreliable and
|
||||
intermittent TCP links.</p>
|
||||
<p>For KISS devices that need only supports a particular MTU, you can use the
|
||||
<code class="docutils literal notranslate"><span class="pre">fixed_mtu</span></code> option.</p>
|
||||
<div class="admonition note">
|
||||
<p class="admonition-title">Note</p>
|
||||
<p>The TCP interfaces support tunneling over I2P, but to do so reliably,
|
||||
@@ -1073,6 +1076,182 @@ relevant regulation for your location, and to make decisions accordingly.</p>
|
||||
</pre></div>
|
||||
</div>
|
||||
</section>
|
||||
<section id="discoverable-interfaces">
|
||||
<span id="interfaces-discoverable"></span><h2>Discoverable Interfaces<a class="headerlink" href="#discoverable-interfaces" title="Link to this heading">¶</a></h2>
|
||||
<p>Reticulum includes a powerful system for publishing your local interfaces to the wider network, allowing other peers to <a class="reference internal" href="using.html#using-interface-discovery"><span class="std std-ref">discover, validate, and automatically connect to them</span></a>. This feature is particularly useful for creating decentralized networks where peers can dynamically find entrypoints, such as public Internet gateways or local radio access points, without relying on static configuration files or centralized directories.</p>
|
||||
<p>When an interface is made <strong>discoverable</strong>, your Reticulum instance will periodically broadcast an announce packet containing the connection details and parameters required for other peers to establish a connection. These announces are propagated over the network using the standard Reticulum announce mechanism using the <code class="docutils literal notranslate"><span class="pre">rnstransport.discovery.interface</span></code> destination type.</p>
|
||||
<div class="admonition note">
|
||||
<p class="admonition-title">Note</p>
|
||||
<p>To use the interface discovery functionality, the <code class="docutils literal notranslate"><span class="pre">LXMF</span></code> module must be installed in your Python environment. You can install it using pip:</p>
|
||||
<div class="highlight-sh notranslate"><div class="highlight"><pre><span></span>pip<span class="w"> </span>install<span class="w"> </span>lxmf
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<section id="enabling-discovery">
|
||||
<h3>Enabling Discovery<a class="headerlink" href="#enabling-discovery" title="Link to this heading">¶</a></h3>
|
||||
<p>Interface discovery is enabled on a per-interface basis. To make a specific interface discoverable, you must add the <code class="docutils literal notranslate"><span class="pre">discoverable</span></code> option to that interface’s configuration block and set it to <code class="docutils literal notranslate"><span class="pre">yes</span></code>.</p>
|
||||
<div class="highlight-ini notranslate"><div class="highlight"><pre><span></span><span class="k">[[My Public Gateway]]</span>
|
||||
<span class="w"> </span><span class="na">type</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">BackboneInterface</span>
|
||||
<span class="w"> </span><span class="na">...</span>
|
||||
<span class="w"> </span><span class="na">discoverable</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">yes</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>Once enabled, Reticulum will automatically handle the generation, signing, stamping, and broadcasting of the discovery announces. It is not <em>required</em> to enable Transport to publish interface discovery information, but for most use cases where you want others to connect to you, you will likely want <code class="docutils literal notranslate"><span class="pre">enable_transport</span></code> set to <code class="docutils literal notranslate"><span class="pre">yes</span></code> in the <code class="docutils literal notranslate"><span class="pre">[reticulum]</span></code> section of your configuration.</p>
|
||||
</section>
|
||||
<section id="discovery-parameters">
|
||||
<h3>Discovery Parameters<a class="headerlink" href="#discovery-parameters" title="Link to this heading">¶</a></h3>
|
||||
<p>When <code class="docutils literal notranslate"><span class="pre">discoverable</span></code> is enabled, a variety of additional options become available to control how the interface is presented to the network. These parameters allow you to fine-tune the metadata, security requirements, and visibility of your interface.</p>
|
||||
<p><strong>Basic Metadata</strong></p>
|
||||
<dl class="simple">
|
||||
<dt><code class="docutils literal notranslate"><span class="pre">discovery_name</span></code></dt><dd><p>A human-readable name for the interface. This name will be displayed to users on remote systems when they list discovered interfaces. If not specified, the interface name (the section header) will be used.</p>
|
||||
</dd>
|
||||
<dt><code class="docutils literal notranslate"><span class="pre">announce_interval</span></code></dt><dd><p>The interval in minutes between successive discovery announces for this interface. Default is 360 minutes (6 hours). For stable, long-running infrastructure, higher intervals (12 to 22 hours) are usually sufficient and reduce network load. Minimum allowed value is 5 minutes (but expect to have your announces throttled if using intervals below one hour).</p>
|
||||
</dd>
|
||||
</dl>
|
||||
<p><strong>Connectivity Specification</strong></p>
|
||||
<dl>
|
||||
<dt><code class="docutils literal notranslate"><span class="pre">reachable_on</span></code></dt><dd><p>Specifies the address that remote peers should use to connect to this interface.</p>
|
||||
<ul class="simple">
|
||||
<li><p>For TCP and Backbone interfaces, this is typically the public IP address or hostname. Do not include the port, this is fetched automatically from the interface.</p></li>
|
||||
<li><p>For I2P interfaces, this is usually the I2P <code class="docutils literal notranslate"><span class="pre">b32</span></code> address. This value is fetched automatically from the <code class="docutils literal notranslate"><span class="pre">I2PInterface</span></code> once it is up and connected to the I2P network, so you should not set this manually, unless you absolutely know what you’re doing.</p></li>
|
||||
</ul>
|
||||
<p><strong>Dynamic Resolution:</strong> This option also accepts a path to an external executable script or binary. If a path is provided, Reticulum will execute the script and use its <code class="docutils literal notranslate"><span class="pre">stdout</span></code> as the reachability address. This is useful for devices behind dynamic DNS, NATs, or complex cloud environments where the external IP is not known locally. The script must simply print the address to stdout and exit.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
<div class="admonition note">
|
||||
<p class="admonition-title">Note</p>
|
||||
<p>When using an executable script for <code class="docutils literal notranslate"><span class="pre">reachable_on</span></code>, Reticulum expects the script to output only the IP address or hostname to <code class="docutils literal notranslate"><span class="pre">stdout</span></code>, followed by a newline character. Any additional output or errors may cause the resolution to fail. Ensure the script has executable permissions and is robust against temporary network failures.</p>
|
||||
</div>
|
||||
<p>A minimal example of a script that resolves the externally available, public IP of an internet-connected system could look like this:</p>
|
||||
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span><span class="ch">#!/bin/bash</span>
|
||||
curl<span class="w"> </span>-s<span class="w"> </span>ip.me
|
||||
<span class="nb">exit</span><span class="w"> </span><span class="nv">$?</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>On a real system, you should make the script robust enough to deal with intermittent Internet or service failures, such that the script <em>always</em> returns a sensible value, or if not possible at least exits with a non-zero exit return code, so Reticulum knows the output is invalid.</p>
|
||||
<p><strong>Security & Cost</strong></p>
|
||||
<dl class="simple">
|
||||
<dt><code class="docutils literal notranslate"><span class="pre">discovery_stamp_value</span></code></dt><dd><p>Defines the proof-of-work difficulty for the cryptographic stamp included in the announce. This value acts as a cost barrier to prevent network flooding. The default value is <code class="docutils literal notranslate"><span class="pre">14</span></code>. Increasing this value makes it computationally more expensive to generate an announce, which can be useful to prevent spam on very large networks, but it also increases CPU load on your system when generating announces. Stamps are cached, and only generated if interface information changes, or at instance restart. If you have the computational resources, it is generally advisable to use as high a stamp value as possible.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
<p><strong>Privacy & Encryption</strong></p>
|
||||
<dl class="simple">
|
||||
<dt><code class="docutils literal notranslate"><span class="pre">discovery_encrypt</span></code></dt><dd><p>If set to <code class="docutils literal notranslate"><span class="pre">yes</span></code>, the discovery announce payload will be encrypted. To decrypt the announce, remote peers must possess the <em>network identity</em> configured for your instance (see <code class="docutils literal notranslate"><span class="pre">network_identity</span></code> in the <code class="docutils literal notranslate"><span class="pre">[reticulum]</span></code> section). This allows you to publish private interfaces that are only discoverable to specific trusted networks.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
<div class="admonition important">
|
||||
<p class="admonition-title">Important</p>
|
||||
<p>If you enable <code class="docutils literal notranslate"><span class="pre">discovery_encrypt</span></code> but do not configure a valid <code class="docutils literal notranslate"><span class="pre">network_identity</span></code> in the <code class="docutils literal notranslate"><span class="pre">[reticulum]</span></code> section of your configuration, Reticulum will abort the interface discovery announce. Encryption requires a valid network identity key to function.</p>
|
||||
</div>
|
||||
<dl class="simple">
|
||||
<dt><code class="docutils literal notranslate"><span class="pre">publish_ifac</span></code></dt><dd><p>If set to <code class="docutils literal notranslate"><span class="pre">yes</span></code>, the Interface Access Code (IFAC) name and passphrase for this interface will be included in the discovery announce. This allows peers to automatically configure the correct authentication parameters when connecting to the interface.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
<p><strong>Physical Location</strong></p>
|
||||
<dl class="simple">
|
||||
<dt><code class="docutils literal notranslate"><span class="pre">latitude</span></code>, <code class="docutils literal notranslate"><span class="pre">longitude</span></code>, <code class="docutils literal notranslate"><span class="pre">height</span></code></dt><dd><p>Optional physical coordinates for the interface. These are useful for mapping discovered interfaces geographically or for clients to automatically select the nearest access point. Coordinates should be in decimal degrees, height in meters.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
<p><strong>Radio Parameters</strong></p>
|
||||
<p>For physical radio interfaces like <code class="docutils literal notranslate"><span class="pre">RNodeInterface</span></code> or <code class="docutils literal notranslate"><span class="pre">KISSInterface</span></code>, the following optional parameters allow you to broadcast the operating frequency and characteristics, allowing clients to verify compatibility before connecting:</p>
|
||||
<dl class="simple">
|
||||
<dt><code class="docutils literal notranslate"><span class="pre">discovery_frequency</span></code></dt><dd><p>The operating frequency in Hz. Auto-configured on RNode interfaces. Necessary on KISS-based radio interfaces and <code class="docutils literal notranslate"><span class="pre">TCPClientInterfaces</span></code> connecting to radio modems.</p>
|
||||
</dd>
|
||||
<dt><code class="docutils literal notranslate"><span class="pre">discovery_bandwidth</span></code></dt><dd><p>The signal bandwidth in Hz. Auto-configured on RNode interfaces. Useful on KISS-based radio interfaces and <code class="docutils literal notranslate"><span class="pre">TCPClientInterfaces</span></code> connecting to radio modems.</p>
|
||||
</dd>
|
||||
<dt><code class="docutils literal notranslate"><span class="pre">discovery_modulation</span></code></dt><dd><p>The modulation type or scheme. Auto-configured on RNode interfaces, but highly advisable to include on other radio-based interfaces.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="interface-modes">
|
||||
<h3>Interface Modes<a class="headerlink" href="#interface-modes" title="Link to this heading">¶</a></h3>
|
||||
<p>When you enable discovery on an interface, Reticulum enforces certain interface modes to ensure the interface is actually useful for remote peers.</p>
|
||||
<p>If an interface is configured as <code class="docutils literal notranslate"><span class="pre">discoverable</span></code>, but its mode is not explicitly set to <code class="docutils literal notranslate"><span class="pre">gateway</span></code> (for server-style interfaces like <code class="docutils literal notranslate"><span class="pre">BackboneInterface</span></code> or <code class="docutils literal notranslate"><span class="pre">TCPServerInterface</span></code>) or <code class="docutils literal notranslate"><span class="pre">access_point</span></code> (for radio interfaces like <code class="docutils literal notranslate"><span class="pre">RNodeInterface</span></code>), Reticulum will automatically configure the appropriate mode and log a notice.</p>
|
||||
<p>For example, if you enable discovery on a <code class="docutils literal notranslate"><span class="pre">RNodeInterface</span></code> without specifying the mode, Reticulum will automatically set it to <code class="docutils literal notranslate"><span class="pre">access_point</span></code> mode.</p>
|
||||
</section>
|
||||
<section id="security-considerations">
|
||||
<h3>Security Considerations<a class="headerlink" href="#security-considerations" title="Link to this heading">¶</a></h3>
|
||||
<p>When making interfaces discoverable, you are effectively broadcasting an invitation to connect to your system. It is important to understand the security implications of the configuration options you choose.</p>
|
||||
<p><strong>Publishing Credentials</strong></p>
|
||||
<p>If you enable <code class="docutils literal notranslate"><span class="pre">publish_ifac</span> <span class="pre">=</span> <span class="pre">yes</span></code>, your interface’s authentication passphrase will be included in the announce. If you are operating a public network and want anyone to connect, this is acceptable. However, if you wish to restrict access to a specific group of users, you <strong>must</strong> enable <code class="docutils literal notranslate"><span class="pre">discovery_encrypt</span> <span class="pre">=</span> <span class="pre">yes</span></code>. This ensures that only peers possessing the correct <code class="docutils literal notranslate"><span class="pre">network_identity</span></code> can decode the passphrase.</p>
|
||||
<p><strong>Topology Exposure</strong></p>
|
||||
<p>A discoverable interface announces its presence, location (if configured), and capabilities to the network. Even if the connection details are encrypted, the <em>fact</em> that a connectable node exists within a certain network becomes public information. In high-security or scenarios requiring operational secrecy, consider the implications of advertising your infrastructure’s existence.</p>
|
||||
</section>
|
||||
<section id="example-configuration">
|
||||
<h3>Example Configuration<a class="headerlink" href="#example-configuration" title="Link to this heading">¶</a></h3>
|
||||
<p>Below is an example configuration for a public backbone gateway. This configuration publishes a high-value, publicly discoverable interface, that anyone can connect to.</p>
|
||||
<div class="highlight-ini notranslate"><div class="highlight"><pre><span></span><span class="k">[[My Public Gateway]]</span>
|
||||
<span class="w"> </span><span class="na">type</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">BackboneInterface</span>
|
||||
<span class="w"> </span><span class="na">mode</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">gateway</span>
|
||||
<span class="w"> </span><span class="na">listen_on</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">0.0.0.0</span>
|
||||
<span class="w"> </span><span class="na">port</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">4242</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># Enable Discovery</span>
|
||||
<span class="w"> </span><span class="na">discoverable</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">yes</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># Interface Details</span>
|
||||
<span class="w"> </span><span class="na">discovery_name</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">Region A Public Entrypoint</span>
|
||||
<span class="w"> </span><span class="na">announce_interval</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">720</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># Use external script to resolve dynamic IP</span>
|
||||
<span class="w"> </span><span class="na">reachable_on</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">/usr/local/bin/get_external_ip.sh</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># Generate high stamp value</span>
|
||||
<span class="w"> </span><span class="na">discovery_stamp_value</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">24</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># Optional location data</span>
|
||||
<span class="w"> </span><span class="na">latitude</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">51.99714</span>
|
||||
<span class="w"> </span><span class="na">longitude</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">-0.74195</span>
|
||||
<span class="w"> </span><span class="na">height</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">15</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>The next example create an encrypted discovery-enabled interface, requiring a specific network identity to decode, and includes IFAC credentials for seamless authentication.</p>
|
||||
<div class="highlight-ini notranslate"><div class="highlight"><pre><span></span><span class="k">[[My Private Gateway]]</span>
|
||||
<span class="w"> </span><span class="na">type</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">BackboneInterface</span>
|
||||
<span class="w"> </span><span class="na">mode</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">gateway</span>
|
||||
<span class="w"> </span><span class="na">listen_on</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">0.0.0.0</span>
|
||||
<span class="w"> </span><span class="na">port</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">5858</span>
|
||||
<span class="w"> </span><span class="na">network_name</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">internal_1</span>
|
||||
<span class="w"> </span><span class="na">passphrase</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">Mevpekyafshak5Wr</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># Enable Discovery</span>
|
||||
<span class="w"> </span><span class="na">discoverable</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">yes</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># Interface Details</span>
|
||||
<span class="w"> </span><span class="na">discovery_name</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">Region A Private Backbone</span>
|
||||
<span class="w"> </span><span class="na">announce_interval</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">720</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># Use external script to resolve dynamic IP</span>
|
||||
<span class="w"> </span><span class="na">reachable_on</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">/usr/local/bin/get_external_ip.sh</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># Target stamp value</span>
|
||||
<span class="w"> </span><span class="na">discovery_stamp_value</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">22</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># Encrypt announces for our network only</span>
|
||||
<span class="w"> </span><span class="na">discovery_encrypt</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">yes</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># Include credentials so trusted</span>
|
||||
<span class="w"> </span><span class="c1"># peers can connect automatically</span>
|
||||
<span class="w"> </span><span class="na">publish_ifac</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">yes</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># Optional location data</span>
|
||||
<span class="w"> </span><span class="na">latitude</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">34.06915</span>
|
||||
<span class="w"> </span><span class="na">longitude</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">-118.44318</span>
|
||||
<span class="w"> </span><span class="na">height</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">15</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>In the <code class="docutils literal notranslate"><span class="pre">[reticulum]</span></code> section of your configuration, you would define the network identity used for encryption as follows:</p>
|
||||
<div class="highlight-ini notranslate"><div class="highlight"><pre><span></span><span class="k">[reticulum]</span>
|
||||
<span class="na">...</span>
|
||||
<span class="c1"># The identity used to sign/encrypt discovery announces</span>
|
||||
<span class="na">network_identity</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">~/.reticulum/storage/identities/my_network_identity</span>
|
||||
<span class="na">...</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>With these configuration options applied, your Reticulum instance will actively participate in the network’s discovery ecosystem. Other peers running Reticulum with discovery enabled will be able to see your interface, validate its cryptographic stamp, and (depending on their configuration) automatically connect to it.</p>
|
||||
<p>For information on how to use these discovered interfaces and configure your system to auto-connect to them, refer to the <a class="reference internal" href="using.html#using-interface-discovery"><span class="std std-ref">Discovering Interfaces</span></a> chapter.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="common-interface-options">
|
||||
<span id="interfaces-options"></span><h2>Common Interface Options<a class="headerlink" href="#common-interface-options" title="Link to this heading">¶</a></h2>
|
||||
<p>A number of general configuration options are available on most interfaces.
|
||||
@@ -1166,11 +1345,22 @@ sufficient, but it can be configured by using the <code class="docutils literal
|
||||
option, to set the interface speed in <em>bits per second</em>.</div>
|
||||
</div>
|
||||
</li>
|
||||
<li><div class="line-block">
|
||||
<div class="line">The <code class="docutils literal notranslate"><span class="pre">bootstrap_only</span></code> option designates an interface as a temporary
|
||||
bridge for initial connectivity. If this option is enabled, the
|
||||
interface will be monitored and automatically detached once the
|
||||
number of auto-connected interfaces reaches the limit configured by
|
||||
<code class="docutils literal notranslate"><span class="pre">autoconnect_discovered_interfaces</span></code>. This is particularly useful
|
||||
for using a slow or expensive connection (such as a single LoRa
|
||||
link or a remote TCP tunnel) solely to discover better local
|
||||
infrastructure, which then supersedes the bootstrap interface.</div>
|
||||
</div>
|
||||
</li>
|
||||
</ul>
|
||||
</div></blockquote>
|
||||
</section>
|
||||
<section id="interface-modes">
|
||||
<span id="interfaces-modes"></span><h2>Interface Modes<a class="headerlink" href="#interface-modes" title="Link to this heading">¶</a></h2>
|
||||
<section id="interfaces-modes">
|
||||
<span id="id4"></span><h2>Interface Modes<a class="headerlink" href="#interfaces-modes" title="Link to this heading">¶</a></h2>
|
||||
<p>The optional <code class="docutils literal notranslate"><span class="pre">mode</span></code> setting is available on all interfaces, and allows
|
||||
selecting the high-level behaviour of the interface from a number of modes.
|
||||
These modes affect how Reticulum selects paths in the network, how announces
|
||||
@@ -1468,8 +1658,16 @@ to <code class="docutils literal notranslate"><span class="pre">30</span></code>
|
||||
<li><a class="reference internal" href="#pipe-interface">Pipe Interface</a></li>
|
||||
<li><a class="reference internal" href="#kiss-interface">KISS Interface</a></li>
|
||||
<li><a class="reference internal" href="#ax-25-kiss-interface">AX.25 KISS Interface</a></li>
|
||||
<li><a class="reference internal" href="#common-interface-options">Common Interface Options</a></li>
|
||||
<li><a class="reference internal" href="#discoverable-interfaces">Discoverable Interfaces</a><ul>
|
||||
<li><a class="reference internal" href="#enabling-discovery">Enabling Discovery</a></li>
|
||||
<li><a class="reference internal" href="#discovery-parameters">Discovery Parameters</a></li>
|
||||
<li><a class="reference internal" href="#interface-modes">Interface Modes</a></li>
|
||||
<li><a class="reference internal" href="#security-considerations">Security Considerations</a></li>
|
||||
<li><a class="reference internal" href="#example-configuration">Example Configuration</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#common-interface-options">Common Interface Options</a></li>
|
||||
<li><a class="reference internal" href="#interfaces-modes">Interface Modes</a></li>
|
||||
<li><a class="reference internal" href="#announce-rate-control">Announce Rate Control</a></li>
|
||||
<li><a class="reference internal" href="#new-destination-rate-limiting">New Destination Rate Limiting</a></li>
|
||||
</ul>
|
||||
@@ -1483,7 +1681,7 @@ to <code class="docutils literal notranslate"><span class="pre">30</span></code>
|
||||
|
||||
</aside>
|
||||
</div>
|
||||
</div><script src="_static/documentation_options.js?v=baaebd52"></script>
|
||||
</div><script src="_static/documentation_options.js?v=58fbf978"></script>
|
||||
<script src="_static/doctools.js?v=9bcbadda"></script>
|
||||
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
|
||||
<script src="_static/scripts/furo.js?v=46bd48cc"></script>
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
<link rel="prefetch" href="_static/rns_logo_512.png" as="image">
|
||||
|
||||
<!-- Generated with Sphinx 8.2.3 and Furo 2025.09.25.dev1 -->
|
||||
<title>Building Networks - Reticulum Network Stack 1.0.3 documentation</title>
|
||||
<title>Building Networks - Reticulum Network Stack 1.1.1 documentation</title>
|
||||
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=d111a655" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/styles/furo.css?v=580074bf" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/copybutton.css?v=76b2166b" />
|
||||
@@ -180,7 +180,7 @@
|
||||
</label>
|
||||
</div>
|
||||
<div class="header-center">
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.0.3 documentation</div></a>
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.1.1 documentation</div></a>
|
||||
</div>
|
||||
<div class="header-right">
|
||||
<div class="theme-toggle-container theme-toggle-header">
|
||||
@@ -204,7 +204,7 @@
|
||||
<img class="sidebar-logo" src="_static/rns_logo_512.png" alt="Logo"/>
|
||||
</div>
|
||||
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.0.3 documentation</span>
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.1.1 documentation</span>
|
||||
|
||||
</a><form class="sidebar-search-container" method="get" action="search.html" role="search">
|
||||
<input class="sidebar-search" placeholder="Search" name="q" aria-label="Search">
|
||||
@@ -259,15 +259,39 @@
|
||||
<article role="main" id="furo-main-content">
|
||||
<section id="building-networks">
|
||||
<span id="networks-main"></span><h1>Building Networks<a class="headerlink" href="#building-networks" title="Link to this heading">¶</a></h1>
|
||||
<p>This chapter will provide you with the knowledge needed to build networks with
|
||||
Reticulum, which can often be easier than using traditional stacks, since you
|
||||
don’t have to worry about coordinating addresses, subnets and routing for an
|
||||
<p>This chapter will provide you with the high-level knowledge needed to build networks with
|
||||
Reticulum. It will not, however tell you all you need to know to succesfully
|
||||
design and configure every kind of network you can imagine. For this, you will
|
||||
most likely need to read this manual in its entirity, invest significant time
|
||||
into experimenting with the stack, and learning functionality intuitively.</p>
|
||||
<p>Still, after reading this chapter, you should be well equipped to <em>start</em> that
|
||||
journey. While Reticulum is <strong>fundamentally different</strong> compared to other
|
||||
networking technologies, it can often be easier than using traditional stacks.
|
||||
If you’ve built networks before, you will probably have to forget, or at least
|
||||
temporarily ignore, a lot of things at this point. It will all makes sense in
|
||||
the end though. Hopefully.</p>
|
||||
<p>If you’re used to protocols like IP, let’s at least start with some relief:
|
||||
You don’t have to worry about coordinating addresses, subnets and routing for an
|
||||
entire network that you might not know how will evolve in the future. With
|
||||
Reticulum, you can simply add more segments to your network when it becomes
|
||||
necessary, and Reticulum will handle the convergence of the entire network
|
||||
automatically.</p>
|
||||
automatically. There’s plenty more neat aspects like that to Reticulum, but
|
||||
we’re getting ahead of ourselves. Let’s cover the basics first.</p>
|
||||
<section id="concepts-overview">
|
||||
<h2>Concepts & Overview<a class="headerlink" href="#concepts-overview" title="Link to this heading">¶</a></h2>
|
||||
<p>Before you start building your own networks, it’s important to understand the
|
||||
fundamental principles that distinguish Reticulum networks from traditional
|
||||
networking approaches. These principles shape how you design your network,
|
||||
what trade-offs you encounter, and what capabilities you can rely on.</p>
|
||||
<p>Reticulum is not a single network you “join”, it is a toolkit for <em>creating</em> networks.
|
||||
You decide what mediums to use, how nodes connect, what trust boundaries exist,
|
||||
and what the network’s purpose is. Reticulum provides the cryptographic foundation,
|
||||
the transport mechanisms, and the convergence algorithms that make your design
|
||||
workable. You provide the intent and the structure.</p>
|
||||
<p>This approach offers tremendous flexibility, but it requires thinking in terms of
|
||||
different abstractions than those used in conventional networking.</p>
|
||||
<section id="introductory-considerations">
|
||||
<h3>Introductory Considerations<a class="headerlink" href="#introductory-considerations" title="Link to this heading">¶</a></h3>
|
||||
<p>There are important points that need to be kept in mind when building networks
|
||||
with Reticulum:</p>
|
||||
<blockquote>
|
||||
@@ -289,7 +313,12 @@ also very useful when just a few devices needs to communicate.</div>
|
||||
<div class="line">Low-bandwidth networks, like LoRa and packet radio, can interoperate and
|
||||
interconnect with much larger and higher bandwidth networks without issue.
|
||||
Reticulum automatically manages the flow of information to and from various
|
||||
network segments, and when bandwidth is limited, local traffic is prioritised.</div>
|
||||
network segments, and when bandwidth is limited, local traffic is prioritised.
|
||||
You will, however, need to configure your interfaces correctly. If you tell
|
||||
Reticulum to pass all announce traffic from a gigabit link to a LoRa interfaces,
|
||||
it will try as best as possible to comply with this, while still respecting
|
||||
bandwidth limits, but you <em>will</em> waste a lot of precious bandwidth and airtime,
|
||||
and your LoRa network will not work very well.</div>
|
||||
</div>
|
||||
</li>
|
||||
<li><div class="line-block">
|
||||
@@ -361,69 +390,197 @@ chapter of this manual for interface configuration examples.</p>
|
||||
decide which are suitable to use in any given situation, depending on where
|
||||
traffic needs to flow.</p>
|
||||
</section>
|
||||
<section id="example-scenarios">
|
||||
<h2>Example Scenarios<a class="headerlink" href="#example-scenarios" title="Link to this heading">¶</a></h2>
|
||||
<p>This section illustrates a few example scenarios, and how they would, in general
|
||||
terms, be planned, implemented and configured.</p>
|
||||
<section id="interconnected-lora-sites">
|
||||
<h3>Interconnected LoRa Sites<a class="headerlink" href="#interconnected-lora-sites" title="Link to this heading">¶</a></h3>
|
||||
<p>An organisation wants to provide communication and information services to it’s
|
||||
members, which are located mainly in three separate areas. Three suitable hill-top
|
||||
locations are found, where the organisation can install equipment: Site A, B and C.</p>
|
||||
<p>Since the amount of data that needs to be exchanged between users is mainly text-
|
||||
based, the bandwidth requirements are low, and LoRa radios are chosen to connect
|
||||
users to the network.</p>
|
||||
<p>Due to the hill-top locations found, there is radio line-of-sight between site A
|
||||
and B, and also between site B and C. Because of this, the organisation does not
|
||||
need to use the Internet to interconnect the sites, but purchases four Point-to-Point
|
||||
WiFi based radios for interconnecting the sites.</p>
|
||||
<p>At each site, a Raspberry Pi is installed to function as a gateway. A LoRa radio
|
||||
is connected to the Pi with a USB cable, and the WiFi radio is connected to the
|
||||
Ethernet port of the Pi. At site B, two WiFi radios are needed to be able to reach
|
||||
both site A and site C, so an extra Ethernet adapter is connected to the Pi in
|
||||
this location.</p>
|
||||
<p>Once the hardware has been installed, Reticulum is installed on all the Pis, and at
|
||||
site A and C, one interface is added for the LoRa radio, as well as one for the WiFi
|
||||
radio. At site B, an interface for the LoRa radio, and one interface for each WiFi
|
||||
radio is added to the Reticulum configuration file. The transport node option is
|
||||
enabled in the configuration of all three gateways.</p>
|
||||
<p>The network is now operational, and ready to serve users across all three areas.
|
||||
The organisation prepares a LoRa radio that is supplied to the end users, along
|
||||
with a Reticulum configuration file, that contains the right parameters for
|
||||
communicating with the LoRa radios installed at the gateway sites.</p>
|
||||
<p>Once users connect to the network, anyone will be able to communicate with anyone
|
||||
else across all three sites.</p>
|
||||
<section id="destinations-not-addresses">
|
||||
<h3>Destinations, Not Addresses<a class="headerlink" href="#destinations-not-addresses" title="Link to this heading">¶</a></h3>
|
||||
<p>In traditional networking, addresses are allocated from a managed space. If you want to
|
||||
communicate with another node, you need to know its address, and that address
|
||||
must be unique within the network segment. This requires coordination, either
|
||||
through manual assignment, DHCP servers, or other allocation mechanisms.</p>
|
||||
<p>Reticulum replaces addresses with <strong>destinations</strong>. A destination is identified by a 16-byte
|
||||
hash (128 bits) derived from a SHA-256 hash of the destination’s identifying
|
||||
characteristics. This hash serves as the address on the network. On the network, it
|
||||
is represented in binary, but when displayed to human users, it will usually look something like
|
||||
this <code class="docutils literal notranslate"><span class="pre"><13425ec15b621c1d928589718000d814></span></code>.</p>
|
||||
<p>The critical difference is that <em>any node can generate as many destinations as it
|
||||
needs, without coordination</em>. A destination’s uniqueness is guaranteed by the
|
||||
collision resistance of SHA-256 and the inclusion of the node’s public key in the
|
||||
hash calculation. Two nodes can both use the destination name
|
||||
<code class="docutils literal notranslate"><span class="pre">messenger.user.inbox</span></code>, but they will have different destination hashes because
|
||||
their public keys differ. Both can coexist on the same network without conflict.</p>
|
||||
<p>This has profound implications for network design:</p>
|
||||
<ul class="simple">
|
||||
<li><p><strong>No address allocation planning:</strong> You never need to reserve address ranges,
|
||||
plan subnets, or coordinate with other network operators. Nodes simply generate
|
||||
destinations and announce them.</p></li>
|
||||
<li><p><strong>Global portability:</strong> A destination is not tied to a physical location or
|
||||
network segment. A node can move its destinations across interfaces, mediums,
|
||||
or even between entirely separate Reticulum networks simply by sending an
|
||||
announce on the new medium.</p></li>
|
||||
<li><p><strong>Implicit authentication:</strong> Because destinations are bound to public keys,
|
||||
communication to a destination is inherently cryptographically authenticated.
|
||||
Only the holder of the corresponding private key can decrypt and respond to
|
||||
traffic addressed to that destination. This also makes application-level
|
||||
authentication <em>much</em> simpler, since it can directly use the foundational
|
||||
identity verification built into the core networking layer.</p></li>
|
||||
<li><p><strong>Identity abstraction:</strong> A single Reticulum Identity can create multiple
|
||||
destinations. This allows a single entity (a person, a device, a service) to
|
||||
present multiple endpoints without needing multiple cryptographic keypairs.</p></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="bridging-over-the-internet">
|
||||
<h3>Bridging Over the Internet<a class="headerlink" href="#bridging-over-the-internet" title="Link to this heading">¶</a></h3>
|
||||
<p>As the organisation grows, several new communities form in places too far away
|
||||
from the core network to be reachable over WiFi links. New gateways similar to those
|
||||
previously installed are set up for the new communities at the new sites D and E, but
|
||||
they are islanded from the core network, and only serve the local users.</p>
|
||||
<p>After investigating the options, it is found that it is possible to install an
|
||||
Internet connection at site A, and an interface on the Internet connection is
|
||||
configured for Reticulum on the Raspberry Pi at site A.</p>
|
||||
<p>A member of the organisation at site D, named Dori, is willing to help by sharing
|
||||
the Internet connection she already has in her home, and is able to leave a Raspberry
|
||||
Pi running. A new Reticulum interface is configured on her Pi, connecting to the newly
|
||||
enabled Internet interface on the gateway at site A. Dori is now connected to both
|
||||
the nodes at her own local site (through the hill-top LoRa gateway), and all the
|
||||
combined users of sites A, B and C. She then enables transport on her node, and
|
||||
traffic from site D can now reach everyone at site A, B and C, and vice versa.</p>
|
||||
<section id="transport-nodes-and-instances">
|
||||
<h3>Transport Nodes and Instances<a class="headerlink" href="#transport-nodes-and-instances" title="Link to this heading">¶</a></h3>
|
||||
<p>Reticulum distinguishes between two types of nodes: <strong>Instances</strong>
|
||||
and <strong>Transport Nodes</strong>. Every node running Reticulum is an Instance, but not
|
||||
every Instance is a Transport Node.</p>
|
||||
<p>A <strong>Reticulum Instance</strong> is any system running the Reticulum stack. It can create
|
||||
destinations, send and receive packets, establish links, and communicate with
|
||||
other nodes. It can also host destinations that are connectable for <em>anyone</em> else
|
||||
in the network. This means you can easily host globally available services from
|
||||
any location, including your home or office. Network-wide, global connectivity
|
||||
for all destinations is guaranteed, as long as there is <em>some</em> physical way to
|
||||
actually transport the packets. Instances are the default state and are appropriate for most end-user devices,
|
||||
such as phones, laptops, sensors, or any device that primarily consumes network services.</p>
|
||||
<p>A <strong>Transport Node</strong> is an Instance that has been explicitly configured to
|
||||
participate in network-wide transport. Transport nodes forward packets across
|
||||
hops, propagate announces, maintain path tables, and serve path requests on
|
||||
behalf of other nodes. When a destination sends an announce, Transport Nodes
|
||||
receive it, remember the path, and rebroadcast it to other interfaces. When a node
|
||||
needs to reach a destination it doesn’t have a path for, Transport Nodes help
|
||||
resolve the path through the network.</p>
|
||||
<p>Even devices hosting services or serving content should probably just be configured
|
||||
as instances, and themselves connect to wider networks via a Transport Node.
|
||||
In some situations, this may not be practical though, and as an example, it is
|
||||
entirely viable to host a personal Transport Node on a Raspberry Pi, while it
|
||||
is at the same time running an LXMF propagation node, and hosting your personal
|
||||
site or files over Reticulum.</p>
|
||||
<p>The distinction is important. <strong>Not</strong> every node should be a Transport Node:</p>
|
||||
<ul class="simple">
|
||||
<li><p><strong>Resource consumption:</strong> Transport nodes maintain path tables, process
|
||||
announces, and forward traffic. This requires memory and CPU resources that
|
||||
may be limited on low-powered devices.</p></li>
|
||||
<li><p><strong>Stability requirements:</strong> Transport nodes contribute to network convergence.
|
||||
If Transport Nodes frequently go offline, path tables become stale and
|
||||
convergence suffers. Stable, always-on nodes make better Transport Nodes.</p></li>
|
||||
<li><p><strong>Bandwidth considerations:</strong> Transport nodes process and rebroadcast network
|
||||
maintenance traffic. On very low-bandwidth mediums, having too many Transport
|
||||
Nodes will consume capacity that should be used for actual data.</p></li>
|
||||
</ul>
|
||||
<p>In practice, a network typically has a relatively small number of Transport Nodes
|
||||
strategically placed to provide coverage and connectivity. End-user devices run
|
||||
as Instances, connecting through nearby Transport Nodes to reach the wider network.
|
||||
This pattern mirrors traditional networking where routers forward traffic while
|
||||
end hosts simply consume connectivity, but with the crucial difference that any
|
||||
node <em>can</em> become a router if needed, and the decision is yours to make based on
|
||||
your network’s requirements.</p>
|
||||
<p>Transport nodes also function as distributed cryptographic keystores. When a
|
||||
destination announces itself, Transport Nodes cache the public key and destination
|
||||
information. Other nodes can request unknown public keys from the network, and
|
||||
Transport Nodes respond with the cached information. This eliminates the need for
|
||||
a central directory service while ensuring that public keys remain available
|
||||
throughout the network.</p>
|
||||
</section>
|
||||
<section id="growth-and-convergence">
|
||||
<h3>Growth and Convergence<a class="headerlink" href="#growth-and-convergence" title="Link to this heading">¶</a></h3>
|
||||
<p>As the organisation grows, more gateways are added to keep up with the growing user
|
||||
base. Some local gateways even add VHF radios and packet modems to reach outlying users
|
||||
and communities that are out of reach for the LoRa radios and WiFi backhauls.</p>
|
||||
<p>As more sites, gateways and users are connected, the amount of coordination required
|
||||
is kept to a minimum. If one community wants to add connectivity to the next one
|
||||
over, it can simply be done without having to involve everyone or coordinate address
|
||||
space or routing tables.</p>
|
||||
<p>With the added geographical coverage, the operators at site A one day find that
|
||||
the original internet bridged interfaces are no longer utilised. The network has
|
||||
converged to be completely self-connected, and the sites that were once poorly
|
||||
connected outliers are now an integral part of the network.</p>
|
||||
<section id="trustless-networking">
|
||||
<h3>Trustless Networking<a class="headerlink" href="#trustless-networking" title="Link to this heading">¶</a></h3>
|
||||
<p>Traditional network security models assume high levels of trust at
|
||||
specific layers. You might trust your ISP to deliver packets without inspection,
|
||||
or trust your VPN provider to handle your traffic, or trust the network
|
||||
administrator to configure firewalls appropriately. These trust relationships
|
||||
create vulnerabilities and dependencies.</p>
|
||||
<p>Reticulum is designed to function in <strong>open, trustless environments</strong>. This
|
||||
means the protocol makes no assumptions about the trustworthiness of the network
|
||||
infrastructure, the other participants, or the transport mediums. Every aspect
|
||||
of communication is secured cryptographically:</p>
|
||||
<ul class="simple">
|
||||
<li><p><strong>Traffic encryption:</strong> All traffic to single destinations is encrypted using
|
||||
ephemeral keys.</p></li>
|
||||
<li><p><strong>Source anonymity:</strong> Reticulum packets do not include source addresses.
|
||||
An observer intercepting a packet cannot determine who sent it, only who it is
|
||||
addressed to (unless IFAC is enabled, in which case nothing can be determined).
|
||||
This provides initiator anonymity by default.</p></li>
|
||||
<li><p><strong>Path verification:</strong> The announce mechanism includes cryptographic signatures that
|
||||
prove the authenticity of destination announcements.</p></li>
|
||||
<li><p><strong>Unforgeable delivery confirmations:</strong> When a destination proves receipt of a
|
||||
packet, the proof is signed with the destination’s identity key. This prevents
|
||||
false acknowledgments and ensures reliable delivery verification.</p></li>
|
||||
<li><p><strong>Interface authentication:</strong> When using Interface Access Codes (IFAC), packets
|
||||
on authenticated interfaces carry signatures derived from a shared secret. Only
|
||||
nodes with the correct network name and passphrase can generate valid packets, allowing creation
|
||||
of virtual private networks on shared mediums.</p></li>
|
||||
</ul>
|
||||
<p>The trustless design has important consequences for network design:</p>
|
||||
<ul class="simple">
|
||||
<li><p><strong>Open-access networks are viable:</strong> You can build networks that anyone can
|
||||
join without pre-approval. Because traffic is encrypted and authenticated end-
|
||||
to-end, participants cannot interfere with each other’s private communication,
|
||||
even if they share the same transport infrastructure.</p></li>
|
||||
<li><p><strong>No traffic inspection or prioritization:</strong> Because traffic contents and
|
||||
sources are opaque to intermediate nodes, there is no mechanism for filtering,
|
||||
prioritizing, or throttling traffic based on its type or origin. All traffic
|
||||
is treated equally. From a neutrality perspective, this is a feature.</p></li>
|
||||
<li><p><strong>Adversarial resilience:</strong> The network can operate even if some nodes are
|
||||
malicious or controlled by adversaries. While a malicious Transport Node could
|
||||
refuse to forward certain traffic or drop packets, it cannot decrypt, modify,
|
||||
or impersonate legitimate traffic. Redundant paths and multiple Transport Nodes
|
||||
mitigate the impact of malicious nodes.</p></li>
|
||||
</ul>
|
||||
<p>Of course, you can also create closed networks. Interface Access
|
||||
Codes allow you to restrict participation on specific interfaces. Network
|
||||
Identities enable you to verify that discovered interfaces belong to trusted
|
||||
operators. Blackhole management lets you block malicious identities. Reticulum
|
||||
provides both the tools for open networks and the controls for closed ones. The
|
||||
choice is yours based on your requirements.</p>
|
||||
</section>
|
||||
<section id="heterogeneous-connectivity">
|
||||
<h3>Heterogeneous Connectivity<a class="headerlink" href="#heterogeneous-connectivity" title="Link to this heading">¶</a></h3>
|
||||
<p>In conventional networking, mixing different transport mediums typically requires
|
||||
gateways, translation layers, and careful configuration. A WiFi network doesn’t
|
||||
natively interoperate with a packet radio network without additional infrastructure,
|
||||
and you can’t just download a car over a serial port, or send an encrypted message
|
||||
in a QR code.</p>
|
||||
<p>Reticulum treats <strong>heterogeneity as a core premise</strong>. The protocol is designed
|
||||
to seamlessly mix mediums with vastly different characteristics:</p>
|
||||
<ul class="simple">
|
||||
<li><p><strong>Bandwidth:</strong> LoRa links operating at a few hundred bits per second can
|
||||
interconnect with gigabit Ethernet backbones. Reticulum automatically manages
|
||||
the flow of information, prioritizing local traffic on slow segments while
|
||||
allowing global convergence.</p></li>
|
||||
<li><p><strong>Latency:</strong> Satellite links with multi-second latency can coexist with local
|
||||
links measured in milliseconds. The transport system handles timing, asynchronous
|
||||
delivery and retransmissions transparently.</p></li>
|
||||
<li><p><strong>Topology:</strong> Point-to-point microwave links, broadcast radio networks,
|
||||
switched Ethernet fabrics, and virtual tunnels over the Internet can all be
|
||||
part of the same Reticulum network.</p></li>
|
||||
<li><p><strong>Reliability:</strong> Intermittent connections that come and go (such as mobile
|
||||
devices or opportunistic radio contacts) can participate alongside always-on
|
||||
infrastructure. Reticulum gracefully handles link loss and reconnection.</p></li>
|
||||
</ul>
|
||||
<p>This heterogeneity is achieved through several design elements:</p>
|
||||
<ul class="simple">
|
||||
<li><p><strong>Expandable, medium-agnostic interface system:</strong> Reticulum communicates with the physical
|
||||
world through interface modules. Adding support for a new medium is a matter
|
||||
of implementing an interface class. The protocol itself remains unchanged.</p></li>
|
||||
<li><p><strong>Interface modes:</strong> Different modes (<code class="docutils literal notranslate"><span class="pre">full</span></code>, <code class="docutils literal notranslate"><span class="pre">gateway</span></code>, <code class="docutils literal notranslate"><span class="pre">access_point</span></code>,
|
||||
<code class="docutils literal notranslate"><span class="pre">roaming</span></code>, <code class="docutils literal notranslate"><span class="pre">boundary</span></code>) allow you to configure how interfaces interact with
|
||||
the wider network based on their characteristics and role.</p></li>
|
||||
<li><p><strong>Announce propagation rules:</strong> Announces are forwarded between interfaces
|
||||
according to rules that account for bandwidth limitations and interface modes.
|
||||
Slow segments are not overwhelmed by traffic from fast segments.</p></li>
|
||||
<li><p><strong>Local traffic prioritization:</strong> When bandwidth is constrained, Reticulum
|
||||
prioritizes announces for nearby destinations. This ensures that local
|
||||
connectivity remains functional even when global convergence is incomplete.</p></li>
|
||||
</ul>
|
||||
<p>For network designers, this means you are free to use whatever mediums are
|
||||
available, affordable, or appropriate for your situation. You might use LoRa for
|
||||
wide-area low-bandwidth coverage, WiFi for local high-capacity links, I2P for
|
||||
anonymous Internet connectivity, and Ethernet for infrastructure backhauls, all
|
||||
within the same network. Reticulum handles the translation and coordination
|
||||
automatically.</p>
|
||||
<p>The key design consideration is not whether different mediums can work together
|
||||
(they can), but <strong>how</strong> they should work together based on your goals. A node
|
||||
with multiple interfaces spanning heterogeneous mediums needs to be configured
|
||||
with appropriate interface modes so that traffic flows efficiently. A gateway
|
||||
connecting a slow LoRa segment to a fast Internet backbone should be configured
|
||||
differently than a mobile device roaming between radio cells.</p>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
@@ -483,11 +640,12 @@ connected outliers are now an integral part of the network.</p>
|
||||
<div class="toc-tree">
|
||||
<ul>
|
||||
<li><a class="reference internal" href="#">Building Networks</a><ul>
|
||||
<li><a class="reference internal" href="#concepts-overview">Concepts & Overview</a></li>
|
||||
<li><a class="reference internal" href="#example-scenarios">Example Scenarios</a><ul>
|
||||
<li><a class="reference internal" href="#interconnected-lora-sites">Interconnected LoRa Sites</a></li>
|
||||
<li><a class="reference internal" href="#bridging-over-the-internet">Bridging Over the Internet</a></li>
|
||||
<li><a class="reference internal" href="#growth-and-convergence">Growth and Convergence</a></li>
|
||||
<li><a class="reference internal" href="#concepts-overview">Concepts & Overview</a><ul>
|
||||
<li><a class="reference internal" href="#introductory-considerations">Introductory Considerations</a></li>
|
||||
<li><a class="reference internal" href="#destinations-not-addresses">Destinations, Not Addresses</a></li>
|
||||
<li><a class="reference internal" href="#transport-nodes-and-instances">Transport Nodes and Instances</a></li>
|
||||
<li><a class="reference internal" href="#trustless-networking">Trustless Networking</a></li>
|
||||
<li><a class="reference internal" href="#heterogeneous-connectivity">Heterogeneous Connectivity</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
@@ -501,7 +659,7 @@ connected outliers are now an integral part of the network.</p>
|
||||
|
||||
</aside>
|
||||
</div>
|
||||
</div><script src="_static/documentation_options.js?v=baaebd52"></script>
|
||||
</div><script src="_static/documentation_options.js?v=58fbf978"></script>
|
||||
<script src="_static/doctools.js?v=9bcbadda"></script>
|
||||
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
|
||||
<script src="_static/scripts/furo.js?v=46bd48cc"></script>
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
<link rel="prefetch" href="_static/rns_logo_512.png" as="image">
|
||||
|
||||
<!-- Generated with Sphinx 8.2.3 and Furo 2025.09.25.dev1 -->
|
||||
<title>API Reference - Reticulum Network Stack 1.0.3 documentation</title>
|
||||
<title>API Reference - Reticulum Network Stack 1.1.1 documentation</title>
|
||||
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=d111a655" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/styles/furo.css?v=580074bf" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/copybutton.css?v=76b2166b" />
|
||||
@@ -180,7 +180,7 @@
|
||||
</label>
|
||||
</div>
|
||||
<div class="header-center">
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.0.3 documentation</div></a>
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.1.1 documentation</div></a>
|
||||
</div>
|
||||
<div class="header-right">
|
||||
<div class="theme-toggle-container theme-toggle-header">
|
||||
@@ -204,7 +204,7 @@
|
||||
<img class="sidebar-logo" src="_static/rns_logo_512.png" alt="Logo"/>
|
||||
</div>
|
||||
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.0.3 documentation</span>
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.1.1 documentation</span>
|
||||
|
||||
</a><form class="sidebar-search-container" method="get" action="search.html" role="search">
|
||||
<input class="sidebar-search" placeholder="Search" name="q" aria-label="Search">
|
||||
@@ -395,6 +395,54 @@ can remotely query and manage this instance.</p>
|
||||
</dl>
|
||||
</dd></dl>
|
||||
|
||||
<dl class="py method">
|
||||
<dt class="sig sig-object py" id="RNS.Reticulum.required_discovery_value">
|
||||
<em class="property"><span class="k"><span class="pre">static</span></span><span class="w"> </span></em><span class="sig-name descname"><span class="pre">required_discovery_value</span></span><span class="sig-paren">(</span><span class="sig-paren">)</span><a class="headerlink" href="#RNS.Reticulum.required_discovery_value" title="Link to this definition">¶</a></dt>
|
||||
<dd><p>Returns the required stamp value for a discovered interface
|
||||
to be considered valid and remembered.</p>
|
||||
<dl class="field-list simple">
|
||||
<dt class="field-odd">Returns<span class="colon">:</span></dt>
|
||||
<dd class="field-odd"><p>The required stamp value as an integer.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</dd></dl>
|
||||
|
||||
<dl class="py method">
|
||||
<dt class="sig sig-object py" id="RNS.Reticulum.publish_blackhole_enabled">
|
||||
<em class="property"><span class="k"><span class="pre">static</span></span><span class="w"> </span></em><span class="sig-name descname"><span class="pre">publish_blackhole_enabled</span></span><span class="sig-paren">(</span><span class="sig-paren">)</span><a class="headerlink" href="#RNS.Reticulum.publish_blackhole_enabled" title="Link to this definition">¶</a></dt>
|
||||
<dd><p>Returns whether blackhole list publishing is enabled for the
|
||||
running instance.</p>
|
||||
<dl class="field-list simple">
|
||||
<dt class="field-odd">Returns<span class="colon">:</span></dt>
|
||||
<dd class="field-odd"><p>True if blackhole list publishing is enabled, False if not.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</dd></dl>
|
||||
|
||||
<dl class="py method">
|
||||
<dt class="sig sig-object py" id="RNS.Reticulum.blackhole_sources">
|
||||
<em class="property"><span class="k"><span class="pre">static</span></span><span class="w"> </span></em><span class="sig-name descname"><span class="pre">blackhole_sources</span></span><span class="sig-paren">(</span><span class="sig-paren">)</span><a class="headerlink" href="#RNS.Reticulum.blackhole_sources" title="Link to this definition">¶</a></dt>
|
||||
<dd><p>Returns the list of transport identity hashes from which
|
||||
blackhole lists are sourced.</p>
|
||||
<dl class="field-list simple">
|
||||
<dt class="field-odd">Returns<span class="colon">:</span></dt>
|
||||
<dd class="field-odd"><p>A list of identity hashes.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</dd></dl>
|
||||
|
||||
<dl class="py method">
|
||||
<dt class="sig sig-object py" id="RNS.Reticulum.interface_discovery_sources">
|
||||
<em class="property"><span class="k"><span class="pre">static</span></span><span class="w"> </span></em><span class="sig-name descname"><span class="pre">interface_discovery_sources</span></span><span class="sig-paren">(</span><span class="sig-paren">)</span><a class="headerlink" href="#RNS.Reticulum.interface_discovery_sources" title="Link to this definition">¶</a></dt>
|
||||
<dd><p>Returns the list of network identity hashes from which
|
||||
interfaces are discovered.</p>
|
||||
<dl class="field-list simple">
|
||||
<dt class="field-odd">Returns<span class="colon">:</span></dt>
|
||||
<dd class="field-odd"><p>A list of identity hashes.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</dd></dl>
|
||||
|
||||
</dd></dl>
|
||||
|
||||
<p id="api-identity"><h3> Identity </h3></p>
|
||||
@@ -2125,6 +2173,25 @@ announces. See the <a class="reference internal" href="examples.html#example-ann
|
||||
</dl>
|
||||
</dd></dl>
|
||||
|
||||
<dl class="py method">
|
||||
<dt class="sig sig-object py" id="RNS.Transport.await_path">
|
||||
<em class="property"><span class="k"><span class="pre">static</span></span><span class="w"> </span></em><span class="sig-name descname"><span class="pre">await_path</span></span><span class="sig-paren">(</span><em class="sig-param"><span class="n"><span class="pre">destination_hash</span></span></em>, <em class="sig-param"><span class="n"><span class="pre">timeout</span></span><span class="o"><span class="pre">=</span></span><span class="default_value"><span class="pre">None</span></span></em>, <em class="sig-param"><span class="n"><span class="pre">on_interface</span></span><span class="o"><span class="pre">=</span></span><span class="default_value"><span class="pre">None</span></span></em><span class="sig-paren">)</span><a class="headerlink" href="#RNS.Transport.await_path" title="Link to this definition">¶</a></dt>
|
||||
<dd><p>Requests a path to the destination from the network and
|
||||
blocks until the path is available, or the timeout is reached.</p>
|
||||
<dl class="field-list simple">
|
||||
<dt class="field-odd">Parameters<span class="colon">:</span></dt>
|
||||
<dd class="field-odd"><ul class="simple">
|
||||
<li><p><strong>destination_hash</strong> – A destination hash as <em>bytes</em>.</p></li>
|
||||
<li><p><strong>timeout</strong> – An optional timeout in seconds.</p></li>
|
||||
<li><p><strong>on_interface</strong> – If specified, the path request will only be sent on this interface. In normal use, Reticulum handles this automatically, and this parameter should not be used.</p></li>
|
||||
</ul>
|
||||
</dd>
|
||||
<dt class="field-even">Returns<span class="colon">:</span></dt>
|
||||
<dd class="field-even"><p><em>True</em> if a path to the destination is found, otherwise <em>False</em>.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</dd></dl>
|
||||
|
||||
<dl class="py method">
|
||||
<dt class="sig sig-object py" id="RNS.Transport.request_path">
|
||||
<em class="property"><span class="k"><span class="pre">static</span></span><span class="w"> </span></em><span class="sig-name descname"><span class="pre">request_path</span></span><span class="sig-paren">(</span><em class="sig-param"><span class="n"><span class="pre">destination_hash</span></span></em>, <em class="sig-param"><span class="n"><span class="pre">on_interface</span></span><span class="o"><span class="pre">=</span></span><span class="default_value"><span class="pre">None</span></span></em>, <em class="sig-param"><span class="n"><span class="pre">tag</span></span><span class="o"><span class="pre">=</span></span><span class="default_value"><span class="pre">None</span></span></em>, <em class="sig-param"><span class="n"><span class="pre">recursive</span></span><span class="o"><span class="pre">=</span></span><span class="default_value"><span class="pre">False</span></span></em><span class="sig-paren">)</span><a class="headerlink" href="#RNS.Transport.request_path" title="Link to this definition">¶</a></dt>
|
||||
@@ -2202,6 +2269,10 @@ will announce it.</p>
|
||||
<li><a class="reference internal" href="#RNS.Reticulum.transport_enabled"><code class="docutils literal notranslate"><span class="pre">transport_enabled()</span></code></a></li>
|
||||
<li><a class="reference internal" href="#RNS.Reticulum.link_mtu_discovery"><code class="docutils literal notranslate"><span class="pre">link_mtu_discovery()</span></code></a></li>
|
||||
<li><a class="reference internal" href="#RNS.Reticulum.remote_management_enabled"><code class="docutils literal notranslate"><span class="pre">remote_management_enabled()</span></code></a></li>
|
||||
<li><a class="reference internal" href="#RNS.Reticulum.required_discovery_value"><code class="docutils literal notranslate"><span class="pre">required_discovery_value()</span></code></a></li>
|
||||
<li><a class="reference internal" href="#RNS.Reticulum.publish_blackhole_enabled"><code class="docutils literal notranslate"><span class="pre">publish_blackhole_enabled()</span></code></a></li>
|
||||
<li><a class="reference internal" href="#RNS.Reticulum.blackhole_sources"><code class="docutils literal notranslate"><span class="pre">blackhole_sources()</span></code></a></li>
|
||||
<li><a class="reference internal" href="#RNS.Reticulum.interface_discovery_sources"><code class="docutils literal notranslate"><span class="pre">interface_discovery_sources()</span></code></a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#RNS.Identity"><code class="docutils literal notranslate"><span class="pre">Identity</span></code></a><ul>
|
||||
@@ -2371,6 +2442,7 @@ will announce it.</p>
|
||||
<li><a class="reference internal" href="#RNS.Transport.hops_to"><code class="docutils literal notranslate"><span class="pre">hops_to()</span></code></a></li>
|
||||
<li><a class="reference internal" href="#RNS.Transport.next_hop"><code class="docutils literal notranslate"><span class="pre">next_hop()</span></code></a></li>
|
||||
<li><a class="reference internal" href="#RNS.Transport.next_hop_interface"><code class="docutils literal notranslate"><span class="pre">next_hop_interface()</span></code></a></li>
|
||||
<li><a class="reference internal" href="#RNS.Transport.await_path"><code class="docutils literal notranslate"><span class="pre">await_path()</span></code></a></li>
|
||||
<li><a class="reference internal" href="#RNS.Transport.request_path"><code class="docutils literal notranslate"><span class="pre">request_path()</span></code></a></li>
|
||||
</ul>
|
||||
</li>
|
||||
@@ -2385,7 +2457,7 @@ will announce it.</p>
|
||||
|
||||
</aside>
|
||||
</div>
|
||||
</div><script src="_static/documentation_options.js?v=baaebd52"></script>
|
||||
</div><script src="_static/documentation_options.js?v=58fbf978"></script>
|
||||
<script src="_static/doctools.js?v=9bcbadda"></script>
|
||||
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
|
||||
<script src="_static/scripts/furo.js?v=46bd48cc"></script>
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
|
||||
<!-- Generated with Sphinx 8.2.3 and Furo 2025.09.25.dev1 -->
|
||||
<meta name="robots" content="noindex" />
|
||||
<title>Search - Reticulum Network Stack 1.0.3 documentation</title><link rel="stylesheet" type="text/css" href="_static/pygments.css?v=d111a655" />
|
||||
<title>Search - Reticulum Network Stack 1.1.1 documentation</title><link rel="stylesheet" type="text/css" href="_static/pygments.css?v=d111a655" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/styles/furo.css?v=580074bf" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/copybutton.css?v=76b2166b" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/styles/furo-extensions.css?v=8dab3a3b" />
|
||||
@@ -180,7 +180,7 @@
|
||||
</label>
|
||||
</div>
|
||||
<div class="header-center">
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.0.3 documentation</div></a>
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.1.1 documentation</div></a>
|
||||
</div>
|
||||
<div class="header-right">
|
||||
<div class="theme-toggle-container theme-toggle-header">
|
||||
@@ -204,7 +204,7 @@
|
||||
<img class="sidebar-logo" src="_static/rns_logo_512.png" alt="Logo"/>
|
||||
</div>
|
||||
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.0.3 documentation</span>
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.1.1 documentation</span>
|
||||
|
||||
</a><form class="sidebar-search-container" method="get" action="#" role="search">
|
||||
<input class="sidebar-search" placeholder="Search" name="q" aria-label="Search">
|
||||
@@ -215,6 +215,7 @@
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="whatis.html">What is Reticulum?</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstartedfast.html">Getting Started Fast</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="software.html">Programs Using Reticulum</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="using.html">Using Reticulum on Your System</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="understanding.html">Understanding Reticulum</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="hardware.html">Communications Hardware</a></li>
|
||||
@@ -299,7 +300,7 @@
|
||||
|
||||
</aside>
|
||||
</div>
|
||||
</div><script src="_static/documentation_options.js?v=baaebd52"></script>
|
||||
</div><script src="_static/documentation_options.js?v=58fbf978"></script>
|
||||
<script src="_static/doctools.js?v=9bcbadda"></script>
|
||||
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
|
||||
<script src="_static/scripts/furo.js?v=46bd48cc"></script>
|
||||
|
||||
@@ -0,0 +1,541 @@
|
||||
<!doctype html>
|
||||
<html class="no-js" lang="en" data-content_root="./">
|
||||
<head><meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width,initial-scale=1">
|
||||
<meta name="color-scheme" content="light dark"><meta name="viewport" content="width=device-width, initial-scale=1" />
|
||||
<link rel="index" title="Index" href="genindex.html"><link rel="search" title="Search" href="search.html"><link rel="next" title="Using Reticulum on Your System" href="using.html"><link rel="prev" title="Getting Started Fast" href="gettingstartedfast.html">
|
||||
<link rel="prefetch" href="_static/rns_logo_512.png" as="image">
|
||||
|
||||
<!-- Generated with Sphinx 8.2.3 and Furo 2025.09.25.dev1 -->
|
||||
<title>Programs Using Reticulum - Reticulum Network Stack 1.1.1 documentation</title>
|
||||
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=d111a655" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/styles/furo.css?v=580074bf" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/copybutton.css?v=76b2166b" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/styles/furo-extensions.css?v=8dab3a3b" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/custom.css?v=bb3cebc5" />
|
||||
|
||||
|
||||
|
||||
|
||||
<style>
|
||||
body {
|
||||
--color-code-background: #f2f2f2;
|
||||
--color-code-foreground: #1e1e1e;
|
||||
|
||||
}
|
||||
@media not print {
|
||||
body[data-theme="dark"] {
|
||||
--color-code-background: #202020;
|
||||
--color-code-foreground: #d0d0d0;
|
||||
--color-background-primary: #202b38;
|
||||
--color-background-secondary: #161f27;
|
||||
--color-foreground-primary: #dbdbdb;
|
||||
--color-foreground-secondary: #a9b1ba;
|
||||
--color-brand-primary: #41adff;
|
||||
--color-background-hover: #161f27;
|
||||
--color-api-name: #ffbe85;
|
||||
--color-api-pre-name: #efae75;
|
||||
|
||||
}
|
||||
@media (prefers-color-scheme: dark) {
|
||||
body:not([data-theme="light"]) {
|
||||
--color-code-background: #202020;
|
||||
--color-code-foreground: #d0d0d0;
|
||||
--color-background-primary: #202b38;
|
||||
--color-background-secondary: #161f27;
|
||||
--color-foreground-primary: #dbdbdb;
|
||||
--color-foreground-secondary: #a9b1ba;
|
||||
--color-brand-primary: #41adff;
|
||||
--color-background-hover: #161f27;
|
||||
--color-api-name: #ffbe85;
|
||||
--color-api-pre-name: #efae75;
|
||||
|
||||
}
|
||||
}
|
||||
}
|
||||
</style></head>
|
||||
<body>
|
||||
|
||||
<script>
|
||||
document.body.dataset.theme = localStorage.getItem("theme") || "auto";
|
||||
</script>
|
||||
|
||||
|
||||
<svg xmlns="http://www.w3.org/2000/svg" style="display: none;">
|
||||
<symbol id="svg-toc" viewBox="0 0 24 24">
|
||||
<title>Contents</title>
|
||||
<svg stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 1024 1024">
|
||||
<path d="M408 442h480c4.4 0 8-3.6 8-8v-56c0-4.4-3.6-8-8-8H408c-4.4 0-8 3.6-8 8v56c0 4.4 3.6 8 8 8zm-8 204c0 4.4 3.6 8 8 8h480c4.4 0 8-3.6 8-8v-56c0-4.4-3.6-8-8-8H408c-4.4 0-8 3.6-8 8v56zm504-486H120c-4.4 0-8 3.6-8 8v56c0 4.4 3.6 8 8 8h784c4.4 0 8-3.6 8-8v-56c0-4.4-3.6-8-8-8zm0 632H120c-4.4 0-8 3.6-8 8v56c0 4.4 3.6 8 8 8h784c4.4 0 8-3.6 8-8v-56c0-4.4-3.6-8-8-8zM115.4 518.9L271.7 642c5.8 4.6 14.4.5 14.4-6.9V388.9c0-7.4-8.5-11.5-14.4-6.9L115.4 505.1a8.74 8.74 0 0 0 0 13.8z"/>
|
||||
</svg>
|
||||
</symbol>
|
||||
<symbol id="svg-menu" viewBox="0 0 24 24">
|
||||
<title>Menu</title>
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor"
|
||||
stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather-menu">
|
||||
<line x1="3" y1="12" x2="21" y2="12"></line>
|
||||
<line x1="3" y1="6" x2="21" y2="6"></line>
|
||||
<line x1="3" y1="18" x2="21" y2="18"></line>
|
||||
</svg>
|
||||
</symbol>
|
||||
<symbol id="svg-arrow-right" viewBox="0 0 24 24">
|
||||
<title>Expand</title>
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor"
|
||||
stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather-chevron-right">
|
||||
<polyline points="9 18 15 12 9 6"></polyline>
|
||||
</svg>
|
||||
</symbol>
|
||||
<symbol id="svg-sun" viewBox="0 0 24 24">
|
||||
<title>Light mode</title>
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor"
|
||||
stroke-width="1" stroke-linecap="round" stroke-linejoin="round" class="feather-sun">
|
||||
<circle cx="12" cy="12" r="5"></circle>
|
||||
<line x1="12" y1="1" x2="12" y2="3"></line>
|
||||
<line x1="12" y1="21" x2="12" y2="23"></line>
|
||||
<line x1="4.22" y1="4.22" x2="5.64" y2="5.64"></line>
|
||||
<line x1="18.36" y1="18.36" x2="19.78" y2="19.78"></line>
|
||||
<line x1="1" y1="12" x2="3" y2="12"></line>
|
||||
<line x1="21" y1="12" x2="23" y2="12"></line>
|
||||
<line x1="4.22" y1="19.78" x2="5.64" y2="18.36"></line>
|
||||
<line x1="18.36" y1="5.64" x2="19.78" y2="4.22"></line>
|
||||
</svg>
|
||||
</symbol>
|
||||
<symbol id="svg-moon" viewBox="0 0 24 24">
|
||||
<title>Dark mode</title>
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor"
|
||||
stroke-width="1" stroke-linecap="round" stroke-linejoin="round" class="icon-tabler-moon">
|
||||
<path stroke="none" d="M0 0h24v24H0z" fill="none" />
|
||||
<path d="M12 3c.132 0 .263 0 .393 0a7.5 7.5 0 0 0 7.92 12.446a9 9 0 1 1 -8.313 -12.454z" />
|
||||
</svg>
|
||||
</symbol>
|
||||
<symbol id="svg-sun-with-moon" viewBox="0 0 24 24">
|
||||
<title>Auto light/dark, in light mode</title>
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor"
|
||||
stroke-width="1" stroke-linecap="round" stroke-linejoin="round"
|
||||
class="icon-custom-derived-from-feather-sun-and-tabler-moon">
|
||||
<path style="opacity: 50%" d="M 5.411 14.504 C 5.471 14.504 5.532 14.504 5.591 14.504 C 3.639 16.319 4.383 19.569 6.931 20.352 C 7.693 20.586 8.512 20.551 9.25 20.252 C 8.023 23.207 4.056 23.725 2.11 21.184 C 0.166 18.642 1.702 14.949 4.874 14.536 C 5.051 14.512 5.231 14.5 5.411 14.5 L 5.411 14.504 Z"/>
|
||||
<line x1="14.5" y1="3.25" x2="14.5" y2="1.25"/>
|
||||
<line x1="14.5" y1="15.85" x2="14.5" y2="17.85"/>
|
||||
<line x1="10.044" y1="5.094" x2="8.63" y2="3.68"/>
|
||||
<line x1="19" y1="14.05" x2="20.414" y2="15.464"/>
|
||||
<line x1="8.2" y1="9.55" x2="6.2" y2="9.55"/>
|
||||
<line x1="20.8" y1="9.55" x2="22.8" y2="9.55"/>
|
||||
<line x1="10.044" y1="14.006" x2="8.63" y2="15.42"/>
|
||||
<line x1="19" y1="5.05" x2="20.414" y2="3.636"/>
|
||||
<circle cx="14.5" cy="9.55" r="3.6"/>
|
||||
</svg>
|
||||
</symbol>
|
||||
<symbol id="svg-moon-with-sun" viewBox="0 0 24 24">
|
||||
<title>Auto light/dark, in dark mode</title>
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor"
|
||||
stroke-width="1" stroke-linecap="round" stroke-linejoin="round"
|
||||
class="icon-custom-derived-from-feather-sun-and-tabler-moon">
|
||||
<path d="M 8.282 7.007 C 8.385 7.007 8.494 7.007 8.595 7.007 C 5.18 10.184 6.481 15.869 10.942 17.24 C 12.275 17.648 13.706 17.589 15 17.066 C 12.851 22.236 5.91 23.143 2.505 18.696 C -0.897 14.249 1.791 7.786 7.342 7.063 C 7.652 7.021 7.965 7 8.282 7 L 8.282 7.007 Z"/>
|
||||
<line style="opacity: 50%" x1="18" y1="3.705" x2="18" y2="2.5"/>
|
||||
<line style="opacity: 50%" x1="18" y1="11.295" x2="18" y2="12.5"/>
|
||||
<line style="opacity: 50%" x1="15.316" y1="4.816" x2="14.464" y2="3.964"/>
|
||||
<line style="opacity: 50%" x1="20.711" y1="10.212" x2="21.563" y2="11.063"/>
|
||||
<line style="opacity: 50%" x1="14.205" y1="7.5" x2="13.001" y2="7.5"/>
|
||||
<line style="opacity: 50%" x1="21.795" y1="7.5" x2="23" y2="7.5"/>
|
||||
<line style="opacity: 50%" x1="15.316" y1="10.184" x2="14.464" y2="11.036"/>
|
||||
<line style="opacity: 50%" x1="20.711" y1="4.789" x2="21.563" y2="3.937"/>
|
||||
<circle style="opacity: 50%" cx="18" cy="7.5" r="2.169"/>
|
||||
</svg>
|
||||
</symbol>
|
||||
<symbol id="svg-pencil" viewBox="0 0 24 24">
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor"
|
||||
stroke-width="1" stroke-linecap="round" stroke-linejoin="round" class="icon-tabler-pencil-code">
|
||||
<path d="M4 20h4l10.5 -10.5a2.828 2.828 0 1 0 -4 -4l-10.5 10.5v4" />
|
||||
<path d="M13.5 6.5l4 4" />
|
||||
<path d="M20 21l2 -2l-2 -2" />
|
||||
<path d="M17 17l-2 2l2 2" />
|
||||
</svg>
|
||||
</symbol>
|
||||
<symbol id="svg-eye" viewBox="0 0 24 24">
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor"
|
||||
stroke-width="1" stroke-linecap="round" stroke-linejoin="round" class="icon-tabler-eye-code">
|
||||
<path stroke="none" d="M0 0h24v24H0z" fill="none" />
|
||||
<path d="M10 12a2 2 0 1 0 4 0a2 2 0 0 0 -4 0" />
|
||||
<path
|
||||
d="M11.11 17.958c-3.209 -.307 -5.91 -2.293 -8.11 -5.958c2.4 -4 5.4 -6 9 -6c3.6 0 6.6 2 9 6c-.21 .352 -.427 .688 -.647 1.008" />
|
||||
<path d="M20 21l2 -2l-2 -2" />
|
||||
<path d="M17 17l-2 2l2 2" />
|
||||
</svg>
|
||||
</symbol>
|
||||
</svg>
|
||||
|
||||
<input type="checkbox" class="sidebar-toggle" name="__navigation" id="__navigation" aria-label="Toggle site navigation sidebar">
|
||||
<input type="checkbox" class="sidebar-toggle" name="__toc" id="__toc" aria-label="Toggle table of contents sidebar">
|
||||
<label class="overlay sidebar-overlay" for="__navigation"></label>
|
||||
<label class="overlay toc-overlay" for="__toc"></label>
|
||||
|
||||
<a class="skip-to-content muted-link" href="#furo-main-content">Skip to content</a>
|
||||
|
||||
|
||||
|
||||
<div class="page">
|
||||
<header class="mobile-header">
|
||||
<div class="header-left">
|
||||
<label class="nav-overlay-icon" for="__navigation">
|
||||
<span class="icon"><svg><use href="#svg-menu"></use></svg></span>
|
||||
</label>
|
||||
</div>
|
||||
<div class="header-center">
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.1.1 documentation</div></a>
|
||||
</div>
|
||||
<div class="header-right">
|
||||
<div class="theme-toggle-container theme-toggle-header">
|
||||
<button class="theme-toggle" aria-label="Toggle Light / Dark / Auto color theme">
|
||||
<svg class="theme-icon-when-auto-light"><use href="#svg-sun-with-moon"></use></svg>
|
||||
<svg class="theme-icon-when-auto-dark"><use href="#svg-moon-with-sun"></use></svg>
|
||||
<svg class="theme-icon-when-dark"><use href="#svg-moon"></use></svg>
|
||||
<svg class="theme-icon-when-light"><use href="#svg-sun"></use></svg>
|
||||
</button>
|
||||
</div>
|
||||
<label class="toc-overlay-icon toc-header-icon" for="__toc">
|
||||
<span class="icon"><svg><use href="#svg-toc"></use></svg></span>
|
||||
</label>
|
||||
</div>
|
||||
</header>
|
||||
<aside class="sidebar-drawer">
|
||||
<div class="sidebar-container">
|
||||
|
||||
<div class="sidebar-sticky"><a class="sidebar-brand" href="index.html">
|
||||
<div class="sidebar-logo-container">
|
||||
<img class="sidebar-logo" src="_static/rns_logo_512.png" alt="Logo"/>
|
||||
</div>
|
||||
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.1.1 documentation</span>
|
||||
|
||||
</a><form class="sidebar-search-container" method="get" action="search.html" role="search">
|
||||
<input class="sidebar-search" placeholder="Search" name="q" aria-label="Search">
|
||||
<input type="hidden" name="check_keywords" value="yes">
|
||||
<input type="hidden" name="area" value="default">
|
||||
</form>
|
||||
<div id="searchbox"></div><div class="sidebar-scroll"><div class="sidebar-tree">
|
||||
<ul class="current">
|
||||
<li class="toctree-l1"><a class="reference internal" href="whatis.html">What is Reticulum?</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstartedfast.html">Getting Started Fast</a></li>
|
||||
<li class="toctree-l1 current current-page"><a class="current reference internal" href="#">Programs Using Reticulum</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="using.html">Using Reticulum on Your System</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="understanding.html">Understanding Reticulum</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="hardware.html">Communications Hardware</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="interfaces.html">Configuring Interfaces</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="networks.html">Building Networks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="support.html">Support Reticulum</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Code Examples</a></li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="reference.html">API Reference</a></li>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
</div>
|
||||
</aside>
|
||||
<div class="main">
|
||||
<div class="content">
|
||||
<div class="article-container">
|
||||
<a href="#" class="back-to-top muted-link">
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24">
|
||||
<path d="M13 20h-2V8l-5.5 5.5-1.42-1.42L12 4.16l7.92 7.92-1.42 1.42L13 8v12z"></path>
|
||||
</svg>
|
||||
<span>Back to top</span>
|
||||
</a>
|
||||
<div class="content-icon-container">
|
||||
<div class="theme-toggle-container theme-toggle-content">
|
||||
<button class="theme-toggle" aria-label="Toggle Light / Dark / Auto color theme">
|
||||
<svg class="theme-icon-when-auto-light"><use href="#svg-sun-with-moon"></use></svg>
|
||||
<svg class="theme-icon-when-auto-dark"><use href="#svg-moon-with-sun"></use></svg>
|
||||
<svg class="theme-icon-when-dark"><use href="#svg-moon"></use></svg>
|
||||
<svg class="theme-icon-when-light"><use href="#svg-sun"></use></svg>
|
||||
</button>
|
||||
</div>
|
||||
<label class="toc-overlay-icon toc-content-icon" for="__toc">
|
||||
<span class="icon"><svg><use href="#svg-toc"></use></svg></span>
|
||||
</label>
|
||||
</div>
|
||||
<article role="main" id="furo-main-content">
|
||||
<section id="programs-using-reticulum">
|
||||
<span id="software-main"></span><h1>Programs Using Reticulum<a class="headerlink" href="#programs-using-reticulum" title="Link to this heading">¶</a></h1>
|
||||
<p>This chapter provides a non-exhaustive list of notable programs, systems and application-layer
|
||||
protocols that have been built using Reticulum.</p>
|
||||
<p>These programs will let you get a feel for how Reticulum works. Most of them have been designed
|
||||
to run well even over slow networks based on LoRa or packet radio, but all can also be used over fast
|
||||
links, such as local WiFi, wired Ethernet, the Internet, or any combination.</p>
|
||||
<p>As such, it is easy to get started experimenting, without having to set up any radio
|
||||
transceivers or infrastructure just to try it out. Launching the programs on separate
|
||||
devices connected to the same WiFi network is enough to get started, and physical
|
||||
radio interfaces can then be added later.</p>
|
||||
<section id="programs-utilities">
|
||||
<h2>Programs & Utilities<a class="headerlink" href="#programs-utilities" title="Link to this heading">¶</a></h2>
|
||||
<p>Many different applications using Reticulum already exist, serving a wide variety of purposes
|
||||
from day-to-day communication and information sharing to systems administration and tackling
|
||||
advanced networking and communications challenges.</p>
|
||||
<p>Development of Reticulum-based applications and systems is ongoing, so consider this list
|
||||
a non-exhaustive starting point of <em>some</em> of the options available. With a bit of searching,
|
||||
primarily over Reticulum itself, you will find many more interesting things.</p>
|
||||
<section id="remote-shell">
|
||||
<h3>Remote Shell<a class="headerlink" href="#remote-shell" title="Link to this heading">¶</a></h3>
|
||||
<p>The <a class="reference external" href="https://github.com/acehoss/rnsh">rnsh</a> program lets you establish fully interactive
|
||||
remote shell sessions over Reticulum. It also allows you to pipe any program to or from a
|
||||
remote system, and is similar to how <code class="docutils literal notranslate"><span class="pre">ssh</span></code> works. The <code class="docutils literal notranslate"><span class="pre">rnsh</span></code> program is very efficient, and
|
||||
can facilitate fully interactive shell sessions, even over extremely low-bandwidth links,
|
||||
such as LoRa or packet radio.</p>
|
||||
<p>In addition to the default, fully interactive terminal mode,
|
||||
for extremely limited links, <code class="docutils literal notranslate"><span class="pre">rnsh</span></code> offers line-interactive mode, allowing you to interact
|
||||
with remote systems, even when link throughput is counted in a few hundreds of bits per second.</p>
|
||||
</section>
|
||||
<section id="nomad-network">
|
||||
<h3>Nomad Network<a class="headerlink" href="#nomad-network" title="Link to this heading">¶</a></h3>
|
||||
<p>The terminal-based program <a class="reference external" href="https://github.com/markqvist/nomadnet">Nomad Network</a>
|
||||
provides a complete encrypted communications suite built with Reticulum. It features
|
||||
encrypted messaging (both direct and delayed-delivery for offline users), file sharing,
|
||||
and has a built-in text-browser and page server with support for dynamically rendered pages,
|
||||
user authentication and more.</p>
|
||||
<a class="reference external image-reference" href="https://github.com/markqvist/nomadnet"><img alt="_images/nomadnet_3.png" src="_images/nomadnet_3.png" />
|
||||
</a>
|
||||
<p><a class="reference external" href="https://github.com/markqvist/nomadnet">Nomad Network</a> is a user-facing client
|
||||
for the messaging and information-sharing protocol LXMF.</p>
|
||||
</section>
|
||||
<section id="rns-page-node">
|
||||
<h3>RNS Page Node<a class="headerlink" href="#rns-page-node" title="Link to this heading">¶</a></h3>
|
||||
<p><a class="reference external" href="https://git.quad4.io/RNS-Things/rns-page-node">RNS Page Node</a> is a simple way to serve pages and files to any other Nomad Network compatible client. Drop-in replacement for NomadNet nodes that primarily serve pages and files.</p>
|
||||
</section>
|
||||
<section id="retipedia">
|
||||
<h3>Retipedia<a class="headerlink" href="#retipedia" title="Link to this heading">¶</a></h3>
|
||||
<p>You can host the entirity of Wikipedia (or any <code class="docutils literal notranslate"><span class="pre">.zim</span></code>) file to other Nomad Network clients using <a class="reference external" href="https://github.com/RFnexus/Retipedia">Retipedia</a>.</p>
|
||||
</section>
|
||||
<section id="sideband">
|
||||
<h3>Sideband<a class="headerlink" href="#sideband" title="Link to this heading">¶</a></h3>
|
||||
<p>If you would rather use an LXMF client with a graphical user interface, you can take
|
||||
a look at <a class="reference external" href="https://unsigned.io/sideband">Sideband</a>, which is available for Android,
|
||||
Linux, macOS and Windows. Sideband is an advanced LXMF and LXST client, and a multi-purpose Reticulum
|
||||
utility, with features and functionality targeted at advanced users.</p>
|
||||
<a class="reference external image-reference" href="https://unsigned.io/sideband"><img alt="_images/sideband_devices.webp" class="align-center" src="_images/sideband_devices.webp" />
|
||||
</a>
|
||||
<p>Sideband allows you to communicate with other people or LXMF-compatible
|
||||
systems over Reticulum networks using LoRa, Packet Radio, WiFi, I2P, Encrypted QR
|
||||
Paper Messages, or anything else Reticulum supports.</p>
|
||||
<p>It also interoperates with all other LXMF clients, and provides advanced features such as voice messaging,
|
||||
real-time voice calls, file attachments, private telemetry sharing, and a full
|
||||
plugin system for expandability.</p>
|
||||
</section>
|
||||
<section id="meshchatx">
|
||||
<h3>MeshChatX<a class="headerlink" href="#meshchatx" title="Link to this heading">¶</a></h3>
|
||||
<p>A <a class="reference external" href="https://git.quad4.io/RNS-Things/MeshChatX">Reticulum MeshChat fork from the future</a>, with the goal of providing everything you need for Reticulum, LXMF, and LXST in one beautiful and feature-rich application. This project is separate from the original Reticulum MeshChat project, and is not affiliated with the original project.</p>
|
||||
<a class="reference external image-reference" href="https://git.quad4.io/RNS-Things/MeshChatX"><img alt="_images/meshchatx.webp" class="align-center" src="_images/meshchatx.webp" />
|
||||
</a>
|
||||
<p>Features include full LXST support, custom voicemail, phonebook, contact sharing, and ringtone support, multi-identity handling, modern UI/UX, offline documentation, expanded tools, page archiving, integrated maps and improved application security.</p>
|
||||
</section>
|
||||
<section id="meshchat">
|
||||
<h3>MeshChat<a class="headerlink" href="#meshchat" title="Link to this heading">¶</a></h3>
|
||||
<p>The <a class="reference external" href="https://github.com/liamcottle/reticulum-meshchat">Reticulum MeshChat</a> application
|
||||
is a user-friendly LXMF client for Linux, macOS and Windows, that also includes a Nomad Network
|
||||
page browser and other interesting functionality.</p>
|
||||
<a class="reference external image-reference" href="https://github.com/liamcottle/reticulum-meshchat"><img alt="_images/meshchat_1.webp" class="align-center" src="_images/meshchat_1.webp" />
|
||||
</a>
|
||||
<p>Reticulum MeshChat is of course also compatible with Sideband and Nomad Network, or
|
||||
any other LXMF client.</p>
|
||||
</section>
|
||||
<section id="columba">
|
||||
<h3>Columba<a class="headerlink" href="#columba" title="Link to this heading">¶</a></h3>
|
||||
<p><a class="reference external" href="https://github.com/torlando-tech/columba/">Columba</a> is a simple and familiar LXMF
|
||||
messaging app Android, built with a native Android interface and Material Design 3.</p>
|
||||
<a class="reference external image-reference" href="https://github.com/torlando-tech/columba/"><img alt="_images/columba.webp" class="align-center" src="_images/columba.webp" style="width: 25%;" />
|
||||
</a>
|
||||
<p>While still in early and very active development, it is of course also compatible
|
||||
with all other LXMF clients, and allows you to message seamlessly with anyone else
|
||||
using LXMF.</p>
|
||||
</section>
|
||||
<section id="reticulum-relay-chat">
|
||||
<h3>Reticulum Relay Chat<a class="headerlink" href="#reticulum-relay-chat" title="Link to this heading">¶</a></h3>
|
||||
<p><a class="reference external" href="https://rrc.kc1awv.net/">Reticulum Relay Chat</a> is a live chat system built on top of the Reticulum Network Stack. It exists to let people talk to each other in real time over Reticulum without dragging in message databases, synchronization engines, or architectural commitments they did not ask for.</p>
|
||||
<p>The <a class="reference external" href="https://github.com/kc1awv/rrcd">rrcd</a> program provides a functional, reference RRC hub-server daemon implementation. RRC user clients include <a class="reference external" href="https://github.com/kc1awv/rrc-gui">rrc-gui</a> and <a class="reference external" href="https://github.com/kc1awv/rrc-web">rrc-web</a>.</p>
|
||||
<p>RRC is closer in spirit to IRC than to modern “everything platforms.” You connect, you join a room, you talk, and then you leave. If you were present, you saw the conversation. If you were not, the conversation did not wait for you. This is not an accident. This is the entire design.</p>
|
||||
</section>
|
||||
<section id="retibbs">
|
||||
<h3>RetiBBS<a class="headerlink" href="#retibbs" title="Link to this heading">¶</a></h3>
|
||||
<p><a class="reference external" href="https://github.com/kc1awv/RetiBBS">RetiBBS</a> is a bulletin board system implementation for Reticulum networks.</p>
|
||||
<a class="reference external image-reference" href="https://github.com/kc1awv/RetiBBS"><img alt="_images/retibbs.webp" class="align-center" src="_images/retibbs.webp" />
|
||||
</a>
|
||||
<p>RetiBBS allows users to communicate through message boards in a secure manner.</p>
|
||||
</section>
|
||||
<section id="rbrowser">
|
||||
<h3>RBrowser<a class="headerlink" href="#rbrowser" title="Link to this heading">¶</a></h3>
|
||||
<p>The <a class="reference external" href="https://github.com/fr33n0w/rBrowser">rBrowser</a> program is a cross-platoform, standalone, web-based browser for exploring NomadNetwork Nodes over Reticulum Network. It automatically discovers NomadNet nodes through network announces and provides a user-friendly interface for browsing distributed content with Micron markup support.</p>
|
||||
<a class="reference external image-reference" href="https://github.com/fr33n0w/rBrowser"><img alt="_images/rbrowser.webp" class="align-center" src="_images/rbrowser.webp" />
|
||||
</a>
|
||||
<p>Includes useful features like automatic listening for announce, adding nodes to favorites, browsing and rendering any kind of NomadNet links, downloading files from remote nodes, a unique local NomadNet Search Engine and more.</p>
|
||||
</section>
|
||||
<section id="reticulum-network-telephone">
|
||||
<h3>Reticulum Network Telephone<a class="headerlink" href="#reticulum-network-telephone" title="Link to this heading">¶</a></h3>
|
||||
<p>The <code class="docutils literal notranslate"><span class="pre">rnphone</span></code> program, included as part of the <a class="reference external" href="https://github.com/markqvist/LXST">LXST</a> package is a command-line Reticulum telephone utility and daemon, that allows building physical, hardware telephones for LXST and Reticulum, as well as simply performing calls via the command line.</p>
|
||||
<a class="reference external image-reference" href="https://github.com/markqvist/LXST"><img alt="_images/rnphone.webp" class="align-center" src="_images/rnphone.webp" />
|
||||
</a>
|
||||
<p>It supports interfacing directly with hardware peripherals such as GPIO keypads and LCD displays, providing a modular system for building secure hardware telephones.</p>
|
||||
</section>
|
||||
<section id="lxst-phone">
|
||||
<h3>LXST Phone<a class="headerlink" href="#lxst-phone" title="Link to this heading">¶</a></h3>
|
||||
<p>The <a class="reference external" href="https://github.com/kc1awv/lxst_phone">LXST Phone</a> program is a cross-platform desktop application for performing LXST voice calls over Reticulum.</p>
|
||||
<a class="reference external image-reference" href="https://github.com/kc1awv/lxst_phone"><img alt="_images/lxst_phone.webp" class="align-center" src="_images/lxst_phone.webp" />
|
||||
</a>
|
||||
<p>It supports various advanced features such as SAS verification, peer blocking, rate limiting, encrypted call history storage and contact management.</p>
|
||||
</section>
|
||||
<section id="lxmfy">
|
||||
<h3>LXMFy<a class="headerlink" href="#lxmfy" title="Link to this heading">¶</a></h3>
|
||||
<p><a class="reference external" href="https://lxmfy.quad4.io/">LXMFy</a> is a comprehensive and advanced bot creation framework for LXMF, that allows building any kind of automation or bot system running over LXMF and Reticulum. <a class="reference external" href="https://github.com/lxmfy/awesome-lxmfy-bots">Bot implementations exist</a> for Home Assistant control, LLM integrations, and various other purposes.</p>
|
||||
</section>
|
||||
<section id="lxmf-interactive-client">
|
||||
<h3>LXMF Interactive Client<a class="headerlink" href="#lxmf-interactive-client" title="Link to this heading">¶</a></h3>
|
||||
<p><a class="reference external" href="https://github.com/fr33n0w/lxmf-cli">LXMF Interactive Client</a> is a feature-rich, terminal-based LXMF messaging client with many advanced features and an extensible plugin architecture.</p>
|
||||
</section>
|
||||
<section id="rns-filesync">
|
||||
<h3>RNS FileSync<a class="headerlink" href="#rns-filesync" title="Link to this heading">¶</a></h3>
|
||||
<p>The <a class="reference external" href="https://git.quad4.io/RNS-Things/RNS-Filesync">RNS FileSync</a> program enables automatic file synchronization between devices without requiring central servers, internet connectivity, or cloud services. It works over any network medium supported by Reticulum, including radio, LoRa, WiFi, or the internet, making it ideal for off-grid, privacy-focused, and resilient file sharing.</p>
|
||||
</section>
|
||||
<section id="micron-parser-js">
|
||||
<h3>Micron Parser JS<a class="headerlink" href="#micron-parser-js" title="Link to this heading">¶</a></h3>
|
||||
<p><a class="reference external" href="https://github.com/RFnexus/micron-parser-js">Micron Parser JS</a> is the JavaScript-based parser for the Micron markup language, that most web-based Nomad Network browsers use. If you want to make utilities or tools that display Micron pages, this library is essential.</p>
|
||||
</section>
|
||||
<section id="rnmon">
|
||||
<h3>RNMon<a class="headerlink" href="#rnmon" title="Link to this heading">¶</a></h3>
|
||||
<p><a class="reference external" href="https://github.com/lbatalha/rnmon">RNMon</a> is a monitoring daemon designed to monitor the status of multiple RNS applications and push the metrics to an InfluxDB instance over the influx line protocol.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="protocols">
|
||||
<h2>Protocols<a class="headerlink" href="#protocols" title="Link to this heading">¶</a></h2>
|
||||
<p>A number of standard protocols have emerged through real-world usage and testing in the Reticulum community. While you may sometimes want to use completely custom protocols and implementations when writing Reticulum-based software, using these protocols provides application developers with an easy way to implement advanced functionality quickly and effortlessly. Using them also ensures compatibility and interoperability between many different client applications, creating an open communications ecosystem where users are free to choose the applications that suit their needs, while remaining connected to everyone else.</p>
|
||||
<section id="lxmf">
|
||||
<h3>LXMF<a class="headerlink" href="#lxmf" title="Link to this heading">¶</a></h3>
|
||||
<p><a class="reference external" href="https://github.com/markqvist/lxmf">LXMF</a> is a simple and flexible messaging format and delivery protocol that allows a wide variety of applications, while using as little bandwidth as possible. It offers zero-conf message routing, end-to-end encryption and Forward Secrecy, and can be transported over any kind of medium that Reticulum supports.</p>
|
||||
<p>LXMF is efficient enough that it can deliver messages over extremely low-bandwidth systems such as packet radio or LoRa. Encrypted LXMF messages can also be encoded as QR-codes or text-based URIs, allowing completely analog paper message transport.</p>
|
||||
<p>Using Propagation Nodes, LXMF also offer a way to store and forward messages to users or endpoints that are not directly reachable at the time of message emission.</p>
|
||||
</section>
|
||||
<section id="id17">
|
||||
<h3>LXST<a class="headerlink" href="#id17" title="Link to this heading">¶</a></h3>
|
||||
<p><a class="reference external" href="https://github.com/markqvist/lxst">LXST</a> is a simple and flexible real-time streaming format and delivery protocol that allows a wide variety of applications, while using as little bandwidth as possible. It is built on top of Reticulum and offers zero-conf stream routing, end-to-end encryption and Forward Secrecy, and can be transported over any kind of medium that Reticulum supports. It currently powers real-time voice and telephony applications over Reticulum.</p>
|
||||
</section>
|
||||
<section id="rrc">
|
||||
<h3>RRC<a class="headerlink" href="#rrc" title="Link to this heading">¶</a></h3>
|
||||
<p>The <a class="reference external" href="https://rrc.kc1awv.net/">Reticulum Relay Chat</a> protocol, is a live chat system built on top of the Reticulum Network Stack. It exists to provide near real-time group communication without dragging in message history databases, federation machinery, or architectural guilt.</p>
|
||||
<p>RRC is intentionally simple. It does not pretend to be email, a mailbox, or a distributed archive. It behaves more like a conversation in a room. If you were there, you heard it. If you were not, you did not. That is not a bug, that is the point.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="interface-modules-connectivity-resources">
|
||||
<h2>Interface Modules & Connectivity Resources<a class="headerlink" href="#interface-modules-connectivity-resources" title="Link to this heading">¶</a></h2>
|
||||
<p>This section provides a list of various community-provided interface modules, guides and resources for creating Reticulum networks over special or challenging mediums.</p>
|
||||
<ul class="simple">
|
||||
<li><p>Custom interface module for running <a class="reference external" href="https://git.quad4.io/RNS-Things/RNS-over-HTTP">RNS over HTTP</a></p></li>
|
||||
<li><p>Guide for running <a class="reference external" href="https://github.com/matvik22000/rns-over-icmp">Reticulum over ICMP</a> using <code class="docutils literal notranslate"><span class="pre">PipeInterface</span></code></p></li>
|
||||
<li><p>Guide for running <a class="reference external" href="https://github.com/markqvist/Reticulum/discussions/1002">Reticulum over DNS</a> with Iodine</p></li>
|
||||
<li><p>Guide for running <a class="reference external" href="https://github.com/RFnexus/reticulum-over-hf">Reticulum over HF radio</a></p></li>
|
||||
<li><p><a class="reference external" href="https://github.com/RFnexus/modem73">Modem73</a> is a KISS TNC OFDM modem frontend that can be used with Reticulum</p></li>
|
||||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
</article>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
<div class="related-pages">
|
||||
<a class="next-page" href="using.html">
|
||||
<div class="page-info">
|
||||
<div class="context">
|
||||
<span>Next</span>
|
||||
</div>
|
||||
<div class="title">Using Reticulum on Your System</div>
|
||||
</div>
|
||||
<svg class="furo-related-icon"><use href="#svg-arrow-right"></use></svg>
|
||||
</a>
|
||||
<a class="prev-page" href="gettingstartedfast.html">
|
||||
<svg class="furo-related-icon"><use href="#svg-arrow-right"></use></svg>
|
||||
<div class="page-info">
|
||||
<div class="context">
|
||||
<span>Previous</span>
|
||||
</div>
|
||||
|
||||
<div class="title">Getting Started Fast</div>
|
||||
|
||||
</div>
|
||||
</a>
|
||||
</div>
|
||||
<div class="bottom-of-page">
|
||||
<div class="left-details">
|
||||
<div class="copyright">
|
||||
Copyright © 2025, Mark Qvist
|
||||
</div>
|
||||
Generated with <a href="https://www.sphinx-doc.org/">Sphinx</a> and
|
||||
<a href="https://github.com/pradyunsg/furo">Furo</a>
|
||||
|
||||
</div>
|
||||
<div class="right-details">
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</footer>
|
||||
</div>
|
||||
<aside class="toc-drawer">
|
||||
|
||||
|
||||
<div class="toc-sticky toc-scroll">
|
||||
<div class="toc-title-container">
|
||||
<span class="toc-title">
|
||||
On this page
|
||||
</span>
|
||||
</div>
|
||||
<div class="toc-tree-container">
|
||||
<div class="toc-tree">
|
||||
<ul>
|
||||
<li><a class="reference internal" href="#">Programs Using Reticulum</a><ul>
|
||||
<li><a class="reference internal" href="#programs-utilities">Programs & Utilities</a><ul>
|
||||
<li><a class="reference internal" href="#remote-shell">Remote Shell</a></li>
|
||||
<li><a class="reference internal" href="#nomad-network">Nomad Network</a></li>
|
||||
<li><a class="reference internal" href="#rns-page-node">RNS Page Node</a></li>
|
||||
<li><a class="reference internal" href="#retipedia">Retipedia</a></li>
|
||||
<li><a class="reference internal" href="#sideband">Sideband</a></li>
|
||||
<li><a class="reference internal" href="#meshchatx">MeshChatX</a></li>
|
||||
<li><a class="reference internal" href="#meshchat">MeshChat</a></li>
|
||||
<li><a class="reference internal" href="#columba">Columba</a></li>
|
||||
<li><a class="reference internal" href="#reticulum-relay-chat">Reticulum Relay Chat</a></li>
|
||||
<li><a class="reference internal" href="#retibbs">RetiBBS</a></li>
|
||||
<li><a class="reference internal" href="#rbrowser">RBrowser</a></li>
|
||||
<li><a class="reference internal" href="#reticulum-network-telephone">Reticulum Network Telephone</a></li>
|
||||
<li><a class="reference internal" href="#lxst-phone">LXST Phone</a></li>
|
||||
<li><a class="reference internal" href="#lxmfy">LXMFy</a></li>
|
||||
<li><a class="reference internal" href="#lxmf-interactive-client">LXMF Interactive Client</a></li>
|
||||
<li><a class="reference internal" href="#rns-filesync">RNS FileSync</a></li>
|
||||
<li><a class="reference internal" href="#micron-parser-js">Micron Parser JS</a></li>
|
||||
<li><a class="reference internal" href="#rnmon">RNMon</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#protocols">Protocols</a><ul>
|
||||
<li><a class="reference internal" href="#lxmf">LXMF</a></li>
|
||||
<li><a class="reference internal" href="#id17">LXST</a></li>
|
||||
<li><a class="reference internal" href="#rrc">RRC</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#interface-modules-connectivity-resources">Interface Modules & Connectivity Resources</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</aside>
|
||||
</div>
|
||||
</div><script src="_static/documentation_options.js?v=58fbf978"></script>
|
||||
<script src="_static/doctools.js?v=9bcbadda"></script>
|
||||
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
|
||||
<script src="_static/scripts/furo.js?v=46bd48cc"></script>
|
||||
<script src="_static/clipboard.min.js?v=a7894cd8"></script>
|
||||
<script src="_static/copybutton.js?v=f281be69"></script>
|
||||
</body>
|
||||
</html>
|
||||
@@ -7,7 +7,7 @@
|
||||
<link rel="prefetch" href="_static/rns_logo_512.png" as="image">
|
||||
|
||||
<!-- Generated with Sphinx 8.2.3 and Furo 2025.09.25.dev1 -->
|
||||
<title>Support Reticulum - Reticulum Network Stack 1.0.3 documentation</title>
|
||||
<title>Support Reticulum - Reticulum Network Stack 1.1.1 documentation</title>
|
||||
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=d111a655" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/styles/furo.css?v=580074bf" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/copybutton.css?v=76b2166b" />
|
||||
@@ -180,7 +180,7 @@
|
||||
</label>
|
||||
</div>
|
||||
<div class="header-center">
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.0.3 documentation</div></a>
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.1.1 documentation</div></a>
|
||||
</div>
|
||||
<div class="header-right">
|
||||
<div class="theme-toggle-container theme-toggle-header">
|
||||
@@ -204,7 +204,7 @@
|
||||
<img class="sidebar-logo" src="_static/rns_logo_512.png" alt="Logo"/>
|
||||
</div>
|
||||
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.0.3 documentation</span>
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.1.1 documentation</span>
|
||||
|
||||
</a><form class="sidebar-search-container" method="get" action="search.html" role="search">
|
||||
<input class="sidebar-search" placeholder="Search" name="q" aria-label="Search">
|
||||
@@ -267,11 +267,11 @@ systems by donating, providing feedback and contributing code and learning resou
|
||||
<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>Monero:
|
||||
84FpY1QbxHcgdseePYNmhTHcrgMX4nFfBYtz2GKYToqHVVhJp8Eaw1Z1EedRnKD19b3B8NiLCGVxzKV17UMmmeEsCrPyA5w
|
||||
|
||||
Ethereum:
|
||||
0x81F7B979fEa6134bA9FD5c701b3501A2e61E897a
|
||||
|
||||
Bitcoin:
|
||||
3CPmacGm34qYvR6XWLVEJmi2aNe3PZqUuq
|
||||
bc1pgqgu8h8xvj4jtafslq396v7ju7hkgymyrzyqft4llfslz5vp99psqfk3a6
|
||||
|
||||
Ethereum:
|
||||
0x91C421DdfB8a30a49A71d63447ddb54cEBe3465E
|
||||
|
||||
Liberapay:
|
||||
https://liberapay.com/Reticulum/
|
||||
@@ -285,18 +285,29 @@ organisation? Make them a reality quickly by sponsoring their implementation.</p
|
||||
</section>
|
||||
<section id="provide-feedback">
|
||||
<h2>Provide Feedback<a class="headerlink" href="#provide-feedback" title="Link to this heading">¶</a></h2>
|
||||
<p>All feedback on the usage, functioning and potential dysfunctioning of any and
|
||||
<p>Feedback on the usage, functioning and potential dysfunctioning of any and
|
||||
all components of the system is very valuable to the continued development and
|
||||
improvement of Reticulum.</p>
|
||||
improvement of Reticulum. But…</p>
|
||||
<div class="admonition warning">
|
||||
<p class="admonition-title">Warning</p>
|
||||
<p><strong>Think before you speak</strong>. As time has shown, over 80% of the “feedback”,
|
||||
“bug reports” and “advice” the Reticulum project has received has been
|
||||
irrelevant noise, stemming from erroneous assumptions, misunderstanding the
|
||||
foundational functionality or philosophy behind the system, or simply
|
||||
the malinformed (but overly opinionated) personal preferences of individual
|
||||
drive-by architects. This wastes the time of everyone involved.</p>
|
||||
<p>The Reticulum project is not a public teahouse for serving the attention
|
||||
needs of random bypassers, but a highly complex system engineered and
|
||||
refined over more than a decade, designed to provide communication and
|
||||
connectivity guarantees in highly adversarial environments.</p>
|
||||
<p>If you want to voice your opinion, it better be well-informed, and we
|
||||
expect you to have a comprehensive and solid foundation for your points
|
||||
of view. Everything else will be ignored.</p>
|
||||
</div>
|
||||
<p>Absolutely no automated analytics, telemetry, error
|
||||
reporting or statistics is collected and reported by Reticulum under any
|
||||
circumstances, so we rely on old-fashioned human feedback.</p>
|
||||
</section>
|
||||
<section id="contribute-code">
|
||||
<h2>Contribute Code<a class="headerlink" href="#contribute-code" title="Link to this heading">¶</a></h2>
|
||||
<p>Join us on <a class="reference external" href="https://github.com/markqvist/reticulum">the GitHub repository</a> to
|
||||
report issues, suggest functionality and contribute code to Reticulum.</p>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
</article>
|
||||
@@ -356,7 +367,6 @@ report issues, suggest functionality and contribute code to Reticulum.</p>
|
||||
<li><a class="reference internal" href="#">Support Reticulum</a><ul>
|
||||
<li><a class="reference internal" href="#donations">Donations</a></li>
|
||||
<li><a class="reference internal" href="#provide-feedback">Provide Feedback</a></li>
|
||||
<li><a class="reference internal" href="#contribute-code">Contribute Code</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
@@ -368,7 +378,7 @@ report issues, suggest functionality and contribute code to Reticulum.</p>
|
||||
|
||||
</aside>
|
||||
</div>
|
||||
</div><script src="_static/documentation_options.js?v=baaebd52"></script>
|
||||
</div><script src="_static/documentation_options.js?v=58fbf978"></script>
|
||||
<script src="_static/doctools.js?v=9bcbadda"></script>
|
||||
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
|
||||
<script src="_static/scripts/furo.js?v=46bd48cc"></script>
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
<link rel="prefetch" href="_static/rns_logo_512.png" as="image">
|
||||
|
||||
<!-- Generated with Sphinx 8.2.3 and Furo 2025.09.25.dev1 -->
|
||||
<title>Understanding Reticulum - Reticulum Network Stack 1.0.3 documentation</title>
|
||||
<title>Understanding Reticulum - Reticulum Network Stack 1.1.1 documentation</title>
|
||||
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=d111a655" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/styles/furo.css?v=580074bf" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/copybutton.css?v=76b2166b" />
|
||||
@@ -180,7 +180,7 @@
|
||||
</label>
|
||||
</div>
|
||||
<div class="header-center">
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.0.3 documentation</div></a>
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.1.1 documentation</div></a>
|
||||
</div>
|
||||
<div class="header-right">
|
||||
<div class="theme-toggle-container theme-toggle-header">
|
||||
@@ -204,7 +204,7 @@
|
||||
<img class="sidebar-logo" src="_static/rns_logo_512.png" alt="Logo"/>
|
||||
</div>
|
||||
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.0.3 documentation</span>
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.1.1 documentation</span>
|
||||
|
||||
</a><form class="sidebar-search-container" method="get" action="search.html" role="search">
|
||||
<input class="sidebar-search" placeholder="Search" name="q" aria-label="Search">
|
||||
@@ -267,9 +267,8 @@ the only complete repository, and final authority on how Reticulum actually func
|
||||
reference implementation and API reference. That being said, this chapter is an essential resource in
|
||||
understanding how Reticulum works from a high-level perspective, along with the general principles of
|
||||
Reticulum, and how to apply them when creating your own networks or software.</p>
|
||||
<p>After reading this document, you should be well-equipped to understand how a Reticulum network
|
||||
operates, what it can achieve, and how you can use it yourself. If you want to help out with the
|
||||
development, this is also the place to start, since it will provide a pretty clear overview of the
|
||||
<p>After reading this chapter, you should be well-equipped to understand how a Reticulum network
|
||||
operates, what it can achieve, and how you can use it yourself. This chapter also seeks to provide an overview of the
|
||||
sentiments and the philosophy behind Reticulum, what problems it seeks to solve, and how it
|
||||
approaches those solutions.</p>
|
||||
<section id="motivation">
|
||||
@@ -381,7 +380,7 @@ to be transported over multiple hops in a complex network to reach the recipient
|
||||
Reticulum uses the singular concept of <em>destinations</em>. Any application using Reticulum as its
|
||||
networking stack will need to create one or more destinations to receive data, and know the
|
||||
destinations it needs to send data to.</p>
|
||||
<p>All destinations in Reticulum are _represented_ as a 16 byte hash. This hash is derived from truncating a full
|
||||
<p>All destinations in Reticulum are <em>represented</em> as a 16 byte hash. This hash is derived from truncating a full
|
||||
SHA-256 hash of identifying characteristics of the destination. To users, the destination addresses
|
||||
will be displayed as 16 hexadecimal bytes, like this example: <code class="docutils literal notranslate"><span class="pre"><13425ec15b621c1d928589718000d814></span></code>.</p>
|
||||
<p>The truncation size of 16 bytes (128 bits) for destinations has been chosen as a reasonable trade-off
|
||||
@@ -402,7 +401,7 @@ packet communication can also provide forward secrecy, with automatic key ratche
|
||||
ratchets on a per-destination basis. The multi-hop transport, coordination, verification and reliability
|
||||
layers are fully autonomous and also based on elliptic curve cryptography.</p>
|
||||
<p>Reticulum also offers symmetric key encryption for group-oriented communications, as well as
|
||||
unencrypted packets for local broadcast purposes.</p>
|
||||
unencrypted packets (for local broadcast purposes <strong>only</strong>).</p>
|
||||
<p>Reticulum can connect to a variety of interfaces such as radio modems, data radios and serial ports,
|
||||
and offers the possibility to easily tunnel Reticulum traffic over IP links such as the Internet or
|
||||
private IP networks.</p>
|
||||
@@ -650,17 +649,26 @@ application specific data, it will replace the old announce.</div>
|
||||
</div>
|
||||
</li>
|
||||
</ul>
|
||||
<p>Once an announce has reached a node in the network, any other node in direct contact with that
|
||||
node will be able to reach the destination the announce originated from, simply by sending a packet
|
||||
addressed to that destination. Any node with knowledge of the announce will be able to direct the
|
||||
packet towards the destination by looking up the next node with the shortest amount of hops to the
|
||||
destination.</p>
|
||||
<p>Once an announce has reached a transport node in the network, any other node in direct contact with that
|
||||
transport node will be able to reach the destination the announce originated from, simply by sending a packet
|
||||
addressed to that destination. Any transport node with knowledge of the announce will be able to direct the
|
||||
packet towards the destination by looking up the most efficient next node to the destination.</p>
|
||||
<p>According to these rules, an announce will propagate throughout the network in a predictable way,
|
||||
and make the announced destination reachable in a short amount of time. Fast networks that have the
|
||||
capacity to process many announces can reach full convergence very quickly, even when constantly adding
|
||||
new destinations. Slower segments of such networks might take a bit longer to gain full knowledge about
|
||||
the wide and fast networks they are connected to, but can still do so over time, while prioritising full
|
||||
and quickly converging end-to-end connectivity for their local, slower segments.</p>
|
||||
<div class="admonition tip">
|
||||
<p class="admonition-title">Tip</p>
|
||||
<p>Even very slow networks, that simply don’t have the capacity to ever reach <em>full</em> convergence
|
||||
will generally still be able to reach <strong>any other destination on any connected segments</strong>, since
|
||||
interconnecting transport nodes will prioritize announces into the slower segments that are
|
||||
actually requested by nodes on these.</p>
|
||||
<p>This means that slow, low-capacity or low-resource segments <strong>don’t</strong> need to have full network
|
||||
knowledge, since paths can always be recursively resolved from other segments that do have
|
||||
knowledge about them.</p>
|
||||
</div>
|
||||
<p>In general, even extremely complex networks, that utilize the maximum 128 hops will converge to full
|
||||
end-to-end connectivity in about one minute, given there is enough bandwidth available to process
|
||||
the required amount of announces.</p>
|
||||
@@ -668,7 +676,7 @@ the required amount of announces.</p>
|
||||
<section id="reaching-the-destination">
|
||||
<span id="understanding-paths"></span><h3>Reaching the Destination<a class="headerlink" href="#reaching-the-destination" title="Link to this heading">¶</a></h3>
|
||||
<p>In networks with changing topology and trustless connectivity, nodes need a way to establish
|
||||
<em>verified connectivity</em> with each other. Since the network is assumed to be trustless, Reticulum
|
||||
<em>verified connectivity</em> with each other. Since the underlying network mediums are assumed to be trustless, Reticulum
|
||||
must provide a way to guarantee that the peer you are communicating with is actually who you
|
||||
expect. Reticulum offers two ways to do this.</p>
|
||||
<p>For exchanges of small amounts of information, Reticulum offers the <em>Packet</em> API, which works exactly like you would expect - on a per packet level. The following process is employed when sending a packet:</p>
|
||||
@@ -681,7 +689,7 @@ an ECDH key exchange with the destination’s public key (or ratchet key, if ava
|
||||
</li>
|
||||
<li><div class="line-block">
|
||||
<div class="line">It is important to note that this key exchange does not require any network traffic. The sender already
|
||||
knows the public key of the destination from an earlier received <em>announce</em>, and can thus perform the ECDH
|
||||
knows the public key of the destination from an earlier received announce, and can thus perform the ECDH
|
||||
key exchange locally, before sending the packet.</div>
|
||||
</div>
|
||||
</li>
|
||||
@@ -719,16 +727,16 @@ strictly necessary to use one of the others.</div>
|
||||
<p>For exchanges of larger amounts of data, or when longer sessions of bidirectional communication is desired, Reticulum offers the <em>Link</em> API. To establish a <em>link</em>, the following process is employed:</p>
|
||||
<ul>
|
||||
<li><div class="line-block">
|
||||
<div class="line">First, the node that wishes to establish a link will send out a special packet, that
|
||||
<div class="line">First, the node that wishes to establish a link will send out a <em>link request</em> packet, that
|
||||
traverses the network and locates the desired destination. Along the way, the Transport Nodes that
|
||||
forward the packet will take note of this <em>link request</em>.</div>
|
||||
forward the packet will take note of this <em>link request</em>, and mark it as pending.</div>
|
||||
</div>
|
||||
</li>
|
||||
<li><div class="line-block">
|
||||
<div class="line">Second, if the destination accepts the <em>link request</em> , it will send back a packet that proves the
|
||||
authenticity of its identity (and the receipt of the link request) to the initiating node. All
|
||||
nodes that initially forwarded the packet will also be able to verify this proof, and thus
|
||||
accept the validity of the <em>link</em> throughout the network.</div>
|
||||
accept the validity of the <em>link</em> throughout the network. The link is now marked as <em>established</em>.</div>
|
||||
</div>
|
||||
</li>
|
||||
<li><div class="line-block">
|
||||
@@ -841,8 +849,11 @@ that is used to encrypt the channel. Information can now be exchanged reliably a
|
||||
</div>
|
||||
</li>
|
||||
</ul>
|
||||
<div class="admonition note">
|
||||
<p class="admonition-title">Note</p>
|
||||
<p>It’s important to note that this methodology ensures that the source of the request does not need to
|
||||
reveal any identifying information about itself. The link initiator remains completely anonymous.</p>
|
||||
reveal any identifying information about itself. <strong>The link initiator remains completely anonymous</strong>.</p>
|
||||
</div>
|
||||
<p>When using <em>links</em>, Reticulum will automatically verify all data sent over the link, and can also
|
||||
automate retransmissions if <em>Resources</em> are used.</p>
|
||||
</section>
|
||||
@@ -861,6 +872,66 @@ of codes to reliably transfer any amount of data. They can be used to transfer d
|
||||
or stream data directly from files.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="network-identities">
|
||||
<span id="understanding-network-identities"></span><h2>Network Identities<a class="headerlink" href="#network-identities" title="Link to this heading">¶</a></h2>
|
||||
<p>In Reticulum, every peer and application utilizes a cryptographic <strong>Identity</strong> to verify authenticity and establish encrypted channels. While standard identities are typically used to represent a single user, device, or service, Reticulum introduces the concept of a <strong>Network Identity</strong> to represent a logical group of nodes or an entire community infrastructure.</p>
|
||||
<p>A Network Identity is, at its core, a standard Reticulum Identity keyset. However, its purpose and usage differ from a personal identity. Instead of identifying a single entity, a Network Identity acts as a shared credential that federates multiple independent Transport Instances under a single, verifiable administrative domain.</p>
|
||||
<section id="conceptual-overview">
|
||||
<h3>Conceptual Overview<a class="headerlink" href="#conceptual-overview" title="Link to this heading">¶</a></h3>
|
||||
<p>You can think of a standard Reticulum Identity as a self-sovereign, privately created passport for a single person. A Network Identity, conversely, is akin to a cryptographic flag, or a charter that flies over a fleet of ships. It signifies that while the ships may operate independently and be physically distant, they belong to the same organization, follow the same protocols, and are expected to act in concert.</p>
|
||||
<p>When you configure a Network Identity on one or more of your nodes, you are effectively declaring that these nodes constitute a specific “network” within a broader Reticulum mesh. This allows other peers to recognize interfaces not just as “a node named Alice”, but as “a gateway belonging to The Eastern Ret Of Freedom”.</p>
|
||||
</section>
|
||||
<section id="current-usage">
|
||||
<h3>Current Usage<a class="headerlink" href="#current-usage" title="Link to this heading">¶</a></h3>
|
||||
<p>At present, the primary function of a Network Identity is within the <a class="reference internal" href="using.html#using-interface-discovery"><span class="std std-ref">Interface Discovery</span></a> system.</p>
|
||||
<p>When a Transport Instance broadcasts a discovery announce for an interface, it can optionally sign that announce with a Network Identity, instead of just its local transport identity. Remote peers receiving the announce can then verify the signature. This provides functionality for two important distinctions:</p>
|
||||
<ol class="arabic simple">
|
||||
<li><p><strong>Authenticity:</strong> It proves that the interface was published by an operator who possesses the private key for that Network Identity.</p></li>
|
||||
<li><p><strong>Trust Boundaries:</strong> It allows users to configure their systems to only accept and connect to interfaces that belong to specific Network Identities, effectively creating “whitelisted” zones of trusted infrastructure.</p></li>
|
||||
</ol>
|
||||
<div class="admonition note">
|
||||
<p class="admonition-title">Note</p>
|
||||
<p>If you enable encryption on your discovery announces, the Network Identity is used as the shared secret. Only peers who have been explicitly provided with the Network Identity’s full keyset (and have it configured locally) will be able to decrypt and utilize the connection details.</p>
|
||||
<p>This functionality will be expanded in the future, so that peers with delegated keys can be allowed to decrypt discovery announces without holding the root network key. Currently, the functionality is sufficient for sharing interface information privately where you control all nodes that must decrypt the discovered interfaces.</p>
|
||||
</div>
|
||||
</section>
|
||||
<section id="future-implications">
|
||||
<h3>Future Implications<a class="headerlink" href="#future-implications" title="Link to this heading">¶</a></h3>
|
||||
<p>While the current implementation focuses on interface discovery, the concept of Network Identities serves as the foundational building block for future Reticulum features designed to support large-scale, organic mesh formation.</p>
|
||||
<p>As the ecosystem evolves, Network Identities will facilitate:</p>
|
||||
<ul class="simple">
|
||||
<li><p><strong>Distributed Name Resolution:</strong> A system where networks can publish name-to-identity mappings, allowing human-readable names to resolve without centralized servers.</p></li>
|
||||
<li><p><strong>Service Publishing:</strong> Networks will be able to announce specific capabilities, services, or information endpoints available publicly or to their members.</p></li>
|
||||
<li><p><strong>Inter-Network Federation:</strong> Trust relationships between different networks, allowing for seamless but managed flow of traffic and information across distinct administrative boundaries.</p></li>
|
||||
<li><p><strong>Distributed Blackhole Management:</strong> A reputation-based system for blackhole list distribution, where trusted Network Identities can sign and publish lists of blackholed identities. This allows communities to collaboratively enforce security standards and filter spam or malicious identities across the parts of the wider mesh that they are responsible for.</p></li>
|
||||
</ul>
|
||||
<p>By adopting the use of Network Identities now, you are preparing your infrastructure to be compatible with this future functionality.</p>
|
||||
</section>
|
||||
<section id="creating-and-using-a-network-identity">
|
||||
<h3>Creating and Using a Network Identity<a class="headerlink" href="#creating-and-using-a-network-identity" title="Link to this heading">¶</a></h3>
|
||||
<p>Since a Network Identity is simply a standard Reticulum Identity, you create one using the built-in tools.</p>
|
||||
<ol class="arabic">
|
||||
<li><p><strong>Generate the Identity:</strong>
|
||||
Use the <code class="docutils literal notranslate"><span class="pre">rnid</span></code> utility to generate a new identity file that will serve as your Network Identity.</p>
|
||||
<div class="highlight-sh notranslate"><div class="highlight"><pre><span></span>$<span class="w"> </span>rnid<span class="w"> </span>-g<span class="w"> </span>~/.reticulum/storage/identities/my_network
|
||||
</pre></div>
|
||||
</div>
|
||||
</li>
|
||||
<li><p><strong>Distribute the Public Key:</strong>
|
||||
The public key must be distributed to any Transport Instance that needs to verify your network’s announces and discovery information. By default, if your node is set up to use a network identity, this happens automatically (using the standard announce mechanism).</p></li>
|
||||
<li><p><strong>Configure Instances:</strong>
|
||||
In the <code class="docutils literal notranslate"><span class="pre">[reticulum]</span></code> section of the configuration file on every node within your network, point the <code class="docutils literal notranslate"><span class="pre">network_identity</span></code> option to the file you created.</p>
|
||||
<div class="highlight-ini notranslate"><div class="highlight"><pre><span></span><span class="k">[reticulum]</span>
|
||||
<span class="na">...</span>
|
||||
<span class="na">network_identity</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">~/.reticulum/storage/identities/my_network</span>
|
||||
<span class="na">...</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
</li>
|
||||
</ol>
|
||||
<p>Once configured, your instances will automatically utilize this identity for signing discovery announces (and potentially decrypting network-private information), presenting a unified front to the wider network.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="reference-setup">
|
||||
<span id="understanding-referencesystem"></span><h2>Reference Setup<a class="headerlink" href="#reference-setup" title="Link to this heading">¶</a></h2>
|
||||
<p>This section will detail a recommended <em>Reference Setup</em> for Reticulum. It is important to
|
||||
@@ -903,27 +974,30 @@ into the future. The current Reference System Setup is as follows:</p>
|
||||
<li><dl class="simple">
|
||||
<dt><strong>Interface Device</strong></dt><dd><p>A data radio consisting of a LoRa radio module, and a microcontroller with open source
|
||||
firmware, that can connect to host devices via USB. It operates in either the 430, 868 or 900
|
||||
MHz frequency bands. More details can be found on the <a class="reference external" href="https://unsigned.io/rnode">RNode Page</a>.</p>
|
||||
MHz frequency bands. More details can be found on the <a class="reference external" href="https://github.com/markqvist/rnode_firmware">RNode Page</a>.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</li>
|
||||
<li><dl class="simple">
|
||||
<dt><strong>Host Device</strong></dt><dd><p>Any computer device running Linux and Python. A Raspberry Pi with a Debian based OS is
|
||||
recommended.</p>
|
||||
a good place to start, but anything can be used.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</li>
|
||||
<li><dl class="simple">
|
||||
<dt><strong>Software Stack</strong></dt><dd><p>The most recently released Python Implementation of Reticulum, running on a Debian based
|
||||
<dt><strong>Software Stack</strong></dt><dd><p>The most recently released Python Implementation of Reticulum, running on a Linux-based
|
||||
operating system.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</li>
|
||||
</ul>
|
||||
<div class="admonition note">
|
||||
<p class="admonition-title">Note</p>
|
||||
<p>To avoid confusion, it is very important to note, that the reference interface device <strong>does not</strong>
|
||||
use the LoRaWAN standard, but uses a custom MAC layer on top of the plain LoRa modulation! As such, you will
|
||||
need a plain LoRa radio module connected to an controller with the correct firmware. Full details on how to
|
||||
get or make such a device is available on the <a class="reference external" href="https://unsigned.io/rnode">RNode Page</a>.</p>
|
||||
need a plain LoRa radio module connected to a controller with the correct firmware. Full details on how to
|
||||
get or make such a device is available on the <a class="reference external" href="https://github.com/markqvist/rnode_firmware">RNode Page</a>.</p>
|
||||
</div>
|
||||
<p>With the current reference setup, it should be possible to get on a Reticulum network for around 100$
|
||||
even if you have none of the hardware already, and need to purchase everything.</p>
|
||||
<p>This reference setup is of course just a recommendation for getting started easily, and you should
|
||||
@@ -932,20 +1006,20 @@ tailor it to your own specific needs, or whatever hardware you have available.</
|
||||
<section id="protocol-specifics">
|
||||
<span id="understanding-protocolspecifics"></span><h2>Protocol Specifics<a class="headerlink" href="#protocol-specifics" title="Link to this heading">¶</a></h2>
|
||||
<p>This chapter will detail protocol specific information that is essential to the implementation of
|
||||
Reticulum, but non critical in understanding how the protocol works on a general level. It should be
|
||||
Reticulum, but non-critical in understanding how the protocol works on a general level. It should be
|
||||
treated more as a reference than as essential reading.</p>
|
||||
<section id="packet-prioritisation">
|
||||
<h3>Packet Prioritisation<a class="headerlink" href="#packet-prioritisation" title="Link to this heading">¶</a></h3>
|
||||
<p>Currently, Reticulum is completely priority-agnostic regarding general traffic. All traffic is handled
|
||||
on a first-come, first-serve basis. Announce re-transmission are handled according to the re-transmission
|
||||
times and priorities described earlier in this chapter.</p>
|
||||
<p>Currently, Reticulum is completely priority-agnostic regarding <em>general</em> traffic. All traffic is handled
|
||||
on a first-come, first-serve basis. Announce re-transmission and other maintenance traffic is handled
|
||||
according to the re-transmission times and priorities described earlier in this chapter.</p>
|
||||
</section>
|
||||
<section id="interface-access-codes">
|
||||
<h3>Interface Access Codes<a class="headerlink" href="#interface-access-codes" title="Link to this heading">¶</a></h3>
|
||||
<p>Reticulum can create named virtual networks, and networks that are only accessible by knowing a preshared
|
||||
passphrase. The configuration of this is detailed in the <a class="reference internal" href="interfaces.html#interfaces-options"><span class="std std-ref">Common Interface Options</span></a>
|
||||
section. To implement these feature, Reticulum uses the concept of Interface Access Codes, that are calculated
|
||||
and verified per packet.</p>
|
||||
section. To implement this feature, Reticulum uses the concept of Interface Access Codes, that are calculated
|
||||
and verified per-packet.</p>
|
||||
<p>An interface with a named virtual network or passphrase authentication enabled will derive a shared Ed25519
|
||||
signing identity, and for every outbound packet generate a signature of the entire packet. This signature is
|
||||
then inserted into the packet as an Interface Access Code before transmission. Depending on the speed and
|
||||
@@ -1141,6 +1215,10 @@ instead use the internal pure-python primitives. A trivial consequence of this i
|
||||
with the OpenSSL backend being <em>much</em> faster. The most important consequence however, is the
|
||||
potential loss of security by using primitives that has not seen the same amount of scrutiny,
|
||||
testing and review as those from OpenSSL.</p>
|
||||
<p>Using the normal RNS installation procedures, it is not possible to install Reticulum on a
|
||||
system without the required OpenSSL primitives being available, and if they are not, they will
|
||||
be resolved and installed as a dependency. It is only possible to use the pure-python primitives
|
||||
by manually specifying this, for example by using the <code class="docutils literal notranslate"><span class="pre">rnspure</span></code> package.</p>
|
||||
<div class="admonition warning">
|
||||
<p class="admonition-title">Warning</p>
|
||||
<p>If you want to use the internal pure-python primitives, it is <strong>highly advisable</strong> that you
|
||||
@@ -1228,6 +1306,13 @@ those risks are acceptable to you.</p>
|
||||
<li><a class="reference internal" href="#resources">Resources</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#network-identities">Network Identities</a><ul>
|
||||
<li><a class="reference internal" href="#conceptual-overview">Conceptual Overview</a></li>
|
||||
<li><a class="reference internal" href="#current-usage">Current Usage</a></li>
|
||||
<li><a class="reference internal" href="#future-implications">Future Implications</a></li>
|
||||
<li><a class="reference internal" href="#creating-and-using-a-network-identity">Creating and Using a Network Identity</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#reference-setup">Reference Setup</a></li>
|
||||
<li><a class="reference internal" href="#protocol-specifics">Protocol Specifics</a><ul>
|
||||
<li><a class="reference internal" href="#packet-prioritisation">Packet Prioritisation</a></li>
|
||||
@@ -1248,7 +1333,7 @@ those risks are acceptable to you.</p>
|
||||
|
||||
</aside>
|
||||
</div>
|
||||
</div><script src="_static/documentation_options.js?v=baaebd52"></script>
|
||||
</div><script src="_static/documentation_options.js?v=58fbf978"></script>
|
||||
<script src="_static/doctools.js?v=9bcbadda"></script>
|
||||
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
|
||||
<script src="_static/scripts/furo.js?v=46bd48cc"></script>
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
<link rel="prefetch" href="_static/rns_logo_512.png" as="image">
|
||||
|
||||
<!-- Generated with Sphinx 8.2.3 and Furo 2025.09.25.dev1 -->
|
||||
<title>Using Reticulum on Your System - Reticulum Network Stack 1.0.3 documentation</title>
|
||||
<title>Using Reticulum on Your System - Reticulum Network Stack 1.1.1 documentation</title>
|
||||
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=d111a655" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/styles/furo.css?v=580074bf" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/copybutton.css?v=76b2166b" />
|
||||
@@ -180,7 +180,7 @@
|
||||
</label>
|
||||
</div>
|
||||
<div class="header-center">
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.0.3 documentation</div></a>
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.1.1 documentation</div></a>
|
||||
</div>
|
||||
<div class="header-right">
|
||||
<div class="theme-toggle-container theme-toggle-header">
|
||||
@@ -204,7 +204,7 @@
|
||||
<img class="sidebar-logo" src="_static/rns_logo_512.png" alt="Logo"/>
|
||||
</div>
|
||||
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.0.3 documentation</span>
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.1.1 documentation</span>
|
||||
|
||||
</a><form class="sidebar-search-container" method="get" action="search.html" role="search">
|
||||
<input class="sidebar-search" placeholder="Search" name="q" aria-label="Search">
|
||||
@@ -554,8 +554,8 @@ Reticulum Transport Instance <5245a8efe1788c6a1cd36144a270e13b> running
|
||||
</div>
|
||||
<p><strong>All Command-Line Options</strong></p>
|
||||
<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>usage: rnstatus [-h] [--config CONFIG] [--version] [-a] [-A]
|
||||
[-l] [-s SORT] [-r] [-j] [-R hash] [-i path]
|
||||
[-w seconds] [-v] [filter]
|
||||
[-l] [-t] [-s SORT] [-r] [-j] [-R hash] [-i path]
|
||||
[-w seconds] [-d] [-D] [-m] [-I seconds] [-v] [filter]
|
||||
|
||||
Reticulum Network Stack Status
|
||||
|
||||
@@ -569,12 +569,19 @@ options:
|
||||
-a, --all show all interfaces
|
||||
-A, --announce-stats show announce stats
|
||||
-l, --link-stats show link stats
|
||||
-s SORT, --sort SORT sort interfaces by [rate, traffic, rx, tx, announces, arx, atx, held]
|
||||
-t, --totals display traffic totals
|
||||
-s, --sort SORT sort interfaces by [rate, traffic, rx, tx, rxs, txs,
|
||||
announces, arx, atx, held]
|
||||
-r, --reverse reverse sorting
|
||||
-j, --json output in JSON format
|
||||
-R hash transport identity hash of remote instance to get status from (requires -i)
|
||||
-R hash transport identity hash of remote instance to get status from
|
||||
-i path path to identity used for remote management
|
||||
-w seconds timeout before giving up on remote queries
|
||||
-d, --discovered list discovered interfaces
|
||||
-D show details and config entries for discovered interfaces
|
||||
-m, --monitor continuously monitor status
|
||||
-I, --monitor-interval seconds
|
||||
refresh interval for monitor mode (default: 1)
|
||||
-v, --verbose
|
||||
</pre></div>
|
||||
</div>
|
||||
@@ -667,7 +674,7 @@ options:
|
||||
</div>
|
||||
</section>
|
||||
<section id="the-rnpath-utility">
|
||||
<h3>The rnpath Utility<a class="headerlink" href="#the-rnpath-utility" title="Link to this heading">¶</a></h3>
|
||||
<span id="utility-rnpath"></span><h3>The rnpath Utility<a class="headerlink" href="#the-rnpath-utility" title="Link to this heading">¶</a></h3>
|
||||
<p>With the <code class="docutils literal notranslate"><span class="pre">rnpath</span></code> utility, you can look up and view paths for
|
||||
destinations on the Reticulum network.</p>
|
||||
<p><strong>Usage Examples</strong></p>
|
||||
@@ -678,21 +685,23 @@ Path found, destination <c89b4da064bf66d280f0e4d8abfd9806> is 4 hops away
|
||||
</pre></div>
|
||||
</div>
|
||||
<p><strong>All Command-Line Options</strong></p>
|
||||
<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>usage: rnpath [-h] [--config CONFIG] [--version] [-t] [-m hops]
|
||||
[-r] [-d] [-D] [-x] [-w seconds] [-R hash] [-i path]
|
||||
[-W seconds] [-j] [-v] [destination]
|
||||
<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>usage: rnpath [-h] [--config CONFIG] [--version] [-t] [-m hops] [-r] [-d] [-D]
|
||||
[-x] [-w seconds] [-R hash] [-i path] [-W seconds] [-b] [-B] [-U]
|
||||
[--duration DURATION] [--reason REASON] [-p] [-j] [-v]
|
||||
[destination] [list_filter]
|
||||
|
||||
Reticulum Path Discovery Utility
|
||||
Reticulum Path Management Utility
|
||||
|
||||
positional arguments:
|
||||
destination hexadecimal hash of the destination
|
||||
list_filter filter for remote blackhole list view
|
||||
|
||||
options:
|
||||
-h, --help show this help message and exit
|
||||
--config CONFIG path to alternative Reticulum config directory
|
||||
--version show program's version number and exit
|
||||
-t, --table show all known paths
|
||||
-m hops, --max hops maximum hops to filter path table by
|
||||
-m, --max hops maximum hops to filter path table by
|
||||
-r, --rates show announce rate info
|
||||
-d, --drop remove the path to a destination
|
||||
-D, --drop-announces drop all queued announces
|
||||
@@ -701,6 +710,13 @@ options:
|
||||
-R hash transport identity hash of remote instance to manage
|
||||
-i path path to identity used for remote management
|
||||
-W seconds timeout before giving up on remote queries
|
||||
-b, --blackholed list blackholed identities
|
||||
-B, --blackhole blackhole identity
|
||||
-U, --unblackhole unblackhole identity
|
||||
--duration DURATION duration of blackhole enforcement in hours
|
||||
--reason REASON reason for blackholing identity
|
||||
-p, --blackholed-list
|
||||
view published blackhole list for remote transport instance
|
||||
-j, --json output in JSON format
|
||||
-v, --verbose
|
||||
</pre></div>
|
||||
@@ -791,10 +807,15 @@ and simply running the program in listener mode:</p>
|
||||
<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>$ rncp --fetch ~/path/to/file.tgz 73cbd378bb0286ed11a707c13447bb1e
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>The default identity file is stored in <code class="docutils literal notranslate"><span class="pre">~/.reticulum/identities/rncp</span></code>, but you can use
|
||||
another one, which will be created if it does not already exist</p>
|
||||
<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>$ rncp ~/path/to/file.tgz 73cbd378bb0286ed11a707c13447bb1e -i /path/to/identity
|
||||
</pre></div>
|
||||
</div>
|
||||
<p><strong>All Command-Line Options</strong></p>
|
||||
<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>usage: rncp [-h] [--config path] [-v] [-q] [-S] [-l] [-F] [-f]
|
||||
[-j path] [-b seconds] [-a allowed_hash] [-n] [-p]
|
||||
[-w seconds] [--version] [file] [destination]
|
||||
[-i identity] [-w seconds] [--version] [file] [destination]
|
||||
|
||||
Reticulum File Transfer Utility
|
||||
|
||||
@@ -819,6 +840,7 @@ options:
|
||||
-a allowed_hash allow this identity (or add in ~/.rncp/allowed_identities)
|
||||
-n, --no-auth accept requests from anyone
|
||||
-p, --print-identity print identity and destination info and exit
|
||||
-i identity path to identity to use
|
||||
-w seconds sender timeout before giving up
|
||||
-P, --phy-rates display physical layer transfer rates
|
||||
--version show program's version number and exit
|
||||
@@ -963,6 +985,87 @@ options:
|
||||
section of this manual.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="discovering-interfaces">
|
||||
<span id="using-interface-discovery"></span><h2>Discovering Interfaces<a class="headerlink" href="#discovering-interfaces" title="Link to this heading">¶</a></h2>
|
||||
<p>Reticulum includes built-in functionality for discovering connectable interfaces over Reticulum itself. This is particularly useful in situations where you want to do one or more of the following:</p>
|
||||
<ul class="simple">
|
||||
<li><p>Discover connectable entrypoints available on the Internet</p></li>
|
||||
<li><p>Find connectable radio access points in the physical world</p></li>
|
||||
<li><p>Maintain connectivity to RNS instances with unknown or changing IP addresses</p></li>
|
||||
</ul>
|
||||
<p>Discovered interfaces can be <strong>auto-connected</strong> by Reticulum, which makes it possible to create setups where an arbitrary interface can act simply as a bootstrap connection, that can be torn down again once more suitable interfaces have been discovered and connected.</p>
|
||||
<p>The interface discovery mechanism uses announces sent over Reticulum itself, and supports both publicly readable interfaces and private, encrypted discovery, that can only be decoded by specified <em>network identities</em>. It is also possible to specify which network identities should be considered valid sources for discovered interfaces, so that interfaces published by unknown entities are ignored.</p>
|
||||
<div class="admonition note">
|
||||
<p class="admonition-title">Note</p>
|
||||
<p>A <em>network identity</em> is a normal Reticulum identity keyset that can be used by
|
||||
one or more transport nodes to identify them as belonging to the same overall
|
||||
network. In the context of interface discovery, this makes it easy to manage
|
||||
connecting to only the particular networks you care about, even if those networks
|
||||
utilize many individual physical transport node.</p>
|
||||
<p>This also makes it convenient to auto-connect discovered interfaces only for networks you have some level of trust in.</p>
|
||||
</div>
|
||||
<p>For information on how to make your interfaces discoverable, see the <a class="reference internal" href="interfaces.html#interfaces-discoverable"><span class="std std-ref">Discoverable Interfaces</span></a> chapter of this manual. The current section will focus on how to actually <em>discover and connect to</em> interfaces available on the network.</p>
|
||||
<p>In its most basic form, enabling interface discovery is as simple as setting <code class="docutils literal notranslate"><span class="pre">discover_interfaces</span></code> to <code class="docutils literal notranslate"><span class="pre">true</span></code> in your Reticulum config:</p>
|
||||
<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>[reticulum]
|
||||
...
|
||||
discover_interfaces = yes
|
||||
...
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>Once this option is enabled, your RNS instance will start listening for interface discovery announces, and store them for later use or inspection. You can list discovered interfaces with the <code class="docutils literal notranslate"><span class="pre">rnstatus</span></code> utility:</p>
|
||||
<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>$ rnstatus -d
|
||||
|
||||
Name Type Status Last Heard Value Location
|
||||
-------------------------------------------------------------------------
|
||||
Sideband Hub Backbone ✓ Available 1h ago 16 46.2316, 6.0536
|
||||
RNS Amsterdam Backbone ✓ Available 32m ago 16 52.3865, 4.9037
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>You can view more detailed information about discovered interfaces, including configuration snippets for pasting directly into your <code class="docutils literal notranslate"><span class="pre">[interfaces]</span></code> config, by using the <code class="docutils literal notranslate"><span class="pre">rnstatus</span> <span class="pre">-D</span></code> option:</p>
|
||||
<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>$ rnstatus -D sideband
|
||||
|
||||
Transport ID : 521c87a83afb8f29e4455e77930b973b
|
||||
Name : Sideband Hub
|
||||
Type : BackboneInterface
|
||||
Status : Available
|
||||
Transport : Enabled
|
||||
Distance : 2 hops
|
||||
Discovered : 9h and 40m ago
|
||||
Last Heard : 1h and 15m ago
|
||||
Location : 46.2316, 6.0536
|
||||
Address : sideband.connect.reticulum.network:7822
|
||||
Stamp Value : 16
|
||||
|
||||
Configuration Entry:
|
||||
[[Sideband Hub]]
|
||||
type = BackboneInterface
|
||||
enabled = yes
|
||||
remote = sideband.connect.reticulum.network
|
||||
target_port = 7822
|
||||
transport_identity = 521c87a83afb8f29e4455e77930b973b
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>In addition to providing local interface discovery information and control, the <code class="docutils literal notranslate"><span class="pre">rnstatus</span></code> utility can export discovered interface data in machine-readable JSON format using the <code class="docutils literal notranslate"><span class="pre">rnstatus</span> <span class="pre">-d</span> <span class="pre">--json</span></code> option. This can be useful for exporting the data to external applications such as status pages, access point maps and similar.</p>
|
||||
<p>To control what sources are considered valid for discovered sources, additional
|
||||
configuration options can be specified for the interface discovery system.</p>
|
||||
<ul class="simple">
|
||||
<li><p>The <code class="docutils literal notranslate"><span class="pre">interface_discovery_sources</span></code> option is a list of the network or transport identities from which interfaces will be accepted. If this option is set, all others will be ignored. If this option is not set, discovered interfaces will be accepted from any source, but are still subject to stamp value requirements.</p></li>
|
||||
<li><p>The <code class="docutils literal notranslate"><span class="pre">required_discovery_value</span></code> options specifies the minimum stamp value required for the interface announce to be considered valid. To make it computationally difficult to spam the network with a large number of defunct or malicious interfaces, each announced interface requires a valid cryptographical stamp, of configurable difficulty value.</p></li>
|
||||
<li><p>The <code class="docutils literal notranslate"><span class="pre">autoconnect_discovered_interfaces</span></code> value defaults to <code class="docutils literal notranslate"><span class="pre">0</span></code>, and specifies the maximum number of discovered interfaces that should be auto-connected at any given time. If set to a number greater than <code class="docutils literal notranslate"><span class="pre">0</span></code>, Reticulum automatically manages discovered interface connections, and will bring discovered interfaces up and down based on availability. You can at any time add discovered interfaces to your configuration manually, to persistently keep them available.</p></li>
|
||||
<li><p>The <code class="docutils literal notranslate"><span class="pre">network_identity</span></code> option specifies the <em>network identity</em> for this RNS instance. This identity is used both to sign (and potentially encrypt) <em>outgoing</em> interface discovery announces, and to decrypt incoming discovery information.</p></li>
|
||||
</ul>
|
||||
<p>The configuration snippet below contains an example of setting these additional configuration options:</p>
|
||||
<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>[reticulum]
|
||||
...
|
||||
discover_interfaces = yes
|
||||
interface_discovery_sources = 521c87a83afb8f29e4455e77930b973b
|
||||
required_discovery_value = 16
|
||||
autoconnect_discovered_interfaces = 3
|
||||
network_identity = ~/.reticulum/storage/identities/my_network
|
||||
...
|
||||
</pre></div>
|
||||
</div>
|
||||
</section>
|
||||
<section id="remote-management">
|
||||
<h2>Remote Management<a class="headerlink" href="#remote-management" title="Link to this heading">¶</a></h2>
|
||||
<p>It is possible to allow remote management of Reticulum
|
||||
@@ -984,6 +1087,97 @@ remote_management_allowed = 9fb6d773498fb3feda407ed8ef2c3229, 2d882c5586e548d79b
|
||||
</div>
|
||||
<p>For a complete example configuration, you can run <code class="docutils literal notranslate"><span class="pre">rnsd</span> <span class="pre">--exampleconfig</span></code>.</p>
|
||||
</section>
|
||||
<section id="blackhole-management">
|
||||
<span id="using-blackhole-management"></span><h2>Blackhole Management<a class="headerlink" href="#blackhole-management" title="Link to this heading">¶</a></h2>
|
||||
<p>Reticulum networks are fundamentally permissionless and open, allowing anyone with a compatible interface to participate. While this openness is essential for a resilient and decentralized network, it also exposes the network to potential abuse, such as peers flooding the network with excessive announce broadcasts or other forms of resource exhaustion.</p>
|
||||
<p>The <strong>Blackhole</strong> system provides tools to help manage this problem. It allows operators and individual users to block specific identities at the Transport layer, preventing them from propagating announces through your node, and for other nodes to reach them through your network.</p>
|
||||
<div class="admonition important">
|
||||
<p class="admonition-title">Important</p>
|
||||
<p>There is fundamentally <strong>no way</strong> to <em>globally</em> block or censor any identity or destination in Reticulum networks. The blackhole functionality will prevent announces from (and traffic to) all destinations associated with the blackholed identity <em>on your own network segments only</em>.</p>
|
||||
<p>This provides users and operators with control over what they want to allow <em>on their own network segments</em>, but there is no way to globally censor or remove an identity, as long as <em>someone</em> is willing to provide transport for it.</p>
|
||||
</div>
|
||||
<p>This functionality serves a dual purpose:</p>
|
||||
<ul class="simple">
|
||||
<li><p><strong>For Individual Users:</strong> It offers a simple way to maintain a quiet and efficient local network by manually blocking spammy or unwanted peers.</p></li>
|
||||
<li><p><strong>For Network Operators:</strong> It enables the creation of federated, community-wide security standards. By publishing and sharing blackhole lists, operators can protect large infrastructures and distribute spam filtering rules across the mesh without manual intervention.</p></li>
|
||||
</ul>
|
||||
<section id="local-blackhole-management">
|
||||
<h3>Local Blackhole Management<a class="headerlink" href="#local-blackhole-management" title="Link to this heading">¶</a></h3>
|
||||
<p>The most immediate way to manage unwanted identities is through manual configuration using the <code class="docutils literal notranslate"><span class="pre">rnpath</span></code> utility. This allows you to instantly block or unblock specific identities on your local Transport Instance.</p>
|
||||
<p><strong>Blackholing an Identity</strong></p>
|
||||
<p>To block an identity, use the <code class="docutils literal notranslate"><span class="pre">-B</span></code> (or <code class="docutils literal notranslate"><span class="pre">--blackhole</span></code>) flag followed by the identity hash. You can optionally specify a duration and a reason, which are useful for logging and future reference.</p>
|
||||
<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>$ rnpath -B 3a4f8b9c1d2e3f4g5h6i7j8k9l0m1n2o
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>You can also add a duration (in hours) and a reason:</p>
|
||||
<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>$ rnpath -B 3a4f8b9c1d2e3f4g5h6i7j8k9l0m1n2o --duration 24 --reason "Excessive announces"
|
||||
</pre></div>
|
||||
</div>
|
||||
<p><strong>Lifting Blackholes</strong></p>
|
||||
<p>To remove an identity from the blackhole, use the <code class="docutils literal notranslate"><span class="pre">-U</span></code> (or <code class="docutils literal notranslate"><span class="pre">--unblackhole</span></code>) flag:</p>
|
||||
<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>$ rnpath -U 3a4f8b9c1d2e3f4g5h6i7j8k9l0m1n2o
|
||||
</pre></div>
|
||||
</div>
|
||||
<p><strong>Viewing the Blackhole List</strong></p>
|
||||
<p>To see all identities currently blackholed on your local instance, use the <code class="docutils literal notranslate"><span class="pre">-b</span></code> (or <code class="docutils literal notranslate"><span class="pre">--blackholed</span></code>) flag:</p>
|
||||
<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>$ rnpath -b
|
||||
|
||||
<3a4f8b9c1d2e3f4g5h6i7j8k9l0m1n2o> blackholed for 23h, 56m (Excessive announces)
|
||||
<399ea050ce0eed1816c300bcb0840938> blackholed indefinitely (Announce spam)
|
||||
<d56a4fa02c0a77b3575935aedd90bdb2> blackholed indefinitely (Announce spam)
|
||||
<2b9ec651326d9bc274119054c70fb75e> blackholed indefinitely (Announce spam)
|
||||
<1178a8f1fad405bf2ad153bf5036bdfd> blackholed indefinitely (Announce spam)
|
||||
</pre></div>
|
||||
</div>
|
||||
</section>
|
||||
<section id="automated-list-sourcing">
|
||||
<h3>Automated List Sourcing<a class="headerlink" href="#automated-list-sourcing" title="Link to this heading">¶</a></h3>
|
||||
<p>Manually blocking identities is effective for immediate threats, but maintaining an up-to-date blocklist for a large network is impractical. Reticulum supports <strong>automated list sourcing</strong>, allowing your node to subscribe to blackhole lists maintained by trusted peers, or a central authority you manage yourself.</p>
|
||||
<div class="admonition warning">
|
||||
<p class="admonition-title">Warning</p>
|
||||
<p><strong>Verify Before Subscribing!</strong> Subscribing to a blackhole source is a powerful action that grants that source the ability to dictate who you can communicate with. Before adding a source to your configuration, verify that the maintainer aligns with your usage policy and values. Blindly subscribing to untrusted lists could inadvertently block legitimate peers or essential services.</p>
|
||||
</div>
|
||||
<p>When enabled, your Transport Instance will periodically (approximately once per hour) connect to configured sources, retrieve their latest blackhole lists, and automatically merge them into your local blocklist. This provides “set-and-forget” protection for both individual users and large networks.</p>
|
||||
<p><strong>Configuration</strong></p>
|
||||
<p>To enable automated sourcing, add the <code class="docutils literal notranslate"><span class="pre">blackhole_sources</span></code> option to the <code class="docutils literal notranslate"><span class="pre">[reticulum]</span></code> section of your configuration file. This option accepts a comma-separated list of Transport Identity hashes that you trust to provide valid blackhole lists.</p>
|
||||
<div class="highlight-ini notranslate"><div class="highlight"><pre><span></span><span class="k">[reticulum]</span>
|
||||
<span class="na">...</span>
|
||||
<span class="c1"># Automatically fetch blackhole lists from these trusted sources</span>
|
||||
<span class="na">blackhole_sources</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">521c87a83afb8f29e4455e77930b973b, 68a4aa91ac350c4087564e8a69f84e86</span>
|
||||
<span class="na">...</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
<p><strong>How It Works</strong></p>
|
||||
<ol class="arabic simple">
|
||||
<li><p>When enabled, the <code class="docutils literal notranslate"><span class="pre">BlackholeUpdater</span></code> service runs in the background.</p></li>
|
||||
<li><p>For every identity hash listed in <code class="docutils literal notranslate"><span class="pre">blackhole_sources</span></code>, it attempts to establish a temporary link to its associated``rnstransport.info.blackhole`` destination.</p></li>
|
||||
<li><p>It requests the <code class="docutils literal notranslate"><span class="pre">/list</span></code> path, which returns a dictionary of blackholed identities and their associated metadata.</p></li>
|
||||
<li><p>The received list is merged with your local <code class="docutils literal notranslate"><span class="pre">blackholed_identities</span></code> database.</p></li>
|
||||
<li><p>The lists are persisted to disk, ensuring they survive restarts.</p></li>
|
||||
</ol>
|
||||
<div class="admonition note">
|
||||
<p class="admonition-title">Note</p>
|
||||
<p>You can verify the external lists you are subscribed to, and their contents, without importing them by using <code class="docutils literal notranslate"><span class="pre">rnpath</span> <span class="pre">-p</span></code>. See the <a class="reference internal" href="#utility-rnpath"><span class="std std-ref">rnpath utility documentation</span></a> for details on querying remote blackhole lists.</p>
|
||||
</div>
|
||||
</section>
|
||||
<section id="publishing-blackhole-lists">
|
||||
<h3>Publishing Blackhole Lists<a class="headerlink" href="#publishing-blackhole-lists" title="Link to this heading">¶</a></h3>
|
||||
<p>If you are operating a public gateway, a community hub, or simply wish to share your blackhole list with others, you can configure your instance to act as a blackhole list publisher. This allows other nodes to subscribe to <em>your</em> definitions of unwanted traffic.</p>
|
||||
<p><strong>Enabling Publishing</strong></p>
|
||||
<p>To publish your local blackhole list, enable the <code class="docutils literal notranslate"><span class="pre">publish_blackhole</span></code> option in the <code class="docutils literal notranslate"><span class="pre">[reticulum]</span></code> section:</p>
|
||||
<div class="highlight-ini notranslate"><div class="highlight"><pre><span></span><span class="k">[reticulum]</span>
|
||||
<span class="na">...</span>
|
||||
<span class="na">publish_blackhole</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">yes</span>
|
||||
<span class="na">...</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>When this is enabled, your Transport Instance will register a request handler at <code class="docutils literal notranslate"><span class="pre">rnstransport.info.blackhole</span></code>. Any peer that connects to this destination and requests <code class="docutils literal notranslate"><span class="pre">/list</span></code> will receive the complete set of identities currently present in your local blackhole database.</p>
|
||||
<p><strong>Federation and Trust</strong></p>
|
||||
<p>The blackhole system relies on the trust relationship between the subscriber and the publisher. By subscribing to a source, you are implicitly trusting that source to only block identities that are genuinely detrimental to the network.</p>
|
||||
<p>As the ecosystem matures, this system is designed to integrate with <strong>Network Identities</strong>. This allows communities to verify that a published blackhole list is actually provided by a specific network or organization with a certain level of reputation and trustworthiness, adding a layer of cryptographic trust to the federation process. This prevents malicious actors from publishing fake lists intended to censor legitimate traffic.</p>
|
||||
<p>For operators, this creates a scalable model where maintaining a single high-quality blocklist can protect thousands of downstream peers, drastically reducing the administrative.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="improving-system-configuration">
|
||||
<h2>Improving System Configuration<a class="headerlink" href="#improving-system-configuration" title="Link to this heading">¶</a></h2>
|
||||
<p>If you are setting up a system for permanent use with Reticulum, there is a
|
||||
@@ -1170,7 +1364,14 @@ systemctl --user enable rnsd.service
|
||||
<li><a class="reference internal" href="#the-rnodeconf-utility">The rnodeconf Utility</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#discovering-interfaces">Discovering Interfaces</a></li>
|
||||
<li><a class="reference internal" href="#remote-management">Remote Management</a></li>
|
||||
<li><a class="reference internal" href="#blackhole-management">Blackhole Management</a><ul>
|
||||
<li><a class="reference internal" href="#local-blackhole-management">Local Blackhole Management</a></li>
|
||||
<li><a class="reference internal" href="#automated-list-sourcing">Automated List Sourcing</a></li>
|
||||
<li><a class="reference internal" href="#publishing-blackhole-lists">Publishing Blackhole Lists</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#improving-system-configuration">Improving System Configuration</a><ul>
|
||||
<li><a class="reference internal" href="#fixed-serial-port-names">Fixed Serial Port Names</a></li>
|
||||
<li><a class="reference internal" href="#reticulum-as-a-system-service">Reticulum as a System Service</a><ul>
|
||||
@@ -1191,7 +1392,7 @@ systemctl --user enable rnsd.service
|
||||
|
||||
</aside>
|
||||
</div>
|
||||
</div><script src="_static/documentation_options.js?v=baaebd52"></script>
|
||||
</div><script src="_static/documentation_options.js?v=58fbf978"></script>
|
||||
<script src="_static/doctools.js?v=9bcbadda"></script>
|
||||
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
|
||||
<script src="_static/scripts/furo.js?v=46bd48cc"></script>
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
<link rel="prefetch" href="_static/rns_logo_512.png" as="image">
|
||||
|
||||
<!-- Generated with Sphinx 8.2.3 and Furo 2025.09.25.dev1 -->
|
||||
<title>What is Reticulum? - Reticulum Network Stack 1.0.3 documentation</title>
|
||||
<title>What is Reticulum? - Reticulum Network Stack 1.1.1 documentation</title>
|
||||
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=d111a655" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/styles/furo.css?v=580074bf" />
|
||||
<link rel="stylesheet" type="text/css" href="_static/copybutton.css?v=76b2166b" />
|
||||
@@ -180,7 +180,7 @@
|
||||
</label>
|
||||
</div>
|
||||
<div class="header-center">
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.0.3 documentation</div></a>
|
||||
<a href="index.html"><div class="brand">Reticulum Network Stack 1.1.1 documentation</div></a>
|
||||
</div>
|
||||
<div class="header-right">
|
||||
<div class="theme-toggle-container theme-toggle-header">
|
||||
@@ -204,7 +204,7 @@
|
||||
<img class="sidebar-logo" src="_static/rns_logo_512.png" alt="Logo"/>
|
||||
</div>
|
||||
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.0.3 documentation</span>
|
||||
<span class="sidebar-brand-text">Reticulum Network Stack 1.1.1 documentation</span>
|
||||
|
||||
</a><form class="sidebar-search-container" method="get" action="search.html" role="search">
|
||||
<input class="sidebar-search" placeholder="Search" name="q" aria-label="Search">
|
||||
@@ -409,6 +409,7 @@ network, and vice versa.</p>
|
||||
<li><p>Or to quickly create interfaces with custom hardware</p></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><p>Anything else using <a class="reference internal" href="interfaces.html#interfaces-custom"><span class="std std-ref">custom interface modules</span></a> written in Python</p></li>
|
||||
</ul>
|
||||
<p>For a full list and more details, see the <a class="reference internal" href="interfaces.html#interfaces-main"><span class="std std-ref">Supported Interfaces</span></a> chapter.</p>
|
||||
</section>
|
||||
@@ -417,9 +418,7 @@ network, and vice versa.</p>
|
||||
<p>Reticulum is an experimental networking stack, and should be considered as
|
||||
such. While it has been built with cryptography best-practices very foremost in
|
||||
mind, it has not yet been externally security audited, and there could very well be
|
||||
privacy-breaking bugs. To be considered secure, Reticulum needs a thorough
|
||||
security review by independent cryptographers and security researchers. If you
|
||||
want to help out with this, or can help sponsor an audit, please do get in touch.</p>
|
||||
privacy-breaking bugs.</p>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
@@ -494,7 +493,7 @@ want to help out with this, or can help sponsor an audit, please do get in touch
|
||||
|
||||
</aside>
|
||||
</div>
|
||||
</div><script src="_static/documentation_options.js?v=baaebd52"></script>
|
||||
</div><script src="_static/documentation_options.js?v=58fbf978"></script>
|
||||
<script src="_static/doctools.js?v=9bcbadda"></script>
|
||||
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
|
||||
<script src="_static/scripts/furo.js?v=46bd48cc"></script>
|
||||
|
||||
@@ -24,6 +24,7 @@ release = RNS._version.__version__
|
||||
extensions = [
|
||||
"sphinx.ext.autodoc",
|
||||
"sphinx_copybutton",
|
||||
"sphinx_markdown_builder",
|
||||
]
|
||||
|
||||
autodoc_member_order = "bysource"
|
||||
|
||||
@@ -8,7 +8,7 @@ scenarios.
|
||||
|
||||
|
||||
Standalone Reticulum Installation
|
||||
=============================================
|
||||
=================================
|
||||
If you simply want to install Reticulum and related utilities on a system,
|
||||
the easiest way is via the ``pip`` package manager:
|
||||
|
||||
@@ -66,106 +66,10 @@ compiled packages available.
|
||||
Try Using a Reticulum-based Program
|
||||
=============================================
|
||||
|
||||
If you simply want to try using a program built with Reticulum, a few different
|
||||
programs exist that allow basic communication and a range of other useful functions,
|
||||
If you simply want to try using a program built with Reticulum, a :ref:`range of different
|
||||
programs <software-main>` exist that allow basic communication and a various other useful functions,
|
||||
even over extremely low-bandwidth Reticulum networks.
|
||||
|
||||
These programs will let you get a feel for how Reticulum works. They have been designed
|
||||
to run well over networks based on LoRa or packet radio, but can also be used over fast
|
||||
links, such as local WiFi, wired Ethernet, the Internet, or any combination.
|
||||
|
||||
As such, it is easy to get started experimenting, without having to set up any radio
|
||||
transceivers or infrastructure just to try it out. Launching the programs on separate
|
||||
devices connected to the same WiFi network is enough to get started, and physical
|
||||
radio interfaces can then be added later.
|
||||
|
||||
Remote Shell
|
||||
^^^^^^^^^^^^
|
||||
|
||||
The `rnsh <https://github.com/acehoss/rnsh>`_ program lets you establish fully interactive
|
||||
remote shell sessions over Reticulum. It also allows you to pipe any program to or from a
|
||||
remote system, and is similar to how ``ssh`` works. The ``rnsh`` is very efficient, and
|
||||
can facilitate fully interactive shell sessions, even over extremely low-bandwidth links,
|
||||
such as LoRa or packet radio.
|
||||
|
||||
Nomad Network
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
The terminal-based program `Nomad Network <https://github.com/markqvist/nomadnet>`_
|
||||
provides a complete encrypted communications suite built with Reticulum. It features
|
||||
encrypted messaging (both direct and delayed-delivery for offline users), file sharing,
|
||||
and has a built-in text-browser and page server with support for dynamically rendered pages,
|
||||
user authentication and more.
|
||||
|
||||
.. image:: screenshots/nomadnet_3.png
|
||||
:target: _images/nomadnet_3.png
|
||||
|
||||
`Nomad Network <https://github.com/markqvist/nomadnet>`_ is a user-facing client
|
||||
for the messaging and information-sharing protocol
|
||||
`LXMF <https://github.com/markqvist/lxmf>`_, another project built with Reticulum.
|
||||
|
||||
You can install Nomad Network via pip:
|
||||
|
||||
.. code::
|
||||
|
||||
# Install ...
|
||||
pip install nomadnet
|
||||
|
||||
# ... and run
|
||||
nomadnet
|
||||
|
||||
.. note::
|
||||
If this is the very first time you use ``pip`` to install a program
|
||||
on your system, you might need to reboot your system for your program to become
|
||||
available. If you get a "command not found" error or similar when running the
|
||||
program, reboot your system and try again. In some cases, you may even need to
|
||||
manually add the ``pip`` install path to your ``PATH`` environment variable.
|
||||
|
||||
Sideband
|
||||
^^^^^^^^
|
||||
|
||||
If you would rather use a program with a graphical user interface, you can take
|
||||
a look at `Sideband <https://unsigned.io/sideband>`_, which is available for Android,
|
||||
Linux, macOS and Windows.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. image:: screenshots/sideband_devices.webp
|
||||
:align: center
|
||||
:target: _images/sideband_devices.webp
|
||||
|
||||
.. only:: latex
|
||||
|
||||
.. image:: screenshots/sideband_devices.png
|
||||
:align: center
|
||||
:target: _images/sideband_devices.png
|
||||
|
||||
Sideband allows you to communicate with other people or LXMF-compatible
|
||||
systems over Reticulum networks using LoRa, Packet Radio, WiFi, I2P, Encrypted QR
|
||||
Paper Messages, or anything else Reticulum supports. It also interoperates with
|
||||
the Nomad Network program.
|
||||
|
||||
MeshChat
|
||||
^^^^^^^^
|
||||
|
||||
The `Reticulum MeshChat <https://github.com/liamcottle/reticulum-meshchat>`_ application
|
||||
is a user-friendly LXMF client for Linux, macOS and Windows, that also includes a Nomad Network
|
||||
page browser and other interesting functionality.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. image:: screenshots/meshchat_1.webp
|
||||
:align: center
|
||||
:target: _images/meshchat_1.webp
|
||||
|
||||
.. only:: latex
|
||||
|
||||
.. image:: screenshots/meshchat_1.png
|
||||
:align: center
|
||||
:target: _images/meshchat_1.png
|
||||
|
||||
Reticulum MeshChat is of course also compatible with Sideband and Nomad Network, or
|
||||
any other LXMF client.
|
||||
|
||||
Using the Included Utilities
|
||||
=============================================
|
||||
@@ -214,94 +118,108 @@ network just using the default (:ref:`AutoInterface<interfaces-auto>`) configura
|
||||
|
||||
Possibly, the examples in the config file are enough to get you started. If
|
||||
you want more information, you can read the :ref:`Building Networks<networks-main>`
|
||||
and :ref:`Interfaces<interfaces-main>` chapters of this manual.
|
||||
|
||||
Connecting Reticulum Instances Over the Internet
|
||||
================================================
|
||||
Reticulum currently offers three interfaces suitable for connecting instances over the Internet: :ref:`Backbone<interfaces-backbone>`, :ref:`TCP<interfaces-tcps>`
|
||||
and :ref:`I2P<interfaces-i2p>`. Each interface offers a different set of features, and Reticulum
|
||||
users should carefully choose the interface which best suites their needs.
|
||||
|
||||
The ``TCPServerInterface`` allows users to host an instance accessible over TCP/IP. This
|
||||
method is generally faster, lower latency, and more energy efficient than using ``I2PInterface``,
|
||||
however it also leaks more data about the server host.
|
||||
|
||||
The ``BackboneInterface`` is a very fast and efficient interface type available on POSIX operating
|
||||
systems, designed to handle many hundreds of connections simultaneously with low memory, processing
|
||||
and I/O overhead. It is fully compatible with the TCP-based interface types.
|
||||
|
||||
TCP connections reveal the IP address of both your instance and the server to anyone who can
|
||||
inspect the connection. Someone could use this information to determine your location or identity. Adversaries
|
||||
inspecting your packets may be able to record packet metadata like time of transmission and packet size.
|
||||
Even though Reticulum encrypts traffic, TCP does not, so an adversary may be able to use
|
||||
packet inspection to learn that a system is running Reticulum, and what other IP addresses connect to it.
|
||||
Hosting a publicly reachable instance over TCP also requires a publicly reachable IP address,
|
||||
which most Internet connections don't offer anymore.
|
||||
|
||||
The ``I2PInterface`` routes messages through the `Invisible Internet Protocol
|
||||
(I2P) <https://geti2p.net/en/>`_. To use this interface, users must also run an I2P daemon in
|
||||
parallel to ``rnsd``. For always-on I2P nodes it is recommended to use `i2pd <https://i2pd.website/>`_.
|
||||
|
||||
By default, I2P will encrypt and mix all traffic sent over the Internet, and
|
||||
hide both the sender and receiver Reticulum instance IP addresses. Running an I2P node
|
||||
will also relay other I2P user's encrypted packets, which will use extra
|
||||
bandwidth and compute power, but also makes timing attacks and other forms of
|
||||
deep-packet-inspection much more difficult.
|
||||
|
||||
I2P also allows users to host globally available Reticulum instances from non-public IP's and behind firewalls and NAT.
|
||||
|
||||
In general it is recommended to use an I2P node if you want to host a publicly accessible
|
||||
instance, while preserving anonymity. If you care more about performance, and a slightly
|
||||
easier setup, use TCP.
|
||||
and :ref:`Interfaces<interfaces-main>` chapters of this manual, but most importantly,
|
||||
start with reading the next section, :ref:`Bootstrapping Connectivity<bootstrapping-connectivity>`,
|
||||
as this provides the most essential understanding of how to ensure reliable
|
||||
connectivity with a minimum of maintenance.
|
||||
|
||||
|
||||
Connect to the Public Testnet
|
||||
===========================================
|
||||
.. _bootstrapping-connectivity:
|
||||
|
||||
An experimental public testnet has been made accessible by volunteers in the community. You
|
||||
can find interface definitions for adding to your ``.reticulum/config`` file on the
|
||||
`Reticulum Website <https://reticulum.network/connect.html>`_ or the
|
||||
`Community Wiki <https://github.com/markqvist/Reticulum/wiki/Community-Node-List>`_
|
||||
Bootstrapping Connectivity
|
||||
==========================
|
||||
|
||||
You can connect your devices or instances to one or more of these to gain access to any
|
||||
Reticulum networks they are physically connected to. Simply add one or more interface
|
||||
snippets to your config file in the ``[interface]`` section, like in the example below:
|
||||
Reticulum is not a service you subscribe to, nor is it a single global network you "join". It is a *networking stack*; a toolkit for building communications systems that align with your specific values, requirements, and operational environment. The way you choose to connect to other Reticulum peers is entirely your own choice.
|
||||
|
||||
.. code:: ini
|
||||
One of the most powerful aspects of Reticulum is that it provides a multitude of tools to establish, maintain, and optimize connectivity. You can use these tools in isolation or combine them in complex configurations to achieve a vast array of goals.
|
||||
|
||||
# TCP/IP interface to the BetweenTheBorders Hub (community-provided)
|
||||
[[RNS Testnet BetweenTheBorders]]
|
||||
type = TCPClientInterface
|
||||
enabled = yes
|
||||
target_host = reticulum.betweentheborders.com
|
||||
target_port = 4242
|
||||
Whether your aim is to create a completely private, air-gapped network for your family; to build a resilient community mesh that survives infrastructure collapse; to connect far and wide to as many nodes as possible; or simply to maintain a reliable, encrypted link to a specific organization you care about, Reticulum provides the mechanisms to make it happen.
|
||||
|
||||
There is no "right" or "wrong" way to build a Reticulum network, and you don't need to be a network engineer just to get started. If the information flows in the way you intend, and your privacy and security requirements are met, your configuration is a success. Reticulum is designed to make the most challenging and difficult scenarios attainable, even when other networking technologies fail.
|
||||
|
||||
|
||||
Finding Your Way
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
When you first start using Reticulum, you need a way to obtain connectivity with the peers you want to communicate with - the process of *bootstrapping connectivity*.
|
||||
|
||||
.. important::
|
||||
|
||||
A common mistake in modern networking is the reliance on a few centralized, hard-coded entrypoints. If every user simply connects to the same list of public IP addresses found on a website, the network becomes brittle, centralized, and ultimately fails to deliver on the promise of decentralization and resilience. You have a responsibility here.
|
||||
|
||||
Reticulum encourages the approach of *organic growth*. Instead of relying on permanent static connections to distant servers, you can use temporary bootstrap connections to continously *discover* more relevant or local infrastructure. Once discovered, your system can automatically form stronger, more direct links to these peers, and discard the temporary bootstrap links. This results in a web of connections that are geographically relevant, resilient and efficient.
|
||||
|
||||
It *is* possible to simply add a few public entrypoints to the ``[interfaces]`` section of your Reticulum configuration and be connected, but a better option is to enable :ref:`interface discovery<using-interface_discovery>` and either manually select relevant, local interfaces, or enable discovered interface auto-connection.
|
||||
|
||||
A relevant option in this context is the :ref:`bootstrap only<interfaces-options>` interface option. This is an automated tool for better distributing connectivity. By enabling interface discovery and auto-connection, and marking an interface as ``bootstrap_only``, you tell Reticulum to use that interface primarliy to find connectivity options, and then disconnect it once sufficient entrypoints have been discovered. This helps create a network topology that favors locality and resilience over the simple centralization caused by using only a few static entrypoints.
|
||||
|
||||
Good places to find interface definitions for bootstrapping connectivity are websites like
|
||||
`directory.rns.recipes <https://directory.rns.recipes/>`_ and `rmap.world <https://rmap.world/>`_.
|
||||
|
||||
|
||||
Build Personal Infrastructure
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
You do not need a datacenter to be a meaningful part of the Reticulum ecosystem. In fact, the most important nodes in the network are often the smallest ones.
|
||||
|
||||
We strongly encourage everyone, even home users, to think in terms of building **personal infrastructure**. Don't connect every phone, tablet, and computer in your house directly to a public internet gateway. Instead, repurpose an old computer, a Raspberry Pi, or a supported router to act as your own, personal **Transport Node**:
|
||||
|
||||
* Your local Transport Node sits in your home, connected to your WiFi and perhaps a radio interface (like an RNode).
|
||||
* You configure this node with a ``bootstrap_only`` interface (perhaps a TCP tunnel to a wider network) and enable interface discovery.
|
||||
* While you sleep, work, or cook, your node listens to the network. It discovers other local community members, validates their Network Identities, and automatically establishes direct links.
|
||||
* Your personal devices now connect to your *local* node, which is integrated into a living, breathing local mesh. Your traffic flows through local paths provided by other real people in the community rather than bouncing off a distant server.
|
||||
|
||||
**Don't wait for others to build the networks you want to see**. Every network is important, perhaps even most so those that support individual families and persons. Once enough of this personal, local infrastructure exist, connecting them directly to each other, without traversing the public Internet, becomes inevitable.
|
||||
|
||||
|
||||
Mixing Strategies
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
There is no requirement to commit to a single strategy. The most robust setups often mix static, dynamic, and discovered interfaces.
|
||||
|
||||
* **Static Interfaces:** You maintain a permanent interface to a trusted friend or organization using a static configuration.
|
||||
* **Bootstrap Links:** You connect a ``bootstrap_only`` interface to a public gateway on the Internet to scan for new connectable peers or to regain connectivity if your other interfaces fail.
|
||||
* **Local Wide-Area Connectivity:** You run a ``RNodeInterface`` on a shared frequency, giving you completely self-sovereign and private wide-area access to both your own network and other Reticulum peers globally, without any "service providers" being able to control or monitor how you interact with people.
|
||||
|
||||
By combining these methods, you create a system that is secure against single points of failure, adaptable to changing network conditions, and better integrated into your physical and social reality.
|
||||
|
||||
|
||||
Network Health & Responsibility
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
As you participate in the wider networks you discover and build, you will inevitably encounter peers that are misconfigured, malicious, or simply broken. To protect your resources and those of your local peers, you can utilize the :ref:`Blackhole Management<using-blackhole_management>` system.
|
||||
|
||||
Whether you manually block a spamming identity or subscribe to a blackhole list maintained by a trusted Network Identity, these tools help ensure that *your* transport capacity is used for what *you* consider legitimate communication. This keeps your local segment efficient and contributes to the health of the wider network.
|
||||
|
||||
|
||||
Contributing to the Global Ret
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you have the means to host a stable node with a public IP address, consider becoming a :ref:`Public Entrypoint<hosting-entrypoints>`. By :ref:`publishing your interface as discoverable<interfaces-discoverable>`, you provide a potential connection point for others, helping the network grow and reach new areas.
|
||||
|
||||
For guidelines on how to properly configure a public entrypoint, refer to the :ref:`Hosting Public Entrypoints<hosting-entrypoints>` section.
|
||||
|
||||
Connect to the Distributed Backbone
|
||||
===================================
|
||||
|
||||
A global, distributed backbone of Reticulum Transport Nodes is being run by volunteers from around the world. This network constitutes a heterogenous collection of both public and private nodes that form an uncoordinated, voluntary inter-networking backbone that currently provides global transport and internetworking capabilities for Reticulum.
|
||||
|
||||
As a good starting point, you can find interface definitions for connecting your own networks to this backbone on websites such as `directory.rns.recipes <https://directory.rns.recipes/>`_ and `rmap.world <https://rmap.world/>`_.
|
||||
|
||||
.. tip::
|
||||
Ideally, set up a Reticulum Transport Node that your own devices can reach locally, and then
|
||||
connect that transport node to a couple of public entrypoints. This will provide efficient
|
||||
connections and redundancy in case any of them go down.
|
||||
Don't rely on just a single connection to the distributed backbone for everyday use. It is much better to have several redundant connections configured, and enable the interface discovery options, so your nodes can continously discover peering opportunities as the network evolves. Refer to the :ref:`Bootstrapping Connectivity<bootstrapping-connectivity>` section to understand the options.
|
||||
|
||||
Many other Reticulum instances are connecting to this testnet, and you can also join it
|
||||
via other entry points if you know them. There is absolutely no control over the network
|
||||
topography, usage or what types of instances connect. It will also occasionally be used
|
||||
to test various failure scenarios, and there are no availability or service guarantees.
|
||||
Expect weird things to happen on this network, as people experiment and try out things.
|
||||
|
||||
.. warning::
|
||||
It probably goes without saying, but *don't use the testnet entry-points as
|
||||
hardcoded or default interfaces in any applications you ship to users*. When
|
||||
shipping applications, the best practice is to provide your own default
|
||||
connectivity solutions, if needed and applicable, or in most cases, simply
|
||||
leave it up to the user which networks to connect to, and how.
|
||||
|
||||
.. _hosting-entrypoints:
|
||||
|
||||
Hosting Public Entrypoints
|
||||
===========================================
|
||||
==========================
|
||||
|
||||
If you want to host a public (or private) entry-point to a Reticulum network over the
|
||||
Internet, this section offers some helpful pointers. You will need a machine, physical or
|
||||
virtual with a public IP address, that can be reached by other devices on the Internet.
|
||||
If you want to help build a strong global interconnection backbone, you can host a public (or private) entry-point to a Reticulum network over the
|
||||
Internet. This section offers some helpful pointers. Once you have set up your public entrypoint, it is a great idea to :ref:`make it discoverable over Reticulum<interfaces-discoverable>`.
|
||||
|
||||
You will need a machine, physical or virtual with a public IP address, that can be reached by other devices on the Internet.
|
||||
|
||||
The most efficient and performant way to host a connectable entry-point supporting many
|
||||
users is to use the ``BackboneInterface``. This interface type is fully compatible with
|
||||
@@ -347,8 +265,47 @@ If you are hosting an entry-point on an operating system that does not support
|
||||
``BackboneInterface``, you can use ``TCPServerInterface`` instead, although it will
|
||||
not be as performant.
|
||||
|
||||
|
||||
Connecting Reticulum Instances Over the Internet
|
||||
================================================
|
||||
Reticulum currently offers three interfaces suitable for connecting instances over the Internet: :ref:`Backbone<interfaces-backbone>`, :ref:`TCP<interfaces-tcps>`
|
||||
and :ref:`I2P<interfaces-i2p>`. Each interface offers a different set of features, and Reticulum
|
||||
users should carefully choose the interface which best suites their needs.
|
||||
|
||||
The ``TCPServerInterface`` allows users to host an instance accessible over TCP/IP. This
|
||||
method is generally faster, lower latency, and more energy efficient than using ``I2PInterface``,
|
||||
however it also leaks more data about the server host.
|
||||
|
||||
The ``BackboneInterface`` is a very fast and efficient interface type available on POSIX operating
|
||||
systems, designed to handle thousands of connections simultaneously with low memory, processing
|
||||
and I/O overhead. It is fully compatible with the TCP-based interface types.
|
||||
|
||||
TCP connections reveal the IP address of both your instance and the server to anyone who can
|
||||
inspect the connection. Someone could use this information to determine your location or identity. Adversaries
|
||||
inspecting your packets may be able to record packet metadata like time of transmission and packet size.
|
||||
Even though Reticulum encrypts traffic, TCP does not, so an adversary may be able to use
|
||||
packet inspection to learn that a system is running Reticulum, and what other IP addresses connect to it.
|
||||
Hosting a publicly reachable instance over TCP also requires a publicly reachable IP address,
|
||||
which most Internet connections don't offer anymore.
|
||||
|
||||
The ``I2PInterface`` routes messages through the `Invisible Internet Protocol
|
||||
(I2P) <https://geti2p.net/en/>`_. To use this interface, users must also run an I2P daemon in
|
||||
parallel to ``rnsd``. For always-on I2P nodes it is recommended to use `i2pd <https://i2pd.website/>`_.
|
||||
|
||||
By default, I2P will encrypt and mix all traffic sent over the Internet, and
|
||||
hide both the sender and receiver Reticulum instance IP addresses. Running an I2P node
|
||||
will also relay other I2P user's encrypted packets, which will use extra
|
||||
bandwidth and compute power, but also makes timing attacks and other forms of
|
||||
deep-packet-inspection much more difficult.
|
||||
|
||||
I2P also allows users to host globally available Reticulum instances from non-public IP's and behind firewalls and NAT.
|
||||
|
||||
In general it is recommended to use an I2P node if you want to host a publicly accessible
|
||||
instance, while preserving anonymity. If you care more about performance, and a slightly
|
||||
easier setup, use TCP.
|
||||
|
||||
Adding Radio Interfaces
|
||||
==============================================
|
||||
=======================
|
||||
Once you have Reticulum installed and working, you can add radio interfaces with
|
||||
any compatible hardware you have available. Reticulum supports a wide range of radio
|
||||
hardware, and if you already have any available, it is very likely that it will
|
||||
@@ -360,24 +317,22 @@ cheaply build an :ref:`RNode<rnode-main>`, which is a general-purpose long-range
|
||||
digital radio transceiver, that integrates easily with Reticulum.
|
||||
|
||||
To build one yourself requires installing a custom firmware on a supported LoRa
|
||||
development board with an auto-install script. Please see the :ref:`Communications Hardware<hardware-main>`
|
||||
chapter for a guide. If you prefer purchasing a ready-made unit, you can refer to the
|
||||
:ref:`list of suppliers<rnode-suppliers>`. For more information on RNode, you can also
|
||||
refer to these additional external resources:
|
||||
development board with an auto-install script or web-based flasher.
|
||||
Please see the :ref:`Communications Hardware<hardware-main>` chapter for a guide.
|
||||
If you prefer purchasing a ready-made unit, you can refer to the
|
||||
:ref:`list of suppliers<rnode-suppliers>`.
|
||||
|
||||
* `How To Make Your Own RNodes <https://unsigned.io/how-to-make-your-own-rnodes/>`_
|
||||
* `Installing RNode Firmware on Compatible LoRa Devices <https://unsigned.io/installing-rnode-firmware-on-supported-devices/>`_
|
||||
* `Private, Secure and Uncensorable Messaging Over a LoRa Mesh <https://unsigned.io/private-messaging-over-lora/>`_
|
||||
* `RNode Firmware <https://github.com/markqvist/RNode_Firmware/>`_
|
||||
Other radio-based hardware interfaces are being developed and made available by
|
||||
the broader Reticulum community. You can find more information on such topics
|
||||
over Reticulum-based information sharing systems.
|
||||
|
||||
If you have communications hardware that is not already supported by any of the
|
||||
:ref:`existing interface types<interfaces-main>`, but you think would be suitable for use with Reticulum,
|
||||
you are welcome to head over to the `GitHub discussion pages <https://github.com/markqvist/Reticulum/discussions>`_
|
||||
and propose adding an interface for the hardware.
|
||||
:ref:`existing interface types<interfaces-main>`, it is easy to write (and potentially
|
||||
publish) a :ref:`custom interface module<interfaces-custom>` that makes it compatible with Reticulum.
|
||||
|
||||
|
||||
Creating and Using Custom Interfaces
|
||||
===========================================
|
||||
====================================
|
||||
|
||||
While Reticulum includes a flexible and broad range of built-in interfaces, these
|
||||
will not cover every conceivable type of communications hardware that Reticulum
|
||||
@@ -404,54 +359,10 @@ ready to import and use RNS in your own programs. The next step will most
|
||||
likely be to look at some :ref:`Example Programs<examples-main>`.
|
||||
|
||||
The entire Reticulum API is documented in the :ref:`API Reference<api-main>`
|
||||
chapter of this manual.
|
||||
chapter of this manual. Before diving in, it's probably a good idea to read
|
||||
this manual in full, but at least start with the :ref:`Understanding Reticulum<understanding-main>` chapter.
|
||||
|
||||
|
||||
Participate in Reticulum Development
|
||||
==============================================
|
||||
If you want to participate in the development of Reticulum and associated
|
||||
utilities, you'll want to get the latest source from GitHub. In that case,
|
||||
don't use pip, but try this recipe:
|
||||
|
||||
.. code:: shell
|
||||
|
||||
# Install dependencies
|
||||
pip install cryptography pyserial
|
||||
|
||||
# Clone repository
|
||||
git clone https://github.com/markqvist/Reticulum.git
|
||||
|
||||
# Move into Reticulum folder and symlink library to examples folder
|
||||
cd Reticulum
|
||||
ln -s ../RNS ./Examples/
|
||||
|
||||
# Run an example
|
||||
python Examples/Echo.py -s
|
||||
|
||||
# Unless you've manually created a config file, Reticulum will do so now,
|
||||
# and immediately exit. Make any necessary changes to the file:
|
||||
nano ~/.reticulum/config
|
||||
|
||||
# ... and launch the example again.
|
||||
python Examples/Echo.py -s
|
||||
|
||||
# You can now repeat the process on another computer,
|
||||
# and run the same example with -h to get command line options.
|
||||
python Examples/Echo.py -h
|
||||
|
||||
# Run the example in client mode to "ping" the server.
|
||||
# Replace the hash below with the actual destination hash of your server.
|
||||
python Examples/Echo.py 174a64852a75682259ad8b921b8bf416
|
||||
|
||||
# Have a look at another example
|
||||
python Examples/Filetransfer.py -h
|
||||
|
||||
When you have experimented with the basic examples, it's time to go read the
|
||||
:ref:`Understanding Reticulum<understanding-main>` chapter. Before submitting
|
||||
your first pull request, it is probably a good idea to introduce yourself on
|
||||
the `disucssion forum on GitHub <https://github.com/markqvist/Reticulum/discussions>`_,
|
||||
or ask one of the developers or maintainers for a good place to start.
|
||||
|
||||
.. _install-guides:
|
||||
|
||||
Platform-Specific Install Notes
|
||||
|
||||
@@ -20,6 +20,7 @@ to participate in the development of Reticulum itself.
|
||||
|
||||
whatis
|
||||
gettingstartedfast
|
||||
software
|
||||
using
|
||||
understanding
|
||||
hardware
|
||||
|
||||
@@ -356,6 +356,7 @@ software-based soundmodems. To do this, use the ``kiss_framing`` option:
|
||||
kiss_framing = True
|
||||
target_host = 127.0.0.1
|
||||
target_port = 8001
|
||||
fixed_mtu = 500
|
||||
|
||||
**Caution!** Only use the KISS framing option when connecting to external devices
|
||||
and programs like soundmodems and similar over TCP. When using the
|
||||
@@ -364,6 +365,9 @@ never enable ``kiss_framing``, since this will disable internal reliability and
|
||||
recovery mechanisms that greatly improves performance over unreliable and
|
||||
intermittent TCP links.
|
||||
|
||||
For KISS devices that need only supports a particular MTU, you can use the
|
||||
``fixed_mtu`` option.
|
||||
|
||||
.. note::
|
||||
The TCP interfaces support tunneling over I2P, but to do so reliably,
|
||||
you must use the i2p_tunneled option:
|
||||
@@ -907,6 +911,213 @@ beaconing functionality described above.
|
||||
# small internal packet buffer.
|
||||
flow_control = false
|
||||
|
||||
.. _interfaces-discoverable:
|
||||
|
||||
Discoverable Interfaces
|
||||
=======================
|
||||
|
||||
Reticulum includes a powerful system for publishing your local interfaces to the wider network, allowing other peers to :ref:`discover, validate, and automatically connect to them<using-interface_discovery>`. This feature is particularly useful for creating decentralized networks where peers can dynamically find entrypoints, such as public Internet gateways or local radio access points, without relying on static configuration files or centralized directories.
|
||||
|
||||
When an interface is made **discoverable**, your Reticulum instance will periodically broadcast an announce packet containing the connection details and parameters required for other peers to establish a connection. These announces are propagated over the network using the standard Reticulum announce mechanism using the ``rnstransport.discovery.interface`` destination type.
|
||||
|
||||
.. note::
|
||||
To use the interface discovery functionality, the ``LXMF`` module must be installed in your Python environment. You can install it using pip:
|
||||
|
||||
.. code:: sh
|
||||
|
||||
pip install lxmf
|
||||
|
||||
|
||||
Enabling Discovery
|
||||
------------------
|
||||
|
||||
Interface discovery is enabled on a per-interface basis. To make a specific interface discoverable, you must add the ``discoverable`` option to that interface's configuration block and set it to ``yes``.
|
||||
|
||||
.. code:: ini
|
||||
|
||||
[[My Public Gateway]]
|
||||
type = BackboneInterface
|
||||
...
|
||||
discoverable = yes
|
||||
|
||||
Once enabled, Reticulum will automatically handle the generation, signing, stamping, and broadcasting of the discovery announces. It is not *required* to enable Transport to publish interface discovery information, but for most use cases where you want others to connect to you, you will likely want ``enable_transport`` set to ``yes`` in the ``[reticulum]`` section of your configuration.
|
||||
|
||||
|
||||
Discovery Parameters
|
||||
--------------------
|
||||
|
||||
When ``discoverable`` is enabled, a variety of additional options become available to control how the interface is presented to the network. These parameters allow you to fine-tune the metadata, security requirements, and visibility of your interface.
|
||||
|
||||
**Basic Metadata**
|
||||
|
||||
``discovery_name``
|
||||
A human-readable name for the interface. This name will be displayed to users on remote systems when they list discovered interfaces. If not specified, the interface name (the section header) will be used.
|
||||
|
||||
``announce_interval``
|
||||
The interval in minutes between successive discovery announces for this interface. Default is 360 minutes (6 hours). For stable, long-running infrastructure, higher intervals (12 to 22 hours) are usually sufficient and reduce network load. Minimum allowed value is 5 minutes (but expect to have your announces throttled if using intervals below one hour).
|
||||
|
||||
**Connectivity Specification**
|
||||
|
||||
``reachable_on``
|
||||
Specifies the address that remote peers should use to connect to this interface.
|
||||
|
||||
* For TCP and Backbone interfaces, this is typically the public IP address or hostname. Do not include the port, this is fetched automatically from the interface.
|
||||
* For I2P interfaces, this is usually the I2P ``b32`` address. This value is fetched automatically from the ``I2PInterface`` once it is up and connected to the I2P network, so you should not set this manually, unless you absolutely know what you're doing.
|
||||
|
||||
**Dynamic Resolution:** This option also accepts a path to an external executable script or binary. If a path is provided, Reticulum will execute the script and use its ``stdout`` as the reachability address. This is useful for devices behind dynamic DNS, NATs, or complex cloud environments where the external IP is not known locally. The script must simply print the address to stdout and exit.
|
||||
|
||||
.. note::
|
||||
When using an executable script for ``reachable_on``, Reticulum expects the script to output only the IP address or hostname to ``stdout``, followed by a newline character. Any additional output or errors may cause the resolution to fail. Ensure the script has executable permissions and is robust against temporary network failures.
|
||||
|
||||
A minimal example of a script that resolves the externally available, public IP of an internet-connected system could look like this:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
#!/bin/bash
|
||||
curl -s ip.me
|
||||
exit $?
|
||||
|
||||
On a real system, you should make the script robust enough to deal with intermittent Internet or service failures, such that the script *always* returns a sensible value, or if not possible at least exits with a non-zero exit return code, so Reticulum knows the output is invalid.
|
||||
|
||||
**Security & Cost**
|
||||
|
||||
``discovery_stamp_value``
|
||||
Defines the proof-of-work difficulty for the cryptographic stamp included in the announce. This value acts as a cost barrier to prevent network flooding. The default value is ``14``. Increasing this value makes it computationally more expensive to generate an announce, which can be useful to prevent spam on very large networks, but it also increases CPU load on your system when generating announces. Stamps are cached, and only generated if interface information changes, or at instance restart. If you have the computational resources, it is generally advisable to use as high a stamp value as possible.
|
||||
|
||||
**Privacy & Encryption**
|
||||
|
||||
``discovery_encrypt``
|
||||
If set to ``yes``, the discovery announce payload will be encrypted. To decrypt the announce, remote peers must possess the *network identity* configured for your instance (see ``network_identity`` in the ``[reticulum]`` section). This allows you to publish private interfaces that are only discoverable to specific trusted networks.
|
||||
|
||||
.. important::
|
||||
If you enable ``discovery_encrypt`` but do not configure a valid ``network_identity`` in the ``[reticulum]`` section of your configuration, Reticulum will abort the interface discovery announce. Encryption requires a valid network identity key to function.
|
||||
|
||||
``publish_ifac``
|
||||
If set to ``yes``, the Interface Access Code (IFAC) name and passphrase for this interface will be included in the discovery announce. This allows peers to automatically configure the correct authentication parameters when connecting to the interface.
|
||||
|
||||
**Physical Location**
|
||||
|
||||
``latitude``, ``longitude``, ``height``
|
||||
Optional physical coordinates for the interface. These are useful for mapping discovered interfaces geographically or for clients to automatically select the nearest access point. Coordinates should be in decimal degrees, height in meters.
|
||||
|
||||
**Radio Parameters**
|
||||
|
||||
For physical radio interfaces like ``RNodeInterface`` or ``KISSInterface``, the following optional parameters allow you to broadcast the operating frequency and characteristics, allowing clients to verify compatibility before connecting:
|
||||
|
||||
``discovery_frequency``
|
||||
The operating frequency in Hz. Auto-configured on RNode interfaces. Necessary on KISS-based radio interfaces and ``TCPClientInterfaces`` connecting to radio modems.
|
||||
|
||||
``discovery_bandwidth``
|
||||
The signal bandwidth in Hz. Auto-configured on RNode interfaces. Useful on KISS-based radio interfaces and ``TCPClientInterfaces`` connecting to radio modems.
|
||||
|
||||
``discovery_modulation``
|
||||
The modulation type or scheme. Auto-configured on RNode interfaces, but highly advisable to include on other radio-based interfaces.
|
||||
|
||||
|
||||
Interface Modes
|
||||
---------------
|
||||
|
||||
When you enable discovery on an interface, Reticulum enforces certain interface modes to ensure the interface is actually useful for remote peers.
|
||||
|
||||
If an interface is configured as ``discoverable``, but its mode is not explicitly set to ``gateway`` (for server-style interfaces like ``BackboneInterface`` or ``TCPServerInterface``) or ``access_point`` (for radio interfaces like ``RNodeInterface``), Reticulum will automatically configure the appropriate mode and log a notice.
|
||||
|
||||
For example, if you enable discovery on a ``RNodeInterface`` without specifying the mode, Reticulum will automatically set it to ``access_point`` mode.
|
||||
|
||||
Security Considerations
|
||||
-----------------------
|
||||
|
||||
When making interfaces discoverable, you are effectively broadcasting an invitation to connect to your system. It is important to understand the security implications of the configuration options you choose.
|
||||
|
||||
**Publishing Credentials**
|
||||
|
||||
If you enable ``publish_ifac = yes``, your interface's authentication passphrase will be included in the announce. If you are operating a public network and want anyone to connect, this is acceptable. However, if you wish to restrict access to a specific group of users, you **must** enable ``discovery_encrypt = yes``. This ensures that only peers possessing the correct ``network_identity`` can decode the passphrase.
|
||||
|
||||
**Topology Exposure**
|
||||
|
||||
A discoverable interface announces its presence, location (if configured), and capabilities to the network. Even if the connection details are encrypted, the *fact* that a connectable node exists within a certain network becomes public information. In high-security or scenarios requiring operational secrecy, consider the implications of advertising your infrastructure's existence.
|
||||
|
||||
Example Configuration
|
||||
---------------------
|
||||
|
||||
Below is an example configuration for a public backbone gateway. This configuration publishes a high-value, publicly discoverable interface, that anyone can connect to.
|
||||
|
||||
.. code:: ini
|
||||
|
||||
[[My Public Gateway]]
|
||||
type = BackboneInterface
|
||||
mode = gateway
|
||||
listen_on = 0.0.0.0
|
||||
port = 4242
|
||||
|
||||
# Enable Discovery
|
||||
discoverable = yes
|
||||
|
||||
# Interface Details
|
||||
discovery_name = Region A Public Entrypoint
|
||||
announce_interval = 720
|
||||
|
||||
# Use external script to resolve dynamic IP
|
||||
reachable_on = /usr/local/bin/get_external_ip.sh
|
||||
|
||||
# Generate high stamp value
|
||||
discovery_stamp_value = 24
|
||||
|
||||
# Optional location data
|
||||
latitude = 51.99714
|
||||
longitude = -0.74195
|
||||
height = 15
|
||||
|
||||
The next example create an encrypted discovery-enabled interface, requiring a specific network identity to decode, and includes IFAC credentials for seamless authentication.
|
||||
|
||||
.. code:: ini
|
||||
|
||||
[[My Private Gateway]]
|
||||
type = BackboneInterface
|
||||
mode = gateway
|
||||
listen_on = 0.0.0.0
|
||||
port = 5858
|
||||
network_name = internal_1
|
||||
passphrase = Mevpekyafshak5Wr
|
||||
|
||||
# Enable Discovery
|
||||
discoverable = yes
|
||||
|
||||
# Interface Details
|
||||
discovery_name = Region A Private Backbone
|
||||
announce_interval = 720
|
||||
|
||||
# Use external script to resolve dynamic IP
|
||||
reachable_on = /usr/local/bin/get_external_ip.sh
|
||||
|
||||
# Target stamp value
|
||||
discovery_stamp_value = 22
|
||||
|
||||
# Encrypt announces for our network only
|
||||
discovery_encrypt = yes
|
||||
|
||||
# Include credentials so trusted
|
||||
# peers can connect automatically
|
||||
publish_ifac = yes
|
||||
|
||||
# Optional location data
|
||||
latitude = 34.06915
|
||||
longitude = -118.44318
|
||||
height = 15
|
||||
|
||||
In the ``[reticulum]`` section of your configuration, you would define the network identity used for encryption as follows:
|
||||
|
||||
.. code:: ini
|
||||
|
||||
[reticulum]
|
||||
...
|
||||
# The identity used to sign/encrypt discovery announces
|
||||
network_identity = ~/.reticulum/storage/identities/my_network_identity
|
||||
...
|
||||
|
||||
With these configuration options applied, your Reticulum instance will actively participate in the network's discovery ecosystem. Other peers running Reticulum with discovery enabled will be able to see your interface, validate its cryptographic stamp, and (depending on their configuration) automatically connect to it.
|
||||
|
||||
For information on how to use these discovered interfaces and configure your system to auto-connect to them, refer to the :ref:`Discovering Interfaces<using-interface_discovery>` chapter.
|
||||
|
||||
.. _interfaces-options:
|
||||
|
||||
Common Interface Options
|
||||
@@ -987,6 +1198,15 @@ These can be used to control various aspects of interface behaviour.
|
||||
option, to set the interface speed in *bits per second*.
|
||||
|
||||
|
||||
* | The ``bootstrap_only`` option designates an interface as a temporary
|
||||
bridge for initial connectivity. If this option is enabled, the
|
||||
interface will be monitored and automatically detached once the
|
||||
number of auto-connected interfaces reaches the limit configured by
|
||||
``autoconnect_discovered_interfaces``. This is particularly useful
|
||||
for using a slow or expensive connection (such as a single LoRa
|
||||
link or a remote TCP tunnel) solely to discover better local
|
||||
infrastructure, which then supersedes the bootstrap interface.
|
||||
|
||||
.. _interfaces-modes:
|
||||
|
||||
Interface Modes
|
||||
|
||||
@@ -4,17 +4,47 @@
|
||||
Building Networks
|
||||
*****************
|
||||
|
||||
This chapter will provide you with the knowledge needed to build networks with
|
||||
Reticulum, which can often be easier than using traditional stacks, since you
|
||||
don't have to worry about coordinating addresses, subnets and routing for an
|
||||
This chapter will provide you with the high-level knowledge needed to build networks with
|
||||
Reticulum. It will not, however tell you all you need to know to succesfully
|
||||
design and configure every kind of network you can imagine. For this, you will
|
||||
most likely need to read this manual in its entirity, invest significant time
|
||||
into experimenting with the stack, and learning functionality intuitively.
|
||||
|
||||
Still, after reading this chapter, you should be well equipped to *start* that
|
||||
journey. While Reticulum is **fundamentally different** compared to other
|
||||
networking technologies, it can often be easier than using traditional stacks.
|
||||
If you've built networks before, you will probably have to forget, or at least
|
||||
temporarily ignore, a lot of things at this point. It will all makes sense in
|
||||
the end though. Hopefully.
|
||||
|
||||
If you're used to protocols like IP, let's at least start with some relief:
|
||||
You don't have to worry about coordinating addresses, subnets and routing for an
|
||||
entire network that you might not know how will evolve in the future. With
|
||||
Reticulum, you can simply add more segments to your network when it becomes
|
||||
necessary, and Reticulum will handle the convergence of the entire network
|
||||
automatically.
|
||||
automatically. There's plenty more neat aspects like that to Reticulum, but
|
||||
we're getting ahead of ourselves. Let's cover the basics first.
|
||||
|
||||
Concepts & Overview
|
||||
--------------------
|
||||
|
||||
Before you start building your own networks, it's important to understand the
|
||||
fundamental principles that distinguish Reticulum networks from traditional
|
||||
networking approaches. These principles shape how you design your network,
|
||||
what trade-offs you encounter, and what capabilities you can rely on.
|
||||
|
||||
Reticulum is not a single network you "join", it is a toolkit for *creating* networks.
|
||||
You decide what mediums to use, how nodes connect, what trust boundaries exist,
|
||||
and what the network's purpose is. Reticulum provides the cryptographic foundation,
|
||||
the transport mechanisms, and the convergence algorithms that make your design
|
||||
workable. You provide the intent and the structure.
|
||||
|
||||
This approach offers tremendous flexibility, but it requires thinking in terms of
|
||||
different abstractions than those used in conventional networking.
|
||||
|
||||
Introductory Considerations
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
There are important points that need to be kept in mind when building networks
|
||||
with Reticulum:
|
||||
|
||||
@@ -31,6 +61,11 @@ with Reticulum:
|
||||
interconnect with much larger and higher bandwidth networks without issue.
|
||||
Reticulum automatically manages the flow of information to and from various
|
||||
network segments, and when bandwidth is limited, local traffic is prioritised.
|
||||
You will, however, need to configure your interfaces correctly. If you tell
|
||||
Reticulum to pass all announce traffic from a gigabit link to a LoRa interfaces,
|
||||
it will try as best as possible to comply with this, while still respecting
|
||||
bandwidth limits, but you *will* waste a lot of precious bandwidth and airtime,
|
||||
and your LoRa network will not work very well.
|
||||
|
||||
* | Reticulum provides sender/initiator anonymity by default. There is no way
|
||||
to filter traffic or discriminate it based on the source of the traffic.
|
||||
@@ -89,81 +124,227 @@ Any number of interfaces can be configured, and Reticulum will automatically
|
||||
decide which are suitable to use in any given situation, depending on where
|
||||
traffic needs to flow.
|
||||
|
||||
Example Scenarios
|
||||
-----------------
|
||||
Destinations, Not Addresses
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This section illustrates a few example scenarios, and how they would, in general
|
||||
terms, be planned, implemented and configured.
|
||||
In traditional networking, addresses are allocated from a managed space. If you want to
|
||||
communicate with another node, you need to know its address, and that address
|
||||
must be unique within the network segment. This requires coordination, either
|
||||
through manual assignment, DHCP servers, or other allocation mechanisms.
|
||||
|
||||
Interconnected LoRa Sites
|
||||
=========================
|
||||
Reticulum replaces addresses with **destinations**. A destination is identified by a 16-byte
|
||||
hash (128 bits) derived from a SHA-256 hash of the destination's identifying
|
||||
characteristics. This hash serves as the address on the network. On the network, it
|
||||
is represented in binary, but when displayed to human users, it will usually look something like
|
||||
this ``<13425ec15b621c1d928589718000d814>``.
|
||||
|
||||
An organisation wants to provide communication and information services to it's
|
||||
members, which are located mainly in three separate areas. Three suitable hill-top
|
||||
locations are found, where the organisation can install equipment: Site A, B and C.
|
||||
The critical difference is that *any node can generate as many destinations as it
|
||||
needs, without coordination*. A destination's uniqueness is guaranteed by the
|
||||
collision resistance of SHA-256 and the inclusion of the node's public key in the
|
||||
hash calculation. Two nodes can both use the destination name
|
||||
``messenger.user.inbox``, but they will have different destination hashes because
|
||||
their public keys differ. Both can coexist on the same network without conflict.
|
||||
|
||||
Since the amount of data that needs to be exchanged between users is mainly text-
|
||||
based, the bandwidth requirements are low, and LoRa radios are chosen to connect
|
||||
users to the network.
|
||||
This has profound implications for network design:
|
||||
|
||||
Due to the hill-top locations found, there is radio line-of-sight between site A
|
||||
and B, and also between site B and C. Because of this, the organisation does not
|
||||
need to use the Internet to interconnect the sites, but purchases four Point-to-Point
|
||||
WiFi based radios for interconnecting the sites.
|
||||
* **No address allocation planning:** You never need to reserve address ranges,
|
||||
plan subnets, or coordinate with other network operators. Nodes simply generate
|
||||
destinations and announce them.
|
||||
|
||||
At each site, a Raspberry Pi is installed to function as a gateway. A LoRa radio
|
||||
is connected to the Pi with a USB cable, and the WiFi radio is connected to the
|
||||
Ethernet port of the Pi. At site B, two WiFi radios are needed to be able to reach
|
||||
both site A and site C, so an extra Ethernet adapter is connected to the Pi in
|
||||
this location.
|
||||
* **Global portability:** A destination is not tied to a physical location or
|
||||
network segment. A node can move its destinations across interfaces, mediums,
|
||||
or even between entirely separate Reticulum networks simply by sending an
|
||||
announce on the new medium.
|
||||
|
||||
Once the hardware has been installed, Reticulum is installed on all the Pis, and at
|
||||
site A and C, one interface is added for the LoRa radio, as well as one for the WiFi
|
||||
radio. At site B, an interface for the LoRa radio, and one interface for each WiFi
|
||||
radio is added to the Reticulum configuration file. The transport node option is
|
||||
enabled in the configuration of all three gateways.
|
||||
* **Implicit authentication:** Because destinations are bound to public keys,
|
||||
communication to a destination is inherently cryptographically authenticated.
|
||||
Only the holder of the corresponding private key can decrypt and respond to
|
||||
traffic addressed to that destination. This also makes application-level
|
||||
authentication *much* simpler, since it can directly use the foundational
|
||||
identity verification built into the core networking layer.
|
||||
|
||||
The network is now operational, and ready to serve users across all three areas.
|
||||
The organisation prepares a LoRa radio that is supplied to the end users, along
|
||||
with a Reticulum configuration file, that contains the right parameters for
|
||||
communicating with the LoRa radios installed at the gateway sites.
|
||||
* **Identity abstraction:** A single Reticulum Identity can create multiple
|
||||
destinations. This allows a single entity (a person, a device, a service) to
|
||||
present multiple endpoints without needing multiple cryptographic keypairs.
|
||||
|
||||
Once users connect to the network, anyone will be able to communicate with anyone
|
||||
else across all three sites.
|
||||
|
||||
Bridging Over the Internet
|
||||
==========================
|
||||
Transport Nodes and Instances
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
As the organisation grows, several new communities form in places too far away
|
||||
from the core network to be reachable over WiFi links. New gateways similar to those
|
||||
previously installed are set up for the new communities at the new sites D and E, but
|
||||
they are islanded from the core network, and only serve the local users.
|
||||
Reticulum distinguishes between two types of nodes: **Instances**
|
||||
and **Transport Nodes**. Every node running Reticulum is an Instance, but not
|
||||
every Instance is a Transport Node.
|
||||
|
||||
After investigating the options, it is found that it is possible to install an
|
||||
Internet connection at site A, and an interface on the Internet connection is
|
||||
configured for Reticulum on the Raspberry Pi at site A.
|
||||
A **Reticulum Instance** is any system running the Reticulum stack. It can create
|
||||
destinations, send and receive packets, establish links, and communicate with
|
||||
other nodes. It can also host destinations that are connectable for *anyone* else
|
||||
in the network. This means you can easily host globally available services from
|
||||
any location, including your home or office. Network-wide, global connectivity
|
||||
for all destinations is guaranteed, as long as there is *some* physical way to
|
||||
actually transport the packets. Instances are the default state and are appropriate for most end-user devices,
|
||||
such as phones, laptops, sensors, or any device that primarily consumes network services.
|
||||
|
||||
A member of the organisation at site D, named Dori, is willing to help by sharing
|
||||
the Internet connection she already has in her home, and is able to leave a Raspberry
|
||||
Pi running. A new Reticulum interface is configured on her Pi, connecting to the newly
|
||||
enabled Internet interface on the gateway at site A. Dori is now connected to both
|
||||
the nodes at her own local site (through the hill-top LoRa gateway), and all the
|
||||
combined users of sites A, B and C. She then enables transport on her node, and
|
||||
traffic from site D can now reach everyone at site A, B and C, and vice versa.
|
||||
A **Transport Node** is an Instance that has been explicitly configured to
|
||||
participate in network-wide transport. Transport nodes forward packets across
|
||||
hops, propagate announces, maintain path tables, and serve path requests on
|
||||
behalf of other nodes. When a destination sends an announce, Transport Nodes
|
||||
receive it, remember the path, and rebroadcast it to other interfaces. When a node
|
||||
needs to reach a destination it doesn't have a path for, Transport Nodes help
|
||||
resolve the path through the network.
|
||||
|
||||
Growth and Convergence
|
||||
======================
|
||||
Even devices hosting services or serving content should probably just be configured
|
||||
as instances, and themselves connect to wider networks via a Transport Node.
|
||||
In some situations, this may not be practical though, and as an example, it is
|
||||
entirely viable to host a personal Transport Node on a Raspberry Pi, while it
|
||||
is at the same time running an LXMF propagation node, and hosting your personal
|
||||
site or files over Reticulum.
|
||||
|
||||
As the organisation grows, more gateways are added to keep up with the growing user
|
||||
base. Some local gateways even add VHF radios and packet modems to reach outlying users
|
||||
and communities that are out of reach for the LoRa radios and WiFi backhauls.
|
||||
The distinction is important. **Not** every node should be a Transport Node:
|
||||
|
||||
As more sites, gateways and users are connected, the amount of coordination required
|
||||
is kept to a minimum. If one community wants to add connectivity to the next one
|
||||
over, it can simply be done without having to involve everyone or coordinate address
|
||||
space or routing tables.
|
||||
* **Resource consumption:** Transport nodes maintain path tables, process
|
||||
announces, and forward traffic. This requires memory and CPU resources that
|
||||
may be limited on low-powered devices.
|
||||
|
||||
With the added geographical coverage, the operators at site A one day find that
|
||||
the original internet bridged interfaces are no longer utilised. The network has
|
||||
converged to be completely self-connected, and the sites that were once poorly
|
||||
connected outliers are now an integral part of the network.
|
||||
* **Stability requirements:** Transport nodes contribute to network convergence.
|
||||
If Transport Nodes frequently go offline, path tables become stale and
|
||||
convergence suffers. Stable, always-on nodes make better Transport Nodes.
|
||||
|
||||
* **Bandwidth considerations:** Transport nodes process and rebroadcast network
|
||||
maintenance traffic. On very low-bandwidth mediums, having too many Transport
|
||||
Nodes will consume capacity that should be used for actual data.
|
||||
|
||||
In practice, a network typically has a relatively small number of Transport Nodes
|
||||
strategically placed to provide coverage and connectivity. End-user devices run
|
||||
as Instances, connecting through nearby Transport Nodes to reach the wider network.
|
||||
This pattern mirrors traditional networking where routers forward traffic while
|
||||
end hosts simply consume connectivity, but with the crucial difference that any
|
||||
node *can* become a router if needed, and the decision is yours to make based on
|
||||
your network's requirements.
|
||||
|
||||
Transport nodes also function as distributed cryptographic keystores. When a
|
||||
destination announces itself, Transport Nodes cache the public key and destination
|
||||
information. Other nodes can request unknown public keys from the network, and
|
||||
Transport Nodes respond with the cached information. This eliminates the need for
|
||||
a central directory service while ensuring that public keys remain available
|
||||
throughout the network.
|
||||
|
||||
Trustless Networking
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Traditional network security models assume high levels of trust at
|
||||
specific layers. You might trust your ISP to deliver packets without inspection,
|
||||
or trust your VPN provider to handle your traffic, or trust the network
|
||||
administrator to configure firewalls appropriately. These trust relationships
|
||||
create vulnerabilities and dependencies.
|
||||
|
||||
Reticulum is designed to function in **open, trustless environments**. This
|
||||
means the protocol makes no assumptions about the trustworthiness of the network
|
||||
infrastructure, the other participants, or the transport mediums. Every aspect
|
||||
of communication is secured cryptographically:
|
||||
|
||||
* **Traffic encryption:** All traffic to single destinations is encrypted using
|
||||
ephemeral keys.
|
||||
|
||||
* **Source anonymity:** Reticulum packets do not include source addresses.
|
||||
An observer intercepting a packet cannot determine who sent it, only who it is
|
||||
addressed to (unless IFAC is enabled, in which case nothing can be determined).
|
||||
This provides initiator anonymity by default.
|
||||
|
||||
* **Path verification:** The announce mechanism includes cryptographic signatures that
|
||||
prove the authenticity of destination announcements.
|
||||
|
||||
* **Unforgeable delivery confirmations:** When a destination proves receipt of a
|
||||
packet, the proof is signed with the destination's identity key. This prevents
|
||||
false acknowledgments and ensures reliable delivery verification.
|
||||
|
||||
* **Interface authentication:** When using Interface Access Codes (IFAC), packets
|
||||
on authenticated interfaces carry signatures derived from a shared secret. Only
|
||||
nodes with the correct network name and passphrase can generate valid packets, allowing creation
|
||||
of virtual private networks on shared mediums.
|
||||
|
||||
The trustless design has important consequences for network design:
|
||||
|
||||
* **Open-access networks are viable:** You can build networks that anyone can
|
||||
join without pre-approval. Because traffic is encrypted and authenticated end-
|
||||
to-end, participants cannot interfere with each other's private communication,
|
||||
even if they share the same transport infrastructure.
|
||||
|
||||
* **No traffic inspection or prioritization:** Because traffic contents and
|
||||
sources are opaque to intermediate nodes, there is no mechanism for filtering,
|
||||
prioritizing, or throttling traffic based on its type or origin. All traffic
|
||||
is treated equally. From a neutrality perspective, this is a feature.
|
||||
|
||||
* **Adversarial resilience:** The network can operate even if some nodes are
|
||||
malicious or controlled by adversaries. While a malicious Transport Node could
|
||||
refuse to forward certain traffic or drop packets, it cannot decrypt, modify,
|
||||
or impersonate legitimate traffic. Redundant paths and multiple Transport Nodes
|
||||
mitigate the impact of malicious nodes.
|
||||
|
||||
Of course, you can also create closed networks. Interface Access
|
||||
Codes allow you to restrict participation on specific interfaces. Network
|
||||
Identities enable you to verify that discovered interfaces belong to trusted
|
||||
operators. Blackhole management lets you block malicious identities. Reticulum
|
||||
provides both the tools for open networks and the controls for closed ones. The
|
||||
choice is yours based on your requirements.
|
||||
|
||||
|
||||
Heterogeneous Connectivity
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
In conventional networking, mixing different transport mediums typically requires
|
||||
gateways, translation layers, and careful configuration. A WiFi network doesn't
|
||||
natively interoperate with a packet radio network without additional infrastructure,
|
||||
and you can't just download a car over a serial port, or send an encrypted message
|
||||
in a QR code.
|
||||
|
||||
Reticulum treats **heterogeneity as a core premise**. The protocol is designed
|
||||
to seamlessly mix mediums with vastly different characteristics:
|
||||
|
||||
* **Bandwidth:** LoRa links operating at a few hundred bits per second can
|
||||
interconnect with gigabit Ethernet backbones. Reticulum automatically manages
|
||||
the flow of information, prioritizing local traffic on slow segments while
|
||||
allowing global convergence.
|
||||
|
||||
* **Latency:** Satellite links with multi-second latency can coexist with local
|
||||
links measured in milliseconds. The transport system handles timing, asynchronous
|
||||
delivery and retransmissions transparently.
|
||||
|
||||
* **Topology:** Point-to-point microwave links, broadcast radio networks,
|
||||
switched Ethernet fabrics, and virtual tunnels over the Internet can all be
|
||||
part of the same Reticulum network.
|
||||
|
||||
* **Reliability:** Intermittent connections that come and go (such as mobile
|
||||
devices or opportunistic radio contacts) can participate alongside always-on
|
||||
infrastructure. Reticulum gracefully handles link loss and reconnection.
|
||||
|
||||
This heterogeneity is achieved through several design elements:
|
||||
|
||||
* **Expandable, medium-agnostic interface system:** Reticulum communicates with the physical
|
||||
world through interface modules. Adding support for a new medium is a matter
|
||||
of implementing an interface class. The protocol itself remains unchanged.
|
||||
|
||||
* **Interface modes:** Different modes (``full``, ``gateway``, ``access_point``,
|
||||
``roaming``, ``boundary``) allow you to configure how interfaces interact with
|
||||
the wider network based on their characteristics and role.
|
||||
|
||||
* **Announce propagation rules:** Announces are forwarded between interfaces
|
||||
according to rules that account for bandwidth limitations and interface modes.
|
||||
Slow segments are not overwhelmed by traffic from fast segments.
|
||||
|
||||
* **Local traffic prioritization:** When bandwidth is constrained, Reticulum
|
||||
prioritizes announces for nearby destinations. This ensures that local
|
||||
connectivity remains functional even when global convergence is incomplete.
|
||||
|
||||
For network designers, this means you are free to use whatever mediums are
|
||||
available, affordable, or appropriate for your situation. You might use LoRa for
|
||||
wide-area low-bandwidth coverage, WiFi for local high-capacity links, I2P for
|
||||
anonymous Internet connectivity, and Ethernet for infrastructure backhauls, all
|
||||
within the same network. Reticulum handles the translation and coordination
|
||||
automatically.
|
||||
|
||||
The key design consideration is not whether different mediums can work together
|
||||
(they can), but **how** they should work together based on your goals. A node
|
||||
with multiple interfaces spanning heterogeneous mediums needs to be configured
|
||||
with appropriate interface modes so that traffic flows efficiently. A gateway
|
||||
connecting a slow LoRa segment to a fast Internet backbone should be configured
|
||||
differently than a mobile device roaming between radio cells.
|
||||
|
After Width: | Height: | Size: 37 KiB |
|
After Width: | Height: | Size: 37 KiB |
|
After Width: | Height: | Size: 24 KiB |
|
After Width: | Height: | Size: 24 KiB |
|
After Width: | Height: | Size: 122 KiB |
|
After Width: | Height: | Size: 47 KiB |
|
After Width: | Height: | Size: 123 KiB |
|
After Width: | Height: | Size: 37 KiB |
|
After Width: | Height: | Size: 131 KiB |
|
After Width: | Height: | Size: 121 KiB |
|
After Width: | Height: | Size: 94 KiB |
|
After Width: | Height: | Size: 46 KiB |
|
After Width: | Height: | Size: 142 KiB |
|
After Width: | Height: | Size: 81 KiB |
@@ -0,0 +1,355 @@
|
||||
.. _software-main:
|
||||
|
||||
************************
|
||||
Programs Using Reticulum
|
||||
************************
|
||||
|
||||
This chapter provides a non-exhaustive list of notable programs, systems and application-layer
|
||||
protocols that have been built using Reticulum.
|
||||
|
||||
These programs will let you get a feel for how Reticulum works. Most of them have been designed
|
||||
to run well even over slow networks based on LoRa or packet radio, but all can also be used over fast
|
||||
links, such as local WiFi, wired Ethernet, the Internet, or any combination.
|
||||
|
||||
As such, it is easy to get started experimenting, without having to set up any radio
|
||||
transceivers or infrastructure just to try it out. Launching the programs on separate
|
||||
devices connected to the same WiFi network is enough to get started, and physical
|
||||
radio interfaces can then be added later.
|
||||
|
||||
Programs & Utilities
|
||||
====================
|
||||
|
||||
Many different applications using Reticulum already exist, serving a wide variety of purposes
|
||||
from day-to-day communication and information sharing to systems administration and tackling
|
||||
advanced networking and communications challenges.
|
||||
|
||||
Development of Reticulum-based applications and systems is ongoing, so consider this list
|
||||
a non-exhaustive starting point of *some* of the options available. With a bit of searching,
|
||||
primarily over Reticulum itself, you will find many more interesting things.
|
||||
|
||||
Remote Shell
|
||||
^^^^^^^^^^^^
|
||||
|
||||
The `rnsh <https://github.com/acehoss/rnsh>`_ program lets you establish fully interactive
|
||||
remote shell sessions over Reticulum. It also allows you to pipe any program to or from a
|
||||
remote system, and is similar to how ``ssh`` works. The ``rnsh`` program is very efficient, and
|
||||
can facilitate fully interactive shell sessions, even over extremely low-bandwidth links,
|
||||
such as LoRa or packet radio.
|
||||
|
||||
In addition to the default, fully interactive terminal mode,
|
||||
for extremely limited links, ``rnsh`` offers line-interactive mode, allowing you to interact
|
||||
with remote systems, even when link throughput is counted in a few hundreds of bits per second.
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\newpage
|
||||
|
||||
Nomad Network
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
The terminal-based program `Nomad Network <https://github.com/markqvist/nomadnet>`_
|
||||
provides a complete encrypted communications suite built with Reticulum. It features
|
||||
encrypted messaging (both direct and delayed-delivery for offline users), file sharing,
|
||||
and has a built-in text-browser and page server with support for dynamically rendered pages,
|
||||
user authentication and more.
|
||||
|
||||
.. image:: screenshots/nomadnet_3.png
|
||||
:target: https://github.com/markqvist/nomadnet
|
||||
|
||||
`Nomad Network <https://github.com/markqvist/nomadnet>`_ is a user-facing client
|
||||
for the messaging and information-sharing protocol LXMF.
|
||||
|
||||
RNS Page Node
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
`RNS Page Node <https://git.quad4.io/RNS-Things/rns-page-node>`_ is a simple way to serve pages and files to any other Nomad Network compatible client. Drop-in replacement for NomadNet nodes that primarily serve pages and files.
|
||||
|
||||
|
||||
Retipedia
|
||||
^^^^^^^^^
|
||||
|
||||
You can host the entirity of Wikipedia (or any ``.zim``) file to other Nomad Network clients using `Retipedia <https://github.com/RFnexus/Retipedia>`_.
|
||||
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\newpage
|
||||
|
||||
Sideband
|
||||
^^^^^^^^
|
||||
|
||||
If you would rather use an LXMF client with a graphical user interface, you can take
|
||||
a look at `Sideband <https://unsigned.io/sideband>`_, which is available for Android,
|
||||
Linux, macOS and Windows. Sideband is an advanced LXMF and LXST client, and a multi-purpose Reticulum
|
||||
utility, with features and functionality targeted at advanced users.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. image:: screenshots/sideband_devices.webp
|
||||
:align: center
|
||||
:target: https://unsigned.io/sideband
|
||||
|
||||
.. only:: latex
|
||||
|
||||
.. image:: screenshots/sideband_devices.png
|
||||
:align: center
|
||||
:target: https://unsigned.io/sideband
|
||||
|
||||
Sideband allows you to communicate with other people or LXMF-compatible
|
||||
systems over Reticulum networks using LoRa, Packet Radio, WiFi, I2P, Encrypted QR
|
||||
Paper Messages, or anything else Reticulum supports.
|
||||
|
||||
It also interoperates with all other LXMF clients, and provides advanced features such as voice messaging,
|
||||
real-time voice calls, file attachments, private telemetry sharing, and a full
|
||||
plugin system for expandability.
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\newpage
|
||||
|
||||
MeshChatX
|
||||
^^^^^^^^
|
||||
|
||||
A `Reticulum MeshChat fork from the future <https://git.quad4.io/RNS-Things/MeshChatX>`_, with the goal of providing everything you need for Reticulum, LXMF, and LXST in one beautiful and feature-rich application. This project is separate from the original Reticulum MeshChat project, and is not affiliated with the original project.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. image:: screenshots/meshchatx.webp
|
||||
:align: center
|
||||
:target: https://git.quad4.io/RNS-Things/MeshChatX
|
||||
|
||||
.. only:: latex
|
||||
|
||||
.. image:: screenshots/meshchatx.png
|
||||
:align: center
|
||||
:target: https://git.quad4.io/RNS-Things/MeshChatX
|
||||
|
||||
|
||||
Features include full LXST support, custom voicemail, phonebook, contact sharing, and ringtone support, multi-identity handling, modern UI/UX, offline documentation, expanded tools, page archiving, integrated maps and improved application security.
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\newpage
|
||||
|
||||
MeshChat
|
||||
^^^^^^^^
|
||||
|
||||
The `Reticulum MeshChat <https://github.com/liamcottle/reticulum-meshchat>`_ application
|
||||
is a user-friendly LXMF client for Linux, macOS and Windows, that also includes a Nomad Network
|
||||
page browser and other interesting functionality.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. image:: screenshots/meshchat_1.webp
|
||||
:align: center
|
||||
:target: https://github.com/liamcottle/reticulum-meshchat
|
||||
|
||||
.. only:: latex
|
||||
|
||||
.. image:: screenshots/meshchat_1.png
|
||||
:align: center
|
||||
:target: https://github.com/liamcottle/reticulum-meshchat
|
||||
|
||||
Reticulum MeshChat is of course also compatible with Sideband and Nomad Network, or
|
||||
any other LXMF client.
|
||||
|
||||
Columba
|
||||
^^^^^^^
|
||||
|
||||
`Columba <https://github.com/torlando-tech/columba/>`_ is a simple and familiar LXMF
|
||||
messaging app Android, built with a native Android interface and Material Design 3.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. image:: screenshots/columba.webp
|
||||
:align: center
|
||||
:width: 25%
|
||||
:target: https://github.com/torlando-tech/columba/
|
||||
|
||||
.. only:: latex
|
||||
|
||||
.. image:: screenshots/columba.png
|
||||
:align: center
|
||||
:width: 25%
|
||||
:target: https://github.com/torlando-tech/columba/
|
||||
|
||||
While still in early and very active development, it is of course also compatible
|
||||
with all other LXMF clients, and allows you to message seamlessly with anyone else
|
||||
using LXMF.
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\newpage
|
||||
|
||||
Reticulum Relay Chat
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
`Reticulum Relay Chat <https://rrc.kc1awv.net/>`_ is a live chat system built on top of the Reticulum Network Stack. It exists to let people talk to each other in real time over Reticulum without dragging in message databases, synchronization engines, or architectural commitments they did not ask for.
|
||||
|
||||
The `rrcd <https://github.com/kc1awv/rrcd>`_ program provides a functional, reference RRC hub-server daemon implementation. RRC user clients include `rrc-gui <https://github.com/kc1awv/rrc-gui>`_ and `rrc-web <https://github.com/kc1awv/rrc-web>`_.
|
||||
|
||||
RRC is closer in spirit to IRC than to modern “everything platforms.” You connect, you join a room, you talk, and then you leave. If you were present, you saw the conversation. If you were not, the conversation did not wait for you. This is not an accident. This is the entire design.
|
||||
|
||||
RetiBBS
|
||||
^^^^^^^
|
||||
|
||||
`RetiBBS <https://github.com/kc1awv/RetiBBS>`_ is a bulletin board system implementation for Reticulum networks.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. image:: screenshots/retibbs.webp
|
||||
:align: center
|
||||
:target: https://github.com/kc1awv/RetiBBS
|
||||
|
||||
.. only:: latex
|
||||
|
||||
.. image:: screenshots/retibbs.png
|
||||
:align: center
|
||||
:target: https://github.com/kc1awv/RetiBBS
|
||||
|
||||
RetiBBS allows users to communicate through message boards in a secure manner.
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\newpage
|
||||
|
||||
RBrowser
|
||||
^^^^^^^^
|
||||
|
||||
The `rBrowser <https://github.com/fr33n0w/rBrowser>`_ program is a cross-platoform, standalone, web-based browser for exploring NomadNetwork Nodes over Reticulum Network. It automatically discovers NomadNet nodes through network announces and provides a user-friendly interface for browsing distributed content with Micron markup support.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. image:: screenshots/rbrowser.webp
|
||||
:align: center
|
||||
:target: https://github.com/fr33n0w/rBrowser
|
||||
|
||||
.. only:: latex
|
||||
|
||||
.. image:: screenshots/rbrowser.png
|
||||
:align: center
|
||||
:target: https://github.com/fr33n0w/rBrowser
|
||||
|
||||
Includes useful features like automatic listening for announce, adding nodes to favorites, browsing and rendering any kind of NomadNet links, downloading files from remote nodes, a unique local NomadNet Search Engine and more.
|
||||
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\newpage
|
||||
|
||||
Reticulum Network Telephone
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The ``rnphone`` program, included as part of the `LXST <https://github.com/markqvist/LXST>`_ package is a command-line Reticulum telephone utility and daemon, that allows building physical, hardware telephones for LXST and Reticulum, as well as simply performing calls via the command line.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. image:: screenshots/rnphone.webp
|
||||
:align: center
|
||||
:target: https://github.com/markqvist/LXST
|
||||
|
||||
.. only:: latex
|
||||
|
||||
.. image:: screenshots/rnphone.jpg
|
||||
:align: center
|
||||
:target: https://github.com/markqvist/LXST
|
||||
|
||||
It supports interfacing directly with hardware peripherals such as GPIO keypads and LCD displays, providing a modular system for building secure hardware telephones.
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\newpage
|
||||
|
||||
LXST Phone
|
||||
^^^^^^^^^^
|
||||
|
||||
The `LXST Phone <https://github.com/kc1awv/lxst_phone>`_ program is a cross-platform desktop application for performing LXST voice calls over Reticulum.
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. image:: screenshots/lxst_phone.webp
|
||||
:align: center
|
||||
:target: https://github.com/kc1awv/lxst_phone
|
||||
|
||||
.. only:: latex
|
||||
|
||||
.. image:: screenshots/lxst_phone.png
|
||||
:align: center
|
||||
:target: https://github.com/kc1awv/lxst_phone
|
||||
|
||||
It supports various advanced features such as SAS verification, peer blocking, rate limiting, encrypted call history storage and contact management.
|
||||
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\newpage
|
||||
|
||||
LXMFy
|
||||
^^^^^
|
||||
|
||||
`LXMFy <https://lxmfy.quad4.io/>`_ is a comprehensive and advanced bot creation framework for LXMF, that allows building any kind of automation or bot system running over LXMF and Reticulum. `Bot implementations exist <https://github.com/lxmfy/awesome-lxmfy-bots>`_ for Home Assistant control, LLM integrations, and various other purposes.
|
||||
|
||||
|
||||
LXMF Interactive Client
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
`LXMF Interactive Client <https://github.com/fr33n0w/lxmf-cli>`_ is a feature-rich, terminal-based LXMF messaging client with many advanced features and an extensible plugin architecture.
|
||||
|
||||
RNS FileSync
|
||||
^^^^^^^^^^^^
|
||||
|
||||
The `RNS FileSync <https://git.quad4.io/RNS-Things/RNS-Filesync>`_ program enables automatic file synchronization between devices without requiring central servers, internet connectivity, or cloud services. It works over any network medium supported by Reticulum, including radio, LoRa, WiFi, or the internet, making it ideal for off-grid, privacy-focused, and resilient file sharing.
|
||||
|
||||
|
||||
Micron Parser JS
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
`Micron Parser JS <https://github.com/RFnexus/micron-parser-js>`_ is the JavaScript-based parser for the Micron markup language, that most web-based Nomad Network browsers use. If you want to make utilities or tools that display Micron pages, this library is essential.
|
||||
|
||||
|
||||
RNMon
|
||||
^^^^^
|
||||
|
||||
`RNMon <https://github.com/lbatalha/rnmon>`_ is a monitoring daemon designed to monitor the status of multiple RNS applications and push the metrics to an InfluxDB instance over the influx line protocol.
|
||||
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\newpage
|
||||
|
||||
Protocols
|
||||
=========
|
||||
|
||||
A number of standard protocols have emerged through real-world usage and testing in the Reticulum community. While you may sometimes want to use completely custom protocols and implementations when writing Reticulum-based software, using these protocols provides application developers with an easy way to implement advanced functionality quickly and effortlessly. Using them also ensures compatibility and interoperability between many different client applications, creating an open communications ecosystem where users are free to choose the applications that suit their needs, while remaining connected to everyone else.
|
||||
|
||||
LXMF
|
||||
^^^^
|
||||
|
||||
`LXMF <https://github.com/markqvist/lxmf>`_ is a simple and flexible messaging format and delivery protocol that allows a wide variety of applications, while using as little bandwidth as possible. It offers zero-conf message routing, end-to-end encryption and Forward Secrecy, and can be transported over any kind of medium that Reticulum supports.
|
||||
|
||||
LXMF is efficient enough that it can deliver messages over extremely low-bandwidth systems such as packet radio or LoRa. Encrypted LXMF messages can also be encoded as QR-codes or text-based URIs, allowing completely analog paper message transport.
|
||||
|
||||
Using Propagation Nodes, LXMF also offer a way to store and forward messages to users or endpoints that are not directly reachable at the time of message emission.
|
||||
|
||||
LXST
|
||||
^^^^
|
||||
|
||||
`LXST <https://github.com/markqvist/lxst>`_ is a simple and flexible real-time streaming format and delivery protocol that allows a wide variety of applications, while using as little bandwidth as possible. It is built on top of Reticulum and offers zero-conf stream routing, end-to-end encryption and Forward Secrecy, and can be transported over any kind of medium that Reticulum supports. It currently powers real-time voice and telephony applications over Reticulum.
|
||||
|
||||
RRC
|
||||
^^^
|
||||
|
||||
The `Reticulum Relay Chat <https://rrc.kc1awv.net/>`_ protocol, is a live chat system built on top of the Reticulum Network Stack. It exists to provide near real-time group communication without dragging in message history databases, federation machinery, or architectural guilt.
|
||||
|
||||
RRC is intentionally simple. It does not pretend to be email, a mailbox, or a distributed archive. It behaves more like a conversation in a room. If you were there, you heard it. If you were not, you did not. That is not a bug, that is the point.
|
||||
|
||||
Interface Modules & Connectivity Resources
|
||||
==========================================
|
||||
|
||||
This section provides a list of various community-provided interface modules, guides and resources for creating Reticulum networks over special or challenging mediums.
|
||||
|
||||
* Custom interface module for running `RNS over HTTP <https://git.quad4.io/RNS-Things/RNS-over-HTTP>`_
|
||||
* Guide for running `Reticulum over ICMP <https://github.com/matvik22000/rns-over-icmp>`_ using ``PipeInterface``
|
||||
* Guide for running `Reticulum over DNS <https://github.com/markqvist/Reticulum/discussions/1002>`_ with Iodine
|
||||
* Guide for running `Reticulum over HF radio <https://github.com/RFnexus/reticulum-over-hf>`_
|
||||
* `Modem73 <https://github.com/RFnexus/modem73>`_ is a KISS TNC OFDM modem frontend that can be used with Reticulum
|
||||
@@ -16,12 +16,12 @@ Donations are gratefully accepted via the following channels:
|
||||
Monero:
|
||||
84FpY1QbxHcgdseePYNmhTHcrgMX4nFfBYtz2GKYToqHVVhJp8Eaw1Z1EedRnKD19b3B8NiLCGVxzKV17UMmmeEsCrPyA5w
|
||||
|
||||
Ethereum:
|
||||
0x81F7B979fEa6134bA9FD5c701b3501A2e61E897a
|
||||
|
||||
Bitcoin:
|
||||
3CPmacGm34qYvR6XWLVEJmi2aNe3PZqUuq
|
||||
bc1pgqgu8h8xvj4jtafslq396v7ju7hkgymyrzyqft4llfslz5vp99psqfk3a6
|
||||
|
||||
Ethereum:
|
||||
0x91C421DdfB8a30a49A71d63447ddb54cEBe3465E
|
||||
|
||||
Liberapay:
|
||||
https://liberapay.com/Reticulum/
|
||||
|
||||
@@ -33,15 +33,28 @@ organisation? Make them a reality quickly by sponsoring their implementation.
|
||||
|
||||
Provide Feedback
|
||||
================
|
||||
All feedback on the usage, functioning and potential dysfunctioning of any and
|
||||
Feedback on the usage, functioning and potential dysfunctioning of any and
|
||||
all components of the system is very valuable to the continued development and
|
||||
improvement of Reticulum.
|
||||
improvement of Reticulum. But...
|
||||
|
||||
.. warning::
|
||||
|
||||
**Think before you speak**. As time has shown, over 80% of the "feedback",
|
||||
"bug reports" and "advice" the Reticulum project has received has been
|
||||
irrelevant noise, stemming from erroneous assumptions, misunderstanding the
|
||||
foundational functionality or philosophy behind the system, or simply
|
||||
the malinformed (but overly opinionated) personal preferences of individual
|
||||
drive-by architects. This wastes the time of everyone involved.
|
||||
|
||||
The Reticulum project is not a public teahouse for serving the attention
|
||||
needs of random bypassers, but a highly complex system engineered and
|
||||
refined over more than a decade, designed to provide communication and
|
||||
connectivity guarantees in highly adversarial environments.
|
||||
|
||||
If you want to voice your opinion, it better be well-informed, and we
|
||||
expect you to have a comprehensive and solid foundation for your points
|
||||
of view. Everything else will be ignored.
|
||||
|
||||
Absolutely no automated analytics, telemetry, error
|
||||
reporting or statistics is collected and reported by Reticulum under any
|
||||
circumstances, so we rely on old-fashioned human feedback.
|
||||
|
||||
Contribute Code
|
||||
===============
|
||||
Join us on `the GitHub repository <https://github.com/markqvist/reticulum>`_ to
|
||||
report issues, suggest functionality and contribute code to Reticulum.
|
||||
|
||||
@@ -13,9 +13,8 @@ reference implementation and API reference. That being said, this chapter is an
|
||||
understanding how Reticulum works from a high-level perspective, along with the general principles of
|
||||
Reticulum, and how to apply them when creating your own networks or software.
|
||||
|
||||
After reading this document, you should be well-equipped to understand how a Reticulum network
|
||||
operates, what it can achieve, and how you can use it yourself. If you want to help out with the
|
||||
development, this is also the place to start, since it will provide a pretty clear overview of the
|
||||
After reading this chapter, you should be well-equipped to understand how a Reticulum network
|
||||
operates, what it can achieve, and how you can use it yourself. This chapter also seeks to provide an overview of the
|
||||
sentiments and the philosophy behind Reticulum, what problems it seeks to solve, and how it
|
||||
approaches those solutions.
|
||||
|
||||
@@ -117,7 +116,7 @@ Reticulum uses the singular concept of *destinations*. Any application using Ret
|
||||
networking stack will need to create one or more destinations to receive data, and know the
|
||||
destinations it needs to send data to.
|
||||
|
||||
All destinations in Reticulum are _represented_ as a 16 byte hash. This hash is derived from truncating a full
|
||||
All destinations in Reticulum are *represented* as a 16 byte hash. This hash is derived from truncating a full
|
||||
SHA-256 hash of identifying characteristics of the destination. To users, the destination addresses
|
||||
will be displayed as 16 hexadecimal bytes, like this example: ``<13425ec15b621c1d928589718000d814>``.
|
||||
|
||||
@@ -141,7 +140,7 @@ ratchets on a per-destination basis. The multi-hop transport, coordination, veri
|
||||
layers are fully autonomous and also based on elliptic curve cryptography.
|
||||
|
||||
Reticulum also offers symmetric key encryption for group-oriented communications, as well as
|
||||
unencrypted packets for local broadcast purposes.
|
||||
unencrypted packets (for local broadcast purposes **only**).
|
||||
|
||||
Reticulum can connect to a variety of interfaces such as radio modems, data radios and serial ports,
|
||||
and offers the possibility to easily tunnel Reticulum traffic over IP links such as the Internet or
|
||||
@@ -401,11 +400,10 @@ any transport node receiving it, but according to some specific rules:
|
||||
to be transmitted, the newest announce is discarded. If the newest announce contains different
|
||||
application specific data, it will replace the old announce.
|
||||
|
||||
Once an announce has reached a node in the network, any other node in direct contact with that
|
||||
node will be able to reach the destination the announce originated from, simply by sending a packet
|
||||
addressed to that destination. Any node with knowledge of the announce will be able to direct the
|
||||
packet towards the destination by looking up the next node with the shortest amount of hops to the
|
||||
destination.
|
||||
Once an announce has reached a transport node in the network, any other node in direct contact with that
|
||||
transport node will be able to reach the destination the announce originated from, simply by sending a packet
|
||||
addressed to that destination. Any transport node with knowledge of the announce will be able to direct the
|
||||
packet towards the destination by looking up the most efficient next node to the destination.
|
||||
|
||||
According to these rules, an announce will propagate throughout the network in a predictable way,
|
||||
and make the announced destination reachable in a short amount of time. Fast networks that have the
|
||||
@@ -414,6 +412,17 @@ new destinations. Slower segments of such networks might take a bit longer to ga
|
||||
the wide and fast networks they are connected to, but can still do so over time, while prioritising full
|
||||
and quickly converging end-to-end connectivity for their local, slower segments.
|
||||
|
||||
.. tip::
|
||||
|
||||
Even very slow networks, that simply don't have the capacity to ever reach *full* convergence
|
||||
will generally still be able to reach **any other destination on any connected segments**, since
|
||||
interconnecting transport nodes will prioritize announces into the slower segments that are
|
||||
actually requested by nodes on these.
|
||||
|
||||
This means that slow, low-capacity or low-resource segments **don't** need to have full network
|
||||
knowledge, since paths can always be recursively resolved from other segments that do have
|
||||
knowledge about them.
|
||||
|
||||
In general, even extremely complex networks, that utilize the maximum 128 hops will converge to full
|
||||
end-to-end connectivity in about one minute, given there is enough bandwidth available to process
|
||||
the required amount of announces.
|
||||
@@ -424,7 +433,7 @@ Reaching the Destination
|
||||
------------------------
|
||||
|
||||
In networks with changing topology and trustless connectivity, nodes need a way to establish
|
||||
*verified connectivity* with each other. Since the network is assumed to be trustless, Reticulum
|
||||
*verified connectivity* with each other. Since the underlying network mediums are assumed to be trustless, Reticulum
|
||||
must provide a way to guarantee that the peer you are communicating with is actually who you
|
||||
expect. Reticulum offers two ways to do this.
|
||||
|
||||
@@ -435,7 +444,7 @@ For exchanges of small amounts of information, Reticulum offers the *Packet* API
|
||||
an ECDH key exchange with the destination's public key (or ratchet key, if available), and encrypt the information.
|
||||
|
||||
* | It is important to note that this key exchange does not require any network traffic. The sender already
|
||||
knows the public key of the destination from an earlier received *announce*, and can thus perform the ECDH
|
||||
knows the public key of the destination from an earlier received announce, and can thus perform the ECDH
|
||||
key exchange locally, before sending the packet.
|
||||
|
||||
* | The public part of the newly generated ephemeral key-pair is included with the encrypted token, and sent
|
||||
@@ -461,14 +470,14 @@ For exchanges of small amounts of information, Reticulum offers the *Packet* API
|
||||
|
||||
For exchanges of larger amounts of data, or when longer sessions of bidirectional communication is desired, Reticulum offers the *Link* API. To establish a *link*, the following process is employed:
|
||||
|
||||
* | First, the node that wishes to establish a link will send out a special packet, that
|
||||
* | First, the node that wishes to establish a link will send out a *link request* packet, that
|
||||
traverses the network and locates the desired destination. Along the way, the Transport Nodes that
|
||||
forward the packet will take note of this *link request*.
|
||||
forward the packet will take note of this *link request*, and mark it as pending.
|
||||
|
||||
* | Second, if the destination accepts the *link request* , it will send back a packet that proves the
|
||||
authenticity of its identity (and the receipt of the link request) to the initiating node. All
|
||||
nodes that initially forwarded the packet will also be able to verify this proof, and thus
|
||||
accept the validity of the *link* throughout the network.
|
||||
accept the validity of the *link* throughout the network. The link is now marked as *established*.
|
||||
|
||||
* | When the validity of the *link* has been accepted by forwarding nodes, these nodes will
|
||||
remember the *link* , and it can subsequently be used by referring to a hash representing it.
|
||||
@@ -560,9 +569,10 @@ an arbitrary number of hops, where information will be exchanged between two nod
|
||||
*link proof* to perform it's own Diffie Hellman Key Exchange and derive the symmetric key
|
||||
that is used to encrypt the channel. Information can now be exchanged reliably and securely.
|
||||
|
||||
.. note::
|
||||
|
||||
It’s important to note that this methodology ensures that the source of the request does not need to
|
||||
reveal any identifying information about itself. The link initiator remains completely anonymous.
|
||||
It’s important to note that this methodology ensures that the source of the request does not need to
|
||||
reveal any identifying information about itself. **The link initiator remains completely anonymous**.
|
||||
|
||||
When using *links*, Reticulum will automatically verify all data sent over the link, and can also
|
||||
automate retransmissions if *Resources* are used.
|
||||
@@ -585,6 +595,82 @@ the transfer, integrity verification and reassembling the data on the other end.
|
||||
of codes to reliably transfer any amount of data. They can be used to transfer data stored in memory,
|
||||
or stream data directly from files.
|
||||
|
||||
.. _understanding-network_identities:
|
||||
|
||||
Network Identities
|
||||
==================
|
||||
|
||||
In Reticulum, every peer and application utilizes a cryptographic **Identity** to verify authenticity and establish encrypted channels. While standard identities are typically used to represent a single user, device, or service, Reticulum introduces the concept of a **Network Identity** to represent a logical group of nodes or an entire community infrastructure.
|
||||
|
||||
A Network Identity is, at its core, a standard Reticulum Identity keyset. However, its purpose and usage differ from a personal identity. Instead of identifying a single entity, a Network Identity acts as a shared credential that federates multiple independent Transport Instances under a single, verifiable administrative domain.
|
||||
|
||||
|
||||
Conceptual Overview
|
||||
-------------------
|
||||
|
||||
You can think of a standard Reticulum Identity as a self-sovereign, privately created passport for a single person. A Network Identity, conversely, is akin to a cryptographic flag, or a charter that flies over a fleet of ships. It signifies that while the ships may operate independently and be physically distant, they belong to the same organization, follow the same protocols, and are expected to act in concert.
|
||||
|
||||
When you configure a Network Identity on one or more of your nodes, you are effectively declaring that these nodes constitute a specific "network" within a broader Reticulum mesh. This allows other peers to recognize interfaces not just as "a node named Alice", but as "a gateway belonging to The Eastern Ret Of Freedom".
|
||||
|
||||
|
||||
Current Usage
|
||||
-------------
|
||||
|
||||
At present, the primary function of a Network Identity is within the :ref:`Interface Discovery<using-interface_discovery>` system.
|
||||
|
||||
When a Transport Instance broadcasts a discovery announce for an interface, it can optionally sign that announce with a Network Identity, instead of just its local transport identity. Remote peers receiving the announce can then verify the signature. This provides functionality for two important distinctions:
|
||||
|
||||
1. **Authenticity:** It proves that the interface was published by an operator who possesses the private key for that Network Identity.
|
||||
2. **Trust Boundaries:** It allows users to configure their systems to only accept and connect to interfaces that belong to specific Network Identities, effectively creating "whitelisted" zones of trusted infrastructure.
|
||||
|
||||
.. note::
|
||||
If you enable encryption on your discovery announces, the Network Identity is used as the shared secret. Only peers who have been explicitly provided with the Network Identity's full keyset (and have it configured locally) will be able to decrypt and utilize the connection details.
|
||||
|
||||
This functionality will be expanded in the future, so that peers with delegated keys can be allowed to decrypt discovery announces without holding the root network key. Currently, the functionality is sufficient for sharing interface information privately where you control all nodes that must decrypt the discovered interfaces.
|
||||
|
||||
|
||||
Future Implications
|
||||
-------------------
|
||||
|
||||
While the current implementation focuses on interface discovery, the concept of Network Identities serves as the foundational building block for future Reticulum features designed to support large-scale, organic mesh formation.
|
||||
|
||||
As the ecosystem evolves, Network Identities will facilitate:
|
||||
|
||||
* **Distributed Name Resolution:** A system where networks can publish name-to-identity mappings, allowing human-readable names to resolve without centralized servers.
|
||||
* **Service Publishing:** Networks will be able to announce specific capabilities, services, or information endpoints available publicly or to their members.
|
||||
* **Inter-Network Federation:** Trust relationships between different networks, allowing for seamless but managed flow of traffic and information across distinct administrative boundaries.
|
||||
* **Distributed Blackhole Management:** A reputation-based system for blackhole list distribution, where trusted Network Identities can sign and publish lists of blackholed identities. This allows communities to collaboratively enforce security standards and filter spam or malicious identities across the parts of the wider mesh that they are responsible for.
|
||||
|
||||
By adopting the use of Network Identities now, you are preparing your infrastructure to be compatible with this future functionality.
|
||||
|
||||
|
||||
Creating and Using a Network Identity
|
||||
-------------------------------------
|
||||
|
||||
Since a Network Identity is simply a standard Reticulum Identity, you create one using the built-in tools.
|
||||
|
||||
1. **Generate the Identity:**
|
||||
Use the ``rnid`` utility to generate a new identity file that will serve as your Network Identity.
|
||||
|
||||
.. code:: sh
|
||||
|
||||
$ rnid -g ~/.reticulum/storage/identities/my_network
|
||||
|
||||
2. **Distribute the Public Key:**
|
||||
The public key must be distributed to any Transport Instance that needs to verify your network's announces and discovery information. By default, if your node is set up to use a network identity, this happens automatically (using the standard announce mechanism).
|
||||
|
||||
3. **Configure Instances:**
|
||||
In the ``[reticulum]`` section of the configuration file on every node within your network, point the ``network_identity`` option to the file you created.
|
||||
|
||||
.. code:: ini
|
||||
|
||||
[reticulum]
|
||||
...
|
||||
network_identity = ~/.reticulum/storage/identities/my_network
|
||||
...
|
||||
|
||||
Once configured, your instances will automatically utilize this identity for signing discovery announces (and potentially decrypting network-private information), presenting a unified front to the wider network.
|
||||
|
||||
.. _understanding-referencesystem:
|
||||
|
||||
Reference Setup
|
||||
@@ -624,18 +710,20 @@ into the future. The current Reference System Setup is as follows:
|
||||
* **Interface Device**
|
||||
A data radio consisting of a LoRa radio module, and a microcontroller with open source
|
||||
firmware, that can connect to host devices via USB. It operates in either the 430, 868 or 900
|
||||
MHz frequency bands. More details can be found on the `RNode Page <https://unsigned.io/rnode>`_.
|
||||
MHz frequency bands. More details can be found on the `RNode Page <https://github.com/markqvist/rnode_firmware>`_.
|
||||
* **Host Device**
|
||||
Any computer device running Linux and Python. A Raspberry Pi with a Debian based OS is
|
||||
recommended.
|
||||
a good place to start, but anything can be used.
|
||||
* **Software Stack**
|
||||
The most recently released Python Implementation of Reticulum, running on a Debian based
|
||||
The most recently released Python Implementation of Reticulum, running on a Linux-based
|
||||
operating system.
|
||||
|
||||
To avoid confusion, it is very important to note, that the reference interface device **does not**
|
||||
use the LoRaWAN standard, but uses a custom MAC layer on top of the plain LoRa modulation! As such, you will
|
||||
need a plain LoRa radio module connected to an controller with the correct firmware. Full details on how to
|
||||
get or make such a device is available on the `RNode Page <https://unsigned.io/rnode>`_.
|
||||
.. note::
|
||||
|
||||
To avoid confusion, it is very important to note, that the reference interface device **does not**
|
||||
use the LoRaWAN standard, but uses a custom MAC layer on top of the plain LoRa modulation! As such, you will
|
||||
need a plain LoRa radio module connected to a controller with the correct firmware. Full details on how to
|
||||
get or make such a device is available on the `RNode Page <https://github.com/markqvist/rnode_firmware>`_.
|
||||
|
||||
With the current reference setup, it should be possible to get on a Reticulum network for around 100$
|
||||
even if you have none of the hardware already, and need to purchase everything.
|
||||
@@ -649,16 +737,16 @@ Protocol Specifics
|
||||
==================
|
||||
|
||||
This chapter will detail protocol specific information that is essential to the implementation of
|
||||
Reticulum, but non critical in understanding how the protocol works on a general level. It should be
|
||||
Reticulum, but non-critical in understanding how the protocol works on a general level. It should be
|
||||
treated more as a reference than as essential reading.
|
||||
|
||||
|
||||
Packet Prioritisation
|
||||
---------------------
|
||||
|
||||
Currently, Reticulum is completely priority-agnostic regarding general traffic. All traffic is handled
|
||||
on a first-come, first-serve basis. Announce re-transmission are handled according to the re-transmission
|
||||
times and priorities described earlier in this chapter.
|
||||
Currently, Reticulum is completely priority-agnostic regarding *general* traffic. All traffic is handled
|
||||
on a first-come, first-serve basis. Announce re-transmission and other maintenance traffic is handled
|
||||
according to the re-transmission times and priorities described earlier in this chapter.
|
||||
|
||||
|
||||
Interface Access Codes
|
||||
@@ -666,8 +754,8 @@ Interface Access Codes
|
||||
|
||||
Reticulum can create named virtual networks, and networks that are only accessible by knowing a preshared
|
||||
passphrase. The configuration of this is detailed in the :ref:`Common Interface Options<interfaces-options>`
|
||||
section. To implement these feature, Reticulum uses the concept of Interface Access Codes, that are calculated
|
||||
and verified per packet.
|
||||
section. To implement this feature, Reticulum uses the concept of Interface Access Codes, that are calculated
|
||||
and verified per-packet.
|
||||
|
||||
An interface with a named virtual network or passphrase authentication enabled will derive a shared Ed25519
|
||||
signing identity, and for every outbound packet generate a signature of the entire packet. This signature is
|
||||
@@ -912,6 +1000,11 @@ with the OpenSSL backend being *much* faster. The most important consequence how
|
||||
potential loss of security by using primitives that has not seen the same amount of scrutiny,
|
||||
testing and review as those from OpenSSL.
|
||||
|
||||
Using the normal RNS installation procedures, it is not possible to install Reticulum on a
|
||||
system without the required OpenSSL primitives being available, and if they are not, they will
|
||||
be resolved and installed as a dependency. It is only possible to use the pure-python primitives
|
||||
by manually specifying this, for example by using the ``rnspure`` package.
|
||||
|
||||
.. warning::
|
||||
If you want to use the internal pure-python primitives, it is **highly advisable** that you
|
||||
have a good understanding of the risks that this pose, and make an informed decision on whether
|
||||
|
||||
@@ -338,8 +338,8 @@ Filter output to only show some interfaces:
|
||||
.. code:: text
|
||||
|
||||
usage: rnstatus [-h] [--config CONFIG] [--version] [-a] [-A]
|
||||
[-l] [-s SORT] [-r] [-j] [-R hash] [-i path]
|
||||
[-w seconds] [-v] [filter]
|
||||
[-l] [-t] [-s SORT] [-r] [-j] [-R hash] [-i path]
|
||||
[-w seconds] [-d] [-D] [-m] [-I seconds] [-v] [filter]
|
||||
|
||||
Reticulum Network Stack Status
|
||||
|
||||
@@ -353,12 +353,19 @@ Filter output to only show some interfaces:
|
||||
-a, --all show all interfaces
|
||||
-A, --announce-stats show announce stats
|
||||
-l, --link-stats show link stats
|
||||
-s SORT, --sort SORT sort interfaces by [rate, traffic, rx, tx, announces, arx, atx, held]
|
||||
-t, --totals display traffic totals
|
||||
-s, --sort SORT sort interfaces by [rate, traffic, rx, tx, rxs, txs,
|
||||
announces, arx, atx, held]
|
||||
-r, --reverse reverse sorting
|
||||
-j, --json output in JSON format
|
||||
-R hash transport identity hash of remote instance to get status from (requires -i)
|
||||
-R hash transport identity hash of remote instance to get status from
|
||||
-i path path to identity used for remote management
|
||||
-w seconds timeout before giving up on remote queries
|
||||
-d, --discovered list discovered interfaces
|
||||
-D show details and config entries for discovered interfaces
|
||||
-m, --monitor continuously monitor status
|
||||
-I, --monitor-interval seconds
|
||||
refresh interval for monitor mode (default: 1)
|
||||
-v, --verbose
|
||||
|
||||
|
||||
@@ -463,6 +470,7 @@ Decrypt a file using the Reticulum Identity it was encrypted for:
|
||||
-B, --base32 Use base32-encoded input and output
|
||||
--version show program's version number and exit
|
||||
|
||||
.. _utility-rnpath:
|
||||
|
||||
The rnpath Utility
|
||||
====================
|
||||
@@ -484,21 +492,23 @@ Resolve path to a destination:
|
||||
|
||||
.. code:: text
|
||||
|
||||
usage: rnpath [-h] [--config CONFIG] [--version] [-t] [-m hops]
|
||||
[-r] [-d] [-D] [-x] [-w seconds] [-R hash] [-i path]
|
||||
[-W seconds] [-j] [-v] [destination]
|
||||
usage: rnpath [-h] [--config CONFIG] [--version] [-t] [-m hops] [-r] [-d] [-D]
|
||||
[-x] [-w seconds] [-R hash] [-i path] [-W seconds] [-b] [-B] [-U]
|
||||
[--duration DURATION] [--reason REASON] [-p] [-j] [-v]
|
||||
[destination] [list_filter]
|
||||
|
||||
Reticulum Path Discovery Utility
|
||||
Reticulum Path Management Utility
|
||||
|
||||
positional arguments:
|
||||
destination hexadecimal hash of the destination
|
||||
list_filter filter for remote blackhole list view
|
||||
|
||||
options:
|
||||
-h, --help show this help message and exit
|
||||
--config CONFIG path to alternative Reticulum config directory
|
||||
--version show program's version number and exit
|
||||
-t, --table show all known paths
|
||||
-m hops, --max hops maximum hops to filter path table by
|
||||
-m, --max hops maximum hops to filter path table by
|
||||
-r, --rates show announce rate info
|
||||
-d, --drop remove the path to a destination
|
||||
-D, --drop-announces drop all queued announces
|
||||
@@ -507,6 +517,13 @@ Resolve path to a destination:
|
||||
-R hash transport identity hash of remote instance to manage
|
||||
-i path path to identity used for remote management
|
||||
-W seconds timeout before giving up on remote queries
|
||||
-b, --blackholed list blackholed identities
|
||||
-B, --blackhole blackhole identity
|
||||
-U, --unblackhole unblackhole identity
|
||||
--duration DURATION duration of blackhole enforcement in hours
|
||||
--reason REASON reason for blackholing identity
|
||||
-p, --blackholed-list
|
||||
view published blackhole list for remote transport instance
|
||||
-j, --json output in JSON format
|
||||
-v, --verbose
|
||||
|
||||
@@ -619,13 +636,20 @@ Or fetch a file from the remote system:
|
||||
|
||||
$ rncp --fetch ~/path/to/file.tgz 73cbd378bb0286ed11a707c13447bb1e
|
||||
|
||||
The default identity file is stored in ``~/.reticulum/identities/rncp``, but you can use
|
||||
another one, which will be created if it does not already exist
|
||||
|
||||
.. code:: text
|
||||
|
||||
$ rncp ~/path/to/file.tgz 73cbd378bb0286ed11a707c13447bb1e -i /path/to/identity
|
||||
|
||||
**All Command-Line Options**
|
||||
|
||||
.. code:: text
|
||||
|
||||
usage: rncp [-h] [--config path] [-v] [-q] [-S] [-l] [-F] [-f]
|
||||
[-j path] [-b seconds] [-a allowed_hash] [-n] [-p]
|
||||
[-w seconds] [--version] [file] [destination]
|
||||
[-i identity] [-w seconds] [--version] [file] [destination]
|
||||
|
||||
Reticulum File Transfer Utility
|
||||
|
||||
@@ -650,6 +674,7 @@ Or fetch a file from the remote system:
|
||||
-a allowed_hash allow this identity (or add in ~/.rncp/allowed_identities)
|
||||
-n, --no-auth accept requests from anyone
|
||||
-p, --print-identity print identity and destination info and exit
|
||||
-i identity path to identity to use
|
||||
-w seconds sender timeout before giving up
|
||||
-P, --phy-rates display physical layer transfer rates
|
||||
--version show program's version number and exit
|
||||
@@ -810,6 +835,104 @@ to create and provision new :ref:`RNodes<rnode-main>` from any supported hardwar
|
||||
For more information on how to create your own RNodes, please read the :ref:`Creating RNodes<rnode-creating>`
|
||||
section of this manual.
|
||||
|
||||
.. _using-interface_discovery:
|
||||
Discovering Interfaces
|
||||
----------------------
|
||||
|
||||
Reticulum includes built-in functionality for discovering connectable interfaces over Reticulum itself. This is particularly useful in situations where you want to do one or more of the following:
|
||||
|
||||
* Discover connectable entrypoints available on the Internet
|
||||
* Find connectable radio access points in the physical world
|
||||
* Maintain connectivity to RNS instances with unknown or changing IP addresses
|
||||
|
||||
Discovered interfaces can be **auto-connected** by Reticulum, which makes it possible to create setups where an arbitrary interface can act simply as a bootstrap connection, that can be torn down again once more suitable interfaces have been discovered and connected.
|
||||
|
||||
The interface discovery mechanism uses announces sent over Reticulum itself, and supports both publicly readable interfaces and private, encrypted discovery, that can only be decoded by specified *network identities*. It is also possible to specify which network identities should be considered valid sources for discovered interfaces, so that interfaces published by unknown entities are ignored.
|
||||
|
||||
.. note::
|
||||
A *network identity* is a normal Reticulum identity keyset that can be used by
|
||||
one or more transport nodes to identify them as belonging to the same overall
|
||||
network. In the context of interface discovery, this makes it easy to manage
|
||||
connecting to only the particular networks you care about, even if those networks
|
||||
utilize many individual physical transport node.
|
||||
|
||||
This also makes it convenient to auto-connect discovered interfaces only for networks you have some level of trust in.
|
||||
|
||||
For information on how to make your interfaces discoverable, see the :ref:`Discoverable Interfaces<interfaces-discoverable>` chapter of this manual. The current section will focus on how to actually *discover and connect to* interfaces available on the network.
|
||||
|
||||
In its most basic form, enabling interface discovery is as simple as setting ``discover_interfaces`` to ``true`` in your Reticulum config:
|
||||
|
||||
.. code:: text
|
||||
|
||||
[reticulum]
|
||||
...
|
||||
discover_interfaces = yes
|
||||
...
|
||||
|
||||
Once this option is enabled, your RNS instance will start listening for interface discovery announces, and store them for later use or inspection. You can list discovered interfaces with the ``rnstatus`` utility:
|
||||
|
||||
.. code:: text
|
||||
|
||||
$ rnstatus -d
|
||||
|
||||
Name Type Status Last Heard Value Location
|
||||
-------------------------------------------------------------------------
|
||||
Sideband Hub Backbone ✓ Available 1h ago 16 46.2316, 6.0536
|
||||
RNS Amsterdam Backbone ✓ Available 32m ago 16 52.3865, 4.9037
|
||||
|
||||
|
||||
You can view more detailed information about discovered interfaces, including configuration snippets for pasting directly into your ``[interfaces]`` config, by using the ``rnstatus -D`` option:
|
||||
|
||||
.. code:: text
|
||||
|
||||
$ rnstatus -D sideband
|
||||
|
||||
Transport ID : 521c87a83afb8f29e4455e77930b973b
|
||||
Name : Sideband Hub
|
||||
Type : BackboneInterface
|
||||
Status : Available
|
||||
Transport : Enabled
|
||||
Distance : 2 hops
|
||||
Discovered : 9h and 40m ago
|
||||
Last Heard : 1h and 15m ago
|
||||
Location : 46.2316, 6.0536
|
||||
Address : sideband.connect.reticulum.network:7822
|
||||
Stamp Value : 16
|
||||
|
||||
Configuration Entry:
|
||||
[[Sideband Hub]]
|
||||
type = BackboneInterface
|
||||
enabled = yes
|
||||
remote = sideband.connect.reticulum.network
|
||||
target_port = 7822
|
||||
transport_identity = 521c87a83afb8f29e4455e77930b973b
|
||||
|
||||
In addition to providing local interface discovery information and control, the ``rnstatus`` utility can export discovered interface data in machine-readable JSON format using the ``rnstatus -d --json`` option. This can be useful for exporting the data to external applications such as status pages, access point maps and similar.
|
||||
|
||||
To control what sources are considered valid for discovered sources, additional
|
||||
configuration options can be specified for the interface discovery system.
|
||||
|
||||
* The ``interface_discovery_sources`` option is a list of the network or transport identities from which interfaces will be accepted. If this option is set, all others will be ignored. If this option is not set, discovered interfaces will be accepted from any source, but are still subject to stamp value requirements.
|
||||
|
||||
* The ``required_discovery_value`` options specifies the minimum stamp value required for the interface announce to be considered valid. To make it computationally difficult to spam the network with a large number of defunct or malicious interfaces, each announced interface requires a valid cryptographical stamp, of configurable difficulty value.
|
||||
|
||||
* The ``autoconnect_discovered_interfaces`` value defaults to ``0``, and specifies the maximum number of discovered interfaces that should be auto-connected at any given time. If set to a number greater than ``0``, Reticulum automatically manages discovered interface connections, and will bring discovered interfaces up and down based on availability. You can at any time add discovered interfaces to your configuration manually, to persistently keep them available.
|
||||
|
||||
* The ``network_identity`` option specifies the *network identity* for this RNS instance. This identity is used both to sign (and potentially encrypt) *outgoing* interface discovery announces, and to decrypt incoming discovery information.
|
||||
|
||||
The configuration snippet below contains an example of setting these additional configuration options:
|
||||
|
||||
.. code:: text
|
||||
|
||||
[reticulum]
|
||||
...
|
||||
discover_interfaces = yes
|
||||
interface_discovery_sources = 521c87a83afb8f29e4455e77930b973b
|
||||
required_discovery_value = 16
|
||||
autoconnect_discovered_interfaces = 3
|
||||
network_identity = ~/.reticulum/storage/identities/my_network
|
||||
...
|
||||
|
||||
Remote Management
|
||||
-----------------
|
||||
|
||||
@@ -835,6 +958,130 @@ in the Reticulum configuration file:
|
||||
|
||||
For a complete example configuration, you can run ``rnsd --exampleconfig``.
|
||||
|
||||
.. _using-blackhole_management:
|
||||
|
||||
Blackhole Management
|
||||
--------------------
|
||||
|
||||
Reticulum networks are fundamentally permissionless and open, allowing anyone with a compatible interface to participate. While this openness is essential for a resilient and decentralized network, it also exposes the network to potential abuse, such as peers flooding the network with excessive announce broadcasts or other forms of resource exhaustion.
|
||||
|
||||
The **Blackhole** system provides tools to help manage this problem. It allows operators and individual users to block specific identities at the Transport layer, preventing them from propagating announces through your node, and for other nodes to reach them through your network.
|
||||
|
||||
.. important::
|
||||
|
||||
There is fundamentally **no way** to *globally* block or censor any identity or destination in Reticulum networks. The blackhole functionality will prevent announces from (and traffic to) all destinations associated with the blackholed identity *on your own network segments only*.
|
||||
|
||||
This provides users and operators with control over what they want to allow *on their own network segments*, but there is no way to globally censor or remove an identity, as long as *someone* is willing to provide transport for it.
|
||||
|
||||
This functionality serves a dual purpose:
|
||||
|
||||
* **For Individual Users:** It offers a simple way to maintain a quiet and efficient local network by manually blocking spammy or unwanted peers.
|
||||
* **For Network Operators:** It enables the creation of federated, community-wide security standards. By publishing and sharing blackhole lists, operators can protect large infrastructures and distribute spam filtering rules across the mesh without manual intervention.
|
||||
|
||||
|
||||
Local Blackhole Management
|
||||
==========================
|
||||
|
||||
The most immediate way to manage unwanted identities is through manual configuration using the ``rnpath`` utility. This allows you to instantly block or unblock specific identities on your local Transport Instance.
|
||||
|
||||
**Blackholing an Identity**
|
||||
|
||||
To block an identity, use the ``-B`` (or ``--blackhole``) flag followed by the identity hash. You can optionally specify a duration and a reason, which are useful for logging and future reference.
|
||||
|
||||
.. code:: text
|
||||
|
||||
$ rnpath -B 3a4f8b9c1d2e3f4g5h6i7j8k9l0m1n2o
|
||||
|
||||
You can also add a duration (in hours) and a reason:
|
||||
|
||||
.. code:: text
|
||||
|
||||
$ rnpath -B 3a4f8b9c1d2e3f4g5h6i7j8k9l0m1n2o --duration 24 --reason "Excessive announces"
|
||||
|
||||
**Lifting Blackholes**
|
||||
|
||||
To remove an identity from the blackhole, use the ``-U`` (or ``--unblackhole``) flag:
|
||||
|
||||
.. code:: text
|
||||
|
||||
$ rnpath -U 3a4f8b9c1d2e3f4g5h6i7j8k9l0m1n2o
|
||||
|
||||
**Viewing the Blackhole List**
|
||||
|
||||
To see all identities currently blackholed on your local instance, use the ``-b`` (or ``--blackholed``) flag:
|
||||
|
||||
.. code:: text
|
||||
|
||||
$ rnpath -b
|
||||
|
||||
<3a4f8b9c1d2e3f4g5h6i7j8k9l0m1n2o> blackholed for 23h, 56m (Excessive announces)
|
||||
<399ea050ce0eed1816c300bcb0840938> blackholed indefinitely (Announce spam)
|
||||
<d56a4fa02c0a77b3575935aedd90bdb2> blackholed indefinitely (Announce spam)
|
||||
<2b9ec651326d9bc274119054c70fb75e> blackholed indefinitely (Announce spam)
|
||||
<1178a8f1fad405bf2ad153bf5036bdfd> blackholed indefinitely (Announce spam)
|
||||
|
||||
|
||||
|
||||
Automated List Sourcing
|
||||
=======================
|
||||
|
||||
Manually blocking identities is effective for immediate threats, but maintaining an up-to-date blocklist for a large network is impractical. Reticulum supports **automated list sourcing**, allowing your node to subscribe to blackhole lists maintained by trusted peers, or a central authority you manage yourself.
|
||||
|
||||
.. warning::
|
||||
**Verify Before Subscribing!** Subscribing to a blackhole source is a powerful action that grants that source the ability to dictate who you can communicate with. Before adding a source to your configuration, verify that the maintainer aligns with your usage policy and values. Blindly subscribing to untrusted lists could inadvertently block legitimate peers or essential services.
|
||||
|
||||
When enabled, your Transport Instance will periodically (approximately once per hour) connect to configured sources, retrieve their latest blackhole lists, and automatically merge them into your local blocklist. This provides "set-and-forget" protection for both individual users and large networks.
|
||||
|
||||
**Configuration**
|
||||
|
||||
To enable automated sourcing, add the ``blackhole_sources`` option to the ``[reticulum]`` section of your configuration file. This option accepts a comma-separated list of Transport Identity hashes that you trust to provide valid blackhole lists.
|
||||
|
||||
.. code:: ini
|
||||
|
||||
[reticulum]
|
||||
...
|
||||
# Automatically fetch blackhole lists from these trusted sources
|
||||
blackhole_sources = 521c87a83afb8f29e4455e77930b973b, 68a4aa91ac350c4087564e8a69f84e86
|
||||
...
|
||||
|
||||
**How It Works**
|
||||
|
||||
1. When enabled, the ``BlackholeUpdater`` service runs in the background.
|
||||
2. For every identity hash listed in ``blackhole_sources``, it attempts to establish a temporary link to its associated``rnstransport.info.blackhole`` destination.
|
||||
3. It requests the ``/list`` path, which returns a dictionary of blackholed identities and their associated metadata.
|
||||
4. The received list is merged with your local ``blackholed_identities`` database.
|
||||
5. The lists are persisted to disk, ensuring they survive restarts.
|
||||
|
||||
.. note::
|
||||
You can verify the external lists you are subscribed to, and their contents, without importing them by using ``rnpath -p``. See the :ref:`rnpath utility documentation<utility-rnpath>` for details on querying remote blackhole lists.
|
||||
|
||||
|
||||
Publishing Blackhole Lists
|
||||
==========================
|
||||
|
||||
If you are operating a public gateway, a community hub, or simply wish to share your blackhole list with others, you can configure your instance to act as a blackhole list publisher. This allows other nodes to subscribe to *your* definitions of unwanted traffic.
|
||||
|
||||
**Enabling Publishing**
|
||||
|
||||
To publish your local blackhole list, enable the ``publish_blackhole`` option in the ``[reticulum]`` section:
|
||||
|
||||
.. code:: ini
|
||||
|
||||
[reticulum]
|
||||
...
|
||||
publish_blackhole = yes
|
||||
...
|
||||
|
||||
When this is enabled, your Transport Instance will register a request handler at ``rnstransport.info.blackhole``. Any peer that connects to this destination and requests ``/list`` will receive the complete set of identities currently present in your local blackhole database.
|
||||
|
||||
**Federation and Trust**
|
||||
|
||||
The blackhole system relies on the trust relationship between the subscriber and the publisher. By subscribing to a source, you are implicitly trusting that source to only block identities that are genuinely detrimental to the network.
|
||||
|
||||
As the ecosystem matures, this system is designed to integrate with **Network Identities**. This allows communities to verify that a published blackhole list is actually provided by a specific network or organization with a certain level of reputation and trustworthiness, adding a layer of cryptographic trust to the federation process. This prevents malicious actors from publishing fake lists intended to censor legitimate traffic.
|
||||
|
||||
For operators, this creates a scalable model where maintaining a single high-quality blocklist can protect thousands of downstream peers, drastically reducing the administrative.
|
||||
|
||||
Improving System Configuration
|
||||
------------------------------
|
||||
|
||||
|
||||
@@ -178,6 +178,8 @@ Reticulum implements a range of generalised interface types that covers the comm
|
||||
|
||||
* Or to quickly create interfaces with custom hardware
|
||||
|
||||
* Anything else using :ref:`custom interface modules<interfaces-custom>` written in Python
|
||||
|
||||
For a full list and more details, see the :ref:`Supported Interfaces<interfaces-main>` chapter.
|
||||
|
||||
|
||||
@@ -186,6 +188,4 @@ Caveat Emptor
|
||||
Reticulum is an experimental networking stack, and should be considered as
|
||||
such. While it has been built with cryptography best-practices very foremost in
|
||||
mind, it has not yet been externally security audited, and there could very well be
|
||||
privacy-breaking bugs. To be considered secure, Reticulum needs a thorough
|
||||
security review by independent cryptographers and security researchers. If you
|
||||
want to help out with this, or can help sponsor an audit, please do get in touch.
|
||||
privacy-breaking bugs.
|
||||