Messaging Protocols over LXMF/Reticulum Research

Summary: Why traditional message brokers (AMQP, MQTT) don’t fit Reticulum. Recommends native LXMF pub/sub with optional MQTT bridge at edge for external integration.

Date: 2026-01-31 Context: Evaluating options for pub/sub and message broker patterns in Styrene mesh networks

Executive Summary

Traditional message broker protocols (AMQP, MQTT) are not well-suited to run natively over Reticulum/LXMF due to fundamental architectural differences. The recommended approach is to build pub/sub semantics native to LXMF, with optional bridges for external integration.

Current Landscape

Existing Bridges

LXMF-Tools by SebastianObi provides protocol bridges:

Bridge	Description
`lxmf_bridge_mqtt`	LXMF ↔ MQTT, JSON with configurable topics
`lxmf_bridge_matrix`	LXMF ↔ Matrix protocol
`lxmf_bridge_telegram`	LXMF ↔ Telegram
`lxmf_bridge_meshtastic`	LXMF ↔ Meshtastic devices

Also includes: lxmf_cmd (remote command execution), lxmf_terminal, lxmf_chatbot, distribution groups, and testing tools.

Key insight: These are edge gateway patterns - they translate between protocols at boundaries, not run one protocol over another.

What Doesn’t Exist

AMQP broker over RNS/LXMF
MQTT broker using RNS as transport
Native pub/sub primitives in LXMF

Why Traditional Brokers Don’t Fit

Protocol Assumptions

Protocol	Assumes	Reticulum Reality
AMQP	TCP/IP, persistent connections, ~MB/s throughput	150 bps - 500 Mbps, connectionless
MQTT	TCP, always-on broker, low latency	Delay-tolerant, store-and-forward
Kafka	High throughput, disk storage, partitions	Edge devices, minimal resources

Reticulum Characteristics

From Reticulum documentation:

Bandwidth: Targets 250 bps to 1 Gbps (currently 150 bps to 500 Mbps)
Transport: Works over LoRa, packet radio, WiFi, I2P, Ethernet, or any mix
No IP required: Complete networking stack, doesn’t need TCP/IP
Delay-tolerant: Designed for high latency, intermittent connectivity
Encryption: All communication encrypted by default (X25519/Ed25519)

LXMF Native Capabilities

LXMF already provides:

Propagation Nodes that peer and synchronize messages automatically
Encrypted, distributed message store
Zero-conf message routing
No accounts or registration required
Can encode messages as QR codes for analog paper transport

This is closer to eventually-consistent pub/sub than traditional message queuing.

Architectural Options

Option A: Native Styrene Pub/Sub (Recommended)

Build pub/sub semantics directly on LXMF primitives:

┌─────────────────────────────────────────────────────────┐
│              Styrene Pub/Sub Layer                      │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────┐ │
│  │ Topics      │  │ Subscriptions│  │ Message Fan-out │ │
│  │ (namespaced │  │ (persistent  │  │ (via LXMF       │ │
│  │  strings)   │  │  in registry)│  │  propagation)   │ │
│  └─────────────┘  └─────────────┘  └─────────────────┘ │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│                    LXMF                                  │
│  - Delivery to destination hash                         │
│  - Propagation nodes for store-and-forward              │
│  - End-to-end encryption                                │
└─────────────────────────────────────────────────────────┘

Proposed message types:

# Subscribe to topic pattern
{
    "type": "subscribe",
    "topic": "sensors/temperature/#",
    "protocol": "styrene_pubsub"
}

# Publish to topic
{
    "type": "publish", 
    "topic": "sensors/temperature/garage",
    "payload": {"value": 72.5, "unit": "F"},
    "protocol": "styrene_pubsub"
}

# Unsubscribe
{
    "type": "unsubscribe",
    "topic": "sensors/temperature/#",
    "protocol": "styrene_pubsub"
}

Advantages:

Delay-tolerant (works over LoRa)
End-to-end encrypted
No central broker required
Infrastructure nodes are optional accelerators, not SPOFs

Option B: MQTT Bridge at Edge

Use existing lxmf_bridge_mqtt for external integration:

External MQTT Clients ←→ [Edge/Infra Node] ←→ LXMF Mesh
                              │
                         mosquitto + 
                         lxmf_bridge_mqtt

Use cases:

Smart home integration (openHAB, Home Assistant, Node-RED)
Legacy IoT devices
External monitoring systems

Option C: Hybrid Approach

Combine both:

Native Styrene pub/sub for mesh-internal communication
MQTT bridge on infrastructure nodes for external integration
Clear separation of concerns

Scaling Considerations

When Local Registry Suffices

Mesh Size	Memory	SQLite	Notes
< 1K peers	~2 MB	Fine	Edge devices comfortable
1K-10K	~20 MB	Fine	Still works on Raspberry Pi
10K-50K	~100 MB	Slower queries	Consider infra nodes
50K+	~500 MB+	Pain point	Need distributed solution

Infrastructure Mode

For large meshes (10K+ nodes), infrastructure nodes could:

Run PostgreSQL/Redis for registry storage
Expose registry queries over LXMF-RPC
Aggregate and deduplicate announces
Provide message relay and offline delivery

Recommendations

Phase 1: PeerRegistry Foundation

Build local peer registry with dict + SQLite backing. This is required regardless of pub/sub approach.

Phase 2: Native Pub/Sub

Add topic-based routing and subscription management to Styrene RPC. Store subscriptions in PeerRegistry.

Phase 3: External Integration

Infrastructure nodes can optionally run MQTT bridge for external systems. Use existing lxmf_bridge_mqtt or similar.