RFC 0009 - Bits in Extensions Improvements

[Ampt]

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

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

[Dist]

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.

[dash]

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.

[Ampt]

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!

[dash]

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.

[dash]

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.

[Dist]

@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.

[Syzuna]

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.

[BarryCarlyon]

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?

[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.

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.

[Syzuna]

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.

[BarryCarlyon]

@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!

[Ampt]

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.

[BarryCarlyon]

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

[tf2casperr]

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.

[LuckyNoS7evin]

I know it’s the Holiday Period… I’m really, really interested in an ETA for this.

Happy Christmas etc

[GhostZero]

@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!