Why is the share always 80% streamer and 20% developer? Would be way better if the developers could decide their extension percentage.

If I sell an cosmetic item in my game ( on my website) for 5$ I get like 4.8$
If I want to sell the same item on twitch I would need to sell it for 24$ to get 4.8$

So as developer I have these options:

• Don't use Bits -> Streamer receives 0$
• Link to our website -> Streamer receives 0$
• Make prices way to expensive -> nobody buys -> Streamer receives 0$

So if you make bits adjustable for every extension it would give us a lot more possibilities. Could be a slider from 10-90% or something like that so that is guaranteed that the streamer gets at least something.

This new system could also lead to more people creating extensions for twitch because of the better (changeable) share

If would be very useful for chat clients or chat overlays to be able to show live updates on these features. Currently they are only available for the broadcaster (redemptions) or not at all through websockets (polls/predictions).

Ideally this would be available for all users to receive, just like chat is (which allows more simple integration into all kinds of tools), but even just mods using third-party moderation tools would already benefit greatly from this.

I included all three of those features, since they all seem to follow the same idea of only allowing the broadcaster access to that information which is otherwise publicly available in chat. If you want me to separate the features into different posts I'd be happy to do it.

We third party dev's often build tools that assist with moderation actions/services for broadcasters.

We tell Moderators to enable 2FA, but we have no way to check it.

It would be useful to block Logins to our tool if 2FA is not enabled. But 2FA data is not surfaced in the API and there's no way to require a User to be 2FA during the login/oAuth loop.

I'd like to see the users endpoint(s) provide 2FA status.
I expect this to be behind the user read or openID scopes.

openID allows email verified. Why not 2fa status (for example)

Worth noting that Discords floats "mfa_enabled" in it's user API so we have precedent.

The v5 endpoint contains the follower's account creation date, the new endpoint (https://dev.twitch.tv/docs/api/reference#get-users-follows) does not.

Knowing when a follower created their account is very useful to moderators monitoring recent follows to keep an eye on potentially problematic users (new account could mean a previously banned user returning) or to detect mass follows from bots (which often have a similar account creation date). Monitoring recent follows is especially useful in follow-only chat mode.

While it is possible to get the account creation date from the "Get Users" endpoint (https://dev.twitch.tv/docs/api/reference#get-users) and then merge it with the follower data, it would be nice if it were in the "Get Users Follows" endpoint as well, which would reduce the amount of API requests required.

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.

For the purposes of GDPR it would be useful to have the following webhooks:

• When a Streamer installs an extension
• When a streamer activates an extension
• When a streamer deactivates an extension
• When a streamer uninstalls an extension.

The most important one is the uninstall, it allows us the third party to be notified of an uninstalled.

The Shopify platform has this with the rule that a third party should, automatically delete all Store (and that stores customer data) 30 days after that hook triggers.

We need/should do the same, delete any broadcaster, or broadcaster viewer (and subscribers) data 30 days after the uninstall. (The 30 days allow for the broadcaster to reinstall the extension and avoid the caster having to re-setup the extension, when talking about any configuration, and hence the need for the install hook to go hand in hand)

Activate/deactivate are useful for the purpose of turning on/off any backend services related to the extension, couple that with https://twitch.uservoice.com/forums/310213-developers/suggestions/37563622-live-activated-channels-w-extension-webhook for video extensions to improve accuracy of whose live and who needs backend service support.

There needs to be an API that allows for the return of channal analytics.
This would have the reqiured query parameters of: broadcaster_id

Only stating the broadcaster_id could return the following results:
- Average viewers
- Total views
- Average new followers per stream
- Total followers
- Average subscribers per stream
- Total subscribers
- Average minutes watched per stream
- Total minutes watched

It could also return:
- Best performing catagories
- Best performing tags

There would idealy also be some optional query parameters: start-date, end-date, time.

Adding the optional query parameters would also add the result:
- Start date
- End date
- Period