[Feature Request] Channel configurations based on subscription status

[seth-rah]

Summary

I have Robot running in a friends channel, but they don't maintain an active subscription for the Robot on their channel, it's mostly just gift subs that come in.

On my end I tried to make some channel specific emotes that relied on the subscription at the start, but after time this slowly turned into a case of messages only sometimes having access to the emotes.

robot/example.toml

Lines 140 to 141 in 74c6842

	[twitch.bocchi.emotes]
	'btw make sure to stretch, hydrate, and take care of yourself <3' = 1

Having a channel config that's only used while Robot is subscribed to the channel would help alleviate issues like this.

[twitch.bocchi.subscribed.emotes] or [twitch.bocchi.subscribed.effects] from the config as an example. although, I'm mostly just interested in the emotes aspect.

What I wouldn't know is how this would work with alongside existing configs that aren't subscriber only.
Do you combine them, or use it based on a configuration that only allows 1 variant based on subscription status.

This request is config specific, as the emotes in the configuration aren't influencing the learning process and would reduce scope.

---

Open thoughts / Scope Creep / Rambling

Not intended for this request, but I have a hard time not sharing details that might be useful to consider.
Sometimes ideas or future considerations like this can help shape the implementation of the topic above to avoid later refactors.

Something that's worth considering at a later stage is tracking whether a string learned in a message is a Twitch channel emote or a word.
If the value is an emote, it can be linked to the channel that owns it.

This could then be used to help Robot filter spoken words if applied to Robot's config. Alternatively Robot could gain access to a list of all emotes they have access towards, and cycle through available emotes when writing a message that has a part it knows is linked to an emote.

Example:

Robot learns Bocchi loves being with friends ${emote}

Robot thinks Ryo has many friends ${emote}

Robot pulls emotes they have access to, and replaces ${emote}

This could be applied to the config format to pull a random emote from the list of emotes Robot has access to instead of targeting a specific one when created.

[twitch.bocchi.emotes]
'btw make sure to stretch, hydrate, and take care of yourself ${emote}' = 1

Tracking emote access I'm not too sure about. Maybe writing a record when a subscription activates could work?

If it's a gift sub, track the expiry date. If it's a recurring subscription, check the renewal date. Each sub registered or renewed does a refresh on existing subscription records to validate whether dates are still correct, or if they need to be adjusted / removed.
Potentially this could also validate whether learned emotes are still available in the channel that owns them.

Probably not smart to check subscription status before each message to avoid flooding network requests.

Another question or maybe configuration would be to allow pulling from all available Twitch channel emotes instead of only "learned" emotes. Which could increase the visibility of under-utilised emotes in a channel.

I don't think BTTV / 7TV / FFZ should be considered just yet. As those extensions are third party in this context it would create a lot of maintenance alongside it.

[zephyrtronium]

With regard to the second half, in the past I've thought quite a bit about having Robot replace emotes. Twitch actually did recently add an API endpoint to get the emotes available to a user, which addresses the main technical problem. I'm still not convinced it's actually a good idea, though. There are a huge number of emotes, especially global ones, which people don't use and don't like, so replacing them at random isn't a good idea. We could try tracking frequency of emote use in each channel to address that, but emotes are also often used in context, which means we also need to keep track of that. We're effectively back to using the Markov chain model for emotes, but now we need to do arbitrary replacements of some terms mid-thought, which will make what is already the most expensive thing to do even more expensive, as well as probably lower quality.

Making channel config depend on whether Robot is subscribed to the channel seems more feasible. The technical challenge here is indeed tracking subscription status. For gift subs in particular, we'd have to listen for notifications that match the bot's account; see #58 and #18. If the bot's own account has a recurring sub, though, there's no reliable way to track that. I can imagine ways to pull off the actual config switch, but overall it seems much harder to do programmatically than to just change the config manually, especially if there's only one channel you need to do it for. (I myself prefer to leave the subscriber emotes alone in the hopes that it will bait people into gifting subs to the bot. Effectiveness varies between channels, but there are definitely several where it seems to work.)

[seth-rah]

For the top half, My use case is definitely just 1 channel right now, so not a big hassle. I'm just not always around to monitor it so thought this was something that could be useful.

For the bottom half, I see what you mean. Honestly I wasn't thinking about global emotes too much, mostly just those on a channel to replace with the same channels emotes. Something I missed when thinking about the setup.

I was hoping for the gift subs to keep the bot afloat but it looks like I only get that win through a mini guilt trip

Rather than replacing emotes based on availability, It might be nice to know if a string is an emote to compare that to a stored emote availability record, or something of the like to avoid excessive calls. As the channel I'm monitoring is on the smaller side, emotes come in from various different places, and results in a lot of messages ending in an emote that the bot doesn't have access to (and probably won't ever get access to).

A workaround would be to maybe poke around in Robots brain to find strings using emotes and clean them out if robot lacks access, and then configuring an expression to avoid learning the emotes based on prefixes, but I think the filter isn't for words and the entire message, so that might limit learning capabilities

Feel free to close this if it's not worth investing resources into though.