# 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
