Username changes / Identifying users?

Chat and IRC
64

Seconded

65

In v5, you can put up to 100 comma-separated usernames to get their user objects: https://api.twitch.tv/kraken/users?login=xangold,alca,mike111177

66

While that is true, it just doesnt make sense to do this.In v5 everything should be be referenced by the user_id per spec, so every endpoint should supply the user_id.

Imagine if you quickly need to get everyone in the chat and do stuff with them, to do stuff with them you need their user_ids. 5k viewers => 50 unnecessary requests, as well as pointless overhead on the implementation

67

It’s just for display on the website, not for the 3rd party developers. It’s pointless for that endpoint to return IDs. Personally, I’d love for it to but that just isn’t its purpose.

68

Well, if at least JOIN / PART / ROOMSTATE IRC messages contained the user_id, but those do not do it either, suggesting that the IRC internally still handles people by their name.

69

To me this is one of the main problems. How do our bots know when a channel changed their name? I don’t think the IRC server can move clients from one channel to another, so we would need to get a warning for us to leave the channel and join the new one.
All this because the IRC channels are named by the username instead of the ID. If they were named by the channel ID we wouldn’t even need to leave the channel since the ID doesn’t change but I’m not sure if IRC channels can be named by integers.

70

Re: mod concerns. A user can only change their name once in a 60 day period. The abandoned name is locked for 6 months.

Re: IDs. These never change during a name change. We made v5 explicitly to support name changes, which is why we moved to reference by ID in the API and put out the action required communications.

Re: historical data. This is something that’s been discussed. Nothing to share right now, but we’re aware of your concerns. I’ll keep you posted as we come to decisions about it.

Re: chatters endpoint and using IDs. This was covered quickly after the v5 announcement. It is question #3 in the FAQ: Twitch API Version Update Discussion & FAQ

Re: initial subs. Since it is a message from an “account”, this will be a little tricky. We’re working on subs and how they’re represented but nothing to announce immediately. :frowning2:

Re: name change notifications for bots. @xangold could speak to that better than I can. I’m chatting with him about the JOIN/PART/ROOMSTATE thing offline. We’ll come back to you once we figure out what makes sense, if anything.

I’m going to be at GDC all this coming week, so I’ll get back to any further questions as soon as I can! :slight_smile:

2 Likes
71

Given that there won’t be an official chatters endpoint, can you recommend a reliable method to determine a user’s time spent in chat? An IRC client could easily keep track of JOIN/PART messages, if user-ids are included with them, but this method falls short when there are over 1000 users in a channel (as JOIN/PART messages are no longer transmitted after this threshold).

Alternatively, a client could poll the unofficial/unreliable chatters endpoint, and subsequently convert each chatter’s display-name to their user-id in batches of 100. However, this seems horribly inefficient and convoluted, both from a development and resource standpoint.

Your insight would be greatly appreciated.

Thanks!

1 Like
72

Didnt even know that join/part is omitted after 1k clients. w/ no official chatters endpoint this is pretty horrible.

73

Resource requirements would still be minimal once you get over the initial batch of users. After that you only need to query new users that you do not already have ID stored for. In the case of loyalty applications the majority of viewers are likely going to be repeats anyway.

If for example you query chatters every 5 minutes that allows for enough time to query up to 30,000 user IDs (assuming you follow a 1 request per second rate limit) before making another chatter request which should be enough for even the largest esport channels.

74

If you cache your username lookup, like we did, you are going to run into trouble very soon because that cache will always be error prone due to frequent name changes.

75

Should be fine if you refresh more often than 60 days

76

Refreshing our entire database just to find a few that have changes is quite inefficient, and will hammer the Twitch API unnecessarily.

For example, I have a database of close to 165m viewers. If I do 1 request a second, it will take me 5.2 years to go through and refresh all IDs…
If I switch to an undocumented API endpoint for querying 100 user ID’s in a single request, that comes down to 19 days (that is a request every second for 19 days straight…).

1 Like
77

How would a database of 165 million twitch user account information not be a violation of the dev agreement?

78

how would it be?

1 Like
79

Its publicly available data, and / or possibly supplied by users trough an oauth login. How would that violate anything?

1 Like
80

It really depends how his system is built and how he handles that information that could cause it to not align with the Developers Agreement.

Without any insight at all into why he stores that information, some of the possible breaches could be:

  • Provide a publicly available and easily accessible privacy policy that explains what data you are collecting and how you will use that data
  • Request only the data and publishing permissions Your Services need
  • Marketing - services used by marketers or their customers for marketing campaigns, campaign analysis, or anything similar.
  • Research - educational and noncommercial projects that examine trends over specific time periods.
  • If you are tracking a Customer’s activity or using other behavioral advertising techniques, provide an opt-out mechanism.

Those are just some of the points made in the developer agreement and again I’ll stress, I don’t know what his use is behind having “close to 165m viewers” stored, I am just providing some examples of what that storage could breach in the Dev Agreement.

81

Debating the compliance of another developer’s application might be a little off topic for this thread.

3 Likes
82

I don’t want to rant too much, but I feel like 2 things should be pointed out.

  1. If you want to switch from a username to ID system, why would you not include the ID in EVERY communication that originally had a username. This really just seems like not paying attention to details.

  2. v5 isn’t fully done and you guys are properly deprecating and moving forward, great. But then you release a feature which basically makes it required for bots to work correctly. I don’t see how this makes any sense at all.

After speaking with various people over there I had some hope things would be improving, but this seems like the same poorly thought out release we’ve been seeing for a while, with maybe a marginal improvement.

2 Likes
83

Well i guess just like other crucial bugs / issues this thread is dead now.