Using Slack through an IRC client
eduardobautista.com
eduardobautista.com
It has some quirks (like not linking to pictures that are posted in chan, I did try to fix that myself) but generally it's the most full featured cli slack client I've used. You can even upload files.
Highly recommended.
You can have your opinions about Slack, about its apps being rubbish, about it being proprietary, whatever. But imagining that your personal use case, and those of your peers who probably are of a similar technical inclination, should represent the be-all and end-all of real-time online communication for groups is really unhelpful.
Yes, Slack and its ilk aren't perfect, but neither is IRC. What would be really great is if the IRC protocol could evolve to support some of these new features, perhaps with some sort of minimum specification for graphical clients that want to implement these new features — and graceful fallbacks for those that don't and text-based client users.
Now if only we had millions in VC money to create nice new clients.
What are the main, real benefits slack has over IRC;
* resilience to network disruption
* onboarding of new users.
* inline media (clients, not protocol, should implement this)
You could argue threads or SIP/VOIP but my admittedly anecdotal evidence suggests that these are seldom used. And, there’s no reason IRC could not expand to relay those.
Well, sure. But while IRC slowly proposes and implements relatively basic features of modern clients, the world will go on without it. That's already happening.
Not that this is a problem for existing IRC users, evidently. But if this is the case, and it's accepted, then it would be great if some HN users would stop trying to pretend that IRC has everything that people want — if that were the case, we'd not have all these alternatives.
> * inline media (clients, not protocol, should implement this)
Which is why part of what I said, and I know you didn't specifically reply to it but I must restate it, is some sort of minimal specification for graphical clients to present the user-facing features that people expect of a modern chat client, voluntarily entered into but with the potential as a great feature to advertise the modernity of a client.
My thinking is that otherwise someone will just make their own Slack knock-off IRC client, bundle it with their own IRCd, and we'll re-enter the IRC wars again. Proprietary IRC with a proprietary client — not that much different from any other proprietary solution other than IRC users reaping none of the benefits.
Going on to the main benefits of Slack, I can't really speak to Slack. However, I'm a Discord user, and I know Discord is inspired of Slack. What I'd like from Discord is:
- persistent session without needing a bouncer, or a simulation of such (e.g. when I connect, show me the last few messages on the server; when I scroll up, keep showing me more)
- an easily customisable role-based permission system rather than the relatively simplistic op/hop/voice, with customisable symbols (as opposed to colours)
- channel categories
- consistent and predictable text formatting, including a subset of Markdown — if I show a code block, I want everybody to see it as a code block (even if all that means is forcing a fixed-width font for a given block of text)
- separating a user's identity from their username, allowing multiple users to use the same nick differentiated by a discriminator
- avatars!
- push notifications!
It's all the little things that add up to a pleasant experience with things like Slack and Discord. I'm sure many will see many of those things as quite separate from an IRC, but these are the things to which people are now accustomed.
Where I work, the argument is reversed:
"just use Slack; I can't deal with some of the limitations of IRC because I'm not willing to, so no one should use IRC."
This effectively happened once Slack discontinued the IRC gateway they provided.
For those people with the need for text chat, sure, use IRC, go right ahead. But for those who need or are accustomed to more, let's stop pretending that things like Slack or Discord don't have things to offer.
Since the implementation is where the bloat exists, it's a fairly simple fix: make open servers and better clients.
So when is Slack going to do that? If they were open source, then anyone could do it based on the protocol specification. But since they're not, then it's up to the employees at Slack and they don't seem to be going in that direction.
The gateway solution they had that got around those problems with their clients was discontinued.
We've got things like Mattermost and Matrix now, we might see others coming forth, and perhaps one day there'll be extensions to IRC to support some of these niceties.
And yes, there'll always be the lovely Slack-like web frontends, and someone will inevitably package those up as native apps with React Native or Electron or whatever. But there's also room for good, high-quality, optimised clients for those platforms as well.
I love a lot of the tech work being done at Slack, but a lot of the product doesn’t feel particularly thoughtful.
Though I do find it interesting that there are those who want threading in a group chat setting, yet they aren't interested in threaded discussions via email or usenet. Modern email clients/platforms actually use a limited threading model that's known as conversation view (where you only have a single thread of messages rather than a tree view like one sees on this website or reddit).
Flowdock does a pretty good job of threaded communication. But Flowdock is pretty feature sparse and barely functioning mobile experience.
The problem is not standards. The problem is apps.
Jabber has been an open standard for god knows how long. Its standard slowly caught up to the modern world of mobile phones and multiple devices [1]. The apps? Not so much.
One of the appeals of Slack is that you have the same functionality across all your OSes and devices (and there’s quite a lot of functionality).
Matrix provides free (free as in beer /and/ free as in speech) gateways to Slack and IRC, so you could use it for your purpose here if you wanted.
[1] https://github.com/rectalogic/TextualSlack [2] https://github.com/SlackKit/SlackKit
Matterbridge seems interesting as well but I haven't had time to play with it yet. https://github.com/42wim/matterbridge
In view of those more-complete, non-proprietary solutions, you have to be a chump to pay for a Slack IRC bridge.
Or part of a network that doesn't want to issue generic API tokens to random users. Since this irccloud is implemented as a specific app integration, if I understand correctly this would be more appealing to administrators and moderators.
Do any of the solutions mentioned here work well on low-bandwidth connections? I'm limited to 128kbps, and slack via web is absolutely unusable.
Open to self-hosted bouncer/proxy solutions, but not interested in involving a third party.
You could run weechat+wee-slack in screen or tmux on a server; the ssh or mosh session to that server would be very low bandwidth.
We actual do this with an IRC client we developed for internal use.
I personally quite like IRC but I understand why people are less keen.
It's not the way of the majority. Probably not the way of the entire center of the bell curve.
Replies in chains are a mixed bag. It makes it easier to follow that particular conversation, but the UI/UX is godawful to the point of it being more confusing than just in-band discussion, IMO.
For example in Whatsapp I often check a notification and find its just a smiley or thumbs-up
I'm glad that IRC works for you, but it's 2018. We can do better than slate and chalk.
Some of the benefits of Slack are things like:
- the rich integrations
- emoji responses + emoji statuses
- video calls that "just work"
- good search (for stored knowledge across a company)
- pinned messages
- notifications people are snoozed and the ability to force a notification
Slack's search is absolutely horrible, in my opinion. It's one of the things I complain about.
Pff, speak for yourself. I used the slack IRC gateway until it was shut down as an alternative to just not using slack. Now I use wee-slack, which works great.
To respond point by point:
- the rich integrations [don't know what you mean]
- emoji responses + emoji statuses [wee-slack has this]
- video calls that "just work" [didn't know Slack had this]
- good search (for stored knowledge across a company) [Slack doesn't have this]
- pinned messages [not sure what this is good for; are you familiar with IRC's "/topic"?]
- notifications people are snoozed and the ability to force a notification [IRC's had the former in many forms for years and I don't think the latter is a benefit]I never heart anyone complain about inline images / gifs (which is also something that most IRC clients support) or that it's paid (which IRC bouncers / clients are often too in cases).
Speak for yourself. I never left and I find it very tedious when I'm forced to use anything else. In practice 90% of the justification for any other system seems to be that people want to post inane cat pictures at each other. That just isn't worth the tradeoffs for me. The 'modern replacements' for IRC are even bigger workplace distractions than IRC.
I use RocketChat for my consulting business for a few reasons that are largely unavailable on IRC without bots:
1) Rich text and syntax highlighting - Small properly fenced off code blocks are a wonder. Contrast that to IRC where it would never look quite right, relies on the other person's client to have monospaced fonts, and usually gets you yelled at for flooding
2) URL expanding - Viewing titles and a snippet of the content is useful. Requires bots on IRC.
3) File sharing in a trivial non-p2p. Nobody liked DCC, and I shudder thinking of going back to opening port ranges for that.
4) Reliability of having a central history which alleviates needing a bouncer, and reduces how important a stable connection actually is.
The only other thing you could come back with is to use yet other external platforms to alleviate those issues like:
For 1) An external public/private pastebin solution
For 2) A bot as I already said
For 3) An external filsharing service: Dropbox, Nextcloud, etc
For 4) External bnc: ZNC, bip, weechat, irssi etc
RocketChat, Mattermost, Slack, et al incorporate all of those things and more and are inherently useful - Plus, if you're the administrator you don't have to enable gifs or cat pictures, yes that shit is dumb.
Rich text is generally worthless except for code highlighting, but pasting large amounts of code into the channel is generally considered antisocial on IRC anyway, and pastebin services are used for this. It's not unusual for a company to provide their own internal pastebin services anyway, since it's generally useful with other systems like email. Ditto file sharing.
> "Oh come on can we drop the cat pictures trope?"
No, because in my personal experience that is OVERWHELMINGLY the most frequently used feature of slack/etc that's not present in IRC. For every time I've seen pasted code, I've seen easily a hundred inane pasted memes. I wouldn't bring it up if I didn't earnestly believe it's the primary reason people prefer systems other than IRC.
Having to search the entire conversation history in the chat window is a terrible idea because it's slow and difficult to use. Having a separate tool or page to search history is a superior solution, and software exists to do that in IRC.
Rich text is over rated, and 99% of messages don't use it anyway. Believe it or not nobody wants to see your silly gif, and they'd be just fine with :-) instead of an emoji.
Integrating with IRC is also trivial because its a standardized open protocol and there are a ton of tools available. It doesn't need a bunch of pre-fab "integrations" because it's not using a dumb proprietary API.
But having an IT guy spend half a day properly setting up an IRC server is hard and it doesn't have a crappy web UI by default, so lets all use Slack.
Many people here want to write about code in their chats so at the very least want to have an option for monospacing parts of a message.
You’re being flippant pretending it’s about GIFs rather than a genuine use case.
> using a dumb proprietary API
Why do you need to insult other people’s work like that?
Fair enough, but I would still argue that if somebody's posting enough code for that to matter, a link to a pastebin or a Github Gist, with syntax highlighting, is a better solution.
> Why do you need to insult other people’s work like that?
Because it's a poor choice to create a proprietary chat protocol because it allows Slack to control what people can say and how they say it.
Be wary of simply justifying why it's not the end of the world when a feature is missing, which is a much different argument. For example, I bet everyone who uses IRC appreciates some sort of indication for when they are mentioned even though they could ctrl-f for their username every once in a while instead.
I'd argue that you don't need to post "enough code" to benefit from monospace or multiline support. A developer channel in IRC is full of one-liners that would be improved by monospace.
Also, as a heavy IRC user, it's pretty painful following code discussion through a bunch of external links.
Compare that to my developer-centric Slack channels like Elm lang's where short code snippets are used heavily and it's easy to see context, it's so much more convenient. And when someone does have enough code, they can use Slack's snippet feature.
But I feel like you can always respond to any feature someone likes with "but why not just [inferior solution], it's not that bad". These things simply add up. :)
FWIW, by default my IRC client notifies me when I've been mentioned. A benefit of using an open protocol is that people can develop different clients that cater to their needs.
For code discussions I open a browser and an IRC window side by side. If I'm not paying attention to the conversation I just close the browser and don't have code snippets polluting the chat window.
> But I feel like you can always respond to any feature someone likes with "but why not just [inferior solution], it's not that bad". These things simply add up. :)
I feel that goes both ways, though. Just in this thread people have complained that Slack uses an absurd amount of resources and is proprietary, only to have the concerns sidelined as not important.
Most IRC clients (I'm thinking of HexChat) let you choose the font, which you can set to a monospace font.
Classic example is the rare power-user running irssi on a VPN so that they can receive messages/mentions while offline. The issue is that nobody else does it. Everyone else parts the second they close their laptop and probably won't remember to rejoin until they have another question to ask. You respond to someone and, whoops, they've already left. The whole community suffers.
Obviously it's true: you can bend your client to your will and that's nice. But what HNers typically do next is wonder why everyone doesn't want to do it. Or they criticize everyone else for not seeing the light. Though I'll admit I'm also responding to multiple sibling comments next to yours, not just you.
Whenever IRC comes up, HN always reminds me of The Simpson's Principal Skinner quote: "Am I out of touch? No, it's the [Slack users] who are wrong."
And IRC supports UTF-8 and unicode emojis just fine.
> But having an IT guy spend half a day properly setting up an IRC server is hard and it doesn't have a crappy web UI by default, so lets all use Slack.
I've found my organization uses Slack less because of the buzzy features and more to route around the brain damage of IT.
E.g., IT won't allow standing up communication servers with access allowed from outside the Corp intranet. Especially IRC.
Sales and support engineers frequently need chat access from outside the corp network. Ergo, 3rd party chat solution.
Slack is the worst solution in many ways, but it turns out fixing idiotic 90s security policies in IT departments is hard and you have to completely block the public internet to block Slack.
I’m pretty sure asking users to leave their app and go to a separate webpage to search wouldn’t sit well with most users, particularly people who are involved in some kind of deadline for their project—what we might brush off as “it’s just like two extra clicks!” is actually much more disrupting. It pulls you out of your workflow and those extra clicks feel like they add up over time.
While some of us may sneer at chat apps like Slack, it’s obvious their UX/UI heavily resonates with users.
We should be looking at why users absolutely prefer Slack and see if we can build a client based on an open protocol which will give the user experience most users prefer while still maintaining an irc type experience for users like us.
I have to disagree with this. Having to search for historical messages right where you can see recent messages is convenient. Using a different tool (potentially with a different UI) increases the context switch overhead. And there's no reason the search must be slow; the current chat window can display a portion of the messages, and the search can be done either on the server, or a background thread searching a database locally. Slack in particular has some bad engineering to make its UI slow and memory-hungry, but many of its copycats are actually functionally similar yet much faster.
IRC is ancient, and pretty much broken, but it still works fantastically well for some things, and I really like having a text-based client to run in a tmux.
EDIT: IRC, XMPP, and such, support integration just fine via bots.
Apart from federation you’ve described Slack.
Neither IRC nor Jabber give it to you out of the box. Slack does.
I'm so used to using wee-slack that I try to use commands like "s/" when I use the web browser interface (which doesn't work).
One thing I wish wee-slack had (and I haven't updated in months, so it may by now) is the ability to download files attached to messages without opening the URL to webslack. That, and occasionally silent failure to display long notes attached to messages, are the only major hurdles I encounter with wee-slack on a regular basis.
https://github.com/wee-slack/wee-slack
It works great!
For XMPP there’s exactly one client that supports may be half of those features. For IRC there are none.