# Why QuicProChat for Mesh: Comparison with Reticulum, Meshtastic, Briar, and Berty This page compares QuicProChat's mesh networking approach against existing mesh/P2P messaging systems. The goal is to explain where QuicProChat fits, what it does better, and what trade-offs it makes. --- ## At a Glance ``` Crypto Groups PQ-Ready Transport Maturity ────── ────── ──────── ───────── ──────── Meshtastic (LoRa) AES-CTR Shared No LoRa Mature no PFS key only Reticulum X25519 None No Any Mature PFS (links) Briar Double 1-hop No BT/WiFi Mature Ratchet only Berty TBD TBD No IPFS/BLE Alpha (Wesh) QuicProChat MLS+PQ Full Yes QUIC/LoRa Early PFS+PCS groups /TCP/Serial ``` --- ## The Fundamental Problem Existing mesh messengers make one of two compromises: 1. **Good crypto, limited mesh** (Briar, Signal): Strong end-to-end encryption but limited to direct connections or one-hop relay. Messages don't traverse multi-hop mesh networks. 2. **Good mesh, limited crypto** (Meshtastic, Reticulum): Transport-agnostic multi-hop routing but weak or absent group encryption. No post-compromise security. No post-quantum protection. **QuicProChat bridges this gap:** MLS group encryption with post-quantum hybrid KEMs, running over a Reticulum-inspired transport-agnostic mesh with multi-hop routing. --- ## Detailed Comparison ### Meshtastic Meshtastic is the dominant LoRa mesh platform with hundreds of thousands of nodes deployed worldwide. It optimizes for simplicity and interoperability over advanced cryptography. | Property | Meshtastic | QuicProChat | |---|---|---| | **Channel encryption** | AES-256-CTR with shared key | MLS per-epoch keys | | **Forward secrecy** | None (same key forever) | Per-epoch key deletion | | **Post-compromise security** | None | MLS Update heals the tree | | **DM encryption** | PKC (X25519), recently added | MLS 1:1 or group DMs | | **Key management** | Manual channel key sharing | Automatic MLS key agreement | | **Post-quantum** | None | Hybrid X25519 + ML-KEM-768 | | **Recent vulnerabilities** | CVE-2025-52464 (low-entropy keys), CVE-2025-53627 (DM downgrade) | Designed for auditability | **Meshtastic's crypto model:** ``` ┌───────────────────────────────────────────────────────────────┐ │ Meshtastic Channel │ │ │ │ All nodes share the same AES-256 key (e.g., "LongFast") │ │ │ │ Node A ── broadcasts ──► Node B ── relays ──► Node C │ │ │ │ Anyone with the channel key can: │ │ • Read all messages (past and future) │ │ • Inject messages (no sender authentication) │ │ • Replay old messages │ │ │ └───────────────────────────────────────────────────────────────┘ ``` **QuicProChat's model:** ``` ┌───────────────────────────────────────────────────────────────┐ │ QuicProChat MLS Group │ │ │ │ Each epoch has a fresh group key derived from ratchet tree │ │ │ │ Node A ── encrypts ──► Node B ── relays ──► Node C │ │ (MLS epoch key) (cannot read) (decrypts) │ │ │ │ • Relay nodes cannot read content │ │ • Past epoch keys are deleted (forward secrecy) │ │ • Any member can trigger re-key (post-compromise security) │ │ • Hybrid KEM protects against quantum harvest-now attacks │ │ │ └───────────────────────────────────────────────────────────────┘ ``` **Why Meshtastic is still useful:** Mature, widely deployed, optimized for LoRa constraints. If your threat model doesn't require forward secrecy or post-quantum protection, Meshtastic is simpler to deploy. --- ### Reticulum Reticulum is the closest architectural inspiration for QuicProChat's mesh layer. It pioneered transport-agnostic cryptographic networking over any medium. | Property | Reticulum | QuicProChat | |---|---|---| | **Language** | Python (CPython required) | Rust (cross-compile, no_std possible) | | **Group encryption** | None (link-level only) | MLS RFC 9420 | | **Crypto primitives** | X25519, Ed25519, AES, HMAC-SHA256 | Ed25519, X25519+ML-KEM-768, ChaCha20-Poly1305, MLS | | **Post-quantum** | No | Yes (hybrid KEM) | | **Forward secrecy** | Link-level only | End-to-end (MLS epochs) | | **Post-compromise security** | No | Yes (MLS Update) | | **Wire format** | msgpack | CBOR (IETF standard) | | **Formal specification** | Reference implementation | Protobuf schemas, potential IETF draft | | **Embedded targets** | No (requires CPython) | Yes (Rust cross-compile) | | **Transport agnostic** | Yes (8 years mature) | Yes (Reticulum-inspired) | | **Announce/discovery** | Mature | Implemented (S3 complete) | | **Multi-hop routing** | Mature | In progress (S4) | **What QuicProChat takes from Reticulum:** - Announce-based self-organizing routing - Transport-agnostic architecture - Truncated hash-based addresses - Lightweight handshake for constrained links - Philosophy of "cryptography is mandatory, not optional" **What QuicProChat adds:** - End-to-end group encryption (MLS) instead of link-level only - Post-quantum protection (hybrid KEM) - Post-compromise security - Rust implementation for embedded/resource-constrained targets - IETF-standardized crypto (MLS RFC 9420) **Reticulum's link-level model:** ``` ┌─────────────────────────────────────────────────────────────────┐ │ Reticulum Link │ │ │ │ A ──────── encrypted link ──────── B │ │ (X25519 ephemeral per link) │ │ │ │ Multi-hop: │ │ A ── link ── Relay1 ── link ── Relay2 ── link ── B │ │ ▲ │ │ ▲ │ │ └───────────┴───────────┴───────────┘ │ │ Each relay can read and re-encrypt │ │ │ └─────────────────────────────────────────────────────────────────┘ ``` **QuicProChat's end-to-end model:** ``` ┌─────────────────────────────────────────────────────────────────┐ │ QuicProChat Mesh │ │ │ │ A ══════════ MLS ciphertext ═══════════════ B │ │ └─── transport ── Relay1 ── transport ── Relay2 ── transport ─┘ │ (opaque) (opaque) │ │ │ │ Relays forward bytes but cannot decrypt content │ │ (link encryption optional, defense in depth) │ │ │ └─────────────────────────────────────────────────────────────────┘ ``` --- ### Briar Briar focuses on high-threat environments (protests, shutdowns) with strong cryptographic guarantees and censorship resistance via Tor. | Property | Briar | QuicProChat | |---|---|---| | **E2E encryption** | Double Ratchet (per-contact) | MLS (groups native) | | **Group encryption** | Sender Keys | MLS ratchet tree | | **Post-compromise security** | Groups: No | Groups: Yes | | **Mesh topology** | One-hop social graph only | Multi-hop routing | | **Transports** | Bluetooth, WiFi Direct, Tor | QUIC, TCP, LoRa, Serial | | **Range** | 10-30m (BT) / 150m (WiFi) | LoRa: km-scale | | **Battery** | 4x Signal (constant scanning) | Configurable announce interval | | **Delay-tolerant** | Yes (store-and-forward) | Yes (MeshStore) | | **Pairing required** | Yes (contact exchange) | Optional (announce discovery) | **Briar's design philosophy:** Briar prioritizes privacy over delivery rate. Messages only travel directly to the intended recipient—no hopping through mutual contacts. This maximizes privacy but limits range. **QuicProChat's approach:** Multi-hop routing like Reticulum, but with end-to-end MLS encryption. Relay nodes cannot read content. This enables km-scale LoRa mesh while maintaining cryptographic privacy. **Battery comparison:** ``` Briar: ████████████████████████████████ 4x baseline (constant BT scan) Signal: ████████ baseline (server push) QPC: ██████████ 1.2x baseline (configurable announce) ``` --- ### Berty (Wesh Protocol) Berty uses IPFS/libp2p as its networking layer with a custom protocol (Wesh) for E2E encryption. | Property | Berty | QuicProChat | |---|---|---| | **Networking** | IPFS/libp2p | Custom (Reticulum-inspired) | | **DHT** | IPFS Kademlia | Announce-based routing | | **Message availability** | Depends on device online | Store-and-forward + server fallback | | **Mobile** | React Native + gomobile-ipfs | Native SDKs (planned) | | **Status** | Alpha, unaudited | Early development | **IPFS limitations for messaging:** - Content availability requires originating device online - DHT lookups add latency (seconds to minutes) - No timestamp authority for ordering - Mobile resource constraints (IPFS daemon is heavy) QuicProChat avoids these by not relying on a global DHT. Routing is local (announce propagation) and message storage is explicit (MeshStore with TTL). --- ## The QuicProChat Advantage: Layered Security Existing mesh protocols provide one or two layers of security. QuicProChat stacks three: ``` Meshtastic: Reticulum: QuicProChat: ─────────── ────────── ─────────── ┌─────────────┐ ┌─────────────┐ ┌─────────────────────┐ │ AES-256-CTR │ │ Link crypto │ │ Layer 3: Hybrid KEM │ │ (shared key)│ │ (X25519/AES)│ │ (X25519 + ML-KEM) │ └─────────────┘ └─────────────┘ ├─────────────────────┤ │ Layer 2: MLS │ │ (E2E group crypto) │ ├─────────────────────┤ │ Layer 1: Transport │ │ (QUIC/TLS or link) │ └─────────────────────┘ To decrypt: To decrypt: To decrypt: • Channel key • Each link key • TLS + MLS epoch key • At each hop + hybrid KEM (3 independent layers) ``` --- ## When to Choose Each System | Use Case | Best Choice | Why | |---|---|---| | **Casual LoRa chat** | Meshtastic | Mature, large community, good enough for non-sensitive use | | **Off-grid data transfer** | Reticulum | Transport-agnostic, Python ecosystem, LXMF for messaging | | **High-threat protest/shutdown** | Briar | Tor integration, one-hop privacy, proven in the field | | **Experimental P2P mobile** | Berty | IPFS ecosystem, mobile-first design | | **Security-critical mesh groups** | **QuicProChat** | MLS + PQ-KEM, multi-hop routing, self-hostable | **QuicProChat is for teams that need:** - End-to-end encrypted group messaging over mesh - Post-compromise security (automatic key healing) - Post-quantum protection (harvest-now-decrypt-later defense) - Multi-transport flexibility (QUIC + LoRa + Serial) - Auditable, standards-based cryptography (MLS RFC 9420) --- ## Technical Differentiation Summary | Capability | Meshtastic | Reticulum | Briar | Berty | QuicProChat | |---|---|---|---|---|---| | **Multi-hop mesh** | ✓ | ✓ | ✗ | ✗ | ✓ | | **LoRa native** | ✓ | ✓ | ✗ | ✗ | ✓ | | **E2E groups** | ✗ | ✗ | ⚠️ | ⚠️ | ✓ | | **Forward secrecy (groups)** | ✗ | ✗ | ⚠️ | ? | ✓ | | **Post-compromise security** | ✗ | ✗ | ✗ | ? | ✓ | | **Post-quantum** | ✗ | ✗ | ✗ | ✗ | ✓ | | **IETF-standard crypto** | ✗ | ✗ | ✗ | ✗ | ✓ | | **Rust/no_std capable** | ✗ | ✗ | ✗ | ✗ | ✓ | | **Self-hostable server** | N/A | N/A | N/A | ✗ | ✓ | Legend: ✓ = yes, ✗ = no, ⚠️ = partial, ? = unclear/unaudited --- ## What QuicProChat Gives Up Honest trade-offs: - **Maturity:** Meshtastic and Reticulum have years of production use. QuicProChat is early-stage. - **Community size:** Meshtastic has hundreds of thousands of nodes. QuicProChat is a research project. - **Simplicity:** Shared-key AES is simpler than MLS. QuicProChat trades simplicity for security. - **Battery/bandwidth:** MLS adds overhead. On extremely constrained links (SF12/BW125 LoRa), this matters. - **Real-world testing:** Briar has been used in actual protests and shutdowns. QuicProChat hasn't. --- ## Roadmap to "Best Mesh Protocol" Current status (2026-03-30): - [x] S1: Binary wire format (CBOR) — complete - [x] S2: Transport abstraction trait — complete - [x] S3: Announce & discovery protocol — complete - [ ] S4: Multi-hop routing — in progress - [ ] S5: Truncated addresses + lightweight handshake — planned - [x] S6: LoRa transport (mock) — complete, hardware integration next After S4-S5: - [ ] Hardware LoRa demo (SX1262, RNode) - [ ] Termux integration (Android as LoRa node) - [ ] Benchmark suite (crypto overhead on constrained devices) - [ ] Security audit (MLS integration, mesh routing, hybrid KEM) --- ## Further Reading - [Reticulum-Inspired Mesh Upgrade Plan](../../plans/reticulum-mesh-upgrade.md) — detailed sprint plan - [Mesh Networking Guide](../../getting-started/mesh-networking.md) — user-facing mesh docs - [Protocol Layers Overview](../protocol-layers/overview.md) — how the crypto stack composes - [Why This Design, Not Signal/Matrix/...](why-not-signal.md) — comparison with traditional messengers - [Comparison with Classical Protocols](protocol-comparison.md) — IRC, XMPP, Telegram comparison