Hacker News Reader

Comment by bluetidepro | Hacker News Reader

I'm not sure if this service specifically requires full access permissions or not, but I do know a ton of these (awesome/neat) plugins like this popping up require a company to give the plugin full write/read permissions. And for that reason, it's stopped our company from being able to use them.

I'd be curious to see how many companies would actually allow a 3rd party service to have that full amount of permissions. It's sort of like GitHub and how some services require the access to private repos. I'm not sure of a solution, but am just curious how it really holds back awesome services like this when companies don't feel comfortable giving it the level of access it has to have (but may not use that full access).

View on HN

Hey there! This is a great point and something we recognized when developing operator. We wanted to make a service that didn't expose your entire chat to a third-party service.

The OAuth scopes operator asks for are the following: chat:write:bot - so we can post to your channel operator's response. commands - to install the commands. users:read - so we can get a bit more information about you (name, team permissions, etc).

We even toyed with the idea of eliminating the "users:read" to be as minimally invasive as possible.

Run an IRC server, configure a hubot. Yes, 'cloud'-based chat is pretty, but it's a new coat of paint over something that's been around for decades (IRC). For a company less than several thousand people, running your own singleton IRC server is about as complicated as setting up a basic 3-tier web application (i.e., a little fiddly, but not hard at all)

Clients on the other hand are somewhat lacking for IRC.

We use Slack in a company of ~30, and while all the devs could easily use IRC, most of the rest of the company would struggle with it, and certainly wouldn't be able to communicate in the wide variety of ways (uploaded files, images/gifs, videos, code snippets, etc) that they do now. Slack is great at making all those rich media types 'just work', and while it was possible with plugins to some IRC clients, the UX was prohibitively bad in my experience.

>Clients on the other hand are somewhat lacking for IRC.

>(uploaded files, images/gifs, videos, code snippets, etc)

Slack is really just a rich-text jabber client.

"Use IRC" isn't a very strong suggestion for a business, what really gets me is seeing open source projects using slack. I even had a casual IRC channel I used to frequent migrate to slack, smh.

That's a fair criticism. I know https://grove.io/ does great work in making 'real IRC' available to the masses, but it's still hosted. It would be nice if they would release their web-client as open source, or if someone wrote an OSS clone.

Take a peek at convos (web IRC client frontend) https://github.com/Nordaaker/convos for a persistent web client. It uses redis to maintain state.

On one hand, you're completely right, on the other, I wish I could block all GIFs from Slack (or just not get notified about them). That kind of thing doesn't help me get work done, which is what I'm at work to do - not to share funny pictures.

That seems more like a Slack setup issue than an issue with Slack itself, to be honest. We have a separate #random channel for stuff like that and have turned off notifications for it. It's still there, but it's much less intrusive.

You might also want to check out the settings in the Messages & Media section, specifically "Expand links to images, video and audio from external sources". That might help to disable the inline GIFs, although I haven't tried it myself.

Yeah of course, blocking gifs is entirely reasonable. However the rich media and ease of use is well worth the money to us. If we were a company of only developers then maybe IRC would suit us better.

Compliance is an annoying issue with IRC. With Slack, Lync, or 99% of Jabber servers out there I can log every communication that takes place (outside of people using something like OTR with Jabber) - I can set up an IRC bot in every channel to log group chats, and maybe somehow disable private messages, but it's a pain in the butt to deal with IRC where compliance is a big deal (I work in healthcare).

I've often toyed with the idea of writing an IRCD with logging built in that drops all CTCP setup messages, but it's a huge hassle.

Indeed compliance is an issue with IRC, but you don't need to write an IRCd to log all messages and you don't even need to configure IRC services: you could just use InspIRCd [1] (which, by the way, is a superb and extensible IRCd) and an extension such as [2] to achieve what you are looking for.

[1] https://www.inspircd.org/ [2] https://github.com/joshenders/inspircd-m_chatlog

I'll have to give it some investigation. I'm pretty confident in the ability of end users to figure out a basic IRC client, but logging made it a non-starter for our use cases - the chatlog module you linked is rather basic, but looking at the source it should be easy to extend for our usage.

UnrealIRCD also has modules for this. You have to contact the site admin to acquire them. https://www.unrealircd.org/

Yes it's not too hard or too different, but have you ever tried getting non-developers to use IRC? Finding a desktop client is confusing (which one is best being the first question) and even basic setup can be daunting (servers, ports, channels etc).

Slack, Hipchat and others however can be easily set up and used by pretty much anyone in a company. IRC is great for companies which only have very technically proficient employees, however that's not most companies...

And without a bouncer your client must be always on to have any backlog. Mobile access sucks without a bouncer. Even with a bouncer it sucks for anyone not technical.

Why not https://matrix.org?

It's a slash command, should only need a webhook AFAIK.

Reply on news.ycombinator.com