Running¶

With no command, rettui starts the terminal UI (Using the TUI); --web starts the Web UI. The other commands work from a shell, without a UI.

The first start¶

Reticulum's default config only reaches your local network, so a new install usually hears no one. The first time rettui starts, in either UI, it opens a Getting started guide (g in the Status tab, or Getting started on the web UI's Status page, opens it again):

• Your name: the display name others see in your announces.
• Identity (terminal UI): use the identity file from Sideband, NomadNet, MeshChat or another rettui, to keep that address (see Data and Storage). The web UI says where the file is instead.
• Entry points: public entry points to connect through, the ones Colorado Mesh's mesh-client recommends, under the same headings (all but RNS Dublin Mainnet, whose address no longer exists):

Each ticked adds a TCP interface to that entry point to your Reticulum config. rettui tries each as the guide opens (a connection, closed at once) and shows how quickly it answered (up · 120 ms); one that refuses, doesn't answer, or whose name isn't found is greyed out and can't be ticked (down · refused), and it's tried again when the guide is opened a minute or more later. If none answer, the guide says so: the device may be offline, or a firewall may block them.

When the config has nothing besides the Auto interface (which reaches your local network only), the three that answer fastest are ticked: a fresh install needs a connection for discovery to hear of others, and with a few, one being down doesn't leave you unconnected. While they're being tried, the ticks move to the fastest as answers come in; once you tick or untick one yourself, they stay as you set them. A config with interfaces of its own (an entry point, a radio) isn't given any unless you tick them; one it already has (by address) shows as in your config already. Each operator sees your IP address, and anyone watching your connection can tell you use Reticulum. They stay connected alongside the entry points discovery finds. - Also find entry points near you over time: turns on interface discovery, as Reticulum's manual recommends, connecting to up to two entry points others announce (see Settings and Reticulum Config). You'll connect to hosts you didn't choose. Discovery hears of entry points through a connection you already have, so it needs one to start. Like the entry points, it's ticked only for a config with nothing besides the Auto interface: a config you've set up yourself is changed only as you ask. When the config is Python Reticulum's (in ~/.reticulum, ~/.config/reticulum or /etc/reticulum), the guide says it's shared with NomadNet, Sideband and rnsd, since changes to it are theirs too. - Pick a propagation node automatically (see Messaging): ticked the first time the guide opens, unless you picked a node by hand, with a warning under it while it's ticked: the node picked sees who your messages are for and when you collect them, and could lose them. Opened again later, it's as you set it. - Check for updates once a day (recommended): not ticked to start with. Ticked, rettui asks GitHub once a day whether a newer release is out, and says so (see Updating); GitHub sees your IP address, so leave it off if you use Reticulum to stay off the internet. It's Check for updates in Status too. - Learn more: Reticulum's manual (getting started, understanding Reticulum), RMAP World's map and directory.rns.recipes for finding entry points, using a LoRa radio (RNode Radios: rettui doesn't flash radios, the page covers the tools that do), the words you'll meet (Glossary), and this wiki.

Nothing changes until you choose Apply; if the Reticulum config changed, Reticulum restarts to connect. As each entry point connects, rettui says so; for one that hasn't within 45 seconds, it says why, in plain words, and keeps trying (in the log, and in the footer in the terminal UI). Not now (or Esc) closes it for good. If another program (such as rnsd) runs the shared instance, the guide leaves its config alone and says so. Installs from before the guide existed don't see it at start.

First steps¶

On a new install, the Status tab (in both UIs) shows five first steps, ticked as you take them: hear from others, announce yourself, choose a propagation node, back up your identity, and send a message. The terminal UI shows them on one line with the next one and its key (for example next: Back up your identity (b)); the web UI lists them with how to take each. Backing up is ticked when b saves a copy; the web UI can't make one, so it has an I've done it button for a copy you made yourself. Once all five are taken the line goes away; x (terminal UI) or Hide (web UI) hides it sooner, for good. Installs from before the first steps existed don't show them.

Commands¶

rettui                      # the TUI
rettui --web [ADDRESS]      # the web UI (default 127.0.0.1:8740)
rettui --web [ADDRESS] --https                          # over HTTPS, with rettui's own certificate
rettui --web [ADDRESS] --tls-cert FILE --tls-key FILE   # over HTTPS, with yours
rettui fetch <hash>[:/page/x.mu] [--raw] [--identify] [-o FILE]
rettui send <address> "text" [-a FILE]... [--mode auto|direct|propagated|paper]  # address or lxma:// link
rettui listen [--seconds N]  # announce, then print incoming messages
rettui sync [--node HASH]    # download messages from the propagation node
rettui ping <address>        # how long a Link takes to set up, and how many hops away
rettui path <address> [-d]   # find the path to any destination (-d: forget it)
rettui path -t               # list every path known
rettui probe <address> [--name NAME]  # time an answer, as rnprobe does
rettui update [--yes]  # check for a newer release, and install it (see Installing)
rettui backup [FILE] [--with-files] [--without-identity]  # everything to one file (see Data and Storage)
rettui restore FILE [--force]  # restore one, with rettui stopped
rettui address [--link]      # print your LXMF address (--link: as an lxma:// link with your key)

--data-dir DIR uses another data directory, and --rns-config DIR another Reticulum config.

path and probe take any destination's address: an LXMF address, a NomadNet node, a propagation node or an RRC hub. A path not known is asked for up to three times over a minute; each request after the first is printed as it goes. With rettui, rnsd or another Reticulum program running as the shared instance, path shows, finds and forgets that instance's paths; otherwise, the paths the last run with this Reticulum config saved. probe --name gives a destination's full name (such as rnsh.listen) for kinds rettui can't tell, which are sent a probe packet they must prove. See Network for how paths and probes work.

send --mode paper writes a paper message instead of sending it. It prints the lxm:// link, and before it the QR code if the output is a terminal wide enough to show it.

Which Reticulum config¶

By default, rettui uses the first Reticulum config it finds in /etc/reticulum, ~/.config/reticulum, or ~/.reticulum. If a shared instance is already running from that config (rnsd, NomadNet, Sideband), rettui joins it. Use --rns-config DIR to choose a different config. The Reticulum tab edits that config file.

Running as a service¶

To keep the web UI up without a terminal open (on a home server, or a Raspberry Pi with an RNode), run rettui --web as a systemd service. The login link is printed to the service's log; it's also in web_token in the data directory (https://…/?token= followed by its contents).

For your own user (no root needed), save this as ~/.config/systemd/user/rettui.service, with the path to rettui (which rettui) and the flags you want:

[Unit]
Description=rettui web UI
Wants=network-online.target
After=network-online.target

[Service]
ExecStart=%h/.cargo/bin/rettui --web 127.0.0.1:8740
Restart=on-failure
RestartSec=10

[Install]
WantedBy=default.target

Then:

systemctl --user daemon-reload
systemctl --user enable --now rettui
loginctl enable-linger "$USER"     # keep it running while you're logged out
journalctl --user -u rettui -e     # the login link, and anything printed

For the whole machine, as a user of its own, save it as /etc/systemd/system/rettui.service:

[Unit]
Description=rettui web UI
Wants=network-online.target
After=network-online.target rnsd.service

[Service]
User=rettui
Group=rettui
# An RNode on a serial port needs the dialout group (uucp on some systems).
SupplementaryGroups=dialout
ExecStart=/usr/local/bin/rettui --data-dir /var/lib/rettui --rns-config /var/lib/rettui/reticulum --web 0.0.0.0:8740 --https
StateDirectory=rettui
Restart=on-failure
RestartSec=10
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

sudo useradd --system --home-dir /var/lib/rettui --shell /usr/sbin/nologin rettui
sudo systemctl daemon-reload
sudo systemctl enable --now rettui
sudo journalctl -u rettui -e

Things to know:

• The Reticulum config: Reticulum keeps its storage beside its config, so the service must be able to write there. The user unit uses the first config found (below), as for you. The system unit above keeps its own in /var/lib/rettui/reticulum (made on the first start; set it up in the web UI's Reticulum section), since ProtectSystem=strict makes /etc read-only and ProtectHome=true hides home directories.
• rnsd: to join an rnsd service as a shared instance instead, use its config (--rns-config /etc/reticulum), add ReadWritePaths=/etc/reticulum, and keep After=rnsd.service so rettui starts once it's up.
• Listening: 0.0.0.0 reaches it from other devices. Prefer --https (see Web UI), a VPN, or a reverse proxy in front of it, as anyone with the link can read and send your messages.
• Logs: what rettui prints goes to the journal; its own log is rettui.log in the data directory, as detailed as Log level (Status) says.
• Stopping: systemctl stop lets rettui leave its RRC hubs and save everything, as Ctrl-C does.