I was thinking, not all extensions need to be tried to a specific channel experience, and don't always interact with the broadcaster at all. Extensions like the chat translator, or maybe a TTS chat for viewers who can't read well, or visually impared, it would be great to have for users on every channel, not just channels where the broadcaster decides they want to use it. My idea is to have extensions that the view can enable on every channels, and possibly have the panel for viewer extensions be where the chat is, and possibly take up the bottom half of the screen, but same dimensions at chat, so you would have the top half of the screen be the chat, and bottom be the panel, or in a case like the translator, allow the viewer to have the panel take up the full height of chat. then the user can switch between their extensions similar to the experience on the streamer dashboard, and the drop down will be able to cycle through the extensions installed, so you can have multiple extensions running on every channel you visit.

The addition of the Emote Library that is coming soon is a fantastic addition, this is great for solving the issue of disparity between partners and affiliates on emote variety, without undermining the parner program and is a fantastic compromise.

I would like to suggest the addition to the Twitch API to allow for enabling and disabling of active emotes from the Emote library via a privlaged API call from a token with sufficient privlages through oAUTH.

An example of the proposed usecase would be 4 API calls:
-Activate Emote [Params: Emote ID, (Optional: Emote Slot)]
-Deactivate Emote by ID [Params: Emote ID]
-Deactivate Emote by Slot [Params: Emote Slot]
-Replace Emote by ID [Params: Emote ID to Find in active emotes, Emote ID to replace with if Param 1 ID is found in active emotes]

• Activate Emote would add an emote from the emote library by specified ID to the first free slot on the channel's active emotes, or if specified would overwrite an emote in the specified slot.

• Deactivate Emote by ID would remove an emote from the active emotes by specified ID if present in any current slot, if emote ID not found, would do nothing or respond with an Error code.

• Deactivate Emote by Slot would deactivate any active emote found in a specified active emote slot, If slot is already clear, would do nothing or respond with an Error code.

• Replace by Emote ID would search active emotes in slots for a specified emote ID, if found the slot containing the found result would be cleared and then a emote from the emote library specified by ID would be activated to the specified slot.

Programatic access to these functions would allow for great viewer interaction by the creation of immersive experiences allowing viewers to use channel points or other events monitored for via IRC or the pubsub API, to trigger changes to active emotes without disrupting the viewing experience by requiring human intervention by the streamer or another user with privlages to swap emotes.
This would also facilitate the ability for channels that play a few different games or perhaps playthroughs such as variety streams to increase their appeal by creating emotes that are themed around current games or ongoing themed streams, which can then be automatically swapped in and out via the twitch API.

This is an amazing addition you've come up with here for the emote library and I would love to see this included programatically in the API for Follower Emotes, Subscriber Emotes and Bit Emotes ideally, but at the very least, subscriber emotes.

A topic to account for emotes being added or remove from "global" or a specific ChannelID would be useful.

It's hamstrung by

https://twitch.uservoice.com/forums/310213-developers/suggestions/39547780-emotes-by-channelid

As we can't catch up

There are a number of Twitch Extensions that would be good to know if/when emotes change. (HypeMeter for example)

And Developers of single channel bots will need to know so they can add/remove emotes from any channel commands.

It's also useful for custom channel tooling to keep lists up to date in custom tooling if/when https://twitch.uservoice.com/forums/310213-developers/suggestions/41137957-upload-emotes is actioned as well

This includes but is not limited to

• regular subscriber emotes
• bits/cheer emotes
• the channel sub badges
• the channel bits badges
• any other channel specific imagery that may be utilised in chat

Summary:
A cheer message can be multiple cheers in a single payload. Providing the individual cheer components in an int array would provide data that is not currently there. Emote placement, while also desired, would be still more work than should be necessary at first glance to determine the bits used.

Example: **
BarryCarlyon PogChamp100 PogChamp100 Party100 Wow Soaryn is Frustrated!
This would result in **"bits": 300; however this is incomplete and would be desired to also have something like "bits_used": [100,100,100]

Reasoning:
While again, emote placement would help, determining the bits used from it would be extra and redundant computational work that was already processed on Twitch's side. On the same note, determining in the emote where the cheer values actually start vs the emote regex may cause issues for this particular use case, unless on the client side a running emote store was kept.

Related Event(s):
- channel.cheer

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.

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.