Re-build PlusPlus (Slack Bot)


Status: active
Help accepted: yes
Tech stack: Go, HTTP, JSON, Docker, Slack

PlusPlus is Slack bot that provides a friendly way to recognise people who have been particularly helpful during a Slack conversation. By mentioning the user and following their name with ++ you allocate them PlusPlus points, e.g. @Bill++.

Over the last couple of months the reliability of the bot has degraded with the occasional delay and unavailability of the bot. Someone asked whether we should build our own. Curious, I thought I’d give this a go (no pun intended).

This is still in very early development and while I have a simple proof of concept working, my current efforts are geared towards understanding the Slack API.

Note: for the avoidance of doubt, this is a personal project and not intended to replace any aspect of the Codebuddies set-up.



I was hoping you would use Node for this. Considering the tech stacks, it would be difficult to have someone interested in this. Of course, this is entirely my opinion and no way demeaning. I’m just gutted you aren’t using Node + Express :disappointed:


I’m assuming you are referring to the existing Codebuddies greetbot project. You raise a very valid point that I failed to make clear in my description of this project. This is a personal project and not intended to replace any aspect of the Codebuddies stack. If it turns out to be a success and we’d like to use it on Codebuddies then I’d be more than happy to support this. That isn’t the primary goal here. I have updated the original description with the following note.

As for interest, you’d be surprised. I’ve had conversations with three individuals about this project so far. Not all of them are using Go but that doesn’t seem to be a barrier to interest, quite the opposite. As this is a personal project, I’m planning to work on this irrespective of external interest. For me, it is an opportunity to learn. That said, external interest is always a great motivator.

Given the challenge “re-build PlusPlus”, is there any particular reason you would recommend choosing Node + Express over my choice of Go? I’m genuinely curious. One key reason could be the abundance of Node Slack bots that can be used as reference implementations, but beyond that I’m not seeing anything that would compel me to pick Node + Express.

If you are really keen, I’d be more than happy if you started a parallel project to implement this in Node + Express. It might make for a great hangout to compare the approaches and talk about the merits and pitfalls of each. Please let me know if you do.


For now, I’m not sure I will be able to handle building a bit from scratch. My goal at the moment is to learn enough to contribute more to the CodeBuddies Greetbot and clear up the issues. Hopefully, pick enough experience to try building something like ++ :slight_smile:


I made a little progress on this project this morning and I’m now responding to the Slack API within the timeout. I’m not sure that I’ve structured the code in the most readable fashion just yet but it works.

Next up:

  • #2 Identify the user ID of the bot - I need to do this in order to prevent the bot responding to itself
  • #3 Untangle the different Slack message types and decide how to handle edited or deleted messages

Background thought:

  • Decide where/how to store the score board - this could be as simple as key:value pairs
  • Decide how to host the bot - as a series of AWS Lambda functions or in a Docker container

I’d welcome any thoughts or considerations on these last two as my current thinking is a little vague.


That’s a commendable goal, @peoray. :slight_smile: I bet you could learn a lot from looking at Bill’s implementation too (or if he ever decided to do a hangout walkthrough of the code he wrote), even if you’re more of a NodeJS than a Go person right now. Perhaps looking at the Go implementation might help you better understand how you could write it from scratch using Node, for example. And then we could have that comparison hangout Bill suggested. :stuck_out_tongue:

I don’t know too much about AWS Lambda functions or hosting using a Docker container, but I wonder if Glitch could be a viable sandbox option? I know it’s been used before to host sample Slack apps in Node, like And from some cursory research, it looks like Glitch supports go-lang apps too.

I think it’s very cool that you’ve decided to play with this idea! One of CB’s goals really is to support personal projects created by members of the community, and if this gets to a point that we replace PlusPlus with it, how awesome would that be. That’s how Greetbot got started, too; we were using a third-party plugin that wasn’t great and broke, and @bethanyg took it upon herself to make her own open-sourced implementation. She decided she wanted the repo to be hosted under, but at the end of the day it’s still her --and the other core contributors’ – project.

That makes sense.


A general note: if an app that the community ends up using heavily (like Greetbot, which is served on a DigitalOcean droplet) does end up incurring some hosting fees, we definitely have a bit of funding at to support those costs at least. Not sure how expensive AWS lambda etc is.


A quick update on progress this morning:

I’m now able to detect both positive and negative scores and respond to the thread with an indication of how the score will change. Two new issues added to the backlog:

  • #4 Mentions of ++ or -- in a thread break the threading model
  • #5 Keep a running total of user scores


A quick update on progress today:

I’m now able to store user scores in an embedded key:value store. If running inside the Docker container you’ll lose the scores when the container exits. All data is stored in a single file so backups should be fairly easy to implement.


I’ve been thinking about the best way to host this and have decided to use AWS Lambda (for now). My reasoning being that I can largely keep various features as separate deployable functions, but the predominant reason is that this appears to be the most cost effective way to host the project.

Slack makes API calls to endpoints on the AWS gateway. These are handled by various lambda functions. Minimal use of the database is required to maintain a leaderboard.

It may be necessary to decouple the initial inbound request handler from the functions that perform any work. This is to ensure that I can respond to the Slack API request within the timeout. I’m hoping to avoid this as it adds complexity.


I’ve made some good progress on this project and now have a proof of concept in place for most of the working parts. These include:

  • mention the bot to ++ a user
  • a database to store a cumulative score
  • posting messages to let users know they’ve received a ++
  • flagging messages for admin attention
  • notifying admins there is a flagged message
  • letting users know their messages have been flagged
  • enabling the bot for multiple slack workspaces

These are some of the areas that I have neglected:

  • a homepage for the bot (HTML, CSS)
  • success/error screens for registration (HTML, CSS)
  • an icon
  • tests (go)
  • performance (AWS SQS)

I’m continuing to chip away at this but if anyone is interested in tackling any of these challenges let me know. I’d be more than willing to help identify something that you felt comfortable working on.


This is an example of how messages get flagged to the admin channel.

There are a couple of obvious challenges here:

  • User who flagged the message is shown as an ID rather than name
  • Author and channel are both shown as IDs rather than name
  • There is no link to the message


I’ve been toying with the idea of moving away from AWS Serverless back to a single Docker container for the bot. The idea is primarily to make it easier for others to contribute. I’ve raised an issue for discussion here:

I’m currently leaning towards jumping in and making the switch. Convince me otherwise :slight_smile: