Hacker News new | past | comments | ask | show | jobs | submit login
Launch HN: Abbot (YC S21) – ChatOps as a Service, inspired by GitHub's Hubot
143 points by icey on July 27, 2021 | hide | past | favorite | 36 comments
Hi HN, we're Phil and Paul and we make Abbot (https://ab.bot/) – a tool for building and running simple automation via chat (currently Slack, Discord, and MS Teams). It's common to go from "I have an idea" to having a fully deployed chat command in under an hour.

The term "ChatOps" comes from GitHub, where the two of us worked together. GitHub was always a distributed company and early on developed a culture of doing most work via chat. Engineers automated the most repetitive processes (and some of their sense of humor, too), and that grew into a shared chat-based command line called Hubot. By typing terminal-style commands into chat, you can execute any sort of process that it makes sense for your team to automate. And because it’s in a shared chat room rather than hidden on your own machine, every time you run a task, you teach someone else how to do it.

Hubot has been wildly successful at GitHub and is amazing in action. We saw GitHub’s ops team fight off the biggest DDoS attack in history from chat using Hubot, while people were cheering along in another channel using Hubot to find appropriate hype gifs. But the effect on day-to-day work was even more amazing. Anyone could easily find out what was recently deployed, how to deploy, monitor servers, page people, you name it. New employees could see how to do all those things as soon as they joined. Since there were fun commands inside of Hubot, it was great for team building, too.

We believe more companies would benefit from working this way. When Covid hit, many companies suddenly found themselves struggling to make distributed teams work better. It is challenging to understand what everyone is doing, or even how to do regular tasks, since it's not easy to tap someone on the shoulder and ask. We decided to build Abbot to help teams adopt this style of work.

When we started, we built a list of what wasn’t fun about Hubot. Hubot required a lot of configuration, wasn’t reachable if chat was down, testing new scripts could be painful, there was no unified way to manage permissions, and so forth. We built Abbot as a hosted platform that handles all these things so developers don’t have to.

Because Abbot is a platform, we provide a unified interface for auditing, access control, data access and more. If users understand how to use a single Abbot command (or “skill” in Abbot parlance), they'll know how to use any other Abbot command. Since we built Abbot to support multiple chat systems, we made it so that all Abbot commands are cross platform – commands written for Slack will work in Discord, and so forth. You can write commands in C#, Python, or JavaScript (we will support more languages in the future). We also do a lot of things Hubot does not, like allowing users to control access to the execution of their commands from inside of chat, or exposing an API endpoint for every command so that they can react to the outside world. There’s nothing to fork or configure – you can get started in two clicks from our website.

Abbot has a Package Directory where people can share the commands they’ve written. There are a few dozen packages in the directory today, with more being added every week. Packages are MIT licensed and installable in one click. Because it's so easy to create new commands, teams tend to create a lot of small ones that accomplish a single task. For example, we have a `tweet` command that allows us to use chat as our communal Twitter client (available in the Package Directory at https://ab.bot/packages/aseriousbiz/tweet).

Today, people use Abbot to deploy Git branches to staging environments, track daily standups, figure out time zones for all their teammates, give each other internet high-fives (well, sparkle points), and even open their office door. We are focused on DevOps and customer support teams right now, but believe ChatOps can make a big impact on every team that has a channel in your chat.

We are open for business! You can add Abbot to your Slack, Discord, or MS Teams chat by clicking "Try for free" at https://ab.bot. We have a free tier that allows people to try it out without any commitments. We don't ask for any information to sign up, you just have to authorize Abbot into chat. For paying users, we charge based on the number of custom commands, number of actions taken, or access to paid features like access controls. Right now we are SaaS only, but will offer a hybrid-premises version in the future.

We are sure that many of you have built your own chatbots and ChatOps tools before. We’re especially interested in hearing about what worked well and what was challenging when building and operating them! And we hope you can give Abbot a try. Have at it, HN!

Super stoked to see you launching after working on it for so long!

I still think Hubot (and bots in general, a la GitHub's internal usage) is severely undervalued. GitHub's usage of internal chat was pretty groundbreaking, which I think led to the movement behind Slack's growth. But there was a missing point in the rise of chat- namely, scripting automated processes and debugging collaboratively in public (internally). Which makes sense, since Hubot was a pain to set up and build a company around. So yeah, really excited about Abbot to jump in that hole in the market.

Thanks holman! That means a lot coming from you! :)

A bit off-topic but the name immediately reminded me of https://www.abbott.com/ which is a ~$215B market cap behemoth

We tried to buy their domain from them, but they haven't gotten back yet. I'm still hopeful :)

abbot.com might be cheaper

And better fits the brand. We want to avoid that extra "t" at the end. :)

I’ve been playing around with Abbot for a few months and the experience has been awesome. It feels like Twilio but for chat: takes the cost of writing a bot down to just a few lines of simple code. Excited to see it on HN — congratulations on all the progress!

Thank you Ted!

This looks great, I just created a command to trigger a job in circleci and it was very easy to get started.

Is there a way to have commands that are approved by another person (for example, `@abbot deploy skip-tests` that has to be approved by another team member with a thumbs up reaction or a reply?)

Is there a way to add replies to the original message from the bot directly? Or at least respond to the same channel? (like: I trigger a deploy, and the bot sends a message to the slack channel when the deploy is done)

Yes, you could use Abbot's support for messages with buttons. https://blog.ab.bot/archive/2021/06/08/user-interface-suppor...

In that case, when someone runs `@abbot deploy skip-tests`, you'd present a message with a button. You'd have to validate the user that clicks the button yourself.

Abbot does have support for ACLs on skills, but it's for the whole skill. It doesn't yet support restrictions on actions within a skill.

Let me know if you attempt this and run into problems. I'm happy to review code! :)

Neat. We used Hubot for a bit, but it was fiddly and cumbersome, so we eventually ditched it. I think we managed to automate the few useful commands with our CI/CD instead… but I definitely liked the idea in principle.

Can you explain what dedicated skill runner means? saw it on the plans page, but couldn’t find (or missed? on mobile now) what it is and why it costs extra…

Hubot still has a special place in our heart. The only reason I ever learned Coffeescript was to build scripts for it. But I have definitely broken installs more than once. We tried to make Abbot very simple to run for exactly that reason!

Right now all skills run through the same infrastructure. We are figuring out our package management story currently, but today everyone has the same packages loaded, and all requests come from our shared infra. Some companies we talked to have specific library needs (especially internal libraries) or requests for dedicated IPs for their runners. For most teams, this probably isn't needed. We spend a lot of time making sure things are fast and scale, so it's mostly about control for our customers.

Interesting, though I'm struggling a bit for when "chat initiated" is the best trigger for things that aren't in the fun category.

That is, when is chat-initiated typically a better fit than something initiated by a check-in, build, incident detection, and so on?

(Not knocking it, just curious)

Great question -- chat is a great interface for anything that falls out of the "easy to fully automate" category. As an example, we use continuous deployment internally; but there are times where we might want to deploy a branch to a branch lab for experimentation. If that happens, doing it from chat lets everyone else know that it's out there (and how to do that deployment).

Chat is also a great environment for getting notifications about extraordinary events. We get notifications in chat if a link on our homepage is 404ing, whenever deploys happen, or as scheduled updates for things we want to pay attention to but don't want to manage a separate website to handle them.

We usually start with small commands and then grow them to automate more of the "well trodden path" as we understand what we want to automate. Because every command (we call them skills) can expose an API, it's possible for an Abbot skill to respond without any person being involved.

Another example we just published is about tweeting from your company's Twitter account from chat. This is a great use-case from chat. https://blog.ab.bot/archive/2021/07/27/tweet-from-chat/

A big benefit is that you don't have to share credentials from the Twitter account, but still make it available to people in your company.

Any thoughts on how customers should think about securing their skills? ChatOps exposes skills that may provide deep access to deploy code or modify system configuration. Slack doesn't have the same security as an SSH session (password protected private key). I'm seeing concerns around phone theft, evil maid, spouses, or former employees who haven't had Slack access pulled.

From my end, I think these are solvable but may require thinking about the problem differently. How are you thinking about security?

Absolutely! We think about security on multiple levels.

For our threat model, we focus on _companies_ using Slack, Discord, and Teams, though our efforts apply to communities, etc. For the sake of this question, I'll focus on companies using Slack, but most of it applies to the others.

Even without Abbot, if someone gains access to an employee Slack account, they can do immense damage. So it's very important for companies to enforce good security on Slack such as 2-factor auth, etc. If you use Abbot, that's even more important. To interact with Abbot in chat, a user must be logged into your Slack organization. So we encourage customers to take their Slack account security seriously.

Now it may happen that a Slack account is compromised despite a company's best efforts. So the next level of protection is the ability to protect skills using Abbot's access control. You can restrict skills to a limited set of users. That makes it possible to follow the principle of least privilege and reduce exposure of the most sensitive skills.

Finally, despite our best efforts, there may be the case where someone gains access to a privileged account. Abbot logs every interaction it has with users, whether through the Bot console (in the website) or via chat. So if someone does somehow get access, you can audit what activities they took, what secrets they accessed.

It's also important to look at security from the perspective of a skill author. To create a skill, a user has to be a member of the "Members" role in https://ab.bot/. This requires that they are a member of the associated Slack organization and have logged into https://ab.bot/ with their Slack account (we don't implement our own authentication).

An Abbot Administrator can choose to let anyone in the Slack organization automatically be added to the "Members" role when they log in. That may be appropriate for smaller high-trust companies. For larger companies, administrators may want have tighter control on access to the website.

Skill authors are encouraged not to embed tokens and other secrets in the code for skills. Instead, use the secrets management built in. There's also a proxy link feature for certain cases where a secret is embedded in a URL and you don't want the secret exposed even to skill authors.

That's where we are today.

In the future, we'd like to integrate with Active Directory, LDAP, etc. for managing access to the site and skills. Also, we know that many systems people want to access are going to be behind a firewall. So we are looking into onprem options, but those may be further down the road.

If you have some ideas on where we can improve or areas we should be thinking about, we are definitely interested in hearing about it. This is very important to us.

Slack is often misconfigured - mid-sized companies without a proper IAM team/engineer often enable auto-provisioning which sends an invite to @<whitelisted domain>. If you can identify a e-mail reflection vuln on the domain you can parlay that into a Slack invite, and while ChatOps might be the least of the concerns I fear this is reinforcing bad hygiene.

Additionally companies forced to be SOX compliant require separation of duties, which is often incompatible with slash commands that impact production or revenue generating infrastructure.

For teams that are concerned about whether their Slack is configured correctly, Abbot can be put into a waitlist mode where an administrator on the Abbot team has to explicitly approve any access. No matter how Abbot is configured, all commands are still logged.

SOX compliance is a bit outside of our domain of influence; our goal is to give people the most powerful tools we can, in a way that they can run it in their environment without having to reinvent the wheel.

> If you can identify a e-mail reflection vuln on the domain you can parlay that into a Slack invite

On reread, I realize that I'm not sure I understand what sort of attack you're talking about. While I think we've done a good job of making Abbot a safe entity, could you describe how this works? It's possible there's an attack vector we haven't considered. Thanks for sharing!

You need to know the Slack workspace URL, looks like the previous method I used to find this for arbitrary domains has been fixed. Workspace URLs aren't secret, though, and can often be guessed. Let's assume finding this for your target isn't an issue.

The most common reflection attack is through support systems, specifics will vary depending on the product used. Not all are vulnerable to this.

Open a support ticket with support@company.com pretending to have a valid complaint. Obtain the unique e-mail address for your ticket such as support+2392@company.com, and use "Sign up" at https://company.slack.com/signup#/domain-signup with the support ticket e-mail address.

The support ticket system can leak the contents of the Slack invitation as a ticket update. Once you know the validation URL Slack allows you to sign up.

Great answer, thanks for the detail!

Sounds nice. I would encourage you to build a Mattermost integration too; it should be similar to Slack.

Mattermost has come up a couple of times recently. Along with Matrix, it's probably our top requested platform. Right now we're focused on improving the core platform, but the nice thing is when we add new platforms all the skills written for other platforms should work on day one. I added your request to our internal tracker for Mattermost and will try to reach out once we add it (your email isn't in your profile, so if you want to email me at paul@ab.bot I can add you to the list).

Hey I'm the Community Manger at Mattermost, if yall do build the integration and need any help with anything, feel free to reach out to me (emily.cook@mattermost.com) or join our community server http://community.mattermost.com/

Wow, awesome! Thanks Emily!

This is amazing, can't wait to setup my DevOps processes to be triggered by Abbot commands. Winner winner.

Can I use Abbot along with Terraform on ECS? Would love to setup some deploy scripts

Thanks! I'm not too familiar with Terraform on ECS, but if there's an API, then you can script it with Abbot.

For example, we have an existing package that uses the GitHub deploy API to deploy software https://ab.bot/packages/aseriousbiz/deploy

If you trigger your deploys using GitHub's API, then you could just use that skill. Otherwise, you can copy that skill's code and adapt it to your needs. Hope that helps!

(In case it's not clear, I'm the "Phil" in the post) :)

Thanks Phil, this is awesome. I'm sure I can leverage AWS API/cli. Also could be a great fit to use Github Actions along with Abbot

boto3 is available in Python skills too, so there's probably a shortcut there for you :)

Very cool to see. Going to have to play around with this. Would love to see additional quick take youtube videos about the value prop. Thanks!

Thanks Ian! That's great feedback, we should absolutely make more YouTube videos (we have a few here, but it's been a little bit since we've released a new one: https://youtube.com/playlist?list=PLs8WZvPC2qpBFpmzI6Fpa-6NB...).

We also wrote a blog post about how we think about our problem space and value proposition recently: https://blog.ab.bot/archive/2021/07/15/tools-for-inside-the-....

Not quite as succinct as a video, but it might help paint a a more vibrant picture of how we see the world.

Congrats on the launch!


Sweet, this is sick!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact