Thanks for the pro-con list! The experience of... 1) build a thing because it's immediately useful for a specific use-case, 2) someone reuses it for another u

Thanks for the pro-con list! The experience of... 1) build a thing because it's immediately useful for a specific use-case, 2) someone reuses it for another use-case because it's already there and saves some work, 3) times passes 4) oops really important stuff now relies on this thing in ways that weren't originally intended ... seems like a common pattern (see: JWT succeeding as the format for interoperable tokens by dint of just being around). In this case, it seems like the pros are basically user-centered pros (`flyctl proxy`, existing tool interop, etc.) and the cons are basically fly-centered cons (state synchronization, maintaining the agent and making it work right). The cons that do affect users (slowness, maybe they can't speak 51820/udp) seem _annoying_ but not deal-breaking for a lot of use cases. If the slowness persists over a long time it will be interesting to see how users opt to route around it (architect applications / processes to not rely on this channel).