If I have an oAuth that represents a User, where the User is either

• the broadcaster the clip is of
• an editor of the channel that the clip is of
• the user is the owner of the clip

And I make a request for a Clip as documented: https://dev.twitch.tv/docs/api/reference#get-clips

(but with the bearer naturally)

The JSON Response should include the direct link to the MP4 or an ability to download the Clip.

This is off the back of the removal/deprecation of some undocumented API's that I was using to get the MP4 URL for automated download for creation of clip reels and similar.

With the removal of the Follow Create endpoint.

A "non moderation bot" can no longer be automatically added to a channel.
The owner of the bot would have to "login" to the account and manually follow the channel(s) the bot joins.

A "non moderation" bot doesn't run moderation commands, so giving it "mod" wouldn't make sense. (Which would bypass the follow requirement)

Please provide a way to "authorise adding a bot to a channel" that will auto follow the bot to the channel. For this purpose

This could be similar to how Discord does bots, where to add a bot to a server, you need an oAuth flow, and then on compleition of that flow lets the bot in the server.

So in this example, I login as barrycarlyon I grant the bot access to my channel using scope "bot:allow" this auto follows that bot to my channel.

So the "follow" is initated from my website and the channel authenticating in.
And I've authenticated "my bot" to my clientID, and the target channel to my clientID.

This essentially sets it up, so that the destination channel triggers the follow.

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

The IRC gateway passes whispers using the WHISPER code:

[16:36:15] [@] @badges=bits-charity/1;color=#3E2E18;display-name=foo;emotes=;message-id=2;thread-id=21001676_470220570;turbo=0;user-id=2109996;user-type= :foo!foo!foo.twitch.tv WHISPER myuser :this is a whisper

But I am unable to find any reference to that code on https://dev.twitch.tv/docs/irc/commands where I would expect it, or any other documentation page under the "Chatbots and IRC" section.

I would suggest adding the WHISPER command to the list of commands at the top of the page on the IRC: Commands section, something similar to:

WHISPER Receive a Whisper message from another user


and then the prototype at the bottom, to include the fact that it appears the WHISPER command is (appears to be) a one-way command (the server can send a WHISPER to you, but you can't send a WHISPER to other users. (When I tried to send a whisper, I got: [16:45:58] tmi.twitch.tv reported an error: WHISPER :Unknown command).

Or maybe this is deprecated or not final yet, but I figured I'd point it out just in case it was an oversight. Thanks for all the hard work!

The raids beta topic, sends raids that don't appear in chat via the IRC raid USERNOTICE

Please either

• extend the payload to mark if a raid appears in chat or not

or

• provide a condition to ignore/include/only be "non chat raids"

or

• all of the above

Please do not remove non chat raids, as developers/streamers would like flexibility on what to actually notify for/collect data on.

Regardless of any limitations Twitch puts in place on what appears in chat.

Would also like to collect it for statistical purposes/reporting on small/large raids for a given stream.

There may also be an expected in bound raid (due to a sponsorship) that Twitch drops from chat for whatever reason and we need to know that it's arriving.

With the addition of animated emotes there is no way to tell from the emote API responses of GetChannelEmotes and GetEmoteSets if a new emote ( id starting with "emotesv2_") is a normal emote or an animated gif emote without downloading it and checking the file contents.

Would be nice to have either a "format" field that tells you "png" or "gif", or at least a "is_animated" bool field for each emote.

Use cases: Whenever you wanna show emote stats or emote info for a channel (like in a chat clients or stats website or emote panel) you often wanna count and display animated sets separately but currently the only way to tell is to actually download the /v2/ files and check the type.

The Create Poll endpoint has optional query parameters to allow additional votes using either bits or channel points.

However, it doesn't actually allow multiple votes. This can be seen in the pubsub response which explictly states that "multi_choice" (property indicating whether additional votes are allowed) is not enabled.

When creating a poll through the web interface, it works just fine as it is created through the GQL and not the API. The GQL message also has an additional property to explicitly allow additional votes, on top of the properties that are used to either allow additional votes by bits and/or channel points.
So either the query parameter is just not documented... or the endpoint itself is flawed because like half of its functionality is just broken.

Also gonna drop the documentation link as a reference: https://dev.twitch.tv/docs/api/reference#create-poll

Feel free to hit me up in case you want additional information regarding this (or when I just overlooked/misunderstood something)

Right now, most of the PubSub topics are inconsistent with each other (understandably so). This, however, is focusing on cleaning up some of the ChannelPoints event data that is either unnecessary, redundant, or unclear:

As a note, the information stripped away from the structure is not invalid data, but rather data we likely don't need per message and instead should have a fetch api like manner. One example is the image objects that are likely to never change in the lifetime of a reward. This would save needless encoding as well as any data costs there may be on either side. When discussing ~512 bytes, some people will assume that is not a lot, but when scaling that up to something that people have no monetary requirement to activate, then we are talking about data sizes several magnitudes larger across the site.

Example of new structure concept:
Cleaned up structure:
{
"Time": string,
"Id": GUID,
"Channel": User (see below),
"Reclaimer": User,
"UserInput": string,
"Status": string, -- ONLY If we can receive things other than "FULFILLED"

"Reward":{
"Id": GUID
"Name": string
"Prompt": string
"Cost": int,
"MaxLimit": int, -- 0 if no limit is present.
"CurrentCount": int
}
}

User Structure:
{
    "User": {
        "DisplayName": string
        "UserName": string
        "Id": GUID (currently an int encoded as a string)
    },
}