From e2c04cf0c3aa6c4ee2a248e14c6b70e7ece5e7cb Mon Sep 17 00:00:00 2001
From: Christian Nennemann <christian@nennemann.de>
Date: Mon, 30 Mar 2026 23:54:05 +0200
Subject: [PATCH] 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!
---
 docs/status.md | 45 ++++++++++++++++++++++++++++++++-------------
 1 file changed, 32 insertions(+), 13 deletions(-)

diff --git a/docs/status.md b/docs/status.md
index 1a33fa0..57d7014 100644
--- a/docs/status.md
+++ b/docs/status.md
@@ -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?
 
 ---