Username changes / Identifying users?

how would it be?

1 Like

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

1 Like

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.

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


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.


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

  1. Are there any news about “name change notifications” in IRC for bots? We still don’t know when we should leave a room in IRC and join another one because a user changed his name. @xangold

  2. Loyalty bots really need the chatters endpoint to return the viewer ID, if the viewer changed his name, there would be no way for us to relate the old name and the new one. (For example, a user would lose all his “points” if he changed his name)

Perhaps what would be better would be to just change all of the IRC channel names to be the channel ID instead of the channel login name?

That’s a huge breaking change. It would be ideal for developers, but it would also break compatibility with normal IRC clients (and protocol) even more. Nicks cannot start with a number and some clients can’t handle ones that do.

I don’t think @JacobiCarter is talking about nicks, he’s talking about Channel Names. If channel names were ids instead of the streamer’s username, the bigger problem would be fixed. Only one room ever, no need to change rooms when a user changes their username. You were saying that nicks can’t start with a number, can channel names start with numbers? If they can, then the solution we were talking about is possible.

Oh yeah. That would be useful.

1 Like

Please no breaking changes…

All you need to do is send an event to the chat when a name-change occurs.

You can already detect if it’s the correct channel when joining it (via ROOMSTATE)

1 Like

What information in ROOMSTATE do you use for that? Or the mere fact there there is a ROOMSTATE?

Not sure how much extra load it would be for the system, but technically it’s possible to support both JOIN #username and JOIN &userid. That would keep backwards compatibility and avoid a quick fix that just ends up being another gotcha to deal with…

Seems like the id was added, but it’s not there anymore.
@broadcaster-lang=;emote-only=0;followers-only=-1;r9k=0;slow=0;subs-only=0 ROOMSTATE #moocat

@xangold Bug?

1 Like

he added rood-id but only on change event

What do you mean change event? ROOMSTATE only happens when you initially join the channel, no?

@msg-id=subs_on NOTICE #ee_man :This room is now in subscribers-only mode.
@room-id=27245045;subs-only=1 ROOMSTATE #ee_man

Having this on join as well would be very useful.

I’d use the word ‘mandatory’

@xangold Any input on ROOMSTATE on-join not containing room-id?