Thanks for requesting feedback on the subscription limits - I’d like to reiterate my notes from the closed beta.
In short, the current limits on EventSockets renders it unusable for my application. To remedy this, moderator user tokens need to allow for cost=0 subscriptions like broadcaster tokens. Currently, the max_total_cost of 10 is too prohibitive for my primary use case, but this would be bypassed with the mod token fix. Lastly, 300 (100 subscriptions per socket times 3 sockets) total subscriptions is not sufficient for power users of my application.
My application relies on PubSub, an interface that Twitch has announced they will deprecate in the future. Twitch has promised that EventSub over WebSockets will allow for a smooth migration from PubSub, but this is patently impossible with the current subscription limits. In particular, I depend on the chat_moderator_actions pubsub topic for my third-party chat client, which is often used to track 50-100 channels concurrently for any given “power mod.” As a result, EventSockets must replicate access to the following data for moderator tokens to smoothly migrate chat_moderator_actions:
- Ban/timeout:
channel.banexists in eventsub, but is not available for mod tokens - Unban/untimeout:
channel.unbanexists in eventsub but is not available for mod token - Clear/delete message: does not exist in eventsub (and IRC does not detail which mod performed the action)
- Roomstate (slow(off), followers(off), r9k(off), emoteonly(off), subscribers(off)): does not exist in eventsub (and IRC does not detail which mod performed the action)
- VIP added: not in eventsub, but not critical for my use case
- VIP removed: not in eventsub, but not critical for my use case
- Moderator added:
channel.moderator.addeventsub, but is not available for mod tokens - Moderator removed:
channel.moderator.removeeventsub, but is not available for mod tokens - Raid started:
channel.raideventsub, but is cost=1 even for moderator token - Unraid: does not exist in eventsub
- Add permitted term: does not exist in eventsub
- Delete permitted term: does not exist in eventsub
- Add blocked term: does not exist in eventsub
- Delete blocked term: does not exist in eventsub
- Modified automod properties: does not exist in eventsub
- Approve unban request: eventsub does not include the moderator message in
channel.unban - Deny unban request: does not exist in eventsub
In addition, my application would use the following eventsub topics that already exist (or have been promised):
channel.shield_mode.beginchannel.shield_mode.end-
channel.follow(v2) channel.shoutout.createchannel.shoutout.receive- Low Trust User Treatment Update
- Low Trust User New Message
- AutoMod Caught Message
In total, my application needs over 20 eventsub subscriptions per channel. If we assume max_total_cost is not binding (with the requested mod token adjustments), this implies we’d only be able to join a measly 15 channels (300 divided by 20). This is a far cry from typical channel counts for power users of our application (e.g., I’m modded in 50+ channels).
Thus, Twitch must decide whether to offer a genuine migration path from PubSub or stop pretending that EventSockets provides such a migration. With the latter option, many third-party moderation tools will suffer or shutdown.
To clarify, I am only asking for elevated permissions for moderator tokens within the WebSocket interface - these changes do not necessarily need to carry over to webhooks. In anticipation of comments from the usual suspects of excessively defending Twitch’s decisions, no, using webhooks and creating my own pubsub system is not viable for these use cases (and departs from the promise of a smooth transition from pubsub to eventsockets). Also, the privacy counterargument doesn’t hold water given broadcasters are already implicitly consenting to chat_moderator_actions use by whatever third-party applications their moderators utilize.