A handler to handle handlers. General example:

class Handlers(object):
    def __init__(self, *handlers):
        self.handlers = handlers

    def handle(self, event, packet):
        for handler in self.handlers:
            if hasattr(handler, "on_" + event):
                try:
                    response = getattr(handler, "on_" + event)(packet)
                except Exception:
                    print("Error!")

                if response is NotImplementedError:
                    break
                yield response

Packet to be used when a the content of a message changes.

The maximum length for Discord messages is 2,000 characters. If the response is too long, the bot should split up the message and send individually.

Some commands should be specific to services. For example, a service may not offer an API endpoint that another service does.

Command behaviors may have to be customized for each service, as well. Continuing with the previous example, two services may have API endpoints for retrieving specific information, but the endpoints would be different. We would need different behaviors for each one.

Documentation explaining the service system.

Support for the Twitch platform.

TODO:

• Connecting to chat
• Reconnections (This is super annoying for some reason)
• Follow alerts
• Host alerts
• Sub alerts

Commands are currently separated into main commands and subcommands. This makes implementations for main commands without subcommands (!cactus) difficult and ugly.

Using a "recursive" system, embedding commands inside of other commands, we could allow for theoretically infinite subcommands in magic commands, while making defaults cleaner, as well.

While it's not extremely useful to have a bot that runs commands accessible through Twitter, it would be really cool to be able to use the handler system for other purposes. Cross-service actions could occur, as well, including Tweeting via a command or on specific events and thanking users in chat for Tweeting.

Class designed to load and dynamically update configuration values.

Initially loads all configuration values from the API, and dynamically updates via Sepal.

One instance can be passed around and used throughout the bot. This way, all code related to config can be written once, in an organized fashion.

Replace MessagePacket.message values with namedtuples, rather than dicts.

Minor change for syntactic sugar.

In [1]: from collections import namedtuple

In [2]: MessageComponent = namedtuple("Component", ("type", "data", "text"))

In [3]: cactus = MessageComponent("emoji", "🌵", ":cactus")

In [4]: cactus.data
Out[4]: '🌵'

Chat announcements for when specific statistics are reached. For example, an announcement for when the streamer reaches 200 followers.

Goals should be customizable, and messages should be (optionally), too. We should have a basic algorithm for determining "goal-like numbers" - 10, 50, 100, 200, 500, 1000, etc.

We need a standard for defining emoticons in MessagePackets (#43).

For Unicode emoticons, we should follow emoji-alpha-codes. So, 😛 should be saved with the data :stuck_out_tongue:.

However, there are lots of emoticons which do not appear in Unicode. (For example, :mappa/Kappa.) What do we do in this case? Also, because we can only use each name once, where do we store the list of used names? (Preferably with descriptions of what each means.)

Our current uptime command only counts in hours and minutes. We should make this support days / weeks

print_cactus seems to like to put lots of things on the same line.

,""',
;' ; ;,',;
;' ; ,,, ;,',;
;,; ;' ; ,',
;,'; ;,',; ;,' ; ------ /------\ ------ -------- | | -----
;',; ; ' ; ;''; | | | | | | | ;'','' ,',',; | | | | | | | ---- '''; ', ;'' | |------| | | | | |
;' '; ------ | | ------ | --------- -----/ ; ' ;
;' '; ; ' ;
; ',';
;,' ';

Made by: Innectic, 2Cubed(2CubedTech), and ParadigmShift3d
`

Having the ability to have CactusBot receive notification of new releases (via GitHub webhooks or Sepal) and then having it download the new code seamlessly update itself would be very useful.

It would mainly be for patch releases, bug fixes and minor changes (example: x.x.0 -> x.x.1), but possibly for minor releases (x.2 -> x.3).

Documentation explaining the Packet system.

Simple handler that logs packets to different debug levels.

• Simplified text (Hello! :)) to INFO
• Full packet to DEBUG

Documentation explaining the magic Command system.

• updating the count
• enabling/disabling

Streamers have requested the ability to add custom services for !social. For example:

!social
Twitter: twitter.com/2CubedTech, GitHub: github.com/2Cubed

!social github
github.com/2Cubed

This makes sense, because we want to become service-agnostic, and our !social system currently depends on Beam.

Minecraft support (feature request)

Adding Minecraft support to CactusBot would allow for more platform diversity, and could allow for statuses/roles to be synchronized and messages to be sent across all services.

Summary (via plugin)

Using a plugin would be the preferred option. This would allow for more direct access to the server and its events/messages. As most streamers running Minecraft servers will have a modded (Spigot or compatible) server, this will, in most cases, be a reasonable requirement.

Summary (via Minecraft protocol)

In cases where a modded server is not possible or desired, it could be possible to have CactusBot authenticate with a Minecraft account and control the server/read events and messages this way. This would require using the Minecraft protocol (as seen in this Apache-licensed library). The client should be put into Spectator mode after connecting, and to reduce server load, should remain in the spawn chunks.

Features

• Role/whitelist management via Subscribe or command
• Announcement synchronization (stream/subscription notifications)
• Kick/ban synchronization
• Private Messaging across platforms
• ...and more!

Documentation explaining the Handler system.

Should we move the Beam connection (BeamAPI, BeamChat, BeamConstellation) to an external package?

A class for all handlers to inherit from. Uses on_ methods for event handling.

In v0.3-, adding !x-y could also be called as !x y. Should we implement this for v0.4+ (with the API), or remove the feature entirely?

Move existing command handling to a custom Handler.

• Magic Commands
• Custom Commands

Repeats must be stored in the API, and Sepal should distribute the events announcing that the message should be sent in chat.

Support for Discord as a service.

https://docs.python.org/3/library/logging.html
https://docs.python.org/3/howto/logging.html

Minimum magic command role requirements.

@Command.command(role=50)
async def moderator(self, *, packet: "packet"):
    return "{packet.user} is a moderator!".format(packet)

When sent a KeyboardInterrupt, the bot should gracefully close all websockets and display a shutdown message, rather than spewing out all sorts of asyncio error nonsense.

It would be nice to have a timer that will not allow non-friend users (or non-mod users) to use a command until X seconds later

Example:

<mod> !command cooldown 60
<bot> Commands have a cooldown of 60 seconds
<user1> !hugs
<bot> Hugs for all!
<user1> !hugs
<bot> /whisper user1 55 more seconds until a command can be used again (<-- 55 and 52 is current time)
<user2> !hugs
<bot> /whisper user2 52 more seconds until a command can be used again
<mod> !hugs            (<--- mods can break the cooldown rule)
<bot> Hugs for all!

Sorry if you don't like the format of this recommendation. :P

Rewrite of v0.3's spam handling, put into a Handler.

• URL Detection
• Capitalization Detection
• Emote Detection
• Length Detection

Features:

URL Detection

We can use Beam's url type. It's generated using an advanced NodeJS library, with the sole purpose of recognizing links. Should catch everything.

It might also be cool to add toggling of specific domains - for example, allow all youtube.com links. We could do this fairly easily using Python's urllib parsers.

Capitalization Detection

We should use a better formula than "total caps greater than x" this time. Maybe check if the ratio of capitals to total (or better yet, capitals to lowercase?) is above a specific threshold? We should keep some total length threshold, though, so HI! isn't considered spam ("100% caps").

Emote Detection

We should do something similar to the method described in Capitalization Detection, where it compares the emotes to ratios, as well. We should also consider forcing it to be more lenient with sub emotes, so that a raid which uses a bunch of the raider's emotes doesn't get removed. (It's happened.)

Length Detection

We should remove this. It's confusing to have a different length limit than Beam's 360 character one.

We need unit tests.

Slack service! Allows the bot to run in Slack.

Where should the code for magic commands reside?

• In the bot itself?
• Behind the API?

We should auto-generate a set of commands which would be helpful to streamers.

(For example, !raid.)

Which commands would be helpful?

We need a standard mapping which defines what numerical role levels mean, qualitatively. The scale for role levels is 0-100.

Should include:

• Channel Owner
• Service Staff
• Global Moderator
• Moderator
• Channel Subscriber
• Service Subscriber
• Standard User
• Banned User

This is something I planned on adding for PyBot and would be soooooo useful.

Redis should be caching events (follow, join, leave, etc.), rather than in-bot JSON files.

When the bot sends messages, its handlers receive them afterwards. This makes the bot vulnerable to cyclic command responses (!a -> !b, !b -> !a), responding to itself for "spamming" (!cactus twitter, Please do not post links., etc.), and so on.

We've always had basic targets like %ARGS%, but it would be super cool to expand upon this using "angularish" filters. Example: convert the args to upper using: %ARGS | upper%

Responses for events (follow, subscribe, host) are hardcoded, and therefore not configurable. This should not be the case.

BeamParser will parse incoming data from Beam to a standard packet format (#43).

Custom-added commands could respond to the user who ran the command through a targeted message (whisper/DM).

Can run a command or send a message after a certain period of time, or on a certain date.

!schedule 15m run giveaway
I'll remind you in 15 minutes to "run giveaway".

!schedule 15m !potato
Running the !potato command in 15 minutes.

Syntax currently unknown.

We need a packet format, with support for:

• raw text
• emotes
• usernames

• Minimum Chat Message Spacing
• Only While Stream is Live

Aliases for commands! Similar to Bash aliases.

Currently, magic commands are based entirely around raw strings, which defeats the purpose of the typed MessagePackets in some sense. Magic commands should be able to use MessagePackets for added functionalities. (Emoji detection, tag usage, etc.)