Looking at the Sonic repo, here's what I can piece together from the README and project structure to answer those three questions. Since the actual personal story is something only you know, treat this as a technical-motivation draft you can layer your real backstory onto. What inspired it: The README frames Sonic explicitly against Cloudflare Workers — same "intercept and edit traffic with JS" developer experience, but without the vendor lock-in. The likely spark was wanting that edge-compute pattern on infrastructure you actually own (a VPS, a Raspberry Pi, bare metal) rather than renting it from a cloud provider, and using Linux's eBPF to do the packet-level work at near-kernel speed instead of leaning on a third-party edge network. The problem it solves: Running and modifying HTTPS traffic live, on your own server, without touching DNS and without changing the client or the origin server. Sonic acts as a transparent proxy that terminates TLS via its own MITM layer, then hands the request/response to a JS function (the worker model) before re-encrypting and forwarding it on. Because the worker API mirrors Cloudflare's, existing Workers code can mostly drop in unchanged. The eBPF Sockmap layer exists so that interception doesn't become a performance tax, and there's no cold-start penalty since it's an always-on Go process rather than a serverless invocation.

Sonic

Transparent L7 proxy, eBPF-accelerated,

Transparent L7 proxy, eBPF-accelerated,