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.

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

Any topic, that deals with reactionary events from chat such as cheers or subscriptions (new/resub/etc.) it would be beneficial to have a display name for all parties involved, the user who subbed, cheered, but also gifted, and broadcaster.

Reasoning:
- Various names have a certain capitalization that identifies that user. Without that there are cases that make the name very difficult to decipher for the viewer if the name appears on screen, due to all the letters being lower case or upper case.
- If the name was already displayed in chat, then this data should also propagate to the event for consistency.

Related events:
- channel.follow
- channel.subscribe
- channel.cheer
- channel.hype_train.begin
- channel.hype_train.progress
- channel.hype_train.end

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.