The UserVoice suggestions for a Polls API and a Channel Points Predictions API have been two of the most upvoted and discussed posts we’ve seen in the developer category. That’s one of the many reasons we are pleased to announce that Polls and Predictions are now available via the Twitch API and EventSub as a public beta.
By launching a public beta we are able to gather further feedback from the developer community to make sure the features operate as intended and meet your expectations. Please feel free to provide your feedback in the developer category of UserVoice as you begin using these endpoints. Although we do not expect major changes, there may be minor updates during this timeframe to address feedback that was received. For this reason, these endpoints are not intended to be used in a production environment until they have graduated from their beta version. For more information about the beta classification, see Product Lifecycle.
Is there any way to extend the prediction API to include all users that predicted instead of just the top 10?
I have an application that already has its predictions and is creating a top list out of it. I would love to support twitch predictions there, but I cannot produce top lists over several predictions with the current API.
What a shame pretty much all of this is useless because only the broadcaster can use it, not their mods.
This seems to be a recurring theme with the new API. Channel point redemptions can only be seen by the broadcaster as well.
From a security point of view it makes sense, mods shouldn’t be able to delegate permission to access things like this for someone elses channel to a 3rd party without the broadcasters permission. Should the app misuse the API endpoints, the broadcaster themselves would have no possibility to revoke that permission as it would be the mod who has the connection to the 3rd party app, and the broadcaster may not know which mod is responsible.
There’s nothing stopping any app developer to create a permissions system on your side to allows mods to interact with these endpoints, you just need the broadcaster to first grant your app access to use these features on their channel.
All the mods I work with, use a control panel (or slack or other tool)
And the mods trigger a prediction from slack.
Then I use the broadcasters token to call the API with.
The broadcaster delegated control to my ClientID then I delegate access to that via my own methods.
As “professional mods” wouldn’t just use this tool but others tools and/or dashboard, and the other tools would include other information relevant to the channel/moderation for that channel, including but not limited to, accessing parts of the channel that are locked to the broadcasters Access Token, (such as the stream title updates for example)
But stream title updates can be done by editors over the API currently…
Restricting predictions/polls/redemptions to the broadcaster is certainly better than nothing but it’s a step backwards in terms of access for other use cases. I shouldn’t have to have separate dashboards open.
What dashboard? Chatty users login with their own credentials. It’s not a web portal, it’s an app running on a user’s desktop. There’s no opportunity for the broadcaster to authenticate. They give users editor/mod access on their channels so they have these kinds of permissions.
We are not talking about chatty we are talking about “professional modding” where I proposed the “professional mods” would have a third party dashboard, to control delegated access to various things, including but not limited to channel title updates (without giving out the editor role), or controlling predictions and polls, or access any central repository of data between all the “professional mods” for that channel
Some channels have dozens of moderators, especially larger channels with more organised moderation policies/teams (although these channels are likely to already have dedicated moderator tools/dashboards like those which Barry has described). It would be bad security practice, and potentially a bad user experience for the viewers of the channel, if a mod could give any app permission to use these API endpoints.
With the current way the API is designed the broadcaster can grant the apps that they specifically want to have access, and then those apps may or may not decide which other users have access. Some broadcasters may want all mods to have access, or no access, or just specific users (regardless of if they are a mod or not), that’s all possible right now, and that granularity of access would be lost if any mod could grant access to any app, unbeknownst to the broadcaster.
If you’re insistent on using Chatty and refusing to use any other service then you’re obviously going to be limited by what Chatty offer. Chatty is primarily a chat client, and is not designed to be a feature rich moderation tool.
If you are willing use other 3rd party tools but still wish your mods to interact through Chatty itself then you could create a bot that the broadcaster grants permission to, and then the mods interact with that bot through Chatty which will perform the API requests. Or simply use a dashboard style approach that many channels/apps already do, like Barry has suggested.
I am aware. I’m a mod/senior mod/head mod for a number of them. Chatty is the most-used dedicated moderator tool that is used by human mods for channels of that size. Moderating using native chat or the official mod view page is too slow/inefficient for channels of that size. This means to run predictions/polls we have to have a page open specifically for that, which is not efficient at all. It should be possible for mods to control them over the API and Twitch should have a proper permissions structure within the broadcaster’s roles dashboard to allow mods to do that if there is a genuine concern about abuse… which I understand, I get it… some idiots out there will abuse it or get their accounts compromised… but that’s not a reason to limit the access for everyone. Improve the logging to show which mod performed the action and setup a proper permissions structure. (I know it’s off-topic but a head mod role is long overdue!)
It’s not a question of what Chatty offers, it’s a question of what Twitch offers in their API.
I don’t agree with this statement.
Why? That’s just not efficient. Why not open the API up and address the concerns of abuse by implementing (among other possible things) a proper permissions structure?
Simple answer? it’s entirely already possible for broadcasters to grant permission for an app to use these endpoints, and let other users act on the channels behalf to use them. If you’re not willing or able to because you’re refusing to use anything other than Chatty, you should submit a feature request on Uservoice https://twitch.uservoice.com/forums/310213-developers or contact Chatty and ask them to implement the functionality you need in their software.
If you wish to complain about efficiency, you’re the one tying your own hands by limiting yourself to Chatty, and not simply using the API as it already allows for. If you continue to use nothing but Chatty then you’ll have to wait on Chatty to implement this functionality in some way, or for Twitch to change their security policy.
That doesn’t sound convincing to me. The broadcaster should be able to know which mod is responsible, because the tool would perform actions on the mod’s behalf (with the mod’s token), so it should be possible on Twitch’s side to both log which mod performs an action and even how they perform it (which client id the token is from), so they could immediately be unmodded. If mods regularly choose malicious or unreliable tools causing havoc (and in the case of IRC-based tools for modding that could have happend already) or the mods themselves have gone rogue, then obviously they need to be unmodded because they can’t be trusted anyway. And these logs on Twitch’s side need to exist anyway, because even a mod using the official website could go rogue and cause major issues.
It might be possible for a clientside moderation tool to build a web app that allows a broadcaster to grant access, then allow mods using the third-party client to use that web app’s API. Building a web app makes sense when you’re already building tools for the web, like a dashboard for a chatbot or donation system, because you need to maintain that infrastructure and handle sensitive data anyway, but for an otherwise clientside application that doesn’t require this except to work around the Twitch API’s intentional limitation, it just adds unnecessary risks (because as we see time and time again, mistakes happen, security issues happen). I’d rather not add more complexity and more possible points of failure than necessary, but instead put time into improving the experience for my (and thus Twitch’s) users.
And if we go that route of building an intermediary API that forwards API requests from mods on the broadcaster’s behalf, then all those actions would appear to be performed on the broadcaster’s behalf. So even if it shows who performs an action on Twitch directly, it wouldn’t show the mod’s name. The broadcaster would have to look up who performed the action on the dashboard of the third-party tool (assuming logs like that exists there).
To me it makes a lot more sense from a security and usability standpoint to not add more complexity to a system, as well as for the mod that actually uses the tool to appear to the Twitch API as the one responsible for an action. Allowing only certain users access to those API endpoints (like editors) and logging mod actions (part of which already exists) seems like basic and important functionality that makes more sense for Twitch to offer themselves in a consistent interface, rather than having to go through multiple different third-party dashboards for each tool a mod prefers to use.
But that’s not currently how things work. There is no way for a broadcaster to see what apps someone else has connected, or permissions granted. So until Twitch implement something along those lines it IS a security issue letting mods delegate permissions to a channel that they mod for, without the broadcasters consent. If you wish to request this feature, post it on Uservoice https://twitch.uservoice.com/
Then use Twitch’s first party mod dashboard and tooling for creating polls/predictions. As has previously been discussed if the current implementation doesn’t meet your needs then it’s best put on Uservoice so that Twitch can see what your use case is and what demand there is by developers for that. And who knows, if people had voted for this use case on Uservoice prior to these endpoints being released maybe Twitch would have considered such functionality at launch.
Most importantly, should mistakes happen the broadcaster (who is the account that’s liable here) can instantly disconnect the app. Doesn’t matter which mod used the app (or if the app acted on it’s own without intervention from a mod), the broadcaster themselves has the capability to kill the connection.
Yes, it would be nice if mods could use the permissions they have more readily in 3rd party tools (or better yet, if Twitch themselves had better tooling), but as it CURRENTLY STANDS it is not something that’s secure, and can put a channel at risk. Yes there are things Twitch can do to make it a viable option, but those are separate features from these specific endpoints and should be requested on Uservoice, and ideally discussed somewhere more appropriate than this announcement thread.
I still don’t really see it as much of a security issue in the first place. If a mod authorizes an app that then happens to break and do bad things, then the broadcaster can unmod the mod responsible for it (at least temporarily until the mod can act). Maybe I also don’t really see it as much of an issue because the kinds of tools I’m thinking of don’t do anything automated, it’s still the mod making the decisions.
But even that aside, for me it all comes down to what a mod does: If they do their job well, then all is fine. If they don’t do their job well, either through the website or through a third-party tool (whether on purpose or accidentally because their tool breaks), then the broadcaster will need take action either way (and actions need to be logged at least by mod name in any case to avoid rogue mods). Showing which tool performed an action or banning client ids were just additional ideas that could be useful in some cases, but I don’t think they’re really necessary in the first place.
But I don’t think this discussion is really progressing anymore, we appear to just have different opinions on this. Thank you for your thoughts.
How do you determine which mod is responsible for it? Some channels have dozens of mods, not all of them are going to be online at the same time, so if there’s an issue with an app the broadcaster may not even be able to find out which mod authorized an the app at fault (or even if it is an app, and not just a compromised mod account). It would require the broadcaster unmodding everyone to kill all permissions those mods may have passed on to 3rd parties, which is not an ideal workflow during a live event.
You’re still giving the app a token to access the API. While the design of the app may be to only do something when a moderator presses a button, there’s nothing technically stopping apps from doing whatever they like with a token after you’ve given them it, even while the mod isn’t there. And there are also apps that don’t require user interaction at all after the initial OAuth process.
