Now I'm on a team which uses slack, and I miss how lightweight hexchat is, but in terms of being able to use it my phone and having something that just works without any additional effort it only has advantages.
But I just know nobody, from a variety of OSes, who doesn't experience the "bug where slack completely looses where you are in time" and then you have to scroll for a while because the "Jump to new messages" doesn't work well. I came to the point where I wonder if anybody here doesn't have that bug at all ...
A bug that kills UX like that and that we can do nothing about, not even contribute a fix, and still it seems Slack is the best product people can find, meh, I run Mattermost in my company and we're all very happy with it and don't experience as much problems as we do with Slack.
Never really been anywhere but in tech channels on IRC, I had a few years without going back but I'm back and I love it.
I think just that goes a long way.
Mattermost might be good (never used it), but being self-hosted means it's a lot harder to set up than just subscribing to Slack. I talked about this before on HN[1]: I think providing a simple hosted SaaS should be a key part of the strategy to displace shitty closed-source products like Slack.
~ uptime
23:22:27 up 787 days, 15:10, 1 user, load average: 0.00, 0.00, 0.00
- Typing latency
- Access from mobile devices
Many people don't care about those things; good for them. Unfortunately for me, I do.
I can (and do) use a bouncer, which theoretically solves both problems: text entry is handled by my local IRC client rather than every keystroke going through a server, and I can run an IRC client on my phone. Unfortunately, bouncers are a rather poor approximation of true cross-device history/state synchronization; e.g. they don't sync unread messages. And they're generally slow and fiddly for various silly reasons. For example, most bouncers require you to make a separate connection for each IRC network, which is slower, and requires configuring each client device for each network, annoying if you have a lot of networks. Also, long backlogs can overload slow IRC clients, but typically the alternative to long backlogs is losing history, since there's no standard mechanism for clients to request history on demand.
There are also some IRC clients that do "true" state synchronization, like Quassel or Weechat's relay mode, but none with a tolerable iPhone version, last I checked.
tmux, irssi, and mosh on a VPS and i’ve had that setup for IRC for ... pushing a decade?
(Alas, most ‘native’ IRC clients for macOS have web views inside anyway, so avoiding web-based stuff may be a lost cause. But then I’m in no position to complain about Slack or Discord using Electron…)
It has been running since whenever the rpi2 came out, and total downtime since has been under an hour.
It's like a relay/proxy/bouncer but actually uses its own protocol between the GUI and core, so you get infinite backscroll, proper sync when running multiple GUI instances at the same time etc. Oh and there is a decent Android client called quasseldroid.
...Yeah. From installing znc from your favourite package manager to having it set up and running in your client is all of ten minutes, with SSL, auto-joins, channel history and all. Is it a barrier? Yeah. Is it so much of a barrier that it would push someone concerned about centralized services and proprietary software to just give up and use Slack? I don't think so.
I'm just going to use Slack and move on with my life.
Actually I lied, I do know what all that mumbo jumbo is, but I hope you get my point.