RFC 0010 - Extension Management Improvements

Is Twitch ID the same as Twitch username?

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.

1 Like

Twitch ID is not the same as Twitch Username.

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.

You really don’t see? I guess you like having to export and visualize your daily CSV also.

As this is a hobby, I’d rather focus on building the extension and not extra code.

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.

1 Like
  • 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.

Thank you for updating this!

First off, I love the new design and lower latency of the extension management API, bravo! :slight_smile:

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:

  1. Only manually “whitelisted viewers” can access extensions that haven’t been reviewed. (An empty list no longer means anyone can access.)
  2. You can’t edit the streamer or viewer whitelists unless in Local Test
  3. 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:

  1. Move the extension into Local Test (since you now can’t edit the viewer whitelist while in Hosted Test)
  2. Add every single username of the channel’s current viewers to the extension’s list
  3. Re-set the extension to Hosted Test
  4. Instruct the viewer in chat to reload, then accept the disclosure
  5. 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 :blush:

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 :smiley: 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).

I doubt that’ll be a thing as it totally circumvents the release system. if you can go into testmode and allow everyone to access

You can do the functionally equivalent same thing right now, just with a lot of typing and clicking. I’m not advocating getting rid of the disclosure popup, just having the option to not manually enable whitelisted test viewers one by one.