c/quicproquo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: add mesh protocol comparison (Reticulum, Meshtastic, Briar, Berty)

Browse Source 
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.
This commit is contained in:
Christian Nennemann
2026-03-30 23:29:50 +02:00
parent 01bc2a4273
commit 84ec822823
2 changed files with 330 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

329
docs/src/design-rationale/mesh-protocol-comparison.md Normal file
View File

@@ -0,0 +1,329 @@
# 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