Is there any possibility in the future to have more additions to the IRCv3 tags such as if the user is following, when the user followed, when someone subscribed, if a users email is confirmed or not, when that user was created and when a stream has started?
Examples:
// Comments
USERSTATE
created_at=(UNIX Timestamp); // When the user has created their channel
ROOMSTATE
created_at=(UNIX Timestamp); // When the stream has started
That data is already in the Twitch API and that is a ALWFUL lot of data to fit into a IRCv3 tag…
Further more most of what you ask for is useless to Twitch’s core usage of Tags, for the Chat interface, which doesn’t utilise the data you are after.
Most people who spend any considerable time on Twitch don’t even use the default chat interface (BTTV mostly, and Chatty), so that’s kind of a stupid statement.
If Twitch would actually build something meant for its 3rd party tools instead of just for their own features, it would be a gain for all of us, including Twitch’s users.
EDIT: That doesn’t mean the particular additions brought up in this thread necessarily have merit though, but other additions and changes might.
I’d honestly settle for just having a timestamp of when the chat server received the chat message, so there’s a better way to synchronize times across irc chat servers (and their chat).
Sending follow date (which could be 0 or -1 if not following) would be useful for moderation bots to allow more relaxed filtering for long time followers.
But what would be the use for the rest of them that’s significantly hindered by having to do an HTTP request to the API?
email verification is probably for spam detection (weak in terms of ability to get around, but maybe useful?)
subscriber is already provided as part of cap request
subscribed since can be useful for detecting length of subscriber chain, but available through the api pretty reasonably
roomstate for when the stream went live (last live?) maaaay be useful, except a user may not have ever gone live. Really the api is more appropriate for this (IMO)
userstate for when someone created there account is another (weak) spam detection helper.
Userstate is only sent to the user, whose userstate it is, and since it never changes, it would be more appropriate for globaluserstate. I still don’t really see the use for it since a simple API lookup will also reveal it and you only need to look it up once.
I think @moocat hit the nail right on the head with this. We all know the tags are for the twitch web chat. Twitch has done an amazing job with making additions and changes that we talk about on this forum though. Instead of a pure yes no response, lets talk about it. What new tags would you guys like to see?
I agree the globaluserstate would be the best place for a tag “created”. An api lookup might be too expensive especially with a new bot coming into a new “for the bot” channel with a lot of users talking.
What about the possibility to request specific tags. A bot doesn’t need color and most times the display name as well. I believe having a default set of tags for requesting the tags capability then the ability to request specific tags maybe through the commands they are used on “except privmsg idk how that would work” Maybe this would be better talked about in the issues section for the ircv3 specs on github? idk, But at least starting a convo about this will help us all.
Size limit for the message tags MUST be 512 bytes, including @ and the trailing space characters, leaving 510 bytes for tags themselves. So the total size of a message becomes limited by 1024 bytes: 512 bytes for message tags, and 512 bytes for the rest as specified by RFC 1459
Currently, only 91 bytes(excluding emote list, displayname and user-type) are used:
My answer is the expected answer from Twitch towers.
I actually expect Twitch to have more people on mobile or console at the moment [citation needed], or at least the largest growth area (and hey lets not even get into the second screen argument), rather than being a user who uses the non default interface. Of course that is my opinion.
My opinion is also based on any of the additional internal lookup that is required by Twitch in order to serve any of the suggested additional tags, we’ve got bandwidth increase both internally for the lookups and bandwidth increase just to serve these additional tags, and as @3ventic points out, who knows how much Emote tag data is or is not going to be attributed to a tag that may/may not violate the RFC for the length of tags (which granted Twitch doesn’t care too much for the RFC’s), and yes I suppose these extra tags is just marginal compared to the possible Emote data.
I’m not adverse to this extra data, but considering the whole system as a whole I wouldn’t expect it to be added, and most of it can be cached/generated via the API and done with as you will in your own systems, potentially more efficiently than to have your IRC/Tag parser have to parse the extra tags out for every single message sent by Twitch chat…
Of course this would naturally be under a “tags-extended” cap, so only those who want it can consume it.
I apologize to @moocat for appearing stupid, I just didn’t expand my initial answer. But as a systems engineer, I consider bare metal to end user and see the whole system model.
I would highly appreciate the follower=0/1 tag.
I develop a bot, and currently it is kinda awkward to check if the user is a follower or not, since i have to request it from api. This tag would be great and make a lot of things easier for developers.
~cs