Christian Nennemann
9b09f09892
Key insight: best-in-class crypto but unproven mesh efficiency. Priority actions: complete S4, measure MLS sizes, design MLS-Lite.
86 lines
5.1 KiB
Markdown
86 lines
5.1 KiB
Markdown
# Status Log
|
|
|
|
## 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
|
|
|
|
### 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?
|
|
|
|
---
|
|
|
|
## 2026-03-30 — Sprint 6: LoRa transport & integration demo
|
|
|
|
### Completed
|
|
- Added `transport_lora.rs`: `LoRaConfig`, Semtech-style airtime estimate, `DutyCycleTracker` (rolling 1 h window, `eu868_one_percent()`), `LoRaMockMedium` + `LoRaTransport` implementing `MeshTransport` (`lora` name for `TransportManager`), LR framing with automatic fragmentation/reassembly, tests (mock roundtrip, fragmentation, duty accounting, `split_for_mtu`).
|
|
- Example `mesh_lora_relay_demo`: A (LoRa mock) → B (relay) → C (TCP) and reply path; `scripts/mesh-demo.sh` runs it.
|
|
- Wired `pub mod transport_lora` in `lib.rs`.
|
|
- Adjusted `cbor_smaller_than_json` to assert CBOR is materially smaller than JSON (fixed overhead dominates; a strict half-JSON threshold failed on current envelope sizes).
|
|
|
|
### What's next
|
|
- Optional: UART-backed `LoRaTransport` behind a feature flag (modem-specific framing).
|
|
- Hardware runbook: replace mock medium with RNode / SX1262 serial when available.
|
|
|
|
## 2026-03-30 — Sprint 3: Announce & Discovery Protocol
|
|
|
|
### Completed
|
|
- Created `MeshAnnounce` struct with Ed25519 signed announcements, CBOR wire format, hop forwarding
|
|
- Created `compute_address()` — SHA-256 truncation of identity key to 16-byte mesh address
|
|
- Created `RoutingTable` with `RoutingEntry` — keyed by 16-byte address, supports lookup by address or full key, TTL-based expiry, sequence-based stale rejection
|
|
- Created `AnnounceDedup` for loop prevention (address+sequence deduplication)
|
|
- Created `AnnounceConfig` with sensible defaults (10min interval, 30min max age, 8 max hops)
|
|
- Created `create_announce()` and `process_received_announce()` — complete announce processing pipeline (verify, expiry check, dedup, routing update, propagation decision)
|
|
- Capability flags: CAP_RELAY, CAP_STORE, CAP_GATEWAY, CAP_CONSTRAINED
|
|
- Tests: 17 tests across 3 modules covering signature verification, tampering, forwarding, expiry, dedup, routing updates, stale rejection, CBOR roundtrip, address determinism
|
|
- Updated lib.rs with `announce`, `announce_protocol`, `routing_table` modules
|
|
|
|
### What's Next
|
|
- S4: Multi-Hop Routing
|
|
- Integrate announce protocol with TransportManager for actual broadcast/receive loops
|
|
- Add tokio async announce loop (periodic re-announce, GC timer)
|
|
|
|
### Notes
|
|
- Signature excludes `hop_count` (same design as MeshEnvelope) so forwarding doesn't break verification
|
|
- Protocol engine uses free functions rather than a stateful struct — simpler, more testable
|
|
- Cannot run `cargo test` in this environment (no C toolchain / linker available)
|
|
|
|
## 2026-03-30 — Sprint 2: Transport Abstraction Layer
|
|
|
|
### Completed
|
|
- Created `MeshTransport` trait with `send`, `recv`, `discover`, `close` methods
|
|
- Created `TransportAddr` enum for transport-agnostic addressing (Iroh, Socket, LoRa, Serial, Raw)
|
|
- Created `TransportInfo` struct for transport capability metadata
|
|
- Implemented `IrohTransport` wrapping iroh `Endpoint` with same length-prefixed framing as `P2pNode`
|
|
- Implemented `TcpTransport` using tokio `TcpListener`/`TcpStream` with length-prefixed framing
|
|
- Implemented `TransportManager` for multi-transport routing based on address type
|
|
- Added `async-trait` dependency, enabled tokio `net` + `io-util` features
|
|
- Tests: TransportAddr Display formatting, TCP roundtrip, TransportManager routing, error cases
|
|
|
|
### What's Next
|
|
- S3: Announce & Discovery Protocol
|
|
- Future: integrate transport layer into `HybridRouter` / replace direct iroh usage
|
|
|
|
### Notes
|
|
- New transport layer sits alongside existing `P2pNode` — no breaking changes
|
|
- `IrohTransport` uses separate ALPN (`quicprochat/mesh/1`) to avoid conflicts with `P2pNode`
|
|
- Cannot run `cargo test`/`cargo clippy` in this environment (no Rust toolchain installed)
|