lewster32 / corporallancot Goto Github PK

This would be specifically for Twitch.

As the bot is hosted on a persistent server, and for Twitch streams, certain messages may need to be forwarded to the streamer, it would make sense to allow messages to be sent to an exposed message queue that can be subscribed to one way or another.

This might not be a separate handler, instead, it may be a feature of any particular handler; for example:

• The streamer runs a local client while they are streaming that subscribes to a message broker. The client handles various messages in different formats
• The bot receives a !bang command
• The bot forwards a message to the message broker
• The message broker publishes the message, which is made available to all subscribers (i.e. the twitch streamer)
• An action subsequently happens on stream; an image changes, a sound or animation plays, VSCode theme changes etc. This depending on the message received and the implementation.

It may be suitable to make the local client scriptable - i.e. allow the streamer to control what actions take place when a command is received. This might take some work, though.

console.log needs to be abstracted and replaced with a logging class. I have already done this and it will be in my next PR:

'use strict';

module.exports = class Logger {
  constructor() {
  }

  async log(message, params) {
    if (params) {
      console.log(message, params);
    } else {
      console.log(message);
    }
  }
}

This is injected into all of the services and classes with Awilix.

However, as you can see the logging class still logs to console.log at present - this needs to be replaced with something like Winston with rolling log expiry. This can be done once the IoC / DI has been PR'd.

This is not a public issue, but one related to https://github.com/lewster32/corporallancot/milestone/1. We need to write an ETL script that transforms the old SQS IRC notes into a script that can be deployed to the MariaDB.

I may push this script to a gist so as to not pollute this repo with project specific code.

It's becoming increasingly difficult to dev / work with the many classes and tests in pure JS.

Let's convert the project to TypeScript to save a lot of dev time.

Log when an action is performed. Maybe the complete note, maybe just the command and user that requested the logging.

Will be relatively straightforward once the IoC is done.

Add twitch chat support

Would be pretty easy to set up a GitHub action CI process for this to confirm changes have not broken anything, especially when the new unit tests in #2 are in place.

CD is unfortunately not going to be possible with GitHub actions as using the runner for a public repo poses a considerable security risk on the digital ocean box.

The idea behind this one is that administrators / owners can register a new (non-reserved) action that simply responds with a message, for example a user typing !github into chat would have the bot respond with "Our github is located at ".

I think we should be able to do this with a single action, not sure how yet, just an idea atm!

The database code needs to be abstracted from the rest of the application.

I am currently working on this as part of the IoC / DI / Testing PR I'm creating.

Related to #10.

With the server abstraction, we could make this bot a multi-server bot by allowing it to connect to multiple servers at once.

If this functionality was included, it would also be sensible to make sure that Actions can be turned on or off on a server-by-server basis. For example !notes might be available in Discord, but not in Twitch. !meow might play a cat meow live on Twitch, but would make no sense in Discord.

It was removed due to a cyclic dependency on itself. We need to figure out a way to handle the listing of all action help messages better.

This will allow the bot to be improved in a generic fashion, each action could be toggled via the config file.

At present, Lancot responds to commands with @UserName, <Message>. It's a small thing, but I think the comma is unnecessary, but I also recall a conversation @lewster32 and I had about the bot responding in different ways.

I've opened this issue to discuss and document ways this should be handled in the future.

Currently, the DB abstraction exists in a single class. Ideally this needs to be further abstracted into separate classes on an action-by-action basis.

Slack server support

We need to abstract Discord into an adapter so it can be easily replaced with other services that use bots, such as Twitch, IRC(!) etc.

I appreciate it's been kept for historical reasons, but !note would make more sense as the action invoker...

Currently the config file represents a flat list of key/value pairs, however now that config for each component/service has been abstracted away into individual classes, we can make this cleaner and specify individual structs for each configurable component/service. This would change the config from something like this:

{
  "key": "<DISCORD_BOT_TOKEN>",
  "db": "notes",
  "dbTable": "notes",
   ...
}

... to something like this:

{
  "discord": {
    "key": "<DISCORD_BOT_TOKEN>"
  },
  "database": {
    "db": "notes",
    "table": "notes",
    ...
  }
}

Started work on this - using https://github.com/jeffijoe/awilix as it seems to be the most popular and feature rich IoC container for Node.js.

I'll be implementing unit tests for new pieces of code, and unit tests for older pieces of code where pragmatic for now, but will continue to improve the coverage over time.

This will result in a considerable amount of refactoring - especially around the existing constructor dependency injection.

I'll create a PR draft linked to my changes so we can monitor any conflicts.

When streaming to multiple platforms, it'd be great to be able to consolidate chat logs into a single place. We can do this easily with a new chat handler that just simply listens and redirects output to another location for those platforms / servers it is enabled for. This relies upon #11 to be completed first.

Definitely not Corporal Lancot's initial use-case, but absolutely useful for multi-platform streamers. If you'd prefer me to fork and work on this kind of thing separately, happy to do so, but I think it'd be cool to turn this bot into a multi-purpose chatbot that can do a fair few things.

This might require some kind of UI - can be simple to start with, but we could change this to incorporate changing config settings etc.

IRC Server support

We can get docker to automatically run scripts (such as the SQL script generated by the ETL script we are writing for #12) when a container is first instantiated.

This can also be used to set up the "notes" table by default, though I'm not sure if we'd want to do that as the "notes" table is action specific (the !notes and !quote actions rely on it). Considering this, I think we should move the table creation into a dependency of BOTH the !notes and !quote action. This should be considered when #9 is tackled.

What do you think @lewster32? Is the auto-execution of SQL scripts actually needed here? The SQL setup script is actually a one-off, specifically for our needs in the SQS Discord channel, and not something that most people who use this bot would need.

Include a feature that allows the bot administrator to limit the rate of messages on a global or action-by-action message.