JSON isn't so great, but configuration is necessary. TOML looks nice, and the htoml library implements it.

Furthermore, configuration should be read-only, unlike the current yukibot, where configuration is rewritten on quit. This is bad because unexpected termination can mess up the config.

The actual configuration may change during execution, due to (eg) #39. There should be a way to dump the actual configuration to a new file, so allow for hand-merging if desired.

yukibot currently just dumps everything to stdout, which is sort of fine if you only have a single backend. But with multiple backends, multiple logs are really needed.

The logging has to be done at the backend level, as the bot gets a higher-level view, so bot-level logging would be useless for debugging.

Would be nice to be able to store keys/values on a per-channel basis, print out all the stored keys, and retrieve a value by key.

Both simple (eg, !roll XdY) and complex (eg, !roll (UdV)dW + XdY + Z)

Using pusher-ws. See #33.

Steal mispy's ebooks bot text generator, it works well with Twitter and so would probably also work well with IRC (perhaps filtering out messages below a certain length).

https://mispy.me/the-mysterious-nature-of-bots/

Having to recompile the bot to add commands and event handlers isn't great, the config should specify which ones to use.

What yukibot has currently, but backend-agnostic.

Plugins should be able to be enabled or disabled on a per-channel bases: both the plugin as a whole, and on an individual event-handler level.

Using slack-api. See #33.

Youtube retired their old API in favour of a new one, https://developers.google.com/youtube/v3/

Currently mutable state is serialised in the configuration file on termination, this has a couple of issues:

• The configuration file blows up, especially when keeping track of things for the seen command
• If serialisation fails for some reason, everything is lost as the file gets completely rewritten.

Both issues could be solved by having a small database. Just a key-value store namespaced by plugin would suffice. Furthermore, by separating configuration from state, much of the serialisation stuff can be dropped, and the configuration file can be read-only. If more rich serialisation is required than key-value, the existing Aeson instances for everything can be re-used when reading/writing to the database.

LinkInfo allows for arbitrary extensions. In particular, the ImgurLinks plugin uses this to provide titles for image URLs. It'd be nice for Youtube links to include things like title, length, up/down votes.

Upon parsing a command, example "!make vote", and giving comma(?) seperated parameters:
!make vote 1,2,3,4,5
Yukibot then accepts votes in the form of "!vote 1" or !vote 3" etc.
After a period (60s?) Yukibot prints the results.

These should be considered high-priority as they actually get used:

• link info
• mueval (with type/kind)
• seen
• trigger

While configuration should be read-only, there is a use for read-write state. Currently mongodb is used, which is very convenient as it doesn't require a schema. Only the other hand, the actual data format used in a few places is pretty rigid: tagged and timestamped strings. Furthermore, mongodb requires a separate database server.

It would be nice to not need a separate database server and, given the in-practice rigidity of the schema, perhaps something like sqlite would be good enough.

Really, there's very little that's actually IRC-specific in an IRC bot. There's the backend, and that's it. The rest of the bot (can be) almost totally oblivious to what the backend actually is, as long as it's kind of IRC-like.

Come up with an abstraction for backends which:

• Are message-oriented
• Have a notion of channels
• Are read/write

The job of a concrete backend implementation would be:

• To transform incoming messages into a form the bot can deal with, and pass them along.
• To transform outgoing messages into a form the backend can deal with, and pass them along.
• To automatically handle control messages (pings, etc).
• To detect and resolve failures (disconnects).
• To facilitate joining and leaving channels.

To most easily support different types of backend, the only configuration should be some sort of connection dictionary.

Furthermore, it should be possible for multiple backends to be executing simultaneously.

There is currently a download function for things-as-ByteStrings, and a wrapper around that for things-as-Strings. It'd be kinda nice if helpers for:

• JSON (Aeson Value type)
• RSS / Atom (some appropriate feed library type)
• XML (HXT)

existed.

Using irc-client. See #33.

Similar to Youtube LinkInfo really: title, uploader, length, 'likes' (or whatever soundcloud calls them)

Now that yukibot is lurking in #hacksoc-committee, optional logging would be really useful.

Currently Yukibot returns "HYPE HYPE HYPE" when the single word "hype" is parsed.
It would be an improvement if Yukibot responded to mention of the word 'hype' within a sentence.

If time permits it may be worth sanity checking for negatives preceding 'hype' e.g. "not", "not very", "anti" ...

These would be used if present:

• topic
• debt tracker -- use hledger for this?

This is kinda cheating as I already have it mostly-written anyway, but... there should be something like lambdabot's evaluation!

The API looks simple enough: https://discordapp.com/developers/docs/intro

To ping all channel mods.

Some brainfuck programs were written with an implementation that uses 8-bit cells specifically in mind, and no not work with one that has unbounded cells, as is the case with yukibot's.

A common prefix for this in bots is "bf8"

Something doing the nix-build/nix-shell + tmux + sourcing the NIX_GHC_LIBDIR path + nix-store --gc automatically.

Currently, triggers work by exact message matching (modulo case). Furthermore, there is no way to modify the trigger list during runtime, or to respond with anything other than a fixed string.

Suggestions:

• Tags which get replaced with metadata, eg %nick, %channel
• Respond with an ACTION.
• Regex triggers.
• Command to add triggers.
• Command to remove triggers.

This subsumes issue #1.

Should watch RSS/Atom feeds and announce new entries to the channel.

irc-client has the ability to ignore events based on nick of sender, but this functionality isn't exposed anywhere.

There could be an ignore plugin, providing a helper function to connect to a network and load the ignore list, and a command to modify the list.

👍

Privileged users should be able to tell yukibot to:

• join a channel,
• leave a channel,
• send a message to a specified (backend,channel) pair,
• disconnect from a backend
• connect to a new backend.

This requires some way of assigning privilege to users. Given that the current permission system is overkill for its actual use-case, perhaps just specifying the username of the administrator in the backend configuration dictionary is sufficient.

A plugin providing access to a BF Joust hill would be nice, similar to zemhill.

I believe we can use gearlanced https://github.com/fis/chainlance quite nicely, although if it existed as a library that'd also be good.

We'll also want to have some sort of web leaderboard display, too. Not quite sure how to go about that.

There should be more broken stuff. Please break something.