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:
@@ -1,29 +1,48 @@
|
||||
# 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
|
||||
|
||||
### Completed
|
||||
- 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
|
||||
- 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
|
||||
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.
|
||||
|
||||
### 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
|
||||
QuicProChat has **best-in-class crypto** AND **viable mesh efficiency** (for classical MLS). PQ hybrid mode needs constrained-link fallback.
|
||||
|
||||
### Open Design Questions
|
||||
- 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?
|
||||
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user