When a "gift bomb"

there is no way to gather all the gifts into one event.
Each gift in a bomb should have a ID to link it to the header event.

IRC sends a header saying "x is giving out y subs to the community"
But the USERNOTICE events, don't say they belong to that event.

Please provide a way to group the events, something as simple as a "parentid" in the child gifts subs, that'll link to a "childid" in the header event.

This header and extra ID's need to be provided on the PubSub event feed for subscriptions as well.

It might be beneficial to include on webhooks, but Helix doesn't only provide if it a given gift was part of a bomb or not.

The chat_moderator_actions topic in the PubSub documentation appears to only work with a broadcaster OAuth token. This prevents third-party modding tools that don't use some kind of centralized system from accessing information that is vital for effective modding (such as which mod performed an action, actions that aren't otherwise visible like unbans and viewing and approving messages filtered by AutoMod).

With a centralized system the broadcaster could provide a token somehow that the moderators don't need to have access to directly, however with purely clientside tools this is not feasible. I'm also not sure why moderators should not have access to that kind of information.

The moderator actions PubSub topic previously announced by Twitch Staff on the developer forums (https://discuss.dev.twitch.tv/t/in-line-broadcaster-chat-mod-logs/7281) does allow moderators to access this information. The announcement of the added "channel:moderate" scope requirement (https://discuss.dev.twitch.tv/t/upcoming-oauth-scope-requirements-for-pubsub/23203) gave me the impression that the old topic was now officially supported, so it's quite surprising and worrying that the topic added to the PubSub documentation has changed in a way that would break tools that many moderators have been using for years.

It would be very helpful to either add/clarify the old topic as officially supported as well, change the token requirements for the new topic or provide some other way to get the same information with a moderator's token.

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

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.