What this is

A browser-based Reticulum messaging client. It generates your cryptographic identity locally in your browser, talks to a radio or daemon for transport, and exchanges end-to-end encrypted LXMF messages with other Reticulum nodes (Sideband, MeshChat, NomadNet, other RNodes). Nothing leaves your browser except over the transport you connect to.

Three ways to connect

• BLE — Web Bluetooth to an RNode LoRa modem. Works on Chrome, Edge, and Brave on Android or desktop. Primary path for LoRa.
• Serial — Web Serial to a USB-connected RNode. Desktop Chrome/Edge/Brave.
• WebSocket — connect to a local or remote rnsd Reticulum daemon through the small Python bridge in tools/ws_bridge.py. Works in every modern browser including Safari, Firefox, and iOS. Use this when you do not have an RNode plugged in or when the browser does not have Web Bluetooth. See the TCP (WebSocket) connection section in the README for setup.

Your identity

The first time you load the page, the client generates a fresh Ed25519 / X25519 identity and stores it in your browser's IndexedDB. Your LXMF address (the 16-byte hash shown under Identity) is derived from that identity and stays the same as long as you do not click New Identity. The Export Identity button writes the private keys to a JSON file so you can move the identity to a different browser or back it up. Never share that file with anyone you do not trust with your messages.

Announcing yourself

Clicking Announce now broadcasts your identity and display name to the Reticulum network. Other nodes learn how to reach you and show you in their contact lists. The client also auto-announces once at connect time and every five minutes after that so the network's path tables stay warm. Without the periodic re-announce, some nodes will silently drop link deliveries addressed to you.

Contacts and Nodes

When the client receives an announce from another LXMF delivery destination, it appears in the Messages contact list. Click a contact to open the conversation.

Announces from non-LXMF destinations — repeater telemetry beacons, heartbeats, auxiliary destinations — never appear in Messages because they are not people you can talk to. They show up in the Nodes view instead, with last-seen time, RSSI, and destination hash. That gives you visibility into the rest of the mesh without cluttering your conversations.

Sending messages and what the marks mean

Type in the compose box and hit Enter (or click Send). A new row appears in the conversation view with a small status glyph next to the timestamp that updates as the send progresses:

• ⏳ pending — the radio is off or the previous send attempt failed; the retry tick will pick it up when the radio is up again.
• ↑ sending — the packet is in flight to the radio right now.
• ✓ sent — the radio has transmitted, but no delivery receipt has come back from the recipient yet.
• ✓✓ delivered — the recipient sent back a delivery proof. The message was received and acknowledged.
• ✗ failed — all retries are exhausted. Hover for the last error.

If a send times out waiting for a delivery proof, the retry tick re-transmits it automatically with a 5s / 15s / 60s backoff (three attempts total, then failed).

Privacy

All Reticulum protocol work — identity, ECDH, HKDF, AES-CBC, HMAC, Ed25519 signing, LXMF packing — happens inside your browser. The radio or daemon on the other end of the transport only sees encrypted packets; it does not see your private keys and cannot decrypt your messages. Message history is stored in IndexedDB, never uploaded anywhere. Closing or clearing the site data wipes everything local.

Security and trust model

This section describes what the app protects and what it does not, so you can make an informed decision about the risks you accept.

• End-to-end encryption — every LXMF message is encrypted with a fresh ephemeral X25519 key exchange and AES-256-CBC + HMAC before it leaves your browser. Neither the radio, the transport daemon, nor any relay node can read message content. Delivery receipts on link-delivered messages are signed with Ed25519 and are unforgeable.
• Private keys at rest — your Ed25519 signing key, X25519 encryption key, and ratchet key are stored unencrypted in your browser's IndexedDB. Anyone with access to your browser profile (browser extensions, device backup tools, physical access to an unlocked device) can extract them. The Export Identity file is likewise unencrypted JSON containing the full private keys. Treat it like a password and store it somewhere safe.
• Forward secrecy — the ratchet key is generated once when your identity is created and is never rotated. It does not provide forward secrecy in the current implementation. If an attacker obtains your private key, they can decrypt past messages they previously captured.
• BLE transport — the Bluetooth link between your device and the RNode modem is not encrypted at the radio layer (no BLE bonding). An observer within Bluetooth range (~10 m) can see the encrypted Reticulum packets and their headers (destination hashes, packet types, sizes, timing) but cannot decrypt the message content inside them.
• WebSocket transport — when connecting to a remote rnsd daemon over ws:// (not wss://), Reticulum packet headers are visible to any network observer on the path. Message content remains end-to-end encrypted. Use wss:// for remote connections if your bridge supports TLS. A warning banner appears in the app when a non-localhost ws:// connection is active.
• Metadata — Reticulum packet headers contain destination hashes in cleartext by design. Any observer on the radio channel or transport path can see who is communicating with whom (by destination hash) and the timing and size of packets, even though they cannot read the content. Periodic announces broadcast your public key, display name, and destination hash to the mesh.
• Map tiles — the Nodes map loads tiles from OpenStreetMap (tile.openstreetmap.org). The tile server sees your IP address and the geographic area you are viewing, though it does not see your identity or messages.