The IRC protocol is simple enough that it wouldn’t be so bad to break backwards compatibility; clients can catch up quickly. If anything, with simple tweaks, client development can be simplified further. For instance, you could take the guesswork out of the message’s maximum length by treating the sender’s hostname [as seen by the server] as meta-message that doesn’t count toward the 512 character limit.
Suggest the correct tags here are networking and api, as this extends beyond unix and is more a technical problem than a culture one.
That said, I’m a little curious about some of the extra features (SASL, avatar icons, etc.) being introduced. Part of the unreasonable success of IRC is probably due to it punting on a lot of features.
A lot of the features, including avatar icons, seem to be a response to Slack. If this is what it takes to stop Slack from taking over, so be it. Displaying icons would still be up to the client.
SASL is supported as an extension by most major IRCds and networks already. Although now is probably not a good time to point out that multiple IRCds had a major vulnerability related to SASL support just a few weeks ago.
A lot of the features, including avatar icons, seem to be a response to Slack.
Who cares about Slack? I’d much rather my irc client didn’t have any icons, and I’d also rather it didn’t use 200MB of memory, like Slack. If IRC decides to clone Slack exactly, nobody will use it at all.
Edit: on the topic of SASL, I don’t know why nobody is talking about certFP. imo, it is much more convenient.
The projects using it or actively switching to it and the people who use it (willingly or otherwise) because projects they contribute to are using it.
I’d much rather my irc client didn’t have any icons, and I’d also rather it didn’t use 200MB of memory, like Slack. If IRC decides to clone Slack exactly, nobody will use it at all.
Me to, which is why I would rather an open standard like IRCv3 succeeds, but blocking our ears and going lalala isn’t going to stop people and projects switching if Slack has features they want and IRC doesn’t – and projects are adopting Slack, so clearly it does.
At my workplace I set up some UNIX user accounts, configured each to run a not-visible tmux with irssi inside it and ircd running on localhost. I created PuTTY sessions that let people log in directly and configured to flash the PuTTY window whenever they had a notification. I also wrote up some basic chat rules and documented switching channel windows, scrolling through history with pageup and pagedown, etc.
But people wanted emojis and had other emotional responses to IRC, so now we’re running Slack with no agreed upon chat rules, and it’s a mess. No one complains anymore, though.
I can see why some people might not like to use irssi at work (personally I can’t think of a more attractive proposal) – maybe hexchat or pidgin would make people happier… Or even something like this.
The only thing I really miss from IRC is server side logging and infinite scrollback, honestly. None of the features here are terrible, but they’re not solving any serious issues I have with IRC as of today.
I’m aware that IRCv3 had been looking at this at one point, but I’m disappointed that I see nothing on it on this page.
I am all for a refreshed IRC to take back async chat from Slack… the UI for Slack is so slow on jessie/lightdm/i3 that I have problems using it effectively and just default to my Nexus6P
The IRC protocol is simple enough that it wouldn’t be so bad to break backwards compatibility; clients can catch up quickly. If anything, with simple tweaks, client development can be simplified further. For instance, you could take the guesswork out of the message’s maximum length by treating the sender’s hostname [as seen by the server] as meta-message that doesn’t count toward the 512 character limit.
Suggest the correct tags here are
networkingandapi, as this extends beyondunixand is more a technical problem than acultureone.That said, I’m a little curious about some of the extra features (SASL, avatar icons, etc.) being introduced. Part of the unreasonable success of IRC is probably due to it punting on a lot of features.
A lot of the features, including avatar icons, seem to be a response to Slack. If this is what it takes to stop Slack from taking over, so be it. Displaying icons would still be up to the client.
SASL is supported as an extension by most major IRCds and networks already. Although now is probably not a good time to point out that multiple IRCds had a major vulnerability related to SASL support just a few weeks ago.
Who cares about Slack? I’d much rather my irc client didn’t have any icons, and I’d also rather it didn’t use 200MB of memory, like Slack. If IRC decides to clone Slack exactly, nobody will use it at all.
Edit: on the topic of SASL, I don’t know why nobody is talking about certFP. imo, it is much more convenient.
The projects using it or actively switching to it and the people who use it (willingly or otherwise) because projects they contribute to are using it.
Me to, which is why I would rather an open standard like IRCv3 succeeds, but blocking our ears and going lalala isn’t going to stop people and projects switching if Slack has features they want and IRC doesn’t – and projects are adopting Slack, so clearly it does.
At my workplace I set up some UNIX user accounts, configured each to run a not-visible tmux with irssi inside it and ircd running on localhost. I created PuTTY sessions that let people log in directly and configured to flash the PuTTY window whenever they had a notification. I also wrote up some basic chat rules and documented switching channel windows, scrolling through history with pageup and pagedown, etc.
But people wanted emojis and had other emotional responses to IRC, so now we’re running Slack with no agreed upon chat rules, and it’s a mess. No one complains anymore, though.
I can see why some people might not like to use irssi at work (personally I can’t think of a more attractive proposal) – maybe hexchat or pidgin would make people happier… Or even something like this.
Thank you. Yeah, I wasn’t sure what to use and looked up other IRC related articles.
Also you can use SASL with many clients:
https://freenode.net/kb/answer/sasl
A useful resource with regards to IRC: ircdocs.horse and modern.ircdocs.horse.
The only thing I really miss from IRC is server side logging and infinite scrollback, honestly. None of the features here are terrible, but they’re not solving any serious issues I have with IRC as of today.
I’m aware that IRCv3 had been looking at this at one point, but I’m disappointed that I see nothing on it on this page.
It’s on there; “Giving clients a standardised way to recognise, access and view chat history (provided by bouncers or servers)” which links to http://ircv3.net/specs/extensions/batch/chathistory-3.3.html
Oops. I was looking at the released specifications: http://ircv3.net/irc/
I use tmux to fake the eternal logging and I sometimes do wish that pageup would cause my IRC client to open the relevant logfile.
I am all for a refreshed IRC to take back async chat from Slack… the UI for Slack is so slow on jessie/lightdm/i3 that I have problems using it effectively and just default to my Nexus6P
What’s the benefit of this as opposed to a more “modern” protocol like matrix?
Generally the newfangled stuff has to be justified and not the other way around.
The newfangled stuff is justified by the loss of mindshare irc has experienced in favour of apps like slack or whatsapp