This RFC proposes a way for developers to do the following:
- Create Extensions that support both Bits Eligible and non-Bits Eligible channels
- Convert non-Bits monetized Extensions to Bits monetized Extensions
- Give control to broadcasters to disable Bits monetization per Extension
Currently, Extensions have to be either defined as Bits-monetized Extensions or non-monetized Extensions at time of first release, and there’s no way to switch between the two at a later date. This has meant that non-Bits monetized Extensions are unable to take advantage of new Bits features without making a new Extension, which is a costly endeavor. This RFC aims to give developers the option to support all channels with one Extension, while giving broadcasters new controls over how Extensions monetize on their channel.
Currently, there are two different states for Extensions, Bits monetized and non-monetized. This RFC proposes to expand these options to the following: Non-Bits Enabled, Bits Enabled, and Bits Required. The following diagram explains the differences between these three states in detail:
|Non-Bits Enabled||Bits Enabled||Bits Required|
|Installable on||Every Channel||Every Channel||Bits Eligible Channels|
|Bits features enabled on||No Channels||Bits Eligible Channels||Bits Eligible Channels|
|Must check Bits Enabled feature flag||No||Yes||No|
|Broadcaster can opt out of Bits features||N/A||Yes||No|
|Must complete tax and payout onboarding||No||Yes||Yes|
Bits Eligible channels are defined as channels that are monetized with Bits. You can think of these as channels where you can cheer in Chat with Bits.
Currently, the only time developers can choose their Bits monetization is before time of first release. We propose that developers should be able to change their Bits monetization with each new release, with the following rules:
- Each version of an Extension can choose a different Bits monetization support level
- Developers can only make their Extension Bits Required at first release, much like the current monetization design
- Developers can move from any state to Bits Enabled, but only to Non-Bits Enabled from Bits Enabled
The following State Diagram illustrates the allowed transitions
Broadcasters can now opt out of Bits features on Extensions in the Bits Enabled state. This means that Extension developers now have to account for broadcasters who choose to use Extensions for their non-Bits monetized features. This flag will default to true on broadcaster dashboards for the first installation of a Bits monetized Extension.
Much like the feature flag for
isChatEnabled, developers can determine if their Extension is allowed to use Bits features on a per-instance basis by checking for the
isBitsEnabled feature flag. To check the flag, Extension developers should check the features object within the
Twitch.ext global. There will be a boolean flag with the key
isBitsEnabled. This flag will indicate whether or not the currently running Extension instance should show and use Bits features.
This flag will only be true if all of the following are true:
- Extension version is marked as Bits Enabled or Bits Required in the developer dashboard
- Broadcaster is Bits Eligible
- Extension is activated
- Broadcaster hasn’t opted out of Bits features for the Extension
If this flag is false, the Extension will not be able to invoke the
useBits call of the Extension helper. Calls to the
useBits function when
isBitsEnabled is false will return a “not supported” error immediately upon being invoked.
All currently released Extensions that are monetized with Bits will be marked as Bits Required in the new system. This gives current Extensions time to adopt the new requirements for Bits Enabled if they would like, or the option to do nothing and maintain their current Extension interactions.
All currently installed Extensions will have their Bits monetization flag set to true for all broadcasters who have installed those Extensions.
Currently we do not support the ability to merge two different Extensions into one. Developers would need to choose the Extension they would like to continue to develop and maintain, and deprecate the other, or continue to support both.
Extensions that find themselves with this dilemma should consider the Bits Required state, which would allow them to guarantee that their Extension would only ever be used with Bits features enabled, but would limit installation and usage to only Bits Eligible Channels.
This feature would allow us to ship slightly earlier, but would not remove the feature flag entirely, as we still have to handle the edge case of non-monetized channels who install monetized Extensions. The flag would simply no longer have any logic around the broadcasters intent to monetize or not. We’ve decided not to pursue this as Twitch has traditionally focused on giving broadcasters control over their channel. Developers already have to cover both use scenarios in either case, the option we’ve chosen just gives broadcasters the ability to choose between those scenarios.