The two biggest pain point that I see is: 1. Because there is no real account management you don't have any proper authentication, which make administrating a channel real dodgy (even with network provided bots).
2. No offline history: You have to have a client/bouncer running 24/24 if you want history.
One thing though, because of how IRC work, you don't have the problem that other protocol like XMPP faced with multy-device sync (there is a extension for that in XMPP but, like almost every extension in XMPP, not many client support it).
Also, nowadays we should consider end-to-end encryption standard.
I feel like IRC is in the same space as email: It's a very good technology that just lack a few feature to be perfect but any project that try to replace them just end up over-bloated with features ...
If it's easy to get history people will assume everyone is reading what they're typing. This would make people feel obligated to play catch-up every time they miss some messages due to being AFK or in the zone.
By making history hard to obtain, IRC simulates real-world conversation -- you're either in the room or you're not.
Chats in organizations are specifically for when email is not realtime enough but it's important to keep a record of the conversations for some time.
https://irc.com/lets-take-irc-further
Latest update from the team: https://irc.com/blog/2019-04-Development_updates
Presumably, when some random IRCd hacker decides to spend their spare time doing so. Most of the IRCds are FOSS, no?
I would say it's even worse than this. Even if you attempt to have a client 24/7, the lack of an acknowledgement and re-transmit on lack of acknowledgement means that if you have any hiccup that causes you to need to reset the TCP connection, you can drop messages.
It's statistically guaranteed to fail, and IRC as a protocol spec is powerless to do anything other than shrug.
That's not really an issue of IRC itself, but the IRC network you are using.
Running your own IRC server would solve that issue - ngircd for instance supports authentication using PAM or inspircd can directly perform authentication against either LDAP or a SQL database.
And doesn't IRCv3 SASL authentication + only allowing registered users into the channel pretty much solve the issue as well?
However, if you're going to run your own IRC server you can also run your own bouncer service. Lots of authentication options exist as well. IRC is totally fine for an org who can stand up a server. It's pretty low-maintenance too.
[1] - https://thelounge.chat/ https://github.com/thelounge/thelounge
"You have to have a client/bouncer running 24/24 if you want history." Or a logging bot, which some channels have. Another alternative is for the logging to be part of the server implementation; I have once done this, and it is possible, but it does not seem to be common (although I think maybe it should be done more).
Another thing about IRC is that it can be used without any kind of special software (although software specifically for IRC is still useful; for one thing, if you do not have a IRC client then you must manually respond to pings). It isn't too complicated; Matrix and Discord and so on are too complicated.
IRCv3 has support for this: https://ircv3.net/specs/extensions/batch/chathistory-3.3.htm... and at least InspIRCd (a major server implementation) implements it.
2. This is also a solved problem, there are bots that log everything on the channel and then you can read/search through channel history from web interface. But mostly this is not needed as you can just spin znc for whole your team.
Re 2: ZNC works, but is a really trash user experience from both sides. For instance, you never really know if someone is there or not. Also no push messages, which breaks the "get this person's attention" thing that most people use it for.
And you get the same problem if for some reason the bouncer loses connectivity.
2 is a problem with the architectural decisions modern IRC has inherited. It cannot be fixed because it depends on persistent TCP connections and that is not the way the internet works.
ihabunek [m] sent a long message: < https://matrix.org/_matrix/media/blahblahblah >
ihabunek [m] uploaded an image: image.png (39KB) < https://matrix.org/_matrix/media/blahblahblah >
The truth is, IRC folks do need to share long snippets and images, and they do it by linking to them; that's exactly what Matrix does when integrating with IRC. That's one among many reasons that Matrix is better than IRC.
I have seen a user who had half their messages replaced by a link, that was unreadable.
https://lists.sr.ht/~sircmpwn/public-inbox/%3Ca6e64b69-c0cf-...
> When one side sees it embedded in the chat but the other side sees it as a link, it affects how the former uses the feature and how the latter perceives the former, in ways that could be unexpected to the former. The point of my article is that these features have a social effect which is not necessarily positive.
How does it affect it? What ways? What social effect?
This explanation is totally devoid of any concrete examples of a mismatch of expectations and resulting social effects, it just alludes to them existing without any concrete basis - essentially weasel wording.
I think this could prove to be a good compromise. https://i.imgur.com/O1qw0dI.png
It's what users already do, but without having to pop a new tab, head to imgur, upload the image, and copy paste it back etc.
I'm always baffled when I see that the Signal client package is like 80MB on desktop and lacks basic functionality and configurability while irssi is barely 1MB, extremely lightweight and effectively endlessly configurable. Let's not even talk about Discord which manages to lag severely in Firefox on my high-end gaming PC.
I personally just $ cp whatever.jpg ~/www/ because I host my static site from my home connection and have for 20 years. I know self-hosting is not for everyone but everyone self hosting would literally solve all the problems of the web.
...and a ton of hate.
Yeah, lets just forget how painful it was for non english speaking users to use IRC. 255 characters for unicode and 510, but you have to guess encoding.
This is why one of the major Thai IRC networks were stuck with TIS-620 for a long time (ThaiNet/irc.thai.com, though I'm not sure if this is still the case) which is 8-bit compatible with ASCII (uses 0xA1 to 0xFB for Thai characters).
But apart from that, I've certainly had my share of truncated messages, both in German and English. Sometimes you want to express a thought in full in several sentences without twenty other channel messages appearing in between the sentences while you're typing.
Once we have some sensible way, then clients can sensibly opt to pop a dialog for new users allowing them to register an account with nickserv without having to fiddle away in a query.
Unless you regard it as inane.
Throwing reaction gifs at a happy birthday/congratulation post is one thing.
Throwing them into the oncall production ops channel and context switch everyone so they can see Homer back into a hedge is another.
Humor is subjective. All you have to do is reference "Office Space"'s "looks like somebody has a case of the Monday's!" scene to realize she thought it was funny, the "someone" did not.
I'm pretty sure Dinnerbone was around 18? at the start of Bukkit.
I help run a irc network which was spawned out of Undernet #linux around 15 years ago, because even back then we were really unhappy with general instability and how Undernet was run. Back then, it would split or simply go down several times a day.
We were making the claim that “Undernet is dying” even back then.
A few people and #linux channel-ops legitimately asked “How hard can it be?” and surprise surprise: not very.
So here we are 15 years later, aside from some very few incidents, with almost zero downtime.
Some servers has gone, some new have arrived. Same with oppers.
But the network is still there and all the same IRC-clients and users can still reach us.
IRC is one of the best things Internet has to offer, and these days people are working furiously to avoid learning what has made it so great.
IRC is capable. It is a box of nuts and bolts that lets us communicate and build awesome bots and so on.
Bloating the protocol gives us suitability: features that are robust and can federate.
This is working well for us, without any issues for years.
Despite all these deficiencies it's still widely used – My guess is that nobody has come up with a chat medium that would replace it completely. It's still pretty much the only decentralized, push-pull, clutter free real time discussion medium.
Make no mistake, we don't want to change IRC, but we do want to take some of the sharp edges off. I'll never move away from hexchat, the client I use now, and maintaining that backwards compatibility and character for all users is a red line for us.
And it doesn't seem to me that "fixing" irc is just a matter of adding the bells and whistles, but there's some work to be done on the lower levels as well
For example, how well would irc work on mobile? Keeping logs requires a bot usually on irc as well.
I really do miss using IRC all the time. My favorite server got taken down and I never bothered to find out where everyone ran off to.
MUDs face a similar set of issues. Some new MUD frameworks skip over these by ignoring telnet and going HTML/JS.
There's an interesting third path, GMCP, which is basically treated by the server/client (once support is negotiated) as out-of-band communication. If either end can't negotiate support, you get the basic experience. As a pressure-release valve, options like this can be better than clients or servers trying to overload the primary protocol with magic messages that other servers/clients without support are still forced to digest and display.
Something like:
%M!i=//shrt.url/j3f87h38f;t=fr,bb;a=Kitten Mittens!
Finally, there is an elegant, comfortable mitten for cats.
The image upload thing, though, the convenience there is being able to just upload an image directly into the client, rather than having to deal with some external service. That's it. There isn't much preventing this from being implemented in an IRC client.
Character limits are silly and should be removed - enforce them with a moderation bot if you really have to.
Just because most modern chat services are Electron trash does not mean we should throw out every bit of convenience learned. IRC (clients) could stand to gain better text formatting and file sharing options - things that make life easier for users, and in most cases don't really affect how the actual protocol works.
I was a part of the original Eternal September in the 1980's as the Internet was opened up to undergrads. The idea of a "Reverse Eternal September" sounds super awesome! I wonder how it can be implemented? (In a limited context, not across the whole of the Internet, of course.)
The eternal september happened when the manswarm flooded in; you can't bail out the flood, but it'll drain to a lower-common-denominator cesspool if one is available, and you might be able to build a high enough tower to stay above the waterline.
This is really the only feature I miss in IRC.
In an increasingly surveillance filled Internet, the fact that what I've said in the past can't be held against me today is a feature, not a bug.
If you don’t adapt, you die. Wanna die? Sure, no one is stopping you.
And when that RFC was made, they made strong decisions about bandwidth costs. They gave up things like federation and more.
So yeah, it's time that it's revisited in making a IRC that can be federated, multiple login/endpoints without using bouncers, and more. I welcome their new RFC. And it it doesn't work, we're free to keep what we currently have.
Of course they aren't, but most people aren't like Drew Devault either. Most people don't use ancient hardware to prove some sort of point. The "Drew Devault will approve of it"-argument generally doesn't show up in a business case.
In a perverse way, I am glad that programmers come up with better and better ways to waste hardware resources. In doing so, they ensure the continued progress of the semiconductor (and battery) industry through mass market demand.
I do not believe it is a coincidence that Moore's law has slowed significantly right at the time when computers became "good enough" for the everyday user. If it wasn't for gamers spending hundreds of dollars on pushing more pixels on-screen, we'd be way behind on deep learning.
Buy a new computer, Drew.
I've purchased a number of computers over the last several decades, yet using facebook/slack is still slower and less responsive on a computer with a Core i7 processor and 16 MB of system memory and a 100 Mbps downstream connection compared with using usenet/irc on a 486 with 16 MB of system memory and a a 28.8 kbps downstream connection.
As one of these greybeards who started with 300 baud modems and text chats in the 80's, and moved onto IRC because the internet was better than BBS's, I wholeheartedly endorse the idea that the only people clinging to the UX garbagefire that is IRC are the people who are either unwilling or unable to adapt to the new reality that modern services offer so much more value than IRC will ever be capable of.
Many of the paint points are solved when using alternative clients. Alternative clients will allow you to, for example:
* Use Slack on an ancient computer
* Use TTS systems
* Not use threads (you can just dump everything in the channel)
* Not have link previews
* Use keyboard only
* Get a less distracting experience
I'm also an IRC user and I like it but I just wanted to point out the post isn't fair with Slack if only one client is evaluated.
Edit: list formatting
I mean it's not IRC where the protocol is etched on stone tablets but Slack has been thus far a good steward of their API.
The official Slack client sets the tone for usage there.