Evaluate Syncthing as additional P2P transport option

[lesaai]

Summary

Evaluate and potentially integrate Syncthing as an optional peer-to-peer transport for multi-device sync. Complements the existing Cloudflare Workers relay. Does NOT replace it.

The problem: The relay works but requires a Cloudflare account. Some users want zero external dependencies. The ~/.ldm/ tree (config, journals, identity files) doesn't need agent-aware sync... plain file mirror is enough.

The solution: Add Syncthing as an optional transport layer:

• ~/.ldm/ tree mirror: P2P sync for config, journals, identity files, daily logs
• Backup transport: real-time P2P backup to a second machine, no cloud dependency
• Simple device pairing: Master/Node model with QR scan, zero port forwarding
• Optional crystal.db mirror: for users who want zero Cloudflare (trade-off: loses agent-aware delta sync)

Critical Constraint

The Cloudflare Workers relay stays primary for Crystal chunk sync. It's agent-aware (watermarks, delta staging, chunk-level operations). Syncthing is file-level sync. Different tools for different problems.

Implementation Plan

Phased approach:

1. Evaluate (no code): install, benchmark small-file sync latency, test NAT traversal, document findings
2. Design UX: installer prompt, Master/Node pairing flow, QR scan
3. Build thin wrapper: LaunchAgent daemon, CLI commands (crystal sync enable/status/pair), MCP status endpoint
4. Optional crystal.db mode: --transport=syncthing for zero-dependency users

Decision gate after Phase 1: if latency > 10s or setup is painful, stop.

Context

• Full product idea: ai/product/product-ideas/syncthing-transport-option.md (private repo)
• Full plan: ai/product/plans-prds/upcoming/syncthing-transport-plan.md (private repo)
• Origin: External code review suggested replacing relay with Syncthing. Replacement is wrong; additional transport is right.
• Syncthing license: MPL-2.0 (compatible with our MIT/AGPL dual)

Labels

enhancement, transport, multi-device