Leading with "wonderful" confused me a little. I was expecting "X is a wonderful project. Here is a new project built on X." When introducing your own project, your subjective praise for it doesn't add as much. I would drop the "wonderful".

I think you make a good point. I removed that word from the description.

Interesting Project.

I'm sure you're aware of Errbot (https://github.com/errbotio/errbot), though not specifically designed with slack in mind: I have had excellent success with this framework.

How does slack-machine compare?

PS: Please forgive the naive question, I'm about the board a flight and don't see anything mentioned or anything radically different about the stated goals.

It's not a naive question at all! The 2 biggest differences I can see:

- Errbot being chat service agnostic, also makes it feel a bit "non-native" for Slack. For example, you cannot say "@mybot deploy webapp to production", but you have to say "!mybot deploy webapp to production". slack-machine can work that way as well (with command prefixes like ! or %), but it also responds to actual mentions (@mybot). There are more differences like that, where Errbot tries to be agnostic of the chat service it's running against, but that also means it has to cater to the lowest common denominator in terms of integration with a chat service. slack-machine can for example add "reactions" to messages, which Errbot cannot.

- slack-machine seems more feature-rich. Errbot seems to be focused only on commands that are triggered by sending certain chat messages. slack-machine lets you listen to any type of event Slack emits. Examples could be: someone joins a channel, a reaction is added to a message, a message is pinned. slack-machine also has built-in scheduling to trigger plugin functions on a cron-like schedule (Errbot has something similar with pollers, but it's not as flexible as a cron schedule)

For me it was a clear design choice to focus only on Slack, so the bots you build with it feel as "integrated" as possible with Slack. You can really leverage all that the Slack API has to offer.

Has anyone ever found a bot-generated message in Slack to be useful?

We have a slackbot that announces when a new customer signs up for our service, with some info on them and links to view them in our admin dashboard + third-party apps. Also, once our app hears back from a third-party fraud-protection API, the slackbot will reply to the message with info on the result, and will also react to the announcement message with an appropriate emoji :) Helps out our support staff a bunch, reduces the surface area of the things they have to consistently look at.

It's very useful for us right now at our current scale. Should we start getting an inordinate amount of new signups everyday, we will have to start relying on other methods to understand the signups.

Sure. We used to have one that reported any error on any web app we had deployed.

You could use other types of reporting, of course, but that worked for us.

Any important information could be reported by the bot instead of wherever you normally find it.

It's a matter of what you build it to do.

How many users x requests do you have that a slack per error is actually something you can live with?

Yup. We have a bot that the user slacks directly with a product code, and the bot will query our WMS and return the location it's in and how many are on hand. Why not just query the WMS directly? Because our WMS charges per user account, but not for API/developer accounts. This way we can allow office personnel that only need to look up something every couple of days without being charged for accounts that hardly ever get used.

How much experience do you have with Slack? It sounds like you might have been burnt by spammy bots in the past?

Having used it for ~7 years at a bunch of companies, I can say with confidence that bots are a very core part of Slack’s value.

There certainly are spammy notifications that sound useful and turn out not to be, but it’s not hard to keep the signal to noise ratio high with a little effort.

Yeah to me it's like the main thing that makes Slack useful. I have a ton of them hooked up. I'm in the events business so I have a feed of ticket sales, there's a feed from the sales department of opps opened, there's a feed from Confluence that tells me when someone edited one of our internal wiki pages, we have a shout-outs channel connected to our employee recognition platform that gets lots of attention when peer to peer praise comes in, we have one that's connected to our customer help chatbot on the homepage, which is expecially useful for responding to very timely questions about live events almost instantly (we get a lot of love for that), and a few others. I'm always thinking of new ones to write.

Having all the notifications just coming into one place is really good for "situational awareness" and I think it's one of Slack's main killer use cases.

I'd say ChatOps is a very legitimate use case. But I see your underlying point of bots frontloaded with a lot of logic.

Absolutely - couple examples that I've used in the last day or so: Github notifications (PR requests), Jira ticket updates (less useful), Figma notifications. Basically, Slack is aggregating the tool notifications into one place so I don't have to check email or each individual website.

Grafana alerts. GitHub PR requests. Jenkins builds. Surveys. Google Drive shares/comments. Dozens of other internal tooling integrations.

I can't imagine working without slack bots at this point.

How big is your team that the amount of these bot alerts is not something that just fades into background noise?

I think there's an obvious solution here. Slack bots that DM whoever is responsible; e.g. if I start a build and it fails, the bot DMs me and only me, no noise for my colleagues

We built a relay bit couple years ago. You can invite the bot into a private channel and then other users who are not part of the channel can use a form to send messages to that channel. The members of the Channel can then use the thread to answer.

Works really well and has the effect that inter-department communication don't always need to go through the department heads. This could, of course be abused for spam, but so far it worked well.

(Grumpy senior engineer voice) "No."

Pretty much any github/jifa/wiki/servicenow/error log/etc type chat bot integration immediately become background noise as soon as your team exceeds a size of about 4 or your user base exceeds a number you can count on your hands.

Everyone slowly mutes or ignores notifications on those channels and goes about their day.

Weekly reminder to fill out a report is nice. I would like Jenkins to send me a Slack message when my build fails.

absolutely, we rely on them for a few things and it's very nice

I especially like that it uses sockets and not an open HTTP endpoint. I've been messing about with Slack bots for a while and will certainly give this a look.

I really like the API and decorators! What I don't see in the documentation is how to respond to events from outside Slack Machine. For example an external message queue.

I suppose I could look into writing a coroutine that listens for messages on a queue and then runs the `emit()` from SM - just not clear to me if that's the "right way".

That is an interesting use case! The solution you propose, could work.

I've also been meaning to add support for webhooks as well, so you could trigger plugin functions by calling an HTTP endpoint. It's a small step from having messages on a queue and triggering webhooks from them.

Yes a webhook could work!

How do you deploy this? I want to run slack bots on 0 running costs where possible.

I'm sure you can set up a raspi to deploy this with minimal running costs.

Anywhere you can run Python code basically. Sadly, with the decline of Heroku, I don't know of any places you can run Python code 24/7 for free.

Myself, I run Slack bots on AWS inside a Docker container on ECS (for $day_job) and inside a Docker container on my Synology for personal use.

I created a micro framework for slack bots that can be deployed to Lambda here: https://github.com/jtwaleson/minimalistic-serverless-slack-a...

It’s probably a lot less rich than your solution, but feel free to look at it you want to run on serverless.

Google Compute Engine has a free tier. The developer experience isn't nearly as smooth as Heroku though.

You could probably use Cloud Run (it will run a python docker container), it scales to 0

Maybe fly.io? They have a pretty generous free tier.

I've been having fun using fly.io for a Telegram bot (listens on an HTTPS endpoint like a Slack bot, if I remember right). Has cost me $0 for my hobbyist bot that is only used by me.

This looks really nice, I've been looking for something to build a bot.

How does one monetize and sell slack bots, is it even done?

I'd argue it's more about service or API integration.

People are willing to pay for solid solutions as long as you can add value

For instance, let's say PagerDuty did not have Slack integration. If you decide to build the glue that connects both you already have a ton of potential clients as they don't want to invest money themselves etc.

If you're trying to get a `worse than zulip` experience but really like threads then your only option is a paid bot called Smithy: https://smithy.app

So at least someone is making money from bots.

Slack workflows are pretty powerful, and there is definitely a gap in available actions (steps).

I'm working on a Slack bot that I'm hoping to monetize.

I'd pay for a slack bot that detects which of the channels I've been involuntarily added to has messages from bots and proactively mutes them for me.

Pretty interesting. I’ll have a look.