Repository navigation
spike: WireGuard implementation choice — wireguard-go vs boringtun for Unit 4 #486
Description
Spike
repo: gominimal/minimal
question: For Unit 4's WireGuard mesh (R4.1), should minimald embed wireguard-go (via cgo, requires a Go toolchain — already needed for gvproxy source build) or boringtun (pure Rust, no additional toolchain dep)? Which is more production-ready for the subnet-router model minimald requires?
hypothesis: wireguard-go is the safe choice (Tailscale's production reference implementation, actively maintained) and has reduced marginal CI cost since gvproxy's source build already requires Go. boringtun is a viable pure-Rust alternative but has narrower production adoption at the subnet-router level.
load-bearing-assumption: wireguard-implementation
depends-on: spec requirement R4.1, R4.7 (Unit 4 of spec-networking); gvproxy-source-build assumption
proof-of-resolution: A written finding at docs/spikes/<date>-wireguard-implementation.md with: (1) a comparison of wireguard-go vs boringtun production maturity for the subnet-router model, (2) CI build-chain impact of each choice given Go is already required for gvproxy, (3) a recommendation with rationale.
Related to #478
Generated by sdd-triage-arch for issue #478 · ◷
Activity
gominimal-aw-bot commentedon Jun 20, 2026
/execute
gominimal-aw-bot commentedon Jun 20, 2026
/execute
docs(spikes): spike wireguard-go vs boringtun for Unit 4 WireGuard mesh
gominimal-aw-bot commentedon Jun 20, 2026
Pull request created: #488