voytechnology / cheapskate

Universal Bot

VoyTechnology

Repository with my personal site

cheapskate's Issues

plugin: Fix 'Missing argument for Fatalf("%s"): format reads arg 3, have only 2 args' issue in plugins\plugins.go

CodeFactor found an issue: Missing argument for Fatalf("%s"): format reads arg 3, have only 2 args

It's currently on:
plugins\plugins.go:125
Commit dce0327

plugin: Add Telegram integration

core: Define v0.1.0 plugin interface

I am not sure is the current plugin interface the best that could be. I feel like there is a way to simplify it somehow. Perhaps we should copy the approach of things like Gin HTTP Framework with Middleware.

We can also take a look at Terraform Providers.

Either way, I am not too happy with it, and would definatelly need an improvement. Python decorators would be nice but (un)fortunately are not available in Go.

plugin: clap chaining creates continous claps

/clap /clap CLAP IN BETWEEN generates CLAP 👏 👏 👏 IN 👏 👏 👏 BETWEEN. This should be somehow stopped with only one 👏 being created between words.

core: Plugin configuration

Right now none of the plugins require configuration, but it will change soon, as things such as Facebook or Github would definitely need API keys to work.

I guess the easiest way to configure it would be to have plugins.config.<name>.*, where <name> is the name of the plugin. This way on plugin creation we can call Configure(config map[string]interface{}) where the the passed in data would correspond to *.

eg.

cheapskate.toml

plugins:
  config:
    facebook:
      email: _________@______
      password: ____________

and Config passed into the plugin would only have the fieldsemail and password available.

This is a meh security measure, as all plugins still have access to settings package which contains all the values.

plugin: Add facebook integration

Facebook is one of the primary integration platforms.

It should listen for the webhooks and then send back a response whenever there is a response.

core: Add plugin chaining

Currently the plugin system is rather limited with how it can handle responses. Essentially currently the flow goes like this:

integration -> Action(Origin: integration: Data: /uppercase /clap clap between every single word)
    v
AddAction
    v
uppercase -> Action(Origin: cmd/regex, Target: integration, Data: /CLAP CLAP BETWEEN EVERY SINGLE WORD)
    v
AddAction (Target is set, go directly to target)
    v
integration

This means that if the resulting data from command or regex is only intended for integration. I guess an option is to have Action as a linked list (see note), and once there is nothing else to do, the Action with the final data would be passed back to integration. Not sure how that will look as a flow tho.

Other way is simply to ignore the target in most cases, and return when there is nothing to be done.

Essentially turning the flow into:

integration -> Action(Origin: integration, Data: /uppercase /clap clap between every single word)
    v
AddAction
    v
uppercase -> Action(Origin: integration, Data: /CLAP CLAP BETWEEN EVERY SINGLE WORD)
    v
AddAction
    v
clap -> Action(Origin: integration: Data: CLAP 👏 BETWEEN 👏 EVERY 👏 SINGLE 👏 WORD)
   v
AddAction (nothing else to be done, go back to integration
   v
integration

I guess the problem is that we loose insight into what plugin handled the action, but this can be somewhat mitigated via good logging

Linked List Note: hah, college is actually useful sometimes. This is the first time I actually see a need for doubly linked list (I think)

core: Use proper HTTP mux

Right now we take a dummy approach to how the hooks are registered. We should consider the hook structure, and how the plugins can be bound. For example, Prometheus might use /metrics, so we cannot allow that to be bounded, but I am not sure is prometheus as a plugin such a good idea, I feel like it should be in the core of the project.

This means we should potentially be limiting the binding space for the integration plugins to something like /plugins/<registered-path>, this clears the root (/) to more core stuff.

plugin: Port steely plugins

All plugins from steely must be ported to cheapskate. Please mark this issue when adding PRs with steely plugins.

• Angry (improvement needed)
• Append
• b
• basic_interpreter
• beer
• box
• btc
• bubble
• bug
• bus
• ca
• cage
• cat
• choose
• clap (#8, Needs improvement for chained/clap /clap - #12)
• coinflip
• cowsay
• dab
• deepdream
• define
• dog
• egypt
• eight
• flip
• flirty
• geoip
• gex
• github
• goth
• haiku
• happy
• help
• imgur
• jokes
• lastfm
• leet
• lenny
• limp
• linden
• markov
• mayo
• middle
• mock
• nose
• numberwang
• obscene
• owo
• parrot
• paul
• prod
• recordmarkov
• recordstat
• reload
• responder
• restart
• roll
• roomcheck
• rpn
• rune
• scramble
• search
• sentiment
• sheriff
• shout
• skrrrt
• slag
• snoop
• sort
• stats
• streets
• stretch
• tilda
• tm
• tracker
• train
• translate
• urban
• url
• vapor
• vowel
• wednesday
• xkcd

(my god. there is a lot of them.)

core: Add plugin panic recovery

In case a plugin panics, we should not kill the entire bot, but gracefully recover. We can perhaps state that a plugin has panicked, and ping the admin of the bot. In case of core panic we should gracefully stop, ideally also pinging maintainers, or creating a github issue with failure details.

core: Add HTTPS hooks

We should be using HTTPS for the webhooks as many sites don't accept non-https hook endpoints (and we care about security)

core: Add support for ENV VAR settings

All the settings should be set using ENV VARS. The code in the settings package already has the basic code, but for some reason it doesn't work. Investigate and fix why it doesn't work.

core: Plugin loading method

Currently all the available plugins are in the plugins directory, but as shown by Steely, with 80+ plugins it can become a bit annoying.

There are several approaches that can be taken to make sure we have easier time with cheapskate and plugins:

1. Remain in repo - This approach pretty much means we don't do anything, we just have the plugin there, and improve it like any other file. This has the benefit of deploying all the plugins with the main system, eliminating the need of additional build steps.

2. Use Hashicorp's go-plugin - It looks like a pretty nice solution, and would allow to write plugins in other languages because it just uses gRPC, but every single plugin would be its own binary, making deployment that much more difficult, but at least all the plugins would be found in the single configurable plugin.location setting

3. Serve plugins as separate services - This is probably the worst idea, as it would mean that each plugin would become its own separate bot, and cheapskate would only serve as proxy and adapter (converting from integration to cheapskate message format that would be served to all plugins). In a way, its pretty similar to idea 2, but we would accept plugin registration using HTTP interface and then the message would be send to the plugin and returned. It would be pretty difficult to manage.