There was an issue opened in 2015 on GitHub that outlines the pros of this protocol, and even with the time spent to implement it I believe it’d still be an insanely useful service to offer, especially since it will reduce the amount of polling on channel states for the massive amount of bots (Discord, Twitch, etc).
I realize that there is the PubSub support via Websockets now, but this doesn’t work too well for services that need quite a few subscriptions, such as the aforementioned bots. If an application needed to subscribe to 500 channels, it’d take 10 websocket connections constantly open, also receiving events that it doesn’t need such as viewer counts. The overhead would be way less with pubsubhubbub, an open and established protocol specifically made for this type of notification.
I was considering an implementation using Websockets and a simple PubSubHubbub server written in Go, but the distributed nature it would require makes it an insanely hard project to stay within the limits of the PubSub API. Meanwhile, it seems like it should be pretty straightforward to support officially, with minimal changes from a developer standpoint (Disclaimer: I don’t know how the Twitch code works, but surely a hook could be added when someone goes live/offline to publish to a hub?)
I’m working with the team to talk through future of PubSub including upping the limits. It’s certainly something I want as part of the platform.
Curious about this point. You only get the data from the topics you subscribe to. For example, if you subscribe to the Bits topic, you only get Bits events and nothing about viewer counts. Viewer counts is its own topic.
The only documentation I could find mentioned using the topic “video-playback.channel”, which receives viewer counts, along with stream up/down events. Is there a different topic I’m missing that ONLY provides up/down events?
