Rate limiting... limits

I wonder how this will impact ESGST and SGTools, 2 very popular tools for this site.

Rather, according to the official staff interpretation across maybe the past 4 or 5 years now.
I've clarified the scope of the official interpretation of the rule in a comment a bit above, if you're interested.

You know, in the civil law (at least here in Italy) we can distinguish three different types of interpretation based on the subject that is doing the aforementioned interpretation (and I apologize but I'm gonna translate the naming from italian, so the names used in the english can differ a bit)

• Judicial interpretation - the interpretation made by the judge when emitting the sentence and in this interpretation the judge (the staff and cg here) has to interpret what was the purpose of the legislator when he wrote that law.
• Legal interpretation - the interpretation made by the legislator (cg only) to clarify the content of the law if there are doubts and/or different judicial interpretation. In this case the legislator could make a new law to solve the issue. This already happened fairly recently here on sg when after years of having applied the rules in the same way a member of the staff (judge) decided to interpret the rules in another way and cg (legislator) had to step in by rewriting the rules and doing that he clarified what it meant what he wrote in the previous version. I'm talking about the case where links external to sg were being posted in some group recruitment thread.
• Doctrinal interpretation - the interpretation made by the studios of law, in this case since we users are arguing and studying in this thread the rules of the site I'm gonna regroup us here.

You are stating that this is the official interpretation (judicial interpretation) made by the staff yet I don't see any proof of that, I've never seen any judicial interpretation being made about the scenario we are talking about.
I've never seen any official statement, the bots and scripts that according are still running, they are well know and also used by many people. (Analog interpretation: since the controversy is not regulamentated by a specific rule and what you are arguing is the rule that should be used has never been enforced against said bots/scripts I'm searching for similar cases to analyze to find out the will of the legislator who made the law) .

cg himself is trying to help those bot/script makers. Proof of that is this topic itself and the fact that in the other topic he is replying to people using and or making bots/scripts and he is trying to help them, not banning them for rule breaking. If I use the logical interpretation and try to use logic to figure out the intention of the legislator (the admin/owner of the site in our case) I would have to assume that the purpose of that rule is not to ban the use of all bots, not to ban bots that post useful, not spamming, not harmful, content, but rather to ban only the ones that would post contents with malicious intents that go against the interest of the site itself. Afterall scripts and bot like esgst, sgtools, the group managing one (which is basically what archibot does but specific for archi's group needs, and in the past used in a more basic form by at least 1 other group), archibot and others are made with the intention of improve the user experience, and if the user experience improves the site will benefit of it as well.

Not to mention that archibot posting useful info in the group giveaways (think about the bundle charts that you can find in the deals section of the forum with additional info regarding the impact of the giveaway in the group and for the user in case of win) got cg (the legislator) approval/permission in the past and has little impact on the site load. We are talking about 1 post per giveaway + 1 edit when the gib is finished, occasionally there may be an additional edit or two but that’s all. But that is a bonus feature, an inexpensive one, not the real the issue here as there are other necessary functions for that and other bots and scripts that are limited/blocked by those limits.

And speaking of load, a lot of issues could be resolve by an API.

Now regardless of the interpretation of that ToS, the ToS in question only refers to machine or randomly generated posts, as stated in my reply directed to tzaar.

So according to your interpretation bots are allowed as long as they don't post anything (and enter giveaways as stated in the guidelines of course).

Now I’m sorry but I’m getting tired and need a break from writing and since the posting part isn’t the main issue as stated above and in my previous comment and since I've already wrote way more than what I wanted to after my last comment (which was 0 btw) I’ll leave the second part of my comment for later or tomorrow morning (cet time).

It's very simple to add an exclusion for SGTools (in site code).
ESGST works similarly to users so this is a problem.
We need the API.

It's very simple to add an exclusion for SGTools (in site code).

Question then will be if that doesn't create an exploit for other scripts to use to get the same exclusion.

An API for bots and scripts would be the best solution, but that will require a lot of work from cg

SGTools is bit different. Just need a system with multiple IPs to use. As it really doesn't need to have logged in user.

User scripts on other hand require a session as there needs to be an user...

knsys said that sgtools isn't affected: https://www.steamgifts.com/go/comment/PMpIns7

https://www.steamgifts.com/go/comment/wU6T92j
It seems to be a difficult situation now, about two weeks later.

Wouldn't SGtools be excluded from communication restrictions?
It's a little worrisome story.( ;'Θ`)Umm..

Hi,
i understand, partly, why you limit the traffic at your site and of course should the script devs upgrade their stuff to a site friendly use.

But is it possible to give SGTools a special right/access or whatever is needed to go around that limitation or limit it for that site in a other way ?

I am not a programmer and i don't know much about the technical details but i can say as normal user that it is extreme annoying that i can't check the winners of my GA's and the applicants for my group if they broke the rules with activating wins/multi wins.

I would, of course, still prefer to make that checks DIRECT at steamgifts but because you don't offer such a option you should not limit such a very important site like SGTools, that do, partly, the job your site should do, to a level where it is unuseable.

As long as i don't be able to check winners i will not make GA's
That's a very clear thing for me.
Plus i bet that i am not the only one that will not create GA's as long as it is impossible to check for rulebreakes of winners.

Have a good day.

I also always use SGTools to check my winners and it would be a real downside if we can't keep SGTools not activated check working because of the rate limits.

Edit: Some background info because it might not be clear from Masafor's post alone: SGTools isn't working for a few days now because of the rate limiting system https://www.steamgifts.com/go/comment/KvFttO6 and knsys said that it's not easy for him to do anything about that and SGTools is only in maintenance mode https://www.steamgifts.com/go/comment/20RUc9O.

I, too, check all my winners.
What makes this situation even more unwieldy is that support staff (in person of Khalaq) is advocating the use of SGTools in this https://www.steamgifts.com/discussion/GeDfy/failure-to-activate-and-regifting thread. So we are rightfully encouraged to check our winners and use SGTools for it, BUT are now severly hampered in doing so.

I'll also won't make any GAs as long as this situation holds.

To be fair you can still check the winners, it is just a much longer, and manual, process.

SGTools does not bother to archive data and as such requests the same information over and over again each time someone checks, at least from the post I saw saying they don't archive anything. For example, if everyone you won a giveaway from did a check for unactivated wins that would be about 28219 page requests instead of 1194, making the website work about 23 times harder. Now factor in duplicate win checks doubling the strain when they could have been done at the same time. Also figure each time you check a SGTools gated giveaway, it has to check the same information over and over again. Instead of looking at your last won page and seeing nothing has changed, or updating the few it didn't record previously, it looks through all 47 pages.

Don't get me wrong, this particular problem could, and should, be solved by SteamGifts keeping check of everyone. But this highlights one of the aspects of why cg imposed these limits.

Edit: Wow, already had an answer regarding cached information ages ago and forgot about it. Was reading a different post about archives and stored information and thought it applied mistakenly

It's more of a stop-gap measure than a proper alternative at this point, but if you're willing to manually compile a list of users' won giveaways, you can then use this site to cut down on the most bothersome part, the library checking.

..not that it'd actually save much time with users with hundreds -or even thousands- of wins, but better than nothing, I guess?
It might be possible to get a script to scrape the list, but that'd also risk incurring into the rate limits the same way SGTools does.

SGTools uses two types of caches, there used to be more but for now let's talk about the ones that are in place today.

First, the big one, that stores for every user all their sent and won giveaways with all the relevant information and flags. This cache allows SGTools to do all the operations with bare minimal queries to Steamgifts because in most cases it just have to check the first page of sent/won giveaways page to update it and then it's ready to go.
This is the cache that got nuked some days ago and it's causing the site to reach rate limit as it tries to build the cache back when a query is done about a user that still doesn't have cached values.

Second cache is related only to the giveaway section of the site and stores for every user cached values for all the variables exposed in custom and basic rules. This cache is invalidated every 24h and it's the one that allows a user to enter protected giveaways really fast starting from the second one in this 24h period.

bump for sgtools problem visibility

Bump, please fix sgtools (and dark mode would be awesome too)