A regular is arguably “between” follower and subscriber, or even totally independent of the two.
A “rank” bestowed independent of a “action” performed on Twitch. In addition a regular doesn’t need to be a follower or a sub (where sub is available).
No this has not been requested and with the advent of the tiered subbadge largely irrelevant since the tiered badge does it.
Correction, Twitch has not yet implemented such a thing in their API. The fact that data is not there already is quite unfortunate.
This is true, but developers should not have to create a workaround for the lack of a roles/tag supplied by Twitch. For the record, I believe there should really only be one tag that species any/all relations between a viewer and a channel. There should be no need for separate tags that define who a viewer is to the channel. I’m referring to the mod/subscriber/user-type tags for those who may not have understood what I meant. The relationship between a viewer and a channel should be specified under one tag separated by a comma and should include all the relations, not just leaving any out because it is not needed for their web based chat (which by the way not every uses). Need I remind that Twitch runs an IRC network on top of their live video broadcasting service so not everyone is connecting via web app.
The same actually could be said for a follower tag.
Hypothetically speaking, if Twitch implemented follow badges and had different tiers based on how long they have been following because it was requested quite a bit. Then would you agree that it would be a key feature for chat functionality?
As my previous message stated, not everyone uses Twitch’s web based chat. Quite a lot of users tend to use third party application/extension that either doesn’t show badges or has features to hide badges so that would not help here.
Exactly, so as it currently stands the subscriber tag provides data that the API can in no way provide. What may or may not happen to the API in the future is not important to the matter at hand.
Twitch is not going to supply what a ‘regular’ is because that’s totally subjective and what one streamer considers a regular may not be considered a regular to others. It’s up to the broadcaster to determine what a ‘regular’ is to them. Regardless of what a ‘regular’ is, again a follower tag doesn’t impact that at all. It’s entirely possible for someone to be a follower without ever having seen a single second of the stream, or even visited the channel!
No one is requesting that though. Hypotheticals don’t help your cause when you lack any sort of thought out use case or evidence to show that such a use case is in demand.
You keep bringing up these sort of users. How does a follows tag help them?
My bad, I would like to correct myself and say that there is currently an implementation to obtain the sub streak via API with the created_at property with a little bit of calculation.
I was not referring to a role that third party developers created to reference users that are not a subscriber or higher up in rank (reference to regulars). Being a follower to a channel which is technically a built-in role on Twitch. I would expect it to be provide in an IRC tag being that every other role is provided in relation to the channel.
Back then no body requested subscriber badges or tiers either. It only took popular streamers with a large viewer base to stir up the idea and spam it on Twitch blogs/forums and everywhere else they could to help the cause. There may not be a case like this for follower badges and tiers but I guarantee you if done the same way it would be highly requested as well. Also quite a lot of good/great ideas are usually built upon hypothetical ideas and scenarios.
You keep denying the use of such a feature but do not provide sufficient reasoning why it wouldn’t be a good idea. Most of the features Twitch provides for it’s users do not help them in any way so singling out one and not the rest is an absurd.
You’re misunderstanding the created_at field. It is not a timestamp of when the subscription to the channel started, but rather that specific subscription object, meaning there are situations where it will change. For example, if you have a 3 year sub to a channel, and changed payment method yesterday, then the created_at field will be a timestamp for yesterday, not 3 years ago. It’s something that has been brought up before to Twitch a few times in the past as hopefully Helix will scrap that field and maybe add something more useful.
Not all roles need to be announced. Like we’ve been trying to get across for most of this thread, provide a specific use case which is actually useful and wanted, and not just because ‘why not?’.
It wasn’t just popular streams, it had wide-spread support by a large number of streamers and also many viewers too.
I’ve been negative because despite asking you, you’ve yet to provide any real use cases for this feature that’s not already doable, and no evidence of demand for it. I have no use for this myself, but I’m all for new things being added when there’s sufficient need and that simply hasn’t been shown here, I love seeing new ideas, and the API used in creative ways, it’s just from everything that’s been said so far it seems like a followers tag is a solution no one is asking for, to a problem that doesn’t exist.
Anyway, were just going round in circles here so I’ll leave things at that, let me know if you think of a use case and can show demand for it.
That may be true about the created_at property changing, but it still is used for when someone initially subscribed and yes it can be updated but I still think you’re not understanding the capability a developer has when challenged with keeping track of such a streak where the created_at field can be updated at any point in time. Simple math and comparison can help determine if the streak should continue or start over based on the difference of the cached timestamp and the new one.
As I previously stated, not all features on Twitch are beneficial to everyone or have useful cases. The lack of any disadvantages such a feature would provide has not been determined in this thread as well. Simply because it does not provide sufficient uses for yourself doesn’t mean it will not for everybody else.
My point proven, it all started with the help of large streamers stirring up a conversation on the topic to help spread word and spamming it everywhere until the feature was implemented. This could be done for the follow feature as specified in this thread.
I beg to differ because I clearly have provided my answer when I stated the use would help take the load of their API servers earlier in the thread and the fact not all applications in the Developer Community use Twitch’s web based chat. The addition for follower badges would be completely up to Twitch as for the use of the tag would be more useful for developers than decorative badges make users stand out from the rest.
The moment people started to deny the fact it has no disadvantages of being implemented I knew this thread would go into a recursive state. The demand might not be here now but could be with the help of larger streamers pushing it like they did for the subscriber badges/tiers. Although It does not provide a financial benefit to Twitch or streamers doesn’t mean it’s not a good idea or feature to be implemented for developers use only.
Also take into consideration not every application needs to connect to the IRC servers so for applications that do not, they would rely heavily on the API. But for applications that do connect to the IRC server, should not have to make more requests than needed or rely heavily on the API for such small tasks. Developers have their limits too you know! Not everybody can be making loads of requests to Twitch due to their network limitations.
Any use case in which the delay of said methods undermines real-time designs around real-time chat.
Quoting my earlier post: “This method introduces unnecessary delay to the process of identifying Followers which […] can obstruct the function of more specialized bots and Extensions with features designed to effectuate Broadcaster-Viewer interactions in a “low-latency” way.”
My use case is Text-to-Speech read from chat in real-time while filtering Followers. API delay on top of stream delay is intolerable and working around a limit of 120 requests per minute on channels with millions of Followers is time-consuming. The API being necessary imposes a burden on Developer resources to store returned information that is not otherwise needed. Furthermore, the relevance of stored information is diminished when it cannot be updated in real-time to fulfill its singular real-time purpose for being requested (filtering Followers).
The elephant in the room is that Followers lack a fundamental chat tag communicating that status in real-time, which every other user group possesses. Developers with real-time designs around filtering Followers are forced to work around a method limited to 120 requests per minute.
Followers represent the Broadcaster’s core audience and can be the largest group for filtering purposes. Developers designing real-time features around chat will face hurdles filtering around this important group without a chat tag.
Should the creative potential of all Developers to design real-time user interactions around real-time user data in chat be limited to the few use cases we can cite or conceive in this thread?
I can already tell that somebody will eventually bring it up so let me just get this out of the way. You can resort to solving your problem by request a limit increase for your application. Granted, raising the API limit would help your application and many others. In most cases that is necessary, but in cases like this where an API request can be avoided in determining the relationship between user and channel when connected via an IRC server should be avoided.
Fetch all followers at TTS Application boot, update internal followers list via webhooks.
or
When someone says something in chat for the first time that day, fetch their follow status.
That is the purpose of webhooks. Collect new information in near real time (delay to make sure the data is correct/updated in helix similar to long poll aka caching)
That only works if you have been working with that streamer since they got a sub button, if suddenly I start working with Ninja tomorrow, I don’t have the cached data to form a cached collection of streaks to do this math or comparison on.
If you are using TTS on a channel with millions of followers, and thus logically even 1000 of them turn up to a stream, your TTS will never catch up. If it’s just reading out what followers say in chat. Lo behold the day two followers write a wall of text one after the other and now your TTS reader is 5/10/15 messages behind…
Can you perhaps expand on your use case to describe what is triggering the TTS?
Edit: also this excludes the probability that a large streamer is more likely to have Followers only mode on in chat. Which makes the whole follow check redundant
This would only provide a temporary solution that would break as soon as someone in that list unfollowed. Then we’d continue this never ending recursive argument as shown in this thread about polling the API when there shouldn’t be a need if you’re connecting to Twitch via their IRC servers just to obtain a simple relationship between viewer and channel.
You got me there, but then again there should have been an implementation in the API to resolve this issue from the start knowing a vast majority of developers may want such statistics instead of me sitting here explaining a somewhat accurate workaround to fiddle with in the API.
This is true, but yet again a workaround can be implemented to check a multitude of things such as sifting through a queue of messages of followers who have been following the longest and/or cheered the most, skipping every few messages or even speeding up the TTS output.
I would imagine someone taking advantage of the NOTICE command to avoid such a redundant check against whether or not they should be checking if follower only mode is enabled/disabled.
Which wouldn’t be too much of an issue for a single stream, given that when a user unfollows they probably have also left the stream and no longer will need use of the TTS function. Which is why I’m asking @Rainy for more specifics around what/how their TTS needs to work.
True, but what about people who part the channel that are still following? If users part after unfollowing and are removed from the TTS functionality and there is no checks in place to determine whether that user actually unfollowed or just left. Anyone following could leave and come back not being in the queue because of garbage collection not checking if the user actually unfollowed or parted. This is where more unnecessary API requests would be needed to determine if that user should be put back into that list for TTS functionality.
I haven’t read all posts above but I think a follower tag would be a good addition. I’ve created a few custom chat bots for a handful of streamers (with features locked behind permission/tags) and the only one I keep requiering the API for is the following status. Would love it if everything was provided through the TMI so some of my projects could skip the REST API integration all together.
This is the third party developers forum, we cannot help you with being banned from TwitchPresents channel
I would also like to have tag for followers and unfollow events. Bots have permissions only for followers etc. and it would help to bot respond in realtime on follow status. Maintaining unfollows just to tag user in db as not follower is chore and that would save a lot of unnecessary API calls.
In response to it being a ‘chore’ to cache followers and being a lot of unnecessary API calls, from all of my work with channels in the high hundreds of thousands of followers, the % time the cache is consist is extremely high, especially thanks to webhooks.
Even when there is an unfollow, which is relatively rare, from my experience they statistically are shorter length followers, meaning you almost never have to do a full poll of the followers, you only have to page through until you discover the unfollower which trends towards the earlier pages.
So even with an unfollow, the window to regain consistency is just a few minutes, and while I don’t track this specific metric there’s anecdotal evidence that someone who unfollows is less likely to speak in chat. Then even if they do speak in chat, during that window, you have to then ask yourself if mistakenly thinking they’re a follower for that brief period will have a critical impact on your use case.
Like I said though, I work with channels in the high hundreds of thousands of followers, if you do work with channels into the millions, or a vast amount of channels, then I’d be interested on the data you’ve already tracked on this and how frequently the Helix limit is a bottleneck (assuming you have already had an appropriate rate limit increase)
Oh, and as for ‘unfollow events’ like has been previously mentioned that’s something that Twitch has intentionally decided not to include for the reasons already mentioned, which is why webhooks only show follow events.
I’m not saying that a follower tag is without benefits, I’m just trying to point out that some people seem to be inflating problems in using a cache based system, or making assumptions without engineering and testing a system beforehand to see what the performance will be before complaining.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.