I wholeheartedly oppose this not just for the systems I work on, but for the overwhelming pressure this will put on EVERY app. The rate limit alone is abhorrent, never mind the 3 short weeks to prepare what, for me, amounts to 20 separate microservices. Twitch keeps holding Developer Day after Developer Day, BEGGING people to develop apps which integrate with the Twitch APIs, and this will kill almost all of them.
Remember when the initial intent was to have feature parity in Helix and remove v5 in late 2018? Pepperidge Farm remembers.
Snarky comment aside, this looks and feels like you’re trying to prematurely strong arm everyone over to Helix. Even if the majority of people are unaffected by this move, people will be affected by this. I’m curious if Helix will get feature party at the rate endpoints are being added/updated.
I understand that the words “we’ll have something soon” isn’t entirely comforting at the moment, but we will have more information about updated Helix endpoints. It’ll be a new announcement post and I’ll link it back in this one.
As a long-time user of various Twitch APIs, this is yet another move that makes it feel like Twitch does not respect what I am doing. I disagree with this decision and am frustrated by it. Having to re-invent legacy infrastructure every year or two is such an aggravating experience, and it makes me want to make less things for Twitch overall.
This is a good point to call out. Moderation tools can benefit from knowing created_at and that is a valid argument for it being included in Helix. I would ask that you submit this feedback for the team and mention it’s importance for moderation on User Voice as @Dist mentioned above.
While I understand the need to restrict nefarious activity on your API, there is no real migration path for existing devs to Helix. Helix remains a fairly barebones “replacement” for the functionality v5 provided. Development of it has been slow to almost non-existent over the past year, and many developers just keep waiting to switch because of this. Scopes cannot be “upgraded” to Helix without re-authorizing all users, and much of the niche functionality (which Moocat alluded to above) my bot also uses is missing in Helix too.
It is fairly disappointing to see this kind of stark action coming from Twitch. Before you bring up walls around the old infrastructure we all still very much rely on, it would be great if there was a solid feature/migration timeline for Helix in place first. The deprecation timeline of less than a month for these added (imo harsh) rate limits is also quite concerning.
So the solution now is to hope that staff blesses you with some kind of special access if you’re enough of a big guy? Also, the user voice feedback on created_at was already submitted last year. I’m guessing no one looked at it, despite being one of the top ““ideas””. The top ““idea”” isn’t even commented by any kind staff member
@jbulava I used to work with Justin Im as my contact in Twitch, since his departure I have been unable to connect with anyone at Twitch to address concerns, promised that people would reach out, and it never happened. We do a lot of deep integrations with Twitch, and have driven a lot of revenue to Twitch, could you DM me so we can discuss this
You must be kidding me.
How are we supposed to combat those chat-spambots if you cut down the only way to get usable user information like the account age?
If Twitch is unable to get this mess sorted out, then at least give us the tools to do it on our own!
How am i supposed to check the accounts of new followers if they create new ones twice as fast as you let me check them?
I guess we just have to disable the chat now in the future if the bots target a channel as there is no way to fix it and Twitch is unable to do so.
This is a good callout as mentioned above. Developers of moderation tools need a way to check for new accounts. Doing this specifically with the created_at field has been added to UserVoice at the link below. I’ll add a note internally that the end goal is to test for new accounts in case this cannot be achieved via adding the field.
Confirming a note for this use case was added to the feedback.
Just a note, the end goal for created_at is not only to see if account is new or not (and even in this use case, a “new account” is open to interpretation), there are even situations where users are inspected for specific created_at dates in range of a couple of minutes or seconds
In my case, i had to deal with a total of about 40k bots on one channel.
For a good amount of them, the creation date of the accounts was in one of a few ranges.
However, the accounts were up to multiple weeks old before they followed and spammed a specific channel.
So yes, a “new-account” flag on the API doesn’t help much, we need the date