Like Bits transaction, it would be great to allow Channel points to be accessible from an extension.

The idea is to not expose channel points to the extension and work the same way Bits transactions are.

This would also need the addition of channelPointSku or allow sku product to have a bits value and/or a channel Point value.

• User click on a button


• Extension fires window.Twitch.ext.points.usePoints(pointsSku)


• User validate transaction


• (if user complete transaction )OnTransactionCompleted callback is fired with receipt containing channelPoint as the currency used


• (if user cancel or don't have the channel Points) onTransactionCanceled is called

To complete it, adding a filter on the endpoint GET helix/extensions/transactions would allow developers to only get Bits transaction, channel points transaction or both.

Channel points in extensions would help people to discover features, interact with extensions more and at the same time, give a way to regulate the interaction by using channel points instead of free actions.

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, 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