The proposed resolutions from Google have been along the lines of changes to the proxy application code. The resistance has been that this is hard because of th

The proposed resolutions from Google have been along the lines of changes to the proxy application code. The resistance has been that this is hard because of the way responsibility is divided between the thin layer that provides the proxy web service and the ‘go’ command itself, which actually fetches the packages. Would it be simple to solve this with an additional layer of the same proxy? Currently, end users request a package from proxy.golang.org as per the default value of the GO_MOD_PROXY env var. Google runs many of these to handle the traffic, let’s say 1000. They all maintain a mirror of all packages that have been recently requested (note that I expect there’s more nuance here around shared lists of required packages, etc, but the structure should hold true) The result is that every one of the 1000 proxy instances requests the source data from git.sr.ht every day. Google could set GO_MOD_PROXY on the existing instances to internalproxy.golang.org. They could then run 100, or maybe 10 of these internal instances. This would drop the traffic to hit.sr.ht by one or two orders of magnitude. I suspect it would require minimal if any change to application code. This might be accomplished entirely within the remit of a sysadmin (SRE?). Any holes in my reasoning?