Extend the Videos API via a "metadata" endpoint, that provides additional data about the video.

Including but not limited to

• Category changes during the video
• Offsets are relative to the source video that the video is from. So for a highlight it would report the video it was cut from and include where in the origin file the highlight is cut from.

For Example: https://api.twitch.tv/helix/videos/metadata?id=1234
Metadata would support up to 100 (or 50) id's at once like Get Videos

Returns examples

A video of type archive
{
"data": [
{
"id": "1234",
"duration": 18000,
"chapters": [
{
"offset": 0,
"gameid": "200"
},
{
"offset": 500,
"gameid": "220"
}
],
parent: null
}
]
}

A video of type highlight
{
"data": [
{
"id": "1235",
"duration": 600,
"chapters": [
{
"offset": 300,
"game_id": "200"
}
],
"parent": {
"offset": 200,
"id": 4321
}
}
]
}

Use cases:

• if we present a highlight on a third party website, when the video is complete, we can present a easy way to go to the next Highlight in the series (where highlights are cut sequentially) or easily link to the original stream archive for continued watching.

This is an expansion of https://twitch.uservoice.com/forums/310213-developers/suggestions/38155990-return-tags-and-game-id-in-get-videos-in-helix

Hey. I know that people are requesting API for Channel Points. But I came up with better and easier idea.

When streamer creates new reward in dashboard, there should be option to "run a link" in background after reward is redeemed. This type of button will trigger bot with GET-request and bot will run specific action.

Why I think this approach is better than API:
1. No API on Twitch side, obviosly.
2. Bots won't be abble to control Channel Points directly.
3. This will work with any bot who will support this kind of triggers.
4. Easier to use and understand for regular users. Bots developers could design this as "to run this action paste this link in your reward". This sounds pretty easy.
5. Gonna be pretty easy to exclude failed requests for Twitch. You just check if requested link returned: {response: success} or something like that. If it returned something like {error: "Requested video have not enough views."} then you just show this error to viewer and do not take his Channel Points.

Possabilities here are endless. Viewers will be able to request songs with Channel Points, run some sounds and animations on stream, play mini-games, change color of lights in streamer's room, etc.

Currently, it is easy to tell if a user that sent a message in a streamer’s channel is a subscriber, VIP, or moderator of that channel. However, there is no way to tell if that user is a follower of the channel.

With the rise of hate raids and malicious messages, I want to ensure that if a streamer is using a chat box overlay, that they have the option to only let messages from followers appear. Malicious users usually don’t follow the channel, and so this will prevent their messages from appearing on stream.

I do understand that this would be a temporary measure at best, because eventually they might catch on (if they even notice) and start following before sending their message. It is still worth doing. It will help.

I also understand that follower-only mode exists. But that is detrimental to gaining new chatters, and it’s easy enough for malicious users to follow once they realize that the channel is on follower-only mode and then send their message. With a follow tag, malicious users may not even realize that their message didn’t show up in the overlay, since they’re usually there to listen to the streamer’s reaction instead. This can ensure that most malicious messages will not show up in clips or VODs.

Imagine the following attack for the OAuth 2.0 authorization flow:

1. Attacker steals the authorization code from the redirect URI.
2. Attacker forces his instance of the client to redeem the victim's authorization code.
3. If the attacker's instance of the client is faster than the victim's instance of the client in redeeming the authorization code, the attacker will get a valid login session within his instance of the client, but for the victim's account.

This attack should especially get attention in the context of Twitch and live streaming, since many streamers are definitely not aware of this vulnerability: If people are logging in with Twitch on 3rd party sites while live streaming, an attacker that has automated this attacking process (e.g. by capturing the stream) can easily grab the authorization code from the visible browser address bar during the streamer's login attempt, except ...

... the OAuth 2.0 PKCE extension is used by the client, which prevents the attack in the following way:

1. A hashed secret (using a cryptographic hash function) is send using the nonce parameter of the initial authorization request (leading to the Twitch login page).
2. Later, the authorization server (that is used to redeem authorization codes) is sending back the same nonce together with the access token.

The back end implementation (that also securely stores the client secret and makes the call to this authorization server) can now verify whether the nonce sent back from the authorization server is indeed the hashed value of the specific secret.
An attacker that does not know the secret should now longer be able to force the back end to authorize him with the victim's permissions.
Of course, the secret is bound to the authentication session and only visible to an attacker in its hashed form (the nonce) within the initial authentication request.

A few months ago someone suggested to support the OAuth 2.0 authroization flow PKCE extension. [1]
I don't know if the nonce usage above is exactly the same as PKCE, but it at least prevents attack scenarios like the one that I just described.

Currently, the documentation does not mention this nonce parameter being available for the OAuth 2.0 authorization flow. [2] It should be added with a short description, similar to the other optional parameters like state or force_verify to make people aware of it.

This user voice is a clone of this thread in the forum. [3]

[1] https://discuss.dev.twitch.tv/t/pkce-extension-for-oauth-authorization-code-flow/19575
[2] https://dev.twitch.tv/docs/authentication/getting-tokens-oauth#oauth-authorization-code-flow
[3] https://discuss.dev.twitch.tv/t/please-document-optional-oauth-2-0-authorization-flow-parameter-nonce/23357

In the new badge-related endpoints, badge objects in returned sets contain only their IDs and URLs, which compared to the only existing alternative (undocumented badges.twitch.tv endpoint announced in twitchdev forums[1]) isn't enough for things like custom chat clients that are very popular among many Twitch users.
Ever since that undocumented endpoint came to existence, we've been using it in our chat client and would at least need "description" and "title" properties that are present in badges.twitch.tv to display information about badges properly and replicate webchat's behavior. I believe both APIs use the same internal data (at least for Global Badges) and if that's possible please include more information about badges in the Helix endpoint if possible, thanks!

[1] https://discuss.dev.twitch.tv/t/beta-badge-api/6388

Summary:
A cheer message can be multiple cheers in a single payload. Providing the individual cheer components in an int array would provide data that is not currently there. Emote placement, while also desired, would be still more work than should be necessary at first glance to determine the bits used.

Example: **
BarryCarlyon PogChamp100 PogChamp100 Party100 Wow Soaryn is Frustrated!
This would result in **"bits": 300; however this is incomplete and would be desired to also have something like "bits_used": [100,100,100]

Reasoning:
While again, emote placement would help, determining the bits used from it would be extra and redundant computational work that was already processed on Twitch's side. On the same note, determining in the emote where the cheer values actually start vs the emote regex may cause issues for this particular use case, unless on the client side a running emote store was kept.

Related Event(s):
- channel.cheer