Classificação mais clara de quando uma transmissão é Rerun, podendo ser um icone ou uma luz azul ao lado do nome do canal (onde atualmente aparece vermelha como a transmissão ao vivo). Como usuário percebo o crescimento contínuo de transmissões rerun que são úteis por um lado, mas pelo outro poluem o feed de quem assiste, sendo que muitos criadores burlan ou dissimulam a regra de colocar no título que é rerun. Muitas vezes só é possível descobrir após perguntar no chat. Essa situação é frustrante, pois interfere na experiência de interação, principal característica da plataforma e desfavorece quem está criando conteúdo em tempo real.

Dear Twitch,

Your phone app is traaash! Why is it that when I open the app I’m not greeted by the only thing I’m there for. The people I follow are buried so far away. “Your offline channels” and “Following” are arbitrary! The channels I follow should be the first thing I see when I open the app. I shouldn’t have to go find them. Sure it’s a couple scrolls away and sure they’re in there somewhere… Nope. Garbage. App is so bad it makes me not want to use it. Stop advertising **** to me and show me literally what I signed up for! Also the fact that it took me more that 1 minute to find this “suggestion box” is outrageous. No support in the app. Hidden support on the website. Terrible. You have to fix your UI. Also it’s 2021 why the F is the website different from the app!?!? People use their phones and tablets more than a desktop. Maybe not as much for gamers and streamers… WHEN THEY’RE DOING THEIR JOB! But when they’re not and they’re out in public they have what on them..? A PHONE! With a ****** Twitch app. Okay rant over. Fix your app.

Sincerely, guy following 2 people..

I know this idea has been asked on the support forums over the years, so I'd like to suggest another use case. I have some friends that I like to gift subscriptions to at a channel we all enjoy. As a programmer, it pains me to enter my credit card in several times to give each person a sub when I know there's probably a better way that can be achieved programmatically. Ideally I'd like to have a system where I could push a button or have a cron go off and give subs to several people.

To avoid abuse and keep money handling out of the API, this could be tied to some kind of prepayment. I as a twitch user would purchase those subs ahead of time and then use the API to gift/assign them later. Then the api doesn't need to handle transactions, just dispersing existing subs.

If the subscription schema would be too difficult to change to allow subs to exist without a user or there are other reasons the twitch api will never support money transactions, then disregard this suggestion.

Stop asking for my mobile number to register applications or for any reason at all.

You already get 2fa by sending the verification code through email. Sending it through mobile is an added security risk. It only makes it easier to compromise the account when hackers can just contact the mobile operator to be able to clone our mobile number.

The verification code through email is plenty. I have secure passwords on both email and twitch accounts, I can make sure they are safe, I can control that. I can't control what my mobile operator does with my SIM ID. Mobile services support line operators are a joke, and give those out like candy, and then accounts get compromised.

You want to cover your butts against any liability just suggest mobile 2fa, bad suggestion whatever, but don't force it. Use properly email 2fa is better, just because some users create email accounts with stupid easy passwords that doesn't mean you should force everyone to use a less secure 2fa method.

Please make it optional.

When I'm building an extension. I use a custom server to help simulate the Twitch Hosted test environment.

To that end it would be useful for me to automatically fetch the new CSP fields from the API

The Endpoint https://dev.twitch.tv/docs/api/reference#get-extensions Get Extensions currently provides a wealth of information about an Extension, including what things are available and enabled and which slots the extension can exist within.

With the Dashboard deployment to allow entry of the new CSP fields. This endpoint should be updated to include the CSP data.

Then I can auto collect the changes into my local test rig and generate a CSP as needed. This is also likely needed for the Developer Rig as well

If a user is banned from chat due to email or phone "cross ban" as per:

Curbing Ban Evasion

We know there are many reasons someone may need to manage more than one account, so you can verify up to five accounts per phone number. That said, to help prevent ban evasion, if one phone-verified account is suspended site-wide, all accounts tied to that number will also be suspended site-wide. Users won’t be able to verify additional accounts using a phone number that is already tied to an actively suspended account. 

At the channel-level, if one phone-verified or email-verified account is banned by a channel, all other accounts tied to that phone number or email will also be banned from chatting in that channel.

Please extend the banned API or provide an API to report his information. As if they are "cross banned" in chat I do not wish to allow such a user to login to third party tools, dashboards, or view portals/panels.

The new endpoint only allows the broadcaster to run commercials: https://dev.twitch.tv/docs/api/reference#start-commercial

The old endpoint also allowed users with the editor role to run commercials: https://dev.twitch.tv/docs/v5/reference/channels#start-channel-commercial

I believe it is of value to allow access to editors as they used to. Editors should be trusted enough to choose their own tools to support the broadcaster, as has already been the case.

Plus, if an editor's token can be used the editor's name will appear in the Activity Log on the Dashboard, rather than the broadcaster's name (assuming some sort of webpanel or bot has to be used, that the broadcaster has granted access), which may lead to confusion. This seems unavoidable for some use-cases, however where possible I would very much prefer the simpler option of using the access token of whoever actually triggered the action.