# RFC 0009 - Bits in Extensions Improvements **URL:** \ **Category:** RFCs\ **Created:** [October 24, 2018, 7:08pm UTC](https://discuss.dev.twitch.com/t/rfc-0009-bits-in-extensions-improvements/18388 "2018-10-24T19:08:52Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![Ampt](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/ampt/32/5564_2.png) [@Ampt](https://discuss.dev.twitch.com/u/Ampt)\ **Post date:** [October 24, 2018, 7:08pm UTC](https://discuss.dev.twitch.com/t/rfc-0009-bits-in-extensions-improvements/18388/1 "2018-10-24T19:08:52Z")
# Summary 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 # Motivation 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. # Detailed Design ## Three New Extension States 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. ## Allowing Developers to Transition Between States 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 ![ext-freeway-dg1](https://d2opxh93rbxzdn.cloudfront.net/original/2X/3/373ba660e633d4ea6b89fef8f3582a37b7a1302a.jpeg) ## New Broadcaster Flag 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. ## New Feature Flag Much like the [feature flag for `isChatEnabled`](https://dev.twitch.tv/docs/Extensions/reference/#twitch-Extension-feature-flags), 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. # Rollout Considerations ## Bits Monetization States For Current Extensions 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. ## Default State of Broadcaster Flag All currently installed Extensions will have their Bits monetization flag set to true for all broadcasters who have installed those Extensions. ## Merging Bits Monetized and Non-Bits Monetized Versions of an Extension 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. # Drawbacks ## Some Extensions May Not Have Any Features If Broadcasters Opt Out of Bits Features 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. # Alternatives ## Don’t Allow Broadcasters to Opt Out of Monetization 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. ---
**Author:** ![Dist](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/dist/32/7192_2.png) [@Dist](https://discuss.dev.twitch.com/u/Dist)\ **Post date:** [October 24, 2018, 7:33pm UTC](https://discuss.dev.twitch.com/t/rfc-0009-bits-in-extensions-improvements/18388/2 "2018-10-24T19:33:40Z")
A nice improvement, this’ll simplify things a lot for me as one of my extensions has 2 versions, both entirely identical other than one has an option to purchase things with bits, the other doesn’t, which means needing to create 2 builds, 2 review processes etc…, so to simplify it into a single extension will save time in the long run! One short-term drawback I see is that without some way to ‘migrate’ users from one extension onto another to consolidate them into a single ‘bits enabled’ extension will mean that for a period some users will start a stream to suddenly find their extension has been deleted, and they’d have to go through the process of finding and installing it again. > [@Ampt](#): > > Some Extensions May Not Have Any Features If Broadcasters Opt Out of Bits Features I don’t really see that as a drawback of this update, as those extensions would already be only available to bits users anyway, so for them now be a ‘bits-required’ extension means no change for them. The option for those types of extensions to be ‘bits enabled’ is still an option, just perhaps not fit for their use case rather than a drawback. ---
**Author:** ![dash](https://avatars.discourse-cdn.com/v4/letter/d/7c8e57/32.png) [@dash](https://discuss.dev.twitch.com/u/dash)\ **Post date:** [October 24, 2018, 8:06pm UTC](https://discuss.dev.twitch.com/t/rfc-0009-bits-in-extensions-improvements/18388/3 "2018-10-24T20:06:55Z")
Did this just go into effect last night? When testing my extension last night on my channel (I am not a broadcaster), I noticed my bits getProducts stopped returning a promise. Bits also stopped working for a friend who was testing my extension, who is also not partnered/affiliated. But a broadcaster friend who is was able to use bits in my extension. Is this all related? Also I noticed the bits portion of the docs were not updated with this information. ---
**Author:** ![Ampt](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/ampt/32/5564_2.png) [@Ampt](https://discuss.dev.twitch.com/u/Ampt)\ **Post date:** [October 24, 2018, 8:34pm UTC](https://discuss.dev.twitch.com/t/rfc-0009-bits-in-extensions-improvements/18388/5 "2018-10-24T20:34:32Z")
No, this hasn’t gone in to effect yet, although we have been doing some behind the scenes stuff related to this, you shouldn’t have been experiencing any issues. The docs will be updated once we have implemented everything and are ready to release! 😃 ---
**Author:** ![dash](https://avatars.discourse-cdn.com/v4/letter/d/7c8e57/32.png) [@dash](https://discuss.dev.twitch.com/u/dash)\ **Post date:** [October 24, 2018, 8:54pm UTC](https://discuss.dev.twitch.com/t/rfc-0009-bits-in-extensions-improvements/18388/6 "2018-10-24T20:54:57Z")
Since I am experiencing an issue with bits and everything was working fine until recently, how would I go about testing issues with the bits helper aside from it not returning a promise. onAuthorized, onContext, PubSub listening the other helpers are working properly. ---
**Author:** ![dash](https://avatars.discourse-cdn.com/v4/letter/d/7c8e57/32.png) [@dash](https://discuss.dev.twitch.com/u/dash)\ **Post date:** [October 25, 2018, 1:12am UTC](https://discuss.dev.twitch.com/t/rfc-0009-bits-in-extensions-improvements/18388/7 "2018-10-25T01:12:24Z")
I did another test on an affiliated channel, and my extension was working properly. However, still on my non-affiliated channel, bits was not working. Also, the affiliate could not use the bits on his own channel. So it seems bits are working differently now but more logically. Have you seen this behavior also? Also if this is the new behavior of bits, this seems to make it more difficult to test live on Twitch. It works in the Dev Rig; however, during Hosted testing it does not. ---
**Author:** ![Dist](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/dist/32/7192_2.png) [@Dist](https://discuss.dev.twitch.com/u/Dist)\ **Post date:** [October 25, 2018, 11:30am UTC](https://discuss.dev.twitch.com/t/rfc-0009-bits-in-extensions-improvements/18388/8 "2018-10-25T11:30:52Z")
@dash for general Bits support you are better off creating your own thread on the subject, as that will keep this thread clear and on-topic for comments on the proposed changes made in this RFC. ---
**Author:** ![Syzuna](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/syzuna/32/3750_2.png) [@Syzuna](https://discuss.dev.twitch.com/u/Syzuna)\ **Post date:** [October 25, 2018, 12:41pm UTC](https://discuss.dev.twitch.com/t/rfc-0009-bits-in-extensions-improvements/18388/9 "2018-10-25T12:41:52Z")
I like this new approach. It was always a pain to maintain 2 versions if you wanted bits to be part of your extension as a bonus. Of course this also adds some complexity in terms of the developer needs to determine if he is allowed to use bits and deactivate functionality otherwise. ---
**Author:** ![BarryCarlyon](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/barrycarlyon/32/253_2.png) [@BarryCarlyon](https://discuss.dev.twitch.com/u/BarryCarlyon)\ **Post date:** [October 25, 2018, 1:33pm UTC](https://discuss.dev.twitch.com/t/rfc-0009-bits-in-extensions-improvements/18388/10 "2018-10-25T13:33:52Z")
I wonder if it’s “better” to have a bit’s enabled HTML File/Path field and a bit’s disabled HTML File/Path field. Like we do for config/dashboard? ---
**Author:** ![MovingViolation](https://avatars.discourse-cdn.com/v4/letter/m/3bc359/32.png) [@MovingViolation](https://discuss.dev.twitch.com/u/MovingViolation)\ **Post date:** [October 26, 2018, 11:29pm UTC](https://discuss.dev.twitch.com/t/rfc-0009-bits-in-extensions-improvements/18388/11 "2018-10-26T23:29:42Z")
I think the challenge with splitting views by monetized status is that it’s a different axis from the current split–for instance, an extension might have different config needs when bits are turned on or a want a different set of controls for all of its views–panel, mobile, component, etc. I worry that over time the matrix of really good reasons to split out content might become overwhelming if it grows to additional dimensions. I think a good argument could be made that monetized on/off is a better axis than view location to split things, but between maintaining backward compatibility with existing extensions and not knowing what better reason to split might appear next time, I’d personally lean toward keeping the endpoints we have now. ---
**Author:** ![Syzuna](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/syzuna/32/3750_2.png) [@Syzuna](https://discuss.dev.twitch.com/u/Syzuna)\ **Post date:** [October 27, 2018, 12:22am UTC](https://discuss.dev.twitch.com/t/rfc-0009-bits-in-extensions-improvements/18388/12 "2018-10-27T00:22:01Z")
Switching the views is not a problem at least for me that uses SPAs that can easily render a different component based on a conditional but I get the point of it getting ugly in plain html/css/js. ---
**Author:** ![BarryCarlyon](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/barrycarlyon/32/253_2.png) [@BarryCarlyon](https://discuss.dev.twitch.com/u/BarryCarlyon)\ **Post date:** [October 27, 2018, 12:58pm UTC](https://discuss.dev.twitch.com/t/rfc-0009-bits-in-extensions-improvements/18388/13 "2018-10-27T12:58:32Z")
> [@MovingViolation](#): > > I think the challenge with splitting views by monetized status is that it’s a different axis from the current split–for instance, an extension might have different config needs when bits are turned on or a want a different set of controls for all of its views–panel, mobile, component, etc. Makes sense. I was just thinking, that for a “game” is possibly easier/quicker to split out the free version code as a standalone and load that up rather than half the code and hooks for the payment components ALL the time. > [@MovingViolation](#): > > between maintaining backward compatibility with existing extensions and not knowing what better reason to split might appear next time, I’d personally lean toward keeping the endpoints we have now. Makes sense, is always something that can be revisted/changed later depending how things tick and how we end up building extensions! 😃 ---
**Author:** ![Ampt](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/ampt/32/5564_2.png) [@Ampt](https://discuss.dev.twitch.com/u/Ampt)\ **Post date:** [October 29, 2018, 7:22pm UTC](https://discuss.dev.twitch.com/t/rfc-0009-bits-in-extensions-improvements/18388/14 "2018-10-29T19:22:37Z")
I agree with you that we should absolutely be conservative with the number of views a developer has to code against in their extension, but in this case, the alternative of having to manage two extensions doesn’t actually reduce that. Should we to not add the `isBitsEnabled` flag and let one extension handle both views, it would increase the amount of duplication across the two extensions, not to mention doubling the scope for backwards compatibility. If we want to get to a long term state of having a minimum number of views per extension, we absolutely need to reduce the friction of releasing and maintaining near-duplicate extensions. Perhaps having different extension “modes” or “flavors” that all maintain a common release version and name would reduce some of the pain in that area, but until then I think that the trade off of more views to handle versus maintaining two extensions is absolutely in favor of more views. ---
**Author:** ![BarryCarlyon](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/barrycarlyon/32/253_2.png) [@BarryCarlyon](https://discuss.dev.twitch.com/u/BarryCarlyon)\ **Post date:** [October 29, 2018, 8:07pm UTC](https://discuss.dev.twitch.com/t/rfc-0009-bits-in-extensions-improvements/18388/15 "2018-10-29T20:07:50Z")
Makes sense. I was more thinking in terms of flexibility for the developer. So a dev can choose to do multiple views, or just offer one. Which could also mean for a bits enabled, mobile enabled, extension, I don’t need to do a feature flag check, as Twitch already detected and determined to deliver the mobile/bits off html and (and thus I load the js) code. Which then means a smaller file and less data over the wire. But I do see how this could lead to over complication. Perhaps an alternative to JS feature flag check is more Query string arguments? But then theres no intelligence in the HTML itself to perform switches, and now we are err-ing towards some sort of HTML templating akin to Pug/Jade under NodeJS for example. I’m probably thinking too much into the Speed/Over The Wire file size for mobile ---
**Author:** ![tf2casperr](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/tf2casperr/32/9301_2.png) [@tf2casperr](https://discuss.dev.twitch.com/u/tf2casperr)\ **Post date:** [October 31, 2018, 5:55pm UTC](https://discuss.dev.twitch.com/t/rfc-0009-bits-in-extensions-improvements/18388/16 "2018-10-31T17:55:46Z")
I’m super excited by this, on the proviso that the isBitsEnabled flag makes it through. I have several popular non-monetized extensions which I would love to add monetized options to without having an affect on those channels who cannot utilise the bits features. ---
**Author:** ![LuckyNoS7evin](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/luckynos7evin/32/5036_2.png) [@LuckyNoS7evin](https://discuss.dev.twitch.com/u/LuckyNoS7evin)\ **Post date:** [December 21, 2018, 1:46am UTC](https://discuss.dev.twitch.com/t/rfc-0009-bits-in-extensions-improvements/18388/17 "2018-12-21T01:46:11Z")
I know it’s the Holiday Period… I’m really, really interested in an ETA for this. Happy Christmas etc ---
**Author:** ![GhostZero](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/ghostzero/32/9761_2.png) [@GhostZero](https://discuss.dev.twitch.com/u/GhostZero)\ **Post date:** [December 27, 2018, 3:20pm UTC](https://discuss.dev.twitch.com/t/rfc-0009-bits-in-extensions-improvements/18388/18 "2018-12-27T15:20:41Z")
> [@LuckyNoS7evin](#): > > I know it’s the Holiday Period… I’m really, really interested in an ETA for this. I’m also interested in a ETA, i currently have an Extension that has Bits Required, but a Bits Enabled would also be great for my extension!