Developer Rig - Question about Opaque IDs

Hey! Just started working with the developer rig and have everything functional so far with my extension. One thing I noticed, however, is that with two “Logged-In Viewer” views (linked or unlinked) the opaque ID returned is identical (URIG00000). I was under the assumption that opaque IDs are how we determine unique users so I was wondering if that ID was supposed to increment with subsequent connections from the developer rig?

For now I can at least get the broadcaster, and a logged out viewer, which have different opaque IDs, to act as additional unique users.

Either way I can already see the developer rig saving me tons of time, so thanks!

An opaque ID cannot and shouldn’t be used for tracking users, as someone whom isn’t auth’ed to your extension can/may/will randomly change opaqueID’s at a whim.

For example, on a live extension, a user can have a opaqueID of “random1” they login to your extension, so you get their actual ID. They logout of your extension again they now have the opaqueID of “wiggle42”

OpaqueID’s are just a useless temp ID that lets you track a user in a single session using your extension, so if they reload the streamers page, they may get a differentID. So you can’t use it to track a “unique user” really.

Yes, it’s probably a bug in the rig always using the same opaqueID you might want to flag this on rig’s github repo as a issue here:

https://github.com/twitchdev/developer-rig/issues

Could be a issue with the extension manager mock.

1 Like

Thanks for bringing this up!

As Barry said, you shouldn’t be using the opaque ID to track users. However, it is a rig specific bug that the logged in and linked users do not have unique IDs. It is due to how we mock the tokens.

Please do open an issue on github so we can track it and I’ll get to it soon!

1 Like

Thank you both for clarifying. I opened the issue on github about “Opaque IDs” but I guess it applies to the Twitch User ID as well (which is always the same “RIG<username>” for linked viewers). I’ll go read up on the different IDs to rework how I’m doing things.

The theory is, that in for say the example of a game.

A user tracked by opaque user ID can play a level of the game, and then prompted to link their true twitch ID, and save their progress.

Now if they reload the page, they would, logically, lose their progress and restart the game. Unless they authed and thus can “reload” their game via their linked/logged in ID.

Hope that scenario/example helps!

That is, in fact, the exact use case I’m going for. So I’ll just have to warn the players up front that their progress won’t be saved unless they link their twitch ID first before playing (and that will then be the unique value I’ll use to store and retrieve their data on subsequent playthroughs). Makes sense!

Thanks!

Woot!

I know streamlegends asks for ID Auth up front.

But it kind makes sense to provide a demo to the user before committing as it were :slight_smile:

So I actually brought this up with the engineer that wrote the opaque ID system, and wanted to drop an update in this thread, because learned a bunch and maybe others can learn as well.

There’s a few cases of opaque IDs:

  1. AOPAQUEID - this user is logged out of twitch and thus the opaque ID will not be persisted across sessions.
  2. UOPAQUEID - this user is logged into twitch but has not shared their identity with your extension. the opaque ID will be persisted across sessions.
  3. UOPAQUEID - this user is logged into twitch and has shared their identity with your extension. additionally in the token payload there will be a user_id field, where the value their Twitch ID. the opaque ID will be persisted across sessions.

As a user you can take two actions:

  1. Share Identity - If you are logged in and share your Twitch identity, your opaque ID remains the same.
  2. Revoke Identity - if you are logged in, have previously shared your identity, then revoke your Twitch identity with an extension, that user gets a new opaque ID.

So in the above example you can track progress on a logged in user’s opaque id. If they share their identity, you can still track the users progress. It is only at the time they revoke their identity that you can no longer track progress.

Hope that made sense!

6 Likes