IRC has a fair share of problems which are often circumvented by layering additional services like bouncers on top of it. I like it for its ubiquity, but let’s not pretend it doesn’t show age everywhere.
I can’t bring myself to like a communications protocol that’s based on HTTP+JSON, with the reference client written as an Electron app. It just all feels so… inefficient :(
The very core of matrix is just the graph behind it all. JSON is just one representation of the information and HTTP is just one transport. Those are the only reference implementations right now, but others are possible, if I’ve understood correctly. But someone more knowledgeable should probably weigh in.
Would you rather there wasn’t an implementation? But, in this case, there are several other implementations. There’s the next generation reference home server dendrite (in golang instead of python like synapse) and ruma (in rust). And there are lots of clients. I think only riot supports e2e crypto, but I hope others will start supporting it as it stabilises.
HTTP+JSON isn’t all that inefficient, just a bit of extra headers, whatever.
Matrix is actually fundamentally inefficient in a different way — it’s not ephemeral message passing like IRC or XMPP, it’s a replicated database — and it’s worth it.
I stopped using IRC and my bouncer 2 weeks ago for Matrix/Riot on my own server with my own IRC bridges and couldn’t be more pleased. Works incredibly well.
edit: was an irssi+irssi-proxy user for over 15 years. Tried every other bouncer. Hated them all. Had a perl script to send my phone a pushover notification for mentions. It worked, but it sucked trying to open up IRC app and find the conversation with no scrollback and respond.
Now I have: consistent chat client on every device, always have scrollback, all my logs are stored in Postgres, logs are searchable in every client and the search is handled server-side, and I can do E2E encryption with my friends on Matrix. I will never experience Slack bloat because the federation means I only need one server connection and account.
I haven’t been impressed with the quality of tooling or clients yet. Their Debian package documentation is incorrect and commands tell you to… run the same command you just ran. I haven’t seen a client I’ve been terribly impressed by either; Riot is your typical Electron fare.
Even without the performance concerns of Electron or running in the browser, there’s still the fact these overgrown web apps feel alien in UX on every platform.
The IRCv3 working group is attempting to standardise a lot of interesting extensions to the old IRC protocol in a backwards-compatible manner. Amongst other things, they seem to be working on history, standardised registration/authentication, and metadata such as user avatars.
It is, isn’t it? I am watching their repo on GitHub and get excited every time I get a notification, hoping that it’s about something major like a good history extension. If I had more time I would love to contribute. Wish they had a Patreon account, or something similar.
Maybe if it was written in JavaScript, used a million npm packages, invented some new Json/Jose derived protocol,.. then you might have a hope.
In all seriousness, I ask myself that question all along. At work we use lync and skype for business and those still feel like a step backwards compared to old Skype, man, icq, and irc. In fact we had logging turned on for a while but the fat xml logs are up our entire email box so it was turned off company wide.
IRCcloud has a couple of interesting issues when using it in a business setup. For example, for simplicities sake, they load twitters, facebooks and stripes JS libraries into their webapp, giving third parties access to that data. We talked to them about this and they said they were looking into it, but never ended up doing something.
It’s nice otherwise, but I prefer to only use it as a bouncer. Finally, it costs ~5$, so it’s not a feasible chat for many people outside of companies.
I think Jabber would make more sense as a modern communication platform than IRC. There’s not much that IRC provides that Jabber conference rooms don’t, but Jabber provides a lot more extensibility than IRC (especially without add-on services like Chanserv, Nickserv, etc.). In which case there are already commercial packages like Cisco Jabber and Openfire that are quite popular.
Whatever we use needs to be really simple and efficient at the core. Then, layers or plug-ins for more complex stuff from there. Preferably, super-easy for library users to add or remove. What’s closest any of you know to that which has a decent chance of being converted into a Slack competitor? Other than IRC.
There aren’t many that are federated like IRC. I can only think of Jabber/XMPP and Matrix. But if you look at slack, which doesn’t seem to be federated, you have lots of options, like mattermost, rocketchat, hipchat, …
You can’t offer Slack’s UI on top of the standard IRC protocol (it lacks links, images, replies, authentication, history…). Proposals to extend the IRC protocol have not been welcomed by the IRC userbase or by established networks. You could tunnel a custom protocol over IRC with magic strings etc. but this would be inherently clunky and the user experience from any other client would be very similar to using Slack’s IRC gateway. You could publish your custom protocol but what would you gain from that? What’s the value proposition where this idea improves over what Slack offers?
Why would this “eat Slack’s lunch”? Theoretically an open protocol would make it easier for others to integrate with you, but Slack attracted plenty of integrations (which now act as a competitive advantage precisely because their protocol isn’t open). Other than that, what’s the advantage of making the protocol public?
Well I explained that that particular issue doesn’t seem to have been a disadvantage for slack, quite the opposite.
Building a protocol as an extension of IRC is inherently going to be more expensive than building it without regard to compatibility with IRC, not cheaper.
Slack extensions are not interoperable. IRC bots have been written for decades.
All true. And yet for so many services one might use when developing (e.g. CI), it’s so much easier to find a good Slack integration than a good IRC integration.
Same. I fire up the electron app on my mac for voice calls (it seems to be the most reliable option, but still worse than skype for connect times + success rate) but everything else is a browser tab. Using Slack in a safari tab on my macbook makes the difference between ~10h of battery or ~4h of battery.
Interesting to hear. I use the dedicated Slack application on Linux because it seems to use fewer resources than when loading Slack inside Firefox or Chrome.
I was watching a video on Youtube the other day and part of it was the guy going over his PC specs. At one point he said “Now some of you may ask why I need 32 GB of RAM, and the answer is that I do a lot of work from this PC, and sometimes I need to have 20 Chrome tabs open at the same time for my job.”
Is this really where we are, that we need 32 GB of RAM just to keep our browser tabs open?
Yes, this is really where we are. I use Safari, because it’s so much more efficient and it’s the only browser that implements color management correctly on wide gamut displays, but for some things I just need Chrome. I have 48 GB RAM and Chrome is usually consuming about 25-30 GB. Before I upgraded to 48 GB RAM, I was swapping like crazy.
That is nuts. But I guess Chrome is really an entire OS in drag & every tab is it’s own virtual machine, so 1-2Gb per running tab actually sounds about right if you think of them as full-fat VMs doing their own thing.
It’s still the most egregious waste of computing resources since the last one of course.
Even when they’re enabled, it can be really hard to use those as your primary interface. E.g., at my company, we do voting on things during company updates via a Slack plugin we wrote. If you’re on IRC for that, you’re SOL. (And while, yes, you could make a chatbot to handle that instead, it’d be an inferior experience. So you’d need very strongly buy-in to not using Slack before that made sense, and at that point, the whole thing’s a bit moot.)
Mainly for that reason I switched to a combo bitlbee + weechat + (screen + mosh + weechat-ncurses)
It was a bit long to set up everything and there are still some rough edges. But, now with about 3Mo of RAM I can chat with:
3 slack community with lot of channels
some gitter channels
many IRC channels freenode
hipchat
I have manually set alerts.
The text use my preferred color theme. Typically the only other reason to get rid of slack is that I couldn’t have clear text on dark background.
Now my chat system feels like a calm place to discuss.
Two things have helped me: turning off all animations (incl. party parrot, GIFs, etc.), and reducing the number of Slacks I’m logged into from ~15 to a core 6. It’s still kind of a tire fire.
I noticed this a while back while using my 15” Macbook Pro at a coffee shop. I forgot to bring my charger and my battery was dropping like crazy. Looked at who was using all the energy and it was Slack. I don’t usually bring my charger to the coffee shop, so now I just don’t use Slack while I’m there.
My solution was to buy the paid slack version. It allows you to setup channels for each of your customers (as opposed to having separate slack groups). Memory usage is much better now. Still shitty, but much better.
Someone please build a slack, but fast, startup :)
No need to bring it back, it’s always been there. The problem is convincing everyone else to use it.
IRC has a fair share of problems which are often circumvented by layering additional services like bouncers on top of it. I like it for its ubiquity, but let’s not pretend it doesn’t show age everywhere.
I think matrix could very well be the successor to IRC. Open, federated, secure, multi-device sync and good support for bridges to other protocols.
I can’t bring myself to like a communications protocol that’s based on HTTP+JSON, with the reference client written as an Electron app. It just all feels so… inefficient :(
The very core of matrix is just the graph behind it all. JSON is just one representation of the information and HTTP is just one transport. Those are the only reference implementations right now, but others are possible, if I’ve understood correctly. But someone more knowledgeable should probably weigh in.
The problem with reference implementations is that, by inertia, they end up being the only implementation.
Would you rather there wasn’t an implementation? But, in this case, there are several other implementations. There’s the next generation reference home server dendrite (in golang instead of python like synapse) and ruma (in rust). And there are lots of clients. I think only riot supports e2e crypto, but I hope others will start supporting it as it stabilises.
To be fair, Riot can run perfectly happy standalone. In fact, I have it running right now on my OpenBSD box. Also, there are many other clients!
HTTP+JSON isn’t all that inefficient, just a bit of extra headers, whatever.
Matrix is actually fundamentally inefficient in a different way — it’s not ephemeral message passing like IRC or XMPP, it’s a replicated database — and it’s worth it.
I stopped using IRC and my bouncer 2 weeks ago for Matrix/Riot on my own server with my own IRC bridges and couldn’t be more pleased. Works incredibly well.
edit: was an irssi+irssi-proxy user for over 15 years. Tried every other bouncer. Hated them all. Had a perl script to send my phone a pushover notification for mentions. It worked, but it sucked trying to open up IRC app and find the conversation with no scrollback and respond.
Now I have: consistent chat client on every device, always have scrollback, all my logs are stored in Postgres, logs are searchable in every client and the search is handled server-side, and I can do E2E encryption with my friends on Matrix. I will never experience Slack bloat because the federation means I only need one server connection and account.
The Riot web app can also serve as a nice IRC client (+bouncer, email notification, etc) if you only need the networks they bridge to.
I haven’t been impressed with the quality of tooling or clients yet. Their Debian package documentation is incorrect and commands tell you to… run the same command you just ran. I haven’t seen a client I’ve been terribly impressed by either; Riot is your typical Electron fare.
The electron wrapper is completely optional, why do so many people say such things, that’s unfair :( I just use it as a pinned tab in Firefox.
Even without the performance concerns of Electron or running in the browser, there’s still the fact these overgrown web apps feel alien in UX on every platform.
I’ve found it to be very unperformant and laggy.
Didn’t know about this. Thanks for the tip.
The IRCv3 working group is attempting to standardise a lot of interesting extensions to the old IRC protocol in a backwards-compatible manner. Amongst other things, they seem to be working on history, standardised registration/authentication, and metadata such as user avatars.
[Comment removed by author]
It is, isn’t it? I am watching their repo on GitHub and get excited every time I get a notification, hoping that it’s about something major like a good history extension. If I had more time I would love to contribute. Wish they had a Patreon account, or something similar.
One aspect of Slack I’d be interested to hear any progress on is the fact that it combines chat and fileshare for groups.
Is Twitch still running this way?
Maybe if it was written in JavaScript, used a million npm packages, invented some new Json/Jose derived protocol,.. then you might have a hope.
In all seriousness, I ask myself that question all along. At work we use lync and skype for business and those still feel like a step backwards compared to old Skype, man, icq, and irc. In fact we had logging turned on for a while but the fat xml logs are up our entire email box so it was turned off company wide.
Additionally, Slack supports IRC. I just use tmux + issi to connect to Slack and other IRC networks.
Slack’s gateway is highly lossy though.
What do you mean? I haven’t had a single issue.
You lose formatting, inline replies (so you will see out of context messages), that kind of thing.
Ah, gotcha. Thanks for the clarification.
[Comment from banned user removed]
IRCcloud comes pretty close to that.
IRCcloud has a couple of interesting issues when using it in a business setup. For example, for simplicities sake, they load twitters, facebooks and stripes JS libraries into their webapp, giving third parties access to that data. We talked to them about this and they said they were looking into it, but never ended up doing something.
It’s nice otherwise, but I prefer to only use it as a bouncer. Finally, it costs ~5$, so it’s not a feasible chat for many people outside of companies.
It’s been done (minus the open source). Used to be called Convore, then changed names to Grove: https://grove.io/
In fact, they conceded defeat to Slack: https://grove.io/blog/closing-shop
[Comment from banned user removed]
Those are really hard to iterate on without a lot of people. You’d have a hard time keeping up with Slack’s fire and motion around you.
Possible though. Particularly if you used their IRC gateway to counter their network effect advantage (until they close it).
You just want a native slack client?
[Comment from banned user removed]
I think Jabber would make more sense as a modern communication platform than IRC. There’s not much that IRC provides that Jabber conference rooms don’t, but Jabber provides a lot more extensibility than IRC (especially without add-on services like Chanserv, Nickserv, etc.). In which case there are already commercial packages like Cisco Jabber and Openfire that are quite popular.
I liked PSYC back when I was comparing them directly since Jabber seemed too complicated:
http://about.psyc.eu/Jabber
http://about.psyc.eu/PSYC
Whatever we use needs to be really simple and efficient at the core. Then, layers or plug-ins for more complex stuff from there. Preferably, super-easy for library users to add or remove. What’s closest any of you know to that which has a decent chance of being converted into a Slack competitor? Other than IRC.
There aren’t many that are federated like IRC. I can only think of Jabber/XMPP and Matrix. But if you look at slack, which doesn’t seem to be federated, you have lots of options, like mattermost, rocketchat, hipchat, …
You can’t offer Slack’s UI on top of the standard IRC protocol (it lacks links, images, replies, authentication, history…). Proposals to extend the IRC protocol have not been welcomed by the IRC userbase or by established networks. You could tunnel a custom protocol over IRC with magic strings etc. but this would be inherently clunky and the user experience from any other client would be very similar to using Slack’s IRC gateway. You could publish your custom protocol but what would you gain from that? What’s the value proposition where this idea improves over what Slack offers?
[Comment from banned user removed]
Why would this “eat Slack’s lunch”? Theoretically an open protocol would make it easier for others to integrate with you, but Slack attracted plenty of integrations (which now act as a competitive advantage precisely because their protocol isn’t open). Other than that, what’s the advantage of making the protocol public?
[Comment from banned user removed]
Well I explained that that particular issue doesn’t seem to have been a disadvantage for slack, quite the opposite.
Building a protocol as an extension of IRC is inherently going to be more expensive than building it without regard to compatibility with IRC, not cheaper.
[Comment from banned user removed]
All true. And yet for so many services one might use when developing (e.g. CI), it’s so much easier to find a good Slack integration than a good IRC integration.
Not sure whether you’re talking about some specific extensions, but from what I can see there are multiple IRCv3 extensions that are implemented by common servers.
Am I the only person that uses Slack but really refuses to use the desktop app in favor of their web interface?
It just seems to work better.
Same. I fire up the electron app on my mac for voice calls (it seems to be the most reliable option, but still worse than skype for connect times + success rate) but everything else is a browser tab. Using Slack in a safari tab on my macbook makes the difference between ~10h of battery or ~4h of battery.
Interesting to hear. I use the dedicated Slack application on Linux because it seems to use fewer resources than when loading Slack inside Firefox or Chrome.
I was watching a video on Youtube the other day and part of it was the guy going over his PC specs. At one point he said “Now some of you may ask why I need 32 GB of RAM, and the answer is that I do a lot of work from this PC, and sometimes I need to have 20 Chrome tabs open at the same time for my job.”
Is this really where we are, that we need 32 GB of RAM just to keep our browser tabs open?
Yes, this is really where we are. I use Safari, because it’s so much more efficient and it’s the only browser that implements color management correctly on wide gamut displays, but for some things I just need Chrome. I have 48 GB RAM and Chrome is usually consuming about 25-30 GB. Before I upgraded to 48 GB RAM, I was swapping like crazy.
That is nuts. But I guess Chrome is really an entire OS in drag & every tab is it’s own virtual machine, so 1-2Gb per running tab actually sounds about right if you think of them as full-fat VMs doing their own thing.
It’s still the most egregious waste of computing resources since the last one of course.
Slack provides IRC and XMPP bridges, but the channel admin has to enable them.
Even when they’re enabled, it can be really hard to use those as your primary interface. E.g., at my company, we do voting on things during company updates via a Slack plugin we wrote. If you’re on IRC for that, you’re SOL. (And while, yes, you could make a chatbot to handle that instead, it’d be an inferior experience. So you’d need very strongly buy-in to not using Slack before that made sense, and at that point, the whole thing’s a bit moot.)
[Comment removed by author]
Mainly for that reason I switched to a combo bitlbee + weechat + (screen + mosh + weechat-ncurses)
It was a bit long to set up everything and there are still some rough edges. But, now with about 3Mo of RAM I can chat with:
I have manually set alerts. The text use my preferred color theme. Typically the only other reason to get rid of slack is that I couldn’t have clear text on dark background.
Now my chat system feels like a calm place to discuss.
[Comment removed by author]
Two things have helped me: turning off all animations (incl. party parrot, GIFs, etc.), and reducing the number of Slacks I’m logged into from ~15 to a core 6. It’s still kind of a tire fire.
I noticed this a while back while using my 15” Macbook Pro at a coffee shop. I forgot to bring my charger and my battery was dropping like crazy. Looked at who was using all the energy and it was Slack. I don’t usually bring my charger to the coffee shop, so now I just don’t use Slack while I’m there.
My solution was to buy the paid slack version. It allows you to setup channels for each of your customers (as opposed to having separate slack groups). Memory usage is much better now. Still shitty, but much better.
Someone please build a slack, but fast, startup :)