I would like to express developer interest in the addition of a PRIVMSG or IRCv3 tag for Followers. Chat presumably does not surface this information because the chat frontend does not need it (there is no Follower “badge”). However, Followers represent the largest portion of a Broadcaster’s community and are therefore one of the most valuable “user groups” to leverage in the design of any chat bot or Extension. It seems remiss that chat does not already support such a necessary tag; the absence of which is certainly felt by Developers, whose designs around this important user group are being frustrated and in turn, discouraged.
Past discussion on this recurring topic has pointed to the API as a solution, but it is not a practical one. The API is limited to 120 Follower requests per minute and there are channels with millions of Followers. This also forces Developers to find a solution for caching the information that is returned (something they do not need to do for any other user group).
The introduction of “low latency” mode has given Broadcasters near real-time interactions with their Viewers in chat. If Developers are going to leverage this new landscape fully, we need a “low latency” solution: chat tags that support all the usergroups relevant to Broadcasters, and not just the ones relevant to Twitch.
I asked about something like this previously, the answer from Twitch Development was that they did not desire to have an easy way to determine if someone unfollowed as there is a level of harassment involved when people unfollow channels. That conversation was steered toward finding other ways to determine loyalty.
You can see in this post:
It actually isn’t omitted for performance reasons. @3ventic is on the right track. Unfollow was something the team wanted to implement, but I was very against it for abuse reasons. I don’t want to create a scenario where it is easy for someone to harass someone else for unfollowing. Obviously this can be achieved in other ways, but I don’t want to make it easy.
That isn’t to say that Twitch does not change their mind but, what you propose as an IRCv3 tag makes it very easy to track follows and unfollows.
Hey IllusionaryOne. Thank you for contributing your interest and historical insight to my thread!
My understanding is that the feature requested in that case was an unfollow webhook deemed to have few practical applications outside of “unfollow notifications”; information believed to no positive value.
What I am requesting is an IRCv3 tag that would communicate whether an active chatter is a Follower. This tag would have limitless, positive applications for bots and Extensions with features that rely on knowing that status the moment a user commits text to chat.
I feel that the possibilities in my proposal represent far more potential for positive use cases. This is information that I strongly feel has a positive value – not just to Developers, but to Broadcasters as well.
Although it might be argued that such a tag could be used to track “unfollows”, spurring edge cases of harassment against users, I would point out that the Twitch API can already be leveraged to do the same, albeit with a limit of 120 Followers per minute. I would also argue that Broadcasters stand to be more financially invested in the status of their Subscribers, which represent an actual monetary value, and for which IRCv3 tags already exist denoting both Subscription tier (price amount) and Subscription length.
Ultimately, if the concern comes down to a specific form of use (tracking unfollows) being unwanted, Twitch could forbid it within the terms of their Developer agreement. I personally feel this would be the more practical deterrent in addressing that concern.
Looking back at my past post mentioned and all the responses, the tags could easily be cleaned up and shortened to cram what the tags currently have plus additional information into a single packet without exceeding the IRC packet limit. Also yes, it is sad they still haven’t added whether someone is following or not into the IRC tags because whether it opposes a privacy/security threat to users being able to track when someone unfollows. That can be easily done by polling the API. Notice I said “easily” because whether they put it in the tags or not. That would be more for convenience than accessibility.
Further more, as for abusing users based on whether they unfollow or not. That would have been a problem from the get-go after the release of their API in the first place since you can basically do the same exact thing just by polling. Keep in mind there have been plenty of instances where viewers have straight up told the broadcaster that they were going to unfollow because they did not like what they were doing or they were ignoring them. As a result in whether people start harassment someone for unfollowing is totally up to them. I would hope people use their common sense about what they do/say to other individuals given that Twitch provides the necessary tools to report such abuse.
Also by now I was hoping that notification developers would have come up with some type of filtering system on all the notifications to combat abuse/spam so that they do not go through and show up on the broadcasters stream. I don’t know how many times i’ve witnessed fake account after fake account follow someone with a hate related phrases in their name or a cheer/donation with a hateful message. The filtering system should be customizable by channel rather than coming up with a single filter for every channel because even though a channel might allow certain words/phrases doesn’t mean that others will.
So to conclude my statement, I feel that Twitch should not leave out any tags that help identify what the user is in conjunction with the broadcaster which would also help mitigate any stress on their servers from API polling.
So, as I suggested in the other thread, you want to move the stress from the API servers to the chat servers instead in order to broadcast this information over chat instead. (Sure their is already a performant lookup occurring anyway for chat in followers only mode, but we are more talking bandwidth and message compilation here rather than DB Lookup time/load)
I would imagine the DB lookup time not being a problem or change in any way being that when the data is pulled on an individual in correlation to the channel. It would contain everything from them being either a moderator/subscriber/follower/etc. As for bandwidth, I previously stated that the issue with adding additional tags could be solved by simplifying and cleaning up what is already present. I don’t see the need for long human-readable tag names since the only people seeing them are most likely programmers and we already have a way to lookup what most of the tags are here https://dev.twitch.tv/docs/irc/tags so why not shorten the tags or abbreviate them, then clarify what they are in the documentation. This would shorten them substantially and save on bandwidth so you can fit more data in the tags if need be. I would presume message compilation would change slightly but shouldn’t have a significant effect overall.
If you need a higher limit, you can request a higher limit. Ohbot does 2 API calls for each message it’s interested in, average in the thousands per minute range.
I agree. If the opposition to a “Follower” tag is its verbosity, then shortening each tag to a single character allows plenty of “room” for it and future tags. That’s the way videogame servers (Valve HLDS flags) and countless emulators (one button press representing all eight buttons in a single character) do things.
Hey 3v. Thank you for this suggestion as I was unaware that was even an option. It’s only a bandaid in my case, but still an option I didn’t have yesterday.
Although it is good to know that Developers designing around Followers can reach out to Twitch on an individual basis and request a higher limit on API calls to identify them – something they do not need to do to identify any other user group in chat – requests can still be denied. The steps following that request impose a human burden on Twitch (responding to and accommodating limit increase), while failing to address the core Developer concern of being required to call on the API, introducing delay.
The issue is not the API limit, but the need to call on the API to identify only one user group in chat, which just so happens to be the largest and most significant user group to Broadcasters on Twitch. This method introduces unnecessary delay to the process of identifying Followers which, while negligible or even workable for a bot like Ohbot, can obstruct the function of more specialized bots and Extensions with features designed to effectuate Broadcaster-Viewer interactions in a “low-latency” way.
The addition of a Follower tag would resolve this Developer roadblock (identification of Followers in chat), eliminate future burden on human resources to accommodate Developer requests “working around” the problem (API limit increase on Follower requests), and reduce a heavy source of traffic Twitch is seeing to the API (Follower requests arising from a need to identify Followers in chat).
Thank you to everyone for the replies and suggestions over the weekend.
I also requested a tag; again, you just look to see when that is removed (like a subscription) and you could easily track who unfollows. I think that was part of the concern before too as i asked if this was a performance drain, and the reply was that it had little to do with performance but other factors. Hope this helps and cheers!
I am curious, Dallas, since IRC has followers-only-mode, if it would ever be possible to provide a follower=1 tag much like the subscriber=1 tag? I completely understand if this would be a performance drain, but just curious, because, if this was the case, then my bot would have almost no need to ever even pull the API endpoint or use the webhook.
Technically not all 3rd party Twitch applications are used to connect to their IRC servers. The API endpoint would still be very much useful even if they added it to the IRC tags. Also the API currently allows you to track people easily with and without certain permissions, so leaving it out of the tags is just an inconvenience to developers.
I can see how the potential for “unfollow tracking” might have raised harassment concerns at one point, but that concern seems depreciated when there is now a Subscriber tag communicating far more information. Subscription “cancellations” can be tracked the same way as “unfollows” would, and financial attachment can be a strong motivator towards harassment. But there’s no need for us to track Subscription cancellations, because Twitch already does that for us via the Channel Analytics Dashboard. A current list of Subscribers – username, sub date, and sub tier – can be reviewed or even downloaded from there and compared month by month. There are convenient financial summaries for revenue “loss” tied to Subscription cancellations. Any potential for harassment in “tracking” doesn’t seem to have been deemed significant enough to impede useful design there – so why let it here?
I respectfully disagree, the most important user group to Broadcasters on Twitch is viewers.
A non followers or even a non subscriber should be treated the exact same way as those that do follow or subscribe.
Suppose the question really is: Why do you need this information? What are you going to do with this information?
Then we can work to a solution.
Subscriptions involve money, for the most part harassment around unsubscribes just isn’t a thing as most people understand or have the common sense to realise that not everyone has money, or were using their Twitch Prime. Following is free and a easy target.
This thread is posted under “Twitch Messaging Interface and Chat”. “Viewers” are not a “user group” in the context being discussed, because Viewers need not be “users” with registered accounts connecting to chat. Viewers can be, and often get identified as, just numbers.
“Followers” are registered users identified by a username in chat. They have committed to “Following” a channel and can be the largest group recognized there for filtering purposes (“Followers Only” mode).
The importance of Followers to Broadcasters and Developers cannot be overstated, even if they are being underutilized in chat design.
If this is your belief, then my request should be agreeable. Followers are the most acknowledged user group without a chat tag.
Do you have a source for these moderation statistics?
Neither of us knows the number of harassment cases tied to “unfollow tracking”, if that number is significant, or how those numbers compare to “unsub tracking” cases. All we know is that the same potential for harassment exists in both groups, but is attributed to impeding chat designs around only one.
The potential for harassment arising from “unfollow tracking” was a concern raised at one time. We haven’t been told how significant the concern was then, or if that concern is still relevant now.
Harassment and technical implementation aside, what are the use cases for a follower tag in chat that can’t be achieved through smart use of caching the API results, and webhooks? I’m neutral on the idea of the tag in chat, I’m just against redundant data bloating the API or Chat as everyone would be receiving that data when the potential use of it is seemingly very minimal.
The use case is different for what you are implementing it for so in Twitch’s chat design’s case it may not be needed. Some people may find that a follower badge would be nice and some may not. The same could be said with the subscriber and prime badge. However, tags that may not seem bloating to Twitch’s chat design may be bloated data for third party developer’s applications which don’t use Twitch’s chat. In this case half the tags could be considered bloated data.
A solution for this would be for Twitch to allow developers to make a request to receive certain tags that may be more suitable for them and their application. This would allow Twitch’s chat to continue receiving the tags needed for their chat design and accommodate developers needs. This would also allow for a wider range of tags to be implemented seeing how developers can simply request what they may want or need.
Which is why I was asking for some specific examples, and why that functionality can’t be possible with the current APIs for followers. Specific use cases can go a long way to help prove the usefulness of a feature and why it should be implemented, simply saying there’s lots of various reasons isn’t helpful.
Some may like a follower badge in chat, but that’s an end user thing and probably more an appropriate suggestion for https://twitch.uservoice.com rather than 3rd party dev forums.
Also implementing a system to request specific tags would result in either defaulting to no tags (a major breaking change), defaulting to all tags (so not solving the bloat issue until all devs both update their libraries for it, and devs using those libraries request not to receive tags they don’t need), or defaulting to current tags, with only new tags requiring them to be requested to receive them (which isn’t very consistent, and going forwards into Helix one of Twitch’s goals is to be more consistent).
Well for their web based chat the default tags should be what they are now. Only when a user makes the request for certain tags should they request for all, custom or none. This method (as long as it is implemented right) in fact would not break any application currently present in the Twitch Developer Community.
IRC tags are used for passing data to clients and by default should not be sent unless requested by the client as specified in the IRCv3 documentation. For anyone not connecting to Twitch’s IRC servers via their web based chat do not receive any tags unless they request it. This alone disproves your statement about things breaking by defaulting to no tags.
Again, by default clients should not be receiving any tags unless they request it. Unless they’re using their web based chat. Any developer not requesting tags as a capability already won’t be affected, but for those requesting it and are not specifying which tags they need should be defaulted to what is used for the web based chat. As for requesting any/all tags and bloating concerns go, that can be resolved by limiting the amount of tags a developer can request if need be.
This ^^ , if we know WHY/what for you need it, as in describe your use case then we can advise what works.
For me across all the streamers I have done work for, there has been only TWO things which could conceivably require a chat tag but doesn’t need it, that casters have asked me for
!followage - (yay chat spam), still need the API lookup to go get the start date, unless you want to throw the follow start date into the tags
some giveaway stuff needing a follow - which for the most part is run outside of chat and the follow checked at drawing rather than from chat, since only need to check the follow status of people drawn to be the winner, sure here a chat tag would save me maybe 3 API requests, but followers only giveaways got phased out a loooooong while back in the same way subscriber only ones did due to legal reasons (please consult a lawyer)
That’s it, in 4 years, thats literally all the things I’ve been asked for around followers only, not because the chat tag exists or not, as for the most part this predates tags even existing. So I have no use cases for this tag, across any of the broadcasters I do work for.
No one has even ever asked for follower only chat bot commands… It’s not a thing people have needed or wanted.
I’m not quite sure how you got that I wanted a follower badge out of that context but I was referring to people other than myself. Anyways, if a follower tag was implemented, seeing how it would just be floating around for developer eye’s only and no person using Twitch’s web based chat would actually see the tag. An addition for a badge wouldn’t hurt.
Yes, I would agree with this statement. But not when the same could be said for other tags such as the subscriber tag.
Have you implemented anything like !subage or !subscriberage at all? I would imagine this being also an important implementation next to !followage that broadcasters would want or does that not get as much attention as !followage does (if it’s implemented)?
That’s probably because it has other pseudo names such as “regulars” of the channel. You know? The people who’ve been around chat for awhile and/or “following” the channel. Do you have any implementation like that? Other widely used bots tend to have something similar to that to differentiate between viewers other than being a moderator or a subscriber, but not seen as just a random viewer.
The subscriber tag has additional data that’s impossible to obtain through the API, such as what sub streak range they are in. Also subscriber badges, and various tiers of those, was a HEAVILY requested feature by streamers, so the sub tag is a key feature for chat functionality, the same can not be said for a follower tag.
The bots I’ve seen that commonly use a ‘regulars’ setting for commands don’t rely entirely on whether a user is a follower or not, as someone who just joined the channel and tapped follow (or even was already a follower due to the mobile apps onboarding) is not a ‘regular’ viewer. To use anything like view time, or number of streams watched, activity in chat, or any other metric to determine if a viewer is a ‘regular’ is in no way helped by a follower tag unless you’re also asking for way more additional data being added too.
