[tptacek]

Is that an answer to some other question I asked? It doesn't seem to be responsive to what I just wrote.

I feel like what I'm sticking up for here is the practice of software development. Building an automated system that generates unexpectedly unwelcome load on someone else's service is... not exactly front-page news? It happens basically all the time? The idea that because the Go team is sponsored by Google, nothing like this should ever happen seems deeply unrealistic. "We can push a button to make this stop happening; the tradeoff is that other hosting services that don't care about this load might currently have fresher cache entries [whatever that means]" seems like a perfectly cromulent response.

He should just tell them to push the button. If you think he shouldn't, you should be able to say why.

I do have a mild rooting interest here: I think the Go module proxy is pretty neat, and does something interesting for the security of the ecosystem. DeVault disagrees. That's fine, disagreement keeps things interesting.

[kcartlidge]

> He should just tell them to push the button. If you think he shouldn't, you should be able to say why.

Accepting that Drew should get them to just push the button is accepting that it is the responsibility of each victim individually to cope with the abusive load being sent their way by engaging directly with their abuser. Rather than the sender, who is truly the one responsible, fixing it for every target by reducing their polling at source.

[voxtech]

More importantly, there is no threshold of usefulness where continuing the behavior is justified.

If the behavior is unimportant enough that drew should accept eliminating it, then its value does not justify the load.

If the behavior is important enough to justify the load, then eliminating it is no solution.

[tptacek]

I don't understand how this logic is meant to hold. The behavior can be of enough value to justify it where the cost to source hosts is low, but not of enough value to justify it for all hosts. Which is where we are now.

It feels like some comments here are trying to reconstruct what happened axiomatically purely from comments on the thread, without any empirical input from, like, how the Go module proxy actually works, and ending up in weird places as a result.

[kcartlidge]

Personally I'm trying to keep it tied down to an issue of responsibilities.

The abuser of resources should stop abusing. It isn't the fault of the victims and they shouldn't each individually need to address it. Stop the issue at source for everyone by stopping being anti-social/parasitical on the use of resources through excessive polling. I think that's the extent of my own argument here.

[tptacek]

It's not a great argument? If Github and Gitlab are fine with the polling, and the polling has even marginal benefits for Go users, why should we care how they handle Github and Gitlab? It sure looks like nobody on the Go project knew that sr.ht would care about these module clones, and when they found out, they gave DeVault the option of stopping them. I'm still not clear what the issue is.

If they knew DeVault's host wasn't going to be able to handle repeated module clones, a priori, then doing it anyways would be a problem. It doesn't look like anyone expected this to be a problem. It turned out it was, and there's a fix.