Thoughts on Bots

For the last few months--wait it's been more than a few now--for the last six months I've had some ideas bouncing around my head, particularly relating to chatbots. Some of these ideas have led me to start working on implementing a chatbot (specifically for Slack, in node) in my spare time. At this point I have little more than an API wrapper, but I've also been learning to use some of the new ES6 features, so even without a working chatbot I'm happy with what I've accomplished so far.

In any event, the primary idea is this: Chatbots are a command-line interface.

CLI has rebranded itself as "chatbot" so that average people can participate in what devs have been doing for years.

past me, just over a year ago

Everything you write to a chatbot can be seen as a command with arguments.

Because of this, actions can be scripted in the same way they would be for a regular CLI command.

Remind me to go grocery shopping at 5

is functionally equivalent to:

remind "go grocery shopping" 5:00PM

Another thought: Because chat channels are persistent, messages and replies can be replayed in a functional manner to produce equivalent output. This means that chatbot conversations can be managed as a form of functional programming. This also means that bots can handle outages gracefully by replaying any messages that were left unresolved.

Me: remind me to go grocery shopping
Bot: when would you like me to remind you?
-- bot disconnects --
Me: 5PM
-- bot later reconnects --
Bot: Ok, I've set a reminder for 5PM

There are some limitations there, of course. Messages come with an implicit timestamp, and other external state must also be managed (e.x. reading a file in the filesystem), but handling these cases in a functional manner has been solved by other people much smarter than I.


A Slack-specific thought: Slack recently introduced threadded messaging. While this was a nice-to-have feature for chat, for chatbots this is an incredible improvement. Now, every message to a chatbot can start its own unique thread so that multiple commands can be in varying degrees of completion simultaneously:

Me: remind me to go grocery shopping
  Bot: when would you like me to remind you?
  [_____]
Me: log time for design meeting
  Bot: which ticket would you like me to log time on?
  [_____]
Me: subscribe to birthday reminders
  Bot: I've subscribed you to the birthday reminders notification list.
       How many days in advance would you like a reminder?
  [_____]

Some thoughts on data-flow: A unidirectional data flow approach could be used to take a subset of state as a Model and pass it to the requisite Controller to generate a "View", which in the case of a chatbot is the response to a given model. That response can then trigger subsequent Actions, which could be Queued up in parity with the server so that State deltas can be optimistically applied. Once the new state is ready it can then be passed to the controllers and the entire cycle can continue.

I've blatantly stolen this idea from Lee Byron's talk, "Immutable User Interfaces".

This would allow for users to edit their messages and for bots to "correct" their response instead of generating a new reply.

An example of this could look like:

Me: remind me to go grocery shopping
Bot: when would you like me to remind you?
-- I edit message --
Me: remind me to go grocery shopping at 5PM
-- Bot edits message --
Bot: Ok, I've set a reminder for 5PM

with a result appearing as:

Me: remind me to go grocery shopping at 5PM
Bot: Ok, I've set a reminder for 5PM

I don't quite know where I'll take these ideas just yet, but so far it's been quite interesting.