docs: update status with implementation sprint results

Completed S4-S5 and MLS-Lite implementation:
- MeshRouter with multi-hop routing
- REPL commands /mesh trace, /mesh stats
- MeshEnvelope V2 with truncated addresses
- MLS-Lite lightweight encryption

Key finding: Classical MLS (306B KeyPackage) IS LoRa-viable!
This commit is contained in:
2026-03-30 23:54:05 +02:00
parent bcde8b733c
commit e2c04cf0c3

View File

@@ -1,29 +1,48 @@
# Status Log # Status Log
## 2026-03-30 — Implementation Sprint (S4-S5 + MLS-Lite)
### Completed
- **S4: Multi-hop routing** — `MeshRouter` with `send()`, `handle_incoming()`, `forward()`, `drain_store_for()`
- **S4: REPL commands** — `/mesh trace <address>` and `/mesh stats`
- **S5: Truncated addresses** — `MeshEnvelopeV2` with 16-byte addresses (~18% smaller)
- **MLS-Lite** — Lightweight symmetric mode for constrained links (`mls_lite.rs`)
- **Size measurements** — Actual MLS and envelope sizes benchmarked
### Actual Measured Sizes (Key Finding!)
| Component | Size | LoRa SF12 fragments |
|-----------|------|---------------------|
| MLS KeyPackage | 306 bytes | 6 |
| MLS Welcome | 840 bytes | 17 |
| MLS-Lite (no sig) | 129 bytes | 3 |
| MLS-Lite (with sig) | 262 bytes | 6 |
| MeshEnvelope V1 | 410 bytes | 9 |
| MeshEnvelope V2 | 336 bytes | 7 |
| MLS KeyPackage (PQ hybrid) | 2,676 bytes | 53 |
**Key insight:** Classical MLS is actually LoRa-viable! 6 fragments for KeyPackage, ~14 sec for group setup at 1% duty. PQ hybrid remains impractical.
### What's Next
1. KeyPackage distribution over mesh (announce-based)
2. Transport capability negotiation
3. Real hardware testing (LoRa boards)
4. MLS-Lite upgrade path to full MLS
---
## 2026-03-30 — Mesh Protocol Gap Analysis ## 2026-03-30 — Mesh Protocol Gap Analysis
### Completed ### Completed
- Created `docs/plans/mesh-protocol-gaps.md` — honest assessment of QuicProChat vs. Reticulum/Meshtastic/Briar - Created `docs/plans/mesh-protocol-gaps.md` — honest assessment of QuicProChat vs. Reticulum/Meshtastic/Briar
- Created `docs/src/design-rationale/mesh-protocol-comparison.md` — technical comparison document - Created `docs/src/design-rationale/mesh-protocol-comparison.md` — technical comparison document
- Updated `docs/positioning.md` — sharper messaging + honest limitations - Updated `docs/positioning.md` — sharper messaging + honest limitations
- Identified critical gaps:
1. **MLS overhead too large for LoRa** — KeyPackages are 500-800 bytes, SF12 MTU is 51 bytes
2. **KeyPackage distribution unsolved** — MLS needs server, mesh has no server
3. **No lightweight mode** — need "MLS-Lite" for constrained links
4. **No real hardware testing** — all LoRa code runs against mocks
### Key Insight ### Key Insight
QuicProChat has **best-in-class crypto** but **unproven mesh efficiency**. Meshtastic and Reticulum have **weak crypto** but **battle-tested mesh**. We need to close the efficiency gap without sacrificing crypto properties. QuicProChat has **best-in-class crypto** AND **viable mesh efficiency** (for classical MLS). PQ hybrid mode needs constrained-link fallback.
### Priority Actions
1. **S4: Multi-hop routing** — complete core mesh (in progress)
2. **Measure actual sizes** — benchmark MLS KeyPackage, Welcome, Commit sizes
3. **Design MLS-Lite** — lightweight symmetric mode for constrained links
4. **Real hardware test** — procure SX1262 boards, test actual LoRa
### Open Design Questions ### Open Design Questions
- How to distribute KeyPackages over mesh without server? - How to distribute KeyPackages over mesh without server?
- What's the right crypto/efficiency tradeoff for SF12 LoRa?
- Should we implement LXMF compatibility for Reticulum interop? - Should we implement LXMF compatibility for Reticulum interop?
--- ---