Rework/redesign Chatter List with options of what to show/not show

[Simon]

With recent outcries against the innocuous “lurk bots” being seen in the chatter list I had the thought that it may be time to rework the list functionality a bit and provide some options to the broadcaster of what is shown in that list.

This would help the broadcaster (and others looking at the list) to see what they want to see, without unnecessary information that may not be helpful overall.

I suggest the following changes:

• Full rework of the list in functionality and use.
• Offer options in settings on the type of data that is displayed:
• Chat list Enabled: Yes/No
• Show Twitch Staff: Yes/No
• Show Channel Mods: Yes/No
• Types of Chatters to Show: All/Active/None

Types would only apply to chatters that aren’t Twitch Staff or a Channel Mod. Active Only will only show chatters that have chatted within the last 15 minutes.

Mock-up of the options as they might appear in channel settings:

[Dist]

Chatters endpoint is already on the Summer 2018 roadmap https://blog.twitch.tv/twitch-api-summer-2018-roadmap-update-6036065f0098

Some of what you suggest, such as showing Twitch staff, mods, active chatters etc… could already be implemented in client-side scripts/browser extensions.

My view is that the chatters list should always be as complete as possible (and I hope the new endpoint includes additional data that the current undocumented one lacks), and any filtering should be client side. While I don’t particularly like “lurk bots” especially when Twitch supports the “follow for follow” nonsense which inflates both chatter and follower numbers, I still think that those bots should be included in the chatters list and that they shouldn’t be filtered server-side, although filtering them client-side by default could help prevent those profiting from the follow for follow stuff.

Some things you’ve suggested, like email verification, could add overhead too so may want to be avoided. Really though we just have to wait and see for Twitch for release info on the chatters endpoint they’re working on and go from there.

[Simon]

E-mail verification is already a thing, the image there is a mock-up for just the chat list options ( https://www.twitch.tv/settings/channel and scroll down) , here is the actual settings screen for that section: https://srink.net/2PXgU1n

Regarding the other points:

• Just because the API roadmap has it there doesn’t mean it’s a feature change on the frontend side of things, and more than likely we won’t see a change just because they add an API endpoint. I say this because the frontend chat list hasn’t really changed since JTV.
• While client side filtering is always an option, it doesn’t address the concern of many broadcasters, which is that they appear in the list at all and can be seen by them and other chatters/viewers. While this wouldn’t do anything when it comes to third-party chat apps (chatty, mIRC) it will improve the view on Twitch.
• There is already server side filtering for chat related features that broadcasters can enable/disable (auto-mod being the biggest example of this), why not add one for the chat list? Default to enabled and display all, if they want to change it they can. While this does require a rework of the frontend display of the chat list, that’s something that needs to happen anyway.
• You made the exact point arguing for this, by filtering non-active chatters they don’t appear in the list and thus lose out on being seen by others. It also allows for a “is_active_chatter” flag to be set that can then be used for channel specific giveaways, gift subs, etc… It adds an option for future things to be done with it.

[Dist]

I meant email verification within the chatter list. Getting a full list is simple, the more filtering you add, especially if it requires hitting other parts of the API to do so, will have some overhead.

One of the reasons the frontend chat list hasn’t changed since JTV, is that the endpoint it’s based on hasn’t changed. If the new endpoint is just an official chatters endpoint, that’s unchanged, then that likely means the frontend wont change, but if the new endpoint provides more data then that potentially means the frontend could have access to that too and can apply filters based on that.

I’d be interested in the numbers of how many broadcasters are ‘concerned’ about this issue. From my experience, the vast majority simply don’t care, a handful notice it but don’t want to do anything to change it, and only a tiny minority I’ve seen speak out against bots and lurkers showing up in the chatters list.

You can’t compare filtering chat with filtering the chatters list. It’s 2 different systems, and again, there will be overheard and only Twitch will have the data to know what the cost will be. Letting it be client-side gives the option to the viewer and the way they want to experience chat, rather than a specific way of viewing chatters (those that actually do look at the chatters list) forced onto them.

Twitch shouldn’t be defining what an “active” chatter is, and there isn’t a need for adding yet another flag for it. For things like giveaways it should be in the hands of the giveaway app, and the broadcaster, to determine what is classed as “active” to work out eligibility for a giveaway. By excluding users from the chatters list you’d also be removing them from all points systems that the channel may be using, and skewing channel analytics. There are many people who watch on mobile, console, or multi-stream sites, that have access to chat but simply don’t because it may not be convenient, that doesn’t mean they should be excluded.

Honestly, this sounds more like a suggestion for https://twitch.uservoice.com not an feature suggestion for 3rd party devs, as what you’re suggesting could actually hamper 3rd party apps that rely on the chatters list being a ‘clean’, unfiltered list of users connected to chat. Maybe if you post it on the suggestions site we’ll be able to get an idea of how much/little demand there is for such a feature.