@rene If you're looking at it for userscripts, there's really no way to completely handle backoff as required by the SE API, unless you're only running a single userscript, in a single tab, in a single browser profile, in a single browser, on a single machine, on your external IP address.
Basically, given the SE API's requirement that backoff be honored per endpoint for every use on the IP address, to completely comply would require coordination between everything accessing the SE API from that IP address. It should be possible for something like MS (complicated by multi-threading/processing), but for a userscript it's effectively impossible.
That doesn't mean a userscript can't do a very good job, just that it's likely to encounter problems from time to time. How many issues there are will depend largely on the combination of things which are being run: what the user is doing (e.g. how many tabs are open and what's happening in the tabs); which userscripts are being used; etc.
@rene I appreciate the data-point. I should have said that first. I may have gotten a bit long-winded in my reply., due to how the SE API handles backoff being an ongoing/repeating frustration for me. While I understand why it's designed the way it is, I just find it frustrating that for a large segment of the SE API's expected use, it's not possible to comply with it.
I just wish they'd relax the restrictions for registered users, and especially moderators. I am always running into API or IP-related blocks. Very irritating.
I am volunteering my time to help improve your site. Why won't you help me?
@CodyGray Yeah, it would be nice if all of those were at least loosened a bit. My impression has been that some of the rate limit restrictions are loosened a bit for moderators, but definitely not the overall ones which result in hard blocks.
@CodyGray Given how long you've been a moderator, I'm not surprised that you wouldn't notice most of them. The ones I'm thinking of are relatively minor. I've only noticed them due to the close contrast between not being a moderator and being a moderator. It's not huge, but it at least feels like it's there. Most of it is lessening restrictions on often/rapidly it's possible to access SE-private endpoints.
[ SmokeDetector | MS ] Potentially bad ip for hostname in answer, potentially bad ns for domain in answer, potentially bad keyword in answer, blacklisted user (74): Sleeping in an inflatable boat by Tony Zhang on outdoors.SE
We have a blacklist of domains, those are automatically transformed to their DNS names, and then when content is scanned, we transform the domains to their DNS names and match them against the list?
Seems absurdly complicated.
All to... what? Catch the case where someone registers a new domain name redirecting to the same IP/NS?
@CodyGray certain spammers like to rotate their product names and domains rather fast to defy traditional domain blacklists. I don't suppose they have that many IP blocks.
@CodyGray we did not know anything about this particular domain name but its IP address and NS configuration are watched because of previous spam involving them
Matched by the following regexes: dominxt(?:[\W_]*+(?:muscle|building|review|buy|\d++|[\da-f]{5,}+)s?)* on line 2405 of bad_keywords.txt domin[\W_]*+xt(?:[\W_]*+(?:pill|order|official|\d++|[\da-f]{5,}+)s?)* on line 25984 of watched_keywords.txt
Yeah there's a possibility that that wasn't spam and that user was actively trying to be helpful with that response.
Have you ever accidentally spammed? I mean, I haven't, and I don't imagine I ever would, but SO is weird, so it's not outside of the realm of possibility.
