RFC 0014 is not enough

API
1

Hello. I’m a developer for a discord bot. Lemme first start this by saying that EventSub is amazing, and it’s a step in the right direction, however, the 10k limit is not feasible for anything but products aimed directly at twitch. On Discord, all we want is to be notified when a streamer goes online, and this post addresses that point of view.

Currently, there are bots in millions of guilds. The largest one that has Twitch notifications is Mee6, which right now is on 16.4 million guilds. While Mee6 code or stats are not public, the reported delay for stream notifications to fire after a streamer is online is somewhere between 5-10m. We can make an educated guess, knowing that we can fetch 8000 streamers every minute with polling, that their streamer count is around 500-800k streamers. There are other bots that I know have broken 50k streamers, and others that have probably even higher numbers, and many other bots that are either close or will reach the 10k limit in the next few months.

The problem with all this is that most of the notifications we get are from servers that want to be notified about their favorite streamers, not something setup by the streamer. This prevents us from setting up an OAuth flow with twitch to subscribe without consuming limits.

We are left with three options:
1 - Use polling, which is bad for us and for twitch, and I worry that it will be disencouraged in the future
2 - Create multiple twitch accounts and break the TOS to keep using EventSub
3 - Drop the twitch notification feature

All 3 are far from ideal.

We don’t want to track data from users, we don’t want to do behaviour analysis on chat messages, we simply want to know when a streamer goes online. It’s an event that is not spammy, has no privacy concerns attached and is light on bandwidth (and quite frankly, if bandwidth is a concern, all you have to do is send back 8 bytes worth of user id and we will be more than happy. We can fetch the stream details, user details, etc using the api. We just need to know who came online, that’s all).

Now what could Twitch do here? Here are some suggestions, feel free to leave your opinion or other suggestions

1 - Decrease the stream.online cost to 0
2 - Introduce another event without all the metadata, with a cost of 0
3 - Introduce some kind of feed we can subscribe to outside of EventSub

Bottom line is, we want to be good neighbors, we want to play by twitchs rules. But at the end of the day the experience, both for us and for our users, is not great. Having to wait several minutes for a notification drives users away, and we don’t have any path forward when it comes to scaling our systems.

I want to open a discussion towards a solution, there is a huge overlap between Discord users and Twitch users, and bots help fill the gap between the services. It’s a widely used, very popular feature, and we want to make it better.

2

You have 800 requests per minute, and can burst to some extent beyond that. With 100 users per request a single token can lookup 80,000 streamers per minute, not 8,000.

That also assumes the default rate limit. Apps that have a legitimate need to have an increased rate limit often have higher rate limits. Add this to the fact that both the API, EventSub .online topic, and even Twitch’s own notifications themselves are cached, a 5 to 10 minute wait before a notification is received is normal and why a significant proportion of streamers use a holding screen at the start of their stream. Even if 3rd party bots could notify quicker, if Twitch still takes 5 to 10 minutes to send out notifications the streamers will wait for that.

Polling isn’t bad for Twitch at all, and still is the most common method of obtaining stream data, nor has there been any indication that it will ever be discouraged.

Don’t do that unless you want to get banned. If the rate limit isn’t sufficient it’s more than likely you’re doing something wrong or using it in a way it’s not intended for.

From the sounds of what you’re saying, because you want to track the online status of streams without those streamers connecting to your app, EventSub isn’t the product for you if you’re reaching 10k subs already.

For your situation, Polling is the intended solution. Even if the streamers that are being looked up haven’t connected to your app, you should get the owners of the Discord server who invited your bot in the first place to auth with your app, then you can use their User token. That way each individual user of your bot has their own individual rate limit, so each server using your bot can lookup 80,000 streamers per minute (even more with some smart caching server-side).

3

Thanks for the reply.

That was a typo, sorry about that, the values are still correct in the calculations though.

This adds friction for the user, no bot asks for this, why would the user do it? I also want to remind you that most bots are 1-person endeavours and they can barely keep up with Discord changes, let alone invest the time in a complex system like this. Also, why would it be fine to have more polling capacity but not more eventsub capacity?

I don’t understand how polling massive amounts of data is the intended solution for a simple use case like being notified when a streamer is online. EventSub is the perfect solution for this, neither us nor Twitch waste resources, notifications get sent fast, it’s scalable on both sides and very light on bandwidth.

I understand the need to limit API usage due to abuse and privacy concerns, and I do not want all the EventSub limits to be lifted. But let me illustrate how different interacting with Twitch is from a developers standpoint:

For Twitch, we have to rotate and visit every single streamer, multiple times an hour, wasting resources on streams that are offline, just to get a handful of streamers that came online per rotation. 80k stream fetchs per min, 800 requests per min, we have to keep this constantly throught the day.

On Reddit, We can query their API once every ~3 seconds (20req/m) and keep up with all new posts. We don’t waste time or resources on duplicate posts, we can query their feed with only new posts and their API even allows us to resume from where we left off in case of a problem.

On YouTube, their PubSubHubBub implementation is very similar to EventSub, and has no limits.

On Twitter, we can tail a feed with the usernames we care about and get new tweets from this feed.

These are all services at the scale of Twitch, and they all allow us to tap into their data easily. Why can’t Twitch make this easier for developers?

4

The user would do it to grant your app the functionality it needs to actually do what you want it to do.

OAuth is an industry standard, there are many examples and guides on how to implement it, it is not a complex system and is how many bots and services on Twitch operate and handle thousands of end users without issue.

It’s really not a massive amount of data. If you use User tokens then even if a streamer wants to look up 1,000 channels, that’s only 10 requests per minute per user. Even if for some reason a Discord server wanted announcements for 80,000 streamers, that’s still 800 requests per minute and perfectly fine with the rate limit.

You do not know how this scales internally at Twitch. The simple fact there are are rate limits that prevent you doing what you intend to do with EventSub, but do allow you to do without issue with User Tokens and polling the API is perhaps indicative that polling the API is the ideal option for your use case. It may not be ideal for you, but for Twitch it may be.

Again, this is solved by using User tokens. 800 requests for each and every user of your bot should be more than sufficient to get all the channels they need once per minute. If your app caches results then where multiple users are interested in the status of the same streamer this can further reduce the number of requests needing to be made.

The options to do what you’re doing at scale are already there, user tokens. It’s how most other apps scale, include those that make millions of requests on behalf of thousands of their users.

5

The problem isn’t really OAuth, its the complexity that comes with managing multiple user tokens, parititoning your data per server rather than globally (which for polling a single user token, or using eventsub, is desirable in order to de-dup streamers) and monitoring such a system that has a new host of problems (how do we handle the user revoking access, how do we handle the user being banned, how do we handle multiple bots using that same token and hitting ratelimits (is this a case? not sure)) while still being able to cache streamers across multiple user tokens. This is much more complex than an EventSub setup, or even a single-token polling system would be

That does nothing to reduce the overall requests needed and we would still be wasting time on offline streamers.

Fair point, taken. Let’s switch gears a little bit then, would it be possible for Twitch to provide a feed of users that recently came online through the API? In this way, you guys could keep the heavy caching and we would benefit from not having to visit offline streamers. There are a host of solutions here that could benefit both sides.

6

An unfair comparison since YouTube probably has more servers, money and sense that most people so doesn’t care about any scale problems that migth occur as they just throw money servers at it and doesn’t care about the cost.

It’s also limited to only providing one topic. (New Videos on a channel)

Not the many topics that Twitch offers.

Twitter has been changing how this work and the current API is pretty limited in comparison (in my opinion) to the older one (without paying for Twitter API access).

The current offering limits you heavily to the types of data you can get and the number of people you can get that from. So Twitter has the same issues.

7

Use the eventsub revoke topic to montor and auto delete relevant EventSubs that user is/was using

A revoke also likely means they are no longer wanting to use your service, so you can unsubscribe anyway.

You can also then delivery an “are you sure” warning to the discord chanenl to nudge if the revoke was unexpected (password reset for example). Then jsut rebuild the subs/topics if they log in again.

(This is what I do on my own Discord/Twitch notification service, on revoke I kill that users evnetsub topics I have)

And if they don’t within 30 days then you GDPR wipe their data.

Create a uservoice

https://twitch.uservoice.com/forums/310213-developers

Citing your needs and use case

8

Fair, but it does bring to light one point, if Twitch cares about keeping cost down, wouldn’t it be desirable to keep bandwidth down and implement EventSub in some greater capacity in order to decrease polling? I am not sure how your system works, but I assume that you guys still pay outbound traffic.

We are also only interested in a single topic, online streamers.

Fair, been so long I’ve looked at this, we specifically don’t offer Twitter notifs.

This is still subjected to the 10k limit, we have 30k unique guilds using twitch notifications now, this would not be feasible for us then.

9

Have each of those go through your OAuth flow, granting you a user token. That’ll take care of their entire needs. This will also allow your app to scale without any rate limit issues for whatever your growth is.

Have your app make a single subscription to the auth revoke topic. When any of those 30k users disconnect from your app you’ll know to stop polling for that servers channels and discard any of their user data.

10

The API is cheaper than having to raise services to send messages to requesting people

API can be cached easily
Outbound HTTP POST cannot, even more so if the receiving party errors and it has to be retried.

Most people replying on the forums are no Twitch Staff btw.
I for sure am not.

But EventSub has to handle/operate/work multiple topics.

YouTube pubsubhubbub only has to optimse for a single topic as they only offer a single topic.

No, it’s not.

The Revoke Topic is a single subscription costing 1 point.
And it notifies for all revokes on a given clientID.

You don’t create a revoke subscription for each user using your App.

Revoke only accepts a clientID as a condition not a user_id.

So for 30k guilds, using one user token per guild thats ONE REVOKE TOPIC TOTAL. As it’s for your ClientID not ClientID/userID Pair

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.