I am concerned by the claim that EventSub is at feature parity with PubSub. It has certainly come a long way, and I am quite pleased by the innovations that have come along with it (i.e. conduits). However, the standard web client still uses PubSub. Just like the separation of the gql API that the web client uses from the helix API we get to use, this separation is being created again. I’d be prepared to say that as long as this separation exists, EventSub will never achieve parity with PubSub.
Some notable ways this is already the case (yes yes undocumented blah blah, I think everyone knew that undocumented pubsub topics were being used a ton):
video-playback.<channel_name> - replaced by 3 (viewcount doesn’t exist which is understandable) separate topics, the most important of which suffers from an up to 5 minute delay due to caching, which was not the case in pubsub.
All events that are delivered to standard users but require additional scopes for bots / apps.
It is completely understandable that some of the data that is now protected behind a broadcaster scope is more than we had before. However, if this is the reason it’s protected by a scope, at least have minimal data versions that only contain the truly public data that don’t require getting scopes from the broadcaster (stream.online and stream.offline already follow this pattern for example). channel.poll.begin also has no information that isn’t already available (the progress and end versions do though), but is still protected behind a scope.
A sample use case: predictions can sometimes last a while, and people sometimes leave before the result occurs. It is completely reasonable for someone to send out a notification when the prediction result is in, say in a fan discord or something like that. Why does that user being a bot make any difference?
It has with DOCUMENTED topics that are documented for third parties to use.
Your answered your own question here.
In that we have feature parity with what is documented for use (other than bits badge unlocks but I don’t think ANYONE uses that topic).
Anything that is undocumented could be removed or changed at any time and we have no idea if first party is even using those topic(s) and they just got left behind from lack of tidy up.
Bits notification is covered by chat notification as far as I can tell (there’s a lot of stuff that got moved around heavily, which requires major changes to handle on our end, but that was to be expected).
My understanding of the documentation of pubsub topics was that it was extremely incomplete due to lack of effort put into the documentation for it (probably because they want to push us towards eventsub), not because we weren’t actually expected to use those topics. If the docs were able to be PR’d to somehow (approved by twitch devs) I do think we’d actually have seen most of those topics documented.
we have no idea if first party is even using those topic(s) and they just got left behind from lack of tidy up.
Yes we do, because it’s the only way to get this information currently. The client does not poll a gql endpoint, irc does not deliver this information, and the client does not connect to eventsub or any other client-only service. The fact is they are dogfooding pubsub, and they’re taking that away from us. As a reminder, we’re talking about information that literally has to be delivered to every user in chat for the feature to work.
Oh, and yes I’ve done the uservoice thing, seems like we don’t have much of a voice at all. Someone asked for these public information realtime updates to be accessible on May 17 2021 (I voted on it around then too) and it has not seen a response since a few hours after it was posted.
So you want just cheers no noise then channel.cheer
And yes switching from PubSub to EventSub will require major changes regardless of the difference in payload formatting.
No thats incorrect. PubSub | Twitch Developers list the topics we are able to use as third parties and the scopes required.
Sure the documentation of these topics may be considered messy and incomplete but any topic not listed here is not for third parties to use.
No the PR would be denied as “topic not for third party usage”
Your understanding is flawed, (as to incomplete causing topics to be missing) not sure where you got this idea from to be honest, since pubsub has generally been this way since before WebSub (the predecesscor to EventSub) existed. Very few topics and documentaiton of it was interesting
Get the relevant authencation/scopes from the channels you need the data of then?
As otherwise why you collecting data you essentially don’t have permission for?
IE whats the use case to collect data you don’t have permission for?
I gave a use case already. If I as a developer want to personally use this data, I’ll go get the scopes from the 1 or 2 channels I want it for yes.
If a random user wants a notification (off-platform) when a stream goes online, they don’t have to obtain permission from the broadcaster, that would be absurd. What’s so different about a prediction / poll result? Or heck even a channel point redemption. Channel point redemptions are a little more likely to want to go through the broadcaster though (ie “Come join the stream, X was just redeemed! You don’t want to miss it”, X being some big goal).
I think you are still misunderstanding the permissions here. Every user in chat has permission to use this data, and must for the feature to work. Why do we not have “permission” as soon as that user is a bot?
Becuase what the first party client does and has access to and what third party clients are allowed to do and have access to is different, with different permission structures and allowances. But thats just my observation as another third party developer.
I don’t know, it’s just how it is on every service I’ve every integrated/work with, theres different things allowed on differnt interfaces/between first party/third party/other parties.
I wouldn’t call it use as it’s the first party client thats consuming the data, the actual user isn’t.
But I guess here we are just gonna have do agree to disagree otherwise we’ll just keep going around in circles. Which is generally what seems to happen on things like this.
That’s why I was hoping for a quick “we’re deciding to differentiate bots from users” or something from staff instead of this cyclical argument.
I guess I’m too used to working with Discord’s API that has very few of these differentiations on the permissions standpoint. To be fair though, Discord bots (until a few months ago) had to be added by server owners / moderators. I wonder if there is a world where there are moderator scopes for these subscriptions as a middle ground so that mods can authorize it instead of just broadcasters (who often don’t like dealing / know how to deal with bots).