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)

    },

}

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

To give more freedom in using Bits, having a Bits escrow system would be great.
RFC0011 ( https://discuss.dev.twitch.tv/t/rfc-0011-extension-entitlement-service/19142 ) introduced that idea but was never implemented.

What would be the possible flows:
- A viewer sends Bits, that are put "on hold"
- The streamer cancels the action asked by the viewers (because the stream is ending for example)
- After some delay, the Bits are refunded to the viewer because the transaction was not validated.

-- Viewers send Bits, that are put "on hold"
- The streamer cancels the action asked by the viewers (because the stream is ending for example)
- The Extension backend send a cancelation order to Twitch, canceling the Bits transaction.
- The Bits are refunded to the viewer because the transaction was not validated.
- If the transaction is not canceled, the Bits are sent to the streamer after the cancelation period expires.

In a practical way, it would be nice to have a way to cancel a Bits transaction before a certain limit of time.
This way we can create experiences that are safer for broadcasters and viewers because they are guaranteed to have the Bits used only when the conditions are met.
We could also use this system to handle server-side errors to refund people that used Bits something went wrong.

With the actual Helix API, there are two ways to retrieve the authenticated user's followed streams:

• First, get user follows (https://dev.twitch.tv/docs/api/reference#get-users-follows) and then get all active streams details, by specifying each user_id individually. If the user is following 300 users, this would require at least 6 requests (eventually one more to get the autenticated user's id). This method is quite inefficient compared to the v5 endpoint.




• The second way is to use the "Stream Changed" webhook (https://dev.twitch.tv/docs/api/webhooks-reference#topic-stream-changed). Again, I should first retrieve all user follows (3 requests for 300 follows), and then subscribe to 300 webhooks events. Again, this is a really inefficient and painful method to simply get an user's followed active streams at a given time point.

The old endpoint was really straightforward and useful for many developers. I'm sure bringing it back would be a great thing.