Developers
-
Add subscription status to Viewer's JWT
Add subscriptionStatus to extension JWT. Currently subscriptionStatus is in Twitch.ext.viewer. With it in the JWT, it can be verified by an extension backend.
7 votes -
Add the bits:read scope to bits enabled extensions
I'm looking to add functionality to an extension where all bits count but bits within the extension have a weighting against those that aren't. I have my own bits transactions through the transactions endpoint but at the moment I have to ask for the scope separately. As my extension is already asking for the `channel:read:subscriptions` I thought it may be a good option to add this as an extra scope to ask for or possibly ask for within the same auth loop as the subscription read
3 votes -
Include username in onAuth callback when a user has granted ID access.
Some third-party developers request id access on their Extensions just for the purpose of getting a viewer's username to build a more personalized experience. The only way to do so is by relying on the Helix user endpoint on their EBS. The Helix team already modified any payload that has a user id to also deliver a username and save developers the extra step of using the /users endpoint, so it's natural for Extensions to follow that path.
2 votes -
Viewer Only Extensions
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…
3 votes -
Streamer whitelist removal after extension is live - [Beta release]
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…
2 votes -
Standardize Transaction Timestamp in Bits Transaction JWT
The given JWT representing the transatction receipt contains a time field that is stringified version of the Golang time object. Parsing in this format is significantly harder than a ISO standard format.
3 votes -
Allow pubsub whispers in Developer Rig
The Twitch Developer Rig should support pubsub whispers. It current supports normal broadcasts, but not whispers to target a specific user's frontend.
1 vote -
Allow Developers to Rollback to Approved Extension Versions
Allowing developers to roll back a released version to another (approved) version would allow developers to quickly address breaking issues without going through a review process.
1 vote -
1 vote
- Don't see your idea?