Given the fact that Twitch had to take down the follow/unfollow api's due to bot programs that are out there - my suggestion would be to have an approved set of developers that propose and showcase their applications.

This way Twitch could bring back the follow/unfollow API and any service or developer that was in violation of Twitch's TOS regarding the API could be warned and ultimately have their access and credentials removed.

Twitch Developers could review the logs of which applications were connected with BOT services and immediately shut those down rather then removing the api in its entirety and removing it for those that are using the api to help smaller content creators gain followers and viewers through content.

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

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.

I have embedded my Twitch channel on my website as a non-interactive iframe in my side panel.

Example:
https://imgur.com/a/v1wc8ri

However, there is so much text there which clutters the UI.

By having my stream title there from when I was online does not add any value. It certainly does not promote my channel.

I would much more prefer if I could just have the bare minimum there and I can show my own offline-image.

Example:
https://imgur.com/a/v1wc8ri

It would be nice if we had a new query parameter option for embedding channels, which could remove any promotion texts or videos / aka make it more minimalistic, to only show the Twitch button and the channel's offline image.

Summary:
Filling in the holes of what chat provides and EventSub provides would be appreciated. In this case hosts, raids, and potentially front page promo attributions. There isn't much reason to have multiple unique events in this case as all of the aforementioned events are the same, a provider of a redirect (user), a recipient (broadcaster), and an attribution amount (viewers attributed to the event). The only specifier needed is a type or context. However, different events wouldn't be necessarily rejected in concept, it would just seem unnecessary. Since a condition is sent for the subscription to the event, one could use this to focus on which type they want to receive.

New Topic(s):
- channel.redirect

Structure:
event: {
public string userid;
public string username;
public string userdisplayname;
public string broadcasteruserid;
public string broadcasterusername;
public string broadcasterdisplayname;
public string type; //auto host, host, raid, front page promo (twitch would be the user in this case)
public int amount; //viewers attributed to the redirect
}