Starting late January and into early February, we’ll be rolling out a new Extension management experience on the Twitch Developer Dashboard. Twitch Extension management will be migrated to our React-based front-end framework – the same one that powers Twitch.tv and other experiences on the Dashboard today. We’re also making a few improvements to Extension management, that will roll out with the migration and continue throughout early 2019:
Lower latency: Build faster with low wait times on page loads.
Version cloning: Clone previous versions of your Extensions with one click, allowing you to rapidly create development branches that you can test simultaneously before selecting a release candidate.
Add whitelist users by Twitch ID username: When testing your Extension, you can search for whitelist users by Twitch ID username, making it easy to collaborate with others as you take your Extension to market.
Easy secret management: Find Twitch API and Extension credentials in one place, so it is easy to get every critical variable you need to continue development.
UX improvements: Our refreshed design organizes information closer to how Extensions operate on Twitch. We’ve also provided more areas to guide you during Extension creation.
The Extension console now better reflects the development lifecycle, consolidating version management details as the primary hub for where you will do your work.
Get Extension credentials needed for development on a single screen.
Rollout Considerations
What will happen to my Extensions that I am currently working on?
All of your Extensions will be carried over to the new experience, and there will be no changes made to Extensions in any state.
What should I do to prepare for the new experience?
When we get closer to the rollout date, we’ll email all current Extension developers about the brief migration window, scheduled to occur in Late January / Early February (a firm date will be provided soon). You will be required to submit any Extensions required for review before the migration window. During the window, we will limit any Extension changes, to ensure a safe and secure data migration. As always, be sure to save your assets locally so you do not lose any Extension data.
Where can I update my screenshots that show up on the Extensions directory?
We plan to consolidate all “discovery” related items under a single tab in the experience. Our experience will match the model our system keeps for every Extension – all details are version specific.
How can I use the Twitch Developer Rig with this new experience?
You will still be able to start projects and manage them in the Rig, but it will be easier to find all the information you need to get started – your client ID and version number will be available in at the top of the screen, and Extension secrets available in a single location. This migration will help us provide more support for Extension lifecycle management in the Rig, including the creation of projects (manifests) and delivery to our CDN.
Will there be any changes to the Extension management experience that would be a regression in functionality?
No. Everything you can do with Extensions today will carry over. We do not anticipate any deprecation of features with this update.
If not, it would be more convenient and easier to collaborate by Twitch username because currently I have to write code to convert the Twitch username to a Twitch ID, then add those IDs to my whitelist, and if I forget whose ID is whose then have to convert the ID back to username or keep a list of corresponding IDs etc.
Usernames are not constant, it’s possible for them to change so you could mistakenly give the wrong person access to your whitelist by giving it to someone who then changes username and someone else taking that username that’s on your list.
So how are you getting the Twitch Id (account Id)? You are still required to know the exact username to lookup the Twitch Id.
Your response implies you set and forget your whitelist, because if you are demonstrating your extension to a lot of different people, the current system of adding/removing Twitch Ids isn’t very convenient.
An improvement would be to use the Twitch username as I mentioned. This can be accomplished by clearing the whitelist for every new version and providing a way to lookup valid usernames, similar to registration forms. That way if the user has changed their username, you will be inputting the current one, which is active vigilance of your whitelist and not just setting and forgetting it. Additionally, if someone’s current workflow is a set it and forget it type, then the previously used whitelisted usernames could be used to quickly repopulate the current version’s whitelist. This can be accomplished a number of different ways and implies you know the people you’re whitelisting and if they’ve changed their names. Lastly, it’s easier to identify the username than an Id, which is a reason why DNS exists.
I actually really like the redesign of that page. the current one is a pain to navigate and sometimes it is not even clear where to find certain stuff. This looks like a big improvement to me
I don’t quite get what all the trouble is? For my use case the users I whitelist are in my database, so if I need to get their Twitch ID’s I can just type in all their usernames, press a button, and have the full list of ID’s to copy paste.
Even if I didn’t use a database, the Get Users endpoint allows you to enter up to 100 usernames, the same as the max whitelist! So just enter your names there, press button to get results, map results to just ID, then copy/paste into the dev rig, all of which could be mostly automated. It would take just as long as entering the names into the dev rig would (ok, maybe 200ms longer due to the API request) as either way you would have to be entering usernames and unlike using usernames as a whitelist value using ID’s doesn’t have the same security implications.
You also mention about clearing the whitelist on every new version, that’s counter-productive and could easily lead to people who should be on the whitelist being removed and then for whatever reason not being re-added.
The point of using ID’s is that it will always be consistent and so should always be used. The page could potentially add a username to ID tool built in to it for people who for some reason are unable to use all the other tools available to them that do that already, and then you could just copy/paste from the tool on the page to the whitelist.
What are you talking about? For the CSV Data they even provide you a webhook so that as soon as it’s available you’ll be notified and can automate the entire process of retrieving the data and storing/processing/visualising whatever way is best for you are your use case.
You obviously don’t understand. I don’t have the time to explain because I’m too busy developing my extension, creating code to get Ids, and retrieving/storing/processing/visualizing my daily statistics.
No, I obviously don’t then. As creating a setup to subscribe to a webhook, pull the CSV data and store it for you to do whatever you like with takes 10 minutes and once setup you can just leave it to do its thing and not have to spend more effort on it. And creating code to get ID’s again is just an API call, it’ll take 10 minutes to write something where you type a list of usernames and it spits out their IDs (this even has the benefit of being able to be used for far more stuff than just extension whitelisting).
If you still want to do whitelist based entirely on username only, and accept the security issues you’re willingly opening yourself up to, you can even do that yourself in the EBS or Client of your extension and just not allow it to be activated by anyone except the list of usernames you provide.
Just because developers can workaround and build their own solutions, doesn’t mean a platform can’t also make things easier for developers (ex. entire reason dev rig exists), but let’s Twitch vet and prioritize the feedback.
I agree, I’m just trying to point out that there are reasons why ID’s are used in place of usernames, and that there are many ways to achieve what he wants to do anyway with negligible effort and without the risks associated with what he is suggesting.
And there’s ways for Twitch to implement it while mitigating risk (see Channel Roles page), and they’d be best to know and figure out the pro’s and con’s of any implementation.
Version cloning : Clone previous versions of your Extensions with one click, allowing you to rapidly create development branches that you can test simultaneously before selecting a release candidate.
This is something I missed a lot - it was really hard to efficiently test all new features before they were merged to the main development branch. It would be great to make one step further and:
create API for managing extension versions, so the whole CD process could be fully automized
allow to remove deprecated version of the extensions (right now it’s impossible to remove any version, even ones that were never released)
In the redesign, the whitelist management UI deals with this by allowing you to search by username, and persists Twitch IDs long term, allowing whitelist entries to be stable with regards to the user being added. When the page reloads in the future, the whitelist is rendered with usernames so it’s easy to know who you’ve added already without having to look up usernames via the API.
First off, I love the new design and lower latency of the extension management API, bravo!
Not sure where best to share this feedback, since it’s the result of a combination of changes since I developed last year, but has added up to make the dev workflow really painful:
Only manually “whitelisted viewers” can access extensions that haven’t been reviewed. (An empty list no longer means anyone can access.)
You can’t edit the streamer or viewer whitelists unless in Local Test
You can’t put a different extension version in Hosted Test if an extension version is In Review / Ready to Release (IIRC)
This has culminated in making the previous workflow for quickly iterating and testing on game-matched extensions no longer possible.
Especially given that there is now a clear viewer disclosure UI, why require a manually restricted whitelist of viewers to test a Hosted Test extension with? It requires a click-through either way.
From what I heard on Discord we need to now fully review and release an extension to test it out with a channel full of viewers.
The only remaining workflow for quickly iterating on extensions with multiple viewers right now is to manually:
Move the extension into Local Test (since you now can’t edit the viewer whitelist while in Hosted Test)
Add every single username of the channel’s current viewers to the extension’s list
Re-set the extension to Hosted Test
Instruct the viewer in chat to reload, then accept the disclosure
Repeat (bringing the extension down for everyone else) any time a new viewer wants to join in
Given that you also can’t move a version into Hosted Test unless there are none in review / ready to release, all together (per recommendations of other devs) this means the best practice is to spin up separate local development, beta, and production extensions and wait for the beta extension to be fully reviewed (and have a beta extension listed live on the extension store?) before testing anything that requires more than a few viewers. Because every extension has different JWT signature keys, this means creating parallel versions / environments for the game client, the EBS/database, etc. so it authenticates with the right tokens. Additionally, by actually releasing a beta extension, you lose the benefit of the disclosure which indicates it is an extension that is not fully meant to be released.
I understand why each of those changes were meant to be improvements engineering/security-wise at the time, but they’ve added up to a really rough experience. I just wish I could still iterate on Twitch extensions in their natural habitat – on Twitch
Let me know if you have any questions about the dev/test workflow or recommendations of how to approach testing that is less painful than what I’ve been doing also happy to chat @ brian@doborog.com
it’s always been this way as far as I can remember.
Because I don’t want EVERYONE to poke about in broken code just my white listed users. But it is annoying to have the extra click.
You don’t need to be in Hosted Test to test with a large group.
Hosted test means “test on the Twitch CDN”
Local Test means “not on the Twitch CDN but on a base URI you define which could be a real domain/website with the code on it and not always localhost”, there is actually no reason to jump into/back from Local/Hosted test if you need/want to rapidly change the whitelist.
Just leave it in local test and throw your code on a real website URL to test leaving you to easily update the whitelist no need to mode jump
Just to clarify, not advocating for removing the option to have a viewer whitelist, just to have an option to whitelist everyone (not have a whitelist).
also happy to chat @