Hacker News Reader

Comment by erur | Hacker News Reader

Kinda stating the obvious here but most of the mental overhead you feel with Slack Apps comes from a long list of Enterprise concerns that needed to be addressed.

If you just want to build a poc Slack won't keep you from creating an app manifest with all the permissions and be done with worrying about them. Also all those public APIs are designed to be fairly permanent. Can't compare it to IRC obviously but I wouldn't worry too much about stuff being deprecated all too quickly.

I work at Slack and frequently build automations for our customers so I'd love to hear about particular annoyances from the perspective of an old school IRC user.

View on HN

I think part of what keeps me from getting too personally invested in Slack (or Discord. Or any other commercial chat platform) is that I've seen so many commercial chat platforms come and go over the years (I think my company has averaged 3 years per platform so far), while IRC is older than I am. I just don't expect any commercial chat platform to have a real long-term future because of the financial friction in keeping it running. But who knows, I grew up alongside computers so maybe the past thirty-something years were just the growing pains and Slack will be "it" for companies for the next thirty years.

Yeah, in their appropriate contexts I'm sure they all make perfect sense! I'm also glossing over quite a bit -- my company has security policies that we enforce on Slack as well, and it's perfectly reasonable for those policies to also complicate custom automation.

I think my biggest gripe is just the amount of state I feel like I need to be aware of. With IRC, I can throw together a bot using either a raw socket or a mature bot framework in an hour or two because there's no real "remote" state for me to think about; I'm just in the flow of editing the source code. With Slack (or any chat app, really), I feel like I context switch much more frequently (more things are full-fledged APIs instead of just string munging, I missed a scope, etc.).

I have a wide selection of clients for IRC, with varying levels of features (including client-side automation scripting), performance, and platform support. I'm annoyed that I have to use a GUI at all, or even worse, an Electron app.

Weeslack works fine.

Does that do requests asynchronously now? For a long time it would stall the whole client every time the slack API had issues (which was quite a lot more times than their status board suggested). At some point it got so bad I had to stop using it - I have switched to matterircd now (it also does slack).

I never noticed that. I have key bindings for moving through the channel list, and movement is not blocked while the channel content is loading, so I guess it's not blocking?

Yeah, exactly. Those IRC bots work by reading EVERY chat message and looking for commands. Not exactly minimum permissions philosophy, and likely not acceptable liability and auditability wise for what is very specifically intentioned to be corporate software.

I'm not going to claim that IRC's permission model is good (it definitely isn't), but "EVERY chat message" is inaccurate in most deployments: you generally pick the channels you want the bot to be in, and prevent it/others from joining other channels. That's no different in effect from a Slack bot that's receiving webhook events on every channel message and scrubbing through them, which is also a common pattern.

Unless the IRC bot is a service like ChanServ it's just another IRC client. It's only receiving messages from channels it has joined or private messages sent directly to it. A bot is receiving what you would receive if you joined the same channels.

Reply on news.ycombinator.com