Christian Nennemann
84ec822823
Technical comparison showing QuicProChat's differentiation: - Only mesh protocol with MLS group encryption + PQ-KEM - Multi-hop routing + LoRa support (like Reticulum) - End-to-end crypto (relays see opaque ciphertext) Honest about tradeoffs vs mature alternatives.
17 KiB
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:
-
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.
-
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):
- S1: Binary wire format (CBOR) — complete
- S2: Transport abstraction trait — complete
- S3: Announce & discovery protocol — complete
- S4: Multi-hop routing — in progress
- S5: Truncated addresses + lightweight handshake — planned
- 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 — detailed sprint plan
- Mesh Networking Guide — user-facing mesh docs
- Protocol Layers Overview — how the crypto stack composes
- Why This Design, Not Signal/Matrix/... — comparison with traditional messengers
- Comparison with Classical Protocols — IRC, XMPP, Telegram comparison