5ht2 / taro-bot Goto Github PK

Waiting for #28

I plan to add a TTS command that uses Google's API for it, I'm just leaving a list of the resources I had open for later.

I'm currently blocked in terms of testing the code so far because a phone number is required to sign up, which I can solve later.

• https://pkg.go.dev/cloud.google.com/go/texttospeech/apiv1
• https://pkg.go.dev/google.golang.org/genproto/googleapis/cloud/texttospeech/v1#SynthesizeSpeechResponse
• https://cloud.google.com/text-to-speech/#section-2
• https://github.com/bwmarrin/dgvoice/blob/master/examples/play/main.go
• https://github.com/diamondburned/arikawa/tree/v3/voice
• https://discord.com/developers/docs/topics/voice-connections#speaking
• https://github.com/GoogleCloudPlatform/golang-samples/blob/main/texttospeech/list_voices/list_voices.go
• https://cloud.google.com/docs/authentication/production

• a channel to vote on prompts with

Blocked by #12

See https://stackoverflow.com/a/41630530 and https://stackoverflow.com/a/41630530

Maybe have a list of all commands, and have a command to get more info about a command, including it's plugin info.

I started on this but can't be bothered to finish now given how big the codebase is atm

Currently, it just tries to load a plugin-name/plugin-version.json file. If the plugin bumps versions, this will not port the config over.

This should also .(config) if possible.

This could be done in two ways:

1. Register a json file for each plugin alongside the config.json (this would need to explicitly disallow naming your plugin "config" and/or throw an error if multiple plugins have the same name)

• Pros:
  Allows for keeping multiple versions easily (i.e., with plugin versions). Maybe have a compatibleVersions field plugins can check to keep configs backwards compatible.
• Cons:
  Multiple files. Takes a tiny bit of extra work to do.

2. Register a new entry in the existing config with a map.

• Pros:
  Easy to do.
• Cons:
  Look at 1.'s pros section.

It is now in the starboardconfig command, in it's own plugin

Re: https://canary.discord.com/channels/543908157165142037/543908157794156584/983811734106165248

This shouldn't be possible, plugin loading should be safe. A plugin will be skipped if it fails to compile currently, but that's it.

We don't want plugin loading to be un-safe because plugins will be loaded during runtime dynamically (#8) in the future, and not just during bot loading.

This should be fixed ASAP.

Now that Go 1.18 has been released, it's fixed my previous issues with mutexes in maps. This means I can get rid of the for loop in GuildContext (which is used everywhere).

• #11
• Allow registering a custom handler for c.AddHandler
• Move Starboard to a plugin
  • Separate channel starboard commands into it's own command
• Move Topics to a plugin
  • Separate channel topic commands into it's own command
• Move responseutil somewhere else

• Re-add the ability to respond with a simple embed or title object.
• Ability to configure each property of a ResponseInfo.
• Setting the fn would require func(Response) functions to already be loaded (maybe via a plugin), but is still handy.
• A command to configure per-guild responses

See: https://github.com/5HT2/taro-bot/tree/impr/guild-response-39

Get the top starboarded posts for the current guild

Depends on #8

When a command is executed

• Add it's message ID to a cache, and it's response ID to a cache, as well as the epoch milli when it was executed
  • Everything is supposed to return a message ID but not always - maybe allow -1 as a default to skip?
• Have an edit message register to check for caches
• After 30 seconds, remove from the cache on a timer. Should this be locked on a mutex? I don't want to block commands but checking a map for an entry is fast.
• I feel like executing a command should also force a 30 second check

• Storing enabled / disabled state
• Per-server plugin configuration (eg, should this plugin only be enabled for set servers)
• Servers should be able to enable / disable plugins for themselves (see #16)
• A config value for which plugins to load by default, that the user can configure

Easy fix oops

2022/10/17 04:05:59 HasAdminCached: found 995142503391047770
2022/10/17 04:06:12 panic: goroutine 76807 [running]:
runtime/debug.Stack()
	/usr/local/go/src/runtime/debug/stack.go:24 +0x68
github.com/5HT2/taro-bot/util.LogPanic()
	/taro-bot/util/builtin.go:20 +0x30
panic({0x991220, 0xe40bf0})
	/usr/local/go/src/runtime/panic.go:838 +0x20c
github.com/5HT2/taro-bot/cmd.UserHasPermission({0x4000eb9800, {0xffff6d8b6d5e, 0xb}, {0x4000a78254, 0x4}, {0x4000055370, 0x0, 0x1}}, 0x4, 0xdcf74d59784305a)
	/taro-bot/cmd/permissions.go:91 +0x58
github.com/5HT2/taro-bot/cmd.HasPermission({0x4000eb9800, {0xffff6d8b6d5e, 0xb}, {0x4000a78254, 0x4}, {0x4000055370, 0x0, 0x1}}, 0x4)
	/taro-bot/cmd/permissions.go:82 +0x154
github.com/5HT2/taro-bot/plugins/hrtgen.DoseCommand({0x4000eb9800, {0xffff6d8b6d5e, 0xb}, {0x4000a78254, 0x4}, {0x4000055370, 0x0, 0x1}})
	/taro-bot/plugins/hrtgen/hrtgen.go:57 +0x8c
github.com/5HT2/taro-bot/cmd.CommandHandlerWithCommand(0x4000eb9800, {0x4000a78254, 0x4}, {0x4000055370?, 0x0?, 0x1?})
	/taro-bot/cmd/util.go:47 +0x228
github.com/5HT2/taro-bot/cmd.CommandHandler(0x4000eb9800)
	/taro-bot/cmd/util.go:20 +0x94
created by main.main.func1
	/taro-bot/main.go:52 +0x64

2022/10/17 04:06:15 HasAdminCached: found 995142503391047770

• Only log config saving on bot shutdown
• Use Zap for logging
• Debug logging options

This should be more of a plugin feature, for example cmd.RegisterJob(plugin, jobInfo)

Just to prevent issues with larger traffic bots

See: https://github.com/deletescape/jobtracker

For example, if the user wants to do

.time 12h 30m thing
.time 12.5h thing

These should return the same time.Duration and "thing" without the developer checking manually.

https://github.com/uber-go/zap

They should edit the reactions

Blocked by: #8, #16, #24, #25, #35.

The way I want to accomplish this is:

• A plugin-name/meta.json file in it's source folder should contain
  • Plugin name
  • Source repo
  • Version
  • Updating URL
  • Current version

Version checking would check updating URL's version, and see if it's larger than ours (regex, format to int).

• Remove -plugindir and force them to a standard path, update docs accordingly

After initial plugin loading,

• Display a message in OPERATOR_CHANNEL and ping OPERATOR_ID if plugin updates are available, and if we want to reload them
• The plugin command should also show if updates are available

This is totally doable, my only concerns lie with the Docker version

• I want plugins to not be reliant on http-bash-requests (for obvious reasons).
• Calling os.Exec from Docker would theoretically work, but this poses new problems
  • The Dockerfile is mounting the config dir to /taro-files, which only contains the config folder
  • /taro-bot contains a copy of files in the image
  • We want to allow the mounted folder to be git pulled to allow easy updates, without fucking up user-level permissions when Docker is run as root

I propose mounting the entire directory taro is built from, and moving config there? Rather than keeping a second mount for config.
You're already intended to build taro yourself, as I don't provide prebuilt images, so keeping a copy of the git repo to allow plugin updates would be entirely optional but required for git pulling plugins.

Being able to

• List loaded plugins
• List all (available) plugins
• Manage reloading (#8)
• Manage downloading, potentially
• Show errors with reloading

A slight improvement to plugin loading:

• Being able to choose which plugins to load
• Default to a set list
• Being able to choose "all"

i would like if, e.g., ;help topic gave all possible invocations of the topic command along with what each one means