Reticulum-Community-Hub

Reticulum Community Hub (RCH)

Community-owned coordination over Reticulum.

Reticulum Community Hub gives a group a shared place to communicate, maintain a common operational picture, coordinate work, and exchange files over Reticulum and LXMF. It is designed for intermittent links, limited bandwidth, and networks that must remain useful without depending on a central Internet service.

RCH is the hub and operator interface in the R3AKT product family:

R3AKT
Reticulum Resilient Response Tactical Kit
Democratizing Situational Awareness

What RCH provides

RCH adds shared services and persistent state to a Reticulum network:

• targeted, broadcast, and topic-based messaging over LXMF;
• telemetry collection and a shared map with operator-managed markers;
• missions, teams, members, assets, skills, and assignments;
• collaborative checklists for procedures and field tasks;
• Emergency Action Messages and team status summaries;
• file and image storage with topic associations;
• a REST and WebSocket API for clients and integrations;
• an optional TAK connector for Cursor-on-Target chat and position exchange.

SQLite is the durable message-history and delivery-recovery owner. The runtime message cache keeps at most 500 records and an estimated 32 MiB, with a 30-minute inactivity limit. /Chat/Messages reads durable history, so cache eviction does not remove old messages or abandon pending delivery. See bounded persistence for the transaction, migration, and validation details.

RCH does not replace Reticulum. Reticulum provides the network. RCH provides the shared coordination services that a community or field team needs on top of it.

Where it fits

REM, R3AKT Client, and other LXMF applications
                     |
              Reticulum + LXMF
                     |
            LXMF-rs reticulumd
                     |
              RCH Rust server
               /           \
       Web/Desktop UI     REST/WebSocket API
                              |
                     Optional TAK service
                              |
                         TAK network

A hub can serve a local group, operate across several Reticulum interfaces, or participate in a larger federation without surrendering local control.

Project status

RCH is being rewritten in Rust for the 3.0 product line. The current workspace contains the Rust server, shared domain crates, the Reticulum/LXMF transport adapter, the web and desktop application, and a separate TAK connector service.

The Rust edition is currently preview software. Use it for testing, integration work, and community evaluation. Review the release notes before using it for unattended or safety-critical deployments.

The current testing candidate is v3.0.0-preview.37, a Linux AMD64 server prerelease for DigitalOcean evaluation. It pairs LXMF-rs SDK 0.16.1 with a daemon built from the same immutable source revision 9b972f9a8d3a7949eae89bc78f7a9691f06f3ed1. The existing release workflow builds the complete Linux AMD64 server archive and a Debian installer using Debian 12 (Bookworm) and Rust 1.99.1; other server platforms and desktop packages are outside this candidate’s scope. Preview.25 remains the earlier full-platform package record. Release notes for every preview are attached to its GitHub release; older notes are kept under docs/. Install the server and daemon from the same package or pinned revision. The AMD64 Debian package targets Debian 12 or later and compatible Ubuntu releases whose libraries satisfy its declared dependencies. It includes the UI and paired daemon, and requires no Rust, Node.js or Python toolchain to install.

The server package workflow selects Tokio 1.53.3 before its locked daemon build. release-manifest.json records the configured requirement as lxmf.required_daemon_tokio_version, alongside the LXMF source commit and daemon checksum. The workflow build log verifies dependency selection; package assembly does not infer a Tokio version from an arbitrary binary.

The Python 2.9.x edition is preserved on the rch-python branch for critical maintenance and reference behavior.

The implementation, migration, and validation notes that previously occupied this README are now referenced from the Rust migration status document.

Getting started

Install a packaged build

The simplest route is to use a package from GitHub Releases. On a supported Debian or Ubuntu AMD64 host, download the .deb and its .sha256 file, verify the checksum, then install it with sudo apt install ./rch-server_3.0.0.preview.37-1_amd64.deb. Configure /etc/rch before explicitly enabling services; installation does not start them. See the packaging instructions for configuration, upgrade preservation and startup. Server archives and desktop packages have their own release notes and platform requirements.

Build the Rust server from source

Requirements:

• Rust 1.89 or newer for the server workspace and Tauri desktop shell;
• a local Reticulum configuration;
• LXMF-rs reticulumd for live LXMF transport;
• Node.js and npm only when building the web or desktop interface.

Clone and build the server:

git clone https://github.com/FreeTAKTeam/Reticulum-Community-Hub.git
cd Reticulum-Community-Hub
cargo build --release -p r3akt-rch-server

Start the HTTP server for local development:

cargo run -p r3akt-rch-server -- \
  --bind 127.0.0.1:8080 \
  --db-path ./rch-runtime.db \
  --config-path ./config.ini \
  --reticulum-config-path "$HOME/.reticulum/config" \
  --api-key change-this-preview-key

This starts the RCH API and local state service. A live mesh deployment also requires the LXMF-rs ZeroMQ endpoints and a local Reticulum destination. See Rust migration status for the current runtime path and development commands.

Replace the example key with a unique credential. Protected routes, including /Status, /diagnostics/runtime, internal adapters and WebSocket streams, require authentication even on loopback. To enroll through the local first-run UI instead, omit --api-key and add --ui-dist-path ./ui/dist after building the shared UI. Documentation and local setup remain available before enrollment.

RCH requires the paired daemon durable broker (--zmq-durable-broker). Its persisted inbox and outbound intents replace legacy event polling and retry ownership. See durable broker cutover before upgrading an existing deployment.

For an already running daemon, use its command endpoint and a response endpoint owned by this RCH instance:

cargo run -p r3akt-rch-server -- \
  --bind 127.0.0.1:8080 --db-path ./rch-runtime.db \
  --config-path ./config.ini --api-key change-this-preview-key \
  --lxmf-zmq-command tcp://127.0.0.1:9100 \
  --lxmf-zmq-response tcp://127.0.0.1:9101 \
  --ui-dist-path ./ui/dist

RCH registers and derives its service destination. --reticulumd-source is optional and only asserts that registered RCH destination.

To let RCH manage the matching daemon, add --reticulumd-exe ../LXMF-rs/target/release/reticulumd, and provide --reticulumd-db-path ./reticulum.db and --reticulum-config-path "$HOME/.reticulum/config". Build that daemon with zmq-pipeline-rpc enabled. Verify /Status and /diagnostics/runtime; a daemon-backed launch must show the configured source and running daemon.

Remote browser connections require HTTPS/WSS. For a TLS proxy or separately hosted UI, set exact comma-separated RCH_ALLOWED_ORIGINS values such as https://rch.example.org. Local loopback HTTP/WS remains supported.

After startup, useful local endpoints include:

• http://127.0.0.1:8080/Status
• http://127.0.0.1:8080/Help
• http://127.0.0.1:8080/openapi.json
• http://127.0.0.1:8080/diagnostics/runtime

Examples

The maintained examples guide walks through server startup, authentication, health and runtime diagnostics, topics, direct/topic/broadcast chat, files, missions and checklists, WebSockets, Reticulum ZeroMQ attachment, and the standalone TAK sidecar. The live server also exposes a compact plaintext quick reference at GET /Examples.

For a first authenticated request:

curl -H 'X-API-Key: change-this-preview-key' \
  http://127.0.0.1:8080/Status

For operational deployment and failure diagnosis, continue with the operations and troubleshooting guide. For large user inventories, see identity directory pagination.

Main components

Component	Purpose
r3akt-rch-server	HTTP, WebSocket, persistence, UI hosting, and RCH runtime
r3akt-rch-core	Missions, teams, checklists, topics, delivery state, and authorization
r3akt-transport-rns	Reticulum and LXMF integration through LXMF-rs
r3akt-profile-rch	RCH command, result, and event fields on LXMF
r3akt-protocol	Shared MessagePack envelopes and acknowledgement types
r3akt-identity	Identity, trust, and enrollment decisions
r3akt-tak-connector	Independent TAK and Cursor-on-Target bridge service
ui/	Shared Vue operator interface
apps/rch-desktop/	Tauri desktop packaging

Related projects

• REM: Reticulum Mobile Emergency Management
• R3AKT Client
• LXMF-rs
• FreeTAKTeam repositories

Development and verification

Hub display name

The Rust server owns the RCH service name in SQLite rch_settings.hub_name. At startup and POST /Command/ReloadConfig, it reconciles that saved name into both [hub] name and [hub] display_name in config.ini. Existing installations without a saved name migrate from [hub] name, then [hub] display_name, then RCH, regardless of INI line order. Conflicting package defaults cannot replace a saved name; keep the database and service identity file across upgrades. Changed legacy configuration is backed up before reconciliation.

To rename, save configuration with PUT /Config, changing either name field or changing both to the same value. One edited field wins over its unchanged mirror; competing edits are rejected. Omitted or unchanged fields retain the saved name. Names must be nonempty, at most 80 characters, and contain no control characters. Config rollback restores the backup’s name, then display_name, or retains the saved name when neither is present. Direct file edits after migration do not override the saved name; use PUT /Config for renames.

Setup, config saves, reload and rollback publish fresh LXMF service metadata using the existing identity keys and destination hash. The daemon’s own display_name belongs to its separate identity and does not override the RCH name. Setup status and app-info report the same desired name; app-info’s unnamed fallback is RCH. If publication fails after a save, the desired name stays saved and the route returns a publication error. First-run setup instead reports successful credential enrollment with identity_announce_update_pending and last_identity_announce_update_error, so enrollment is not repeated. /diagnostics/runtime exposes both fields; publication remains pending without an LXMF runtime. Retry with ReloadConfig or restart after restoring connectivity. Clients can display the old cached name until they receive the fresh announce.

Before submitting a pull request, run the Rust quality checks:

cargo fmt --all -- --check
cargo clippy --workspace --all-targets -- -D warnings
cargo test --workspace

The repository also contains release-readiness scripts and live Reticulum validation tools. These are documented in Rust migration status.

Contributing

Issues, tests, documentation corrections, and pull requests are welcome. Keep changes focused, explain the user-visible effect, and add tests for modified runtime behavior.

For substantial protocol or architecture changes, open an issue first so the wire contract and compatibility impact can be discussed before implementation.

License

RCH is licensed under the Eclipse Public License 2.0.

The Rust implementation also provides the optional R3S/1 origin sensor telemetry contract, including native map projections and the TAK sensor adapter. Its provisional SID and remaining delivery/hardware release gates are documented there.