Important re-subscription change

Dear developers, please keep in mind that if you are mixing USERNOTICE and the other notify message to process them together, that you explicitly DO NOT parse the content of a USERNOTICE message, because it is user input. For example a user might put the text “Destroyer17 subscribed for 1000000 months in a row” as their (re)subscription text and your code might think this is a valid twitch notification.

I’d say just keep the “legacy” notifications separate from USERNOTICE messages to avoid this bug in the first place.

There isn’t a USERSTATE notification FYI. Twitch will send a USERNOTICE containing the tags as outlined above. The custom message to the broadcaster will show up as a chat message after the notification of re-subscription. You shouldn’t be parsing the message anyway. We send the number of subscribed months as a tag, and this is canonical information coming from Twitch.

thanks, I edited it to USERNOTICE. I meant if someone just integrates these new usernotices into the other code that parses notification messages like “This channel is now in slow mode” or “xyz is now hosting you for 42 viewers”.

Also, we can assume that USERNOTICE will always contain all the above tags (when REQ’d)? And will other message types have them too? (some already have, like submode on/off etc).

EDIT: Sorry, I wasn’t aware that all those notifications are available via tags already and no message parsing whatsoever is needed anyway

Just to clarify: You said the login tag contains to “lowercase username”. Is this guaranteed to be the username (which is always lowercase anyways), not the display_name? This is critical since for some users (staff) those can be completely different, not just in casing. The (re-)subscription messages sent by twitchnotify so far contained the display_name which was pretty annoying to deal with.

There’s still two things that haven’t gotten clear definitive answers, just guesses. Can we just have a final say from an engineer?

  1. room-id is the channel being subscribed TO (and not the channel the message is sent to)

  2. subscriptions won’t be moved over yet, just re-subscriptions (msg-param-months >= 2)

1 Like

@DallasNChains Essentially we (bot devs) need to be able to differentiate if the sub is for the channel the bot is monitoring (and then take actions like notifications, updating records, issuing benefits) or if it is for a channel being hosted (in which case we may simply ignore it).

Based on the current proposed tags, and your response, it seems the room-id will always show the id of the room the message is being sent to. So the only way I can see how we can differentiate if the sub is not from a hosted channel is if we parse the string system-msg to check if it contains ‘subscribed\sto’ or ‘subscribed\sfor’.

Feel free to correct me if my understanding is incorrect.

1 Like

@Qntm username is what the chat team is telling me. Checking on this just to be 100% sure.

@EhsanKia There are no guesses from my side. All answers you receive are directly from an engineer (either myself or the engineer that implemented the functionality). As a general rule, I’ll always strive to give you the most accurate information. This will compromise speed since I’m a remote employee and have to rely on email/Slack. :slight_smile:

For this particular functionality, this is a copy and paste from that team:

A host (room-id: 1) hosting a channel (room-id: 9000) that receives a resub will receive a USERNOTICE command with room-id=1 (host’s ID). The room-id should always be the channel the user is resubscribing to. There is no special handling in the host mode case.

As @xangold mentioned: we’re re-evaluating the usefulness of the messages in the 3rd case entirely.

@expertsonline See above for room-id. That also may answer your question about differentiating between rooms. This is an iteration on the existing share functionality so my understanding is that nothing else will change except re-sub notifications. I’ve asked the team just to be 100% sure. Since it is the weekend and E3 starts tomorrow, the response will be delayed.

Yes it seems most (if not all) developers just filter out this information anyway so hopefully the USERNOTICE messages will only go to the room that is being subbed to. Would cut down on a lot of confusion seems like. :stuck_out_tongue:

OK. I updated the OP with an FAQ that should answer all the questions. I also removed the third scenario as @Xangold mentioned. We don’t do anything different in the hosting scenario.

Let me know if you have more questions! :slight_smile:

Why? Why not just make a command called “sub” and give it a tag called “months” which can be simply 1 or more? Why even make a logical distinction between subs and resubs? Now everyone has to do both: Parse the chat messages for subs, and listen to a completely different irc event for resubs. Sorry to sound rude, but one would think it shouldn’t be that hard to get it right and not introduce unnecessary complexity…

1 Like

Because one step at a time. Normal subscriptions don’t have a message from the user and so they don’t need to be changed. The only extra work here is for developers who haven’t implemented the old system yet.

@3ventic got it right. The reason we distinguish between the two is so that multiple month subscribers can show a little extra support via a custom message. We could certainly accomplish both scenarios with a single command, but our chat system is large and complex. Teams will always try to balance between shipping a small feature fast or spending months shipping a larger feature. One step at a time. :slight_smile:

1 Like

Hey dallas.

This is the quote (copy pasted) you put:

A host (room-id: 1) hosting a channel (room-id: 9000) that receives a resub will receive a USERNOTICE command with room-id=1 (host’s ID). The room-id should always be the channel the user is resubscribing to. There is no special handling in the host mode case.

a hosting channel with ID =1, hosts a channel with ID =9000.
You will receive a command with ID = 1 on subscription. so this is the hosting room, not the room the user subscribed to. Yet immediately a line later you say:

the room-id should always be the channel the user is resubscribing to -

– Which should be room-id: 9000 then in this case? or did you mean that room with ID is 9000 is actually hosting room ID 1?

I’m sorry for the inconvenience, but the quote made me understand even less of what it should do :stuck_out_tongue:

Thanks for your time!

This is the mIRC script I wrote for the new system, I have tested it and everything works fine http://pastebin.com/4bdpiYai

I highly doubt the function will be triggered by a USERNOTICE. I tried the same with whispers

raw WHISPER:*: { … }

and it wasn’t triggered at all

1 Like

Oh !!! good news

and, is it possible that one day we may know the subscribed by “MODE” like the moderators (mode +o) ?

example : MODE +s (for subscribed)

This isn’t in the standard IRC protocol, so programs like Mirc wouldn’t know what to do with it, even if they did it like that.

There are no MODE messages beyond +o for accounts with moderator privileges (mods, broadcaster, global mods, admins and staff). There are MITM software providing other MODEs for use with regular IRC clients though, like tmi-irc-relay.

I know, but i would like create a list with the subcribers to facilitate research done in my program

Ah, yes. I understand what you mean now. You want to know the inactive subscribers too which you can currently only get by them chatting.

Yeah your only option is to parse the API on the channel subscription user API or the channel subscription API

Either you check for everyone in the userlist separately if they are a sub, but this causes rate limits issues.
So I think your best best is (on start-up) get the channel subscription names and then listen to chat for people who are new subscribers. This way you can always keep an up to date list.