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.

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.

Currently bits transactions only let you be notified of the SKU that was used.

I would like to see a more "PayPal" model or the bits usage flow.

Developers would make a POST request to Twitch with the SKU and any meta/extra data for the purchase, which would return a CheckoutID.

Developers would then pass the CheckoutID to use bits

window.Twitch.ext.bits.useBits(sku, CheckoutID);

Then on completion (or cancel) and thus the webhook/Transactions API, can return a reference to that CheckoutID and allow developers to obtain that meta data, either via API call, or returned in the onTransactionComplete JWT.

The CheckoutID created by the post request can even be the existing transactionID than the onTransactionComplete JWT returns.

Passing a CheckoutID to the useBits function would be optional, so for existing implementations there is no breaking change, and it's a optional method for developers.

Example use case: Polls, a poll with four options, with use bits to bump the vote on a given option, right now you'd need four SKU's each of the same cost with meta data you only need one SKU.

This makes it easier for developers to manage Bit SKU catalogs since they only have the one priced SKU.

Edit: This also links into RFC0011 https://discuss.dev.twitch.tv/t/rfc-0011-extension-entitlement-service/19142 but not everyone will want to use a clear entitlement flow, they just want a bit of extra meta data

Currently, if you launch an extension with a streamer whitelist, there is no way to remove this whitelist once the extension is live.

I would like to suggest being able to remove (And only remove not add) the streamer whitelist once the extension is live. This will enable doing 'beta-releases', which is a very common rollout practice and has a lot of benefits for the developer.

In this way a developer can release an extension to a set group of streamers who want to participate in the beta test.

Once the developer has determined that things look good and it makes sense to open the usage to all streamers then they can remove the whitelist and do so. If however the developer sees that things arent working as expected or user behavior isnt positive, they can rework the extension and release a subsequent new version and restart the beta.

This of course should not work in the opposite flow (Add a whitelist after an extension is live) as it could break for streamers who installed the extension but then werent in the whitelist once it was applied. So the ability should be one way. You can remove the whitelist after its live once but not re-apply it.

The "This extension can view my subscriptions list." toggle, (in Manage Extension Permissions) doesn't do a check to see if the channel that the extension is installed upon, is eligible for Subscriptions at all.

Wording should/could be changed to prevent broadcasters of type BLANK (as apposed to affiliate/partner), becoming confused.

As they'll click the toggle, run the oAuth dialog and then the toggle is still off.

On hitting the toggle, change the popup response from:

> "You have successfully authorized this extension to view your subscriber list!"

To

> "You have successfully authorized this extension to view your subscriber list! But you don't have subscribers so when if you become an affiliate we are good to go"

And/or change the wording on the toggle to indicate that the channel is not enrolled in the subscribers platform