I love the simplicity of IRC, I still use it to this day, but I have to say, I understand why IRC cannot be used for any serious team communication.
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 ...
The author specifically calls out ephemerality as a feature of IRC.
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.
Personally, the main benefit of a bouncer is not missing highlights when someone wants to turn your attention to something interesting, reading up the logs for even a single channel isn't a reasonable way to invest your time.
Which makes for an interesting dynamic, since it's the people with the most experience for whom the chat is least ephemeral, and the people who would benefit most from having scrollback who are least likely to have it set up properly.
This varies immensely per organisation so it's always kind of dangerous to generalise like this. For example: The use-case you quote does not align with my experience of (bigcorp) chats at all.
I think either you misunderstood the scope of what I meant ("I need to see what I just wrote") or I misunderstood the scope of what you meant ("I need to see what I wrote last month") when talking about logging. I should have asked for a more specific definition.
After doing some digging, it looks like there's some people working on a new spec for IRC version 3. One of the additions is the ability to request chat history from the server. Though I'm not sure when it will be implemented since it's been on the table for 4 years now.
Well there's still active discussion on how the extension should work. This needs to be squared away first since you'll need all server software and client software to agree.
> No offline history: You have to have a client/bouncer running 24/24 if you want history.
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.
Having been on IRC for maybe two decades now, I find the impermanence to be part of IRC's charm. People engage with you when you ask them what has been going on; just like in real life.
The post you're replying to isn't referring to "impermanence," it's referring to messages dropped in transit. IRC is an unreliable message transport even if all users are online and trying to listen to each other.
The most obvious version of this is a netsplit, but even single users can get isolated from the network and have all of their messages dropped without realizing it until minutes later (if ever). There's no cool name for that; it's just IRC being unreliable.
Maybe unreliability is part of the charm for you, but that bug is absolutely not a feature, and not intrinsic to being a "social protocol."
You do however get informed by the server after a netsplit has occurred... and key-up retains most of what you have said recently so achieving coherency isn't difficult, although a manual task.
Certain use cases that Slack et al cater to, you might not get to choose impermanence. There might be compliance/regulatory issues that require you to have document retention policies.
And if you have retention you need retrieval, and backups, and audit trails for access, and pretty soon you're a SAP customer suffering the Curse of Greyface.
But the lack of reliability I described a few comments up is not just a problem for 24/7 archiving. You will see it in everyday use: your connection will drop, it will take a while for a timeout to notice, and you will miss messages for that period.
Now in a real life situation you can mishear or fail to hear. But technology can make this better.
The irc userbase is pretty technical and maybe forgiving of glitches. So perhaps that is more OK there.
For the general population, the user may not know to doubt reliability, nor do I think they ought to. So I think there is value in higher reliability of delivery.
> you ask if you missed anything during the period
For high-volume, fast-paced channels this may not be appropriate. For slower channels where people rarely post anything, you constantly asking "did I miss anything while I disconnected" might be considered spam.
> I might not want a 24/7 archive
What you may or may not want has no bearing on what the technology should be capable of providing when others may require it.
Technology can, and already has, solved these problems. If that's not your cup of tea, fine, but don't impose your own use cases on others through "but it works fine for me"-ism.
> The social structure in those two examples will be very different. You would not want to do what you suggest.
I didn't suggest anybody do anything in my post. I merely postulated on scenarios where technology can (and does exist to) solve problems that aren't your own.
> IRC remains popular
I don't doubt it; in fact, I never disputed that. Further, in no way did I imply that IRC should cease to exist because other options are out there that address other peoples' needs, nor did I indicate that I think any IRC users are wrong to prefer it.
> so same to you buddy
Please keep your language respectful; your tone in that reply was nothing short of dismissive and needlessly condescending.
That's only relevant if the feature is being used between bouncers and clients with existing servers.
While this is certainly the initial deployment scenario, there's no reason in principle why you couldn't develop a server that natively supports that extension.
> 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).
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?
I think both of these are important problems (and number among the issues I alluded to in the conclusion of the article). I hope to see them improved in the future and will provide whatever support I can to IRC networks working on them.
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.
In my experience, the lounge leaks a lot of memory. After about 30 days of running, it used 8GB and the shared hoster I put it on killed it. Would definitely not recommend as bouncer.
If you have many users/channels, you can tweak `maxHistory`, which controls how many messages are kept in memory per channel for the backlog. That's where most of the memory usage comes from.
Couldn't you layer your own account management and other conveniences on top of IRC ? Like use the underlying chansrv tech for auth but add your own layer on top for password retrieval or 2FA. You could always run a server which has dedicated bots doing the bounce per user. That way you never have to auth directly with the server, etc. Maybe a little over-complicated, but it lets you use the existing tech which is already widespread.
"Because there is no real account management you don't have any proper authentication, which make administrating a channel real dodgy" I think often that lack of needing an accout is an advantage, and not a disadvantage. However, sometimes you do want some, and many IRC services include NS REGISTER and NS INFO and so on for account management; even without that, channels can be passworded if needed.
"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.
1. Use nickserv and chanserv? This is solved problem.
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 1: Most users of Slack don't even use the slash commands, so I'd say that requiring what ammounts to CLI syntax to manage channels and accounts, something you get for free in a user-friendly way in most modern communication tools, is a nonstarter.
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.
1. GUIs can be (and have been) written for channel management and other functions. There's multiple clients (or client plugins) for such functions as changing modes (with checkboxes), changing the topic, etc.
2. ZNC has plugins for push messages, or at least it did when I was using it several years ago.
My personal bouncer was configured to automatically set my away status when I went offline; alternatives include (de)voicing (in)active users, changing nickname, etc. When my bouncer had no clients connected and someone sent me a pm, it was configured to send a message to Pushbullet.
If you're not using a bouncer or the bouncer is down, services packages such as anope may include a memoserv for sending messages to offline users; on services login, memoserv will notify you of pending messages.
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.
Care to elaborate? It solves authentication for us and we are using it for 10+ years like this.
> 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.
Let me check my current znc IRC session signon: Wed Jul 18 07:43:12
> Care to elaborate? It solves authentication for us and we are using it for 10+ years like this
If "we use plaintext passwords communicated to a faux user" is your idea of "solved" then we have very different standards.
> Let me check my current znc IRC session signon: Wed Jul 18 07:43:12
Congrats on being rich and lucky I guess? That's not a thing most folks can replicate at scale. I have had more than one IP address in the duration of writing this post.
> If "we use plaintext passwords communicated to a faux user" is your idea of "solved" then we have very different standards.
plaintext? In our use case TLS usage is mandatory and passwords are not stored in plaintext. I think your knowledge about how IRC is used now is a little outdated.
> Congrats on being rich and lucky I guess? That's not a thing most folks can replicate at scale. I have had more than one IP address in the duration of writing this post.
VPN -> znc -> IRC
You don't need to be rich and lucky to replicate this. Signon time was from znc to irc, not from my home connection to irc.
Plaintext negotiation is my complaint. I doubt we'd be discussing this if it was plaintext storage. Not even the most fanatical IRC proponent would be okay with that.
> TLS usage is mandatory and passwords are not stored in it plaintext. I think your knowledge about how IRC is used now is a little outdated.
> VPN -> znc -> IRC
Where is your znc hosted? How much does it cost? Are you paying for a VPN service (please no)?
Even having a decent in-home internet connection, a way to route traffic back into your network, and a raspberry pi to host it on is a tall order.
You can do all that over an encrypted connection [1] if you like. All this protocol nitpicking kind of ignores that IRC is a stack that is a) open to a multitude of clients and thus use cases (vs. all those fancy web-things that offer me either lockin and emojis or a lack of user base) and b) proven over decades. Yeah, it has it's inherited edge cases and downsides but this thread makes it seem like it's a stupid idea somebody came up with in 2 hours, which it is absolutely not.
It's not that it's stupid. It's that it's antiquated in a bad way. The network architecture of server networks is similarly ridiculous by modern standards.
Yeah, sorry, I guess I just don't get this animosity towards a protocol that, to me, still has a bunch of upsides over other alternatives that actually have a userbase (again, userbase that's relevant to me). IRC and the associated ecosystem might be ancient but it feels like it adopts (slowly but surely) and puts me more in control than the weird commercial alternatives that crop up every few years. With the added bonus of still running after decades instead of going under and burrying my data (or putting workload on me).
The network architecture was ridiculous 20 years ago, it still works. That's one of those things where I feel like "cool, if it's really broken enough, write a new backend and maintain compatbility to my stuff. I'm a user and don't care about your architecture". I'll gladly admit that there's a non-trivial amount of nostalgia in that logic though. :)
You can run your own matrix servers and they address most of the issues you can find with IRC. It's true that for a short while Matrix had some privacy concerns, and I'm relieved that they're being answered within a reasonable timeframe.
IRC's network architecture only survives because people tolerate it. Even slightly animosity from the community brings it down hard every time.
I think what's valuable is the chatroom model, which is largely dead outside of Telegram (which is, I agree, unusable from a user privacy and control standpoint). Part of the reason I'm passionate about this is that I want the model to be robust and well-maintained. I am nostalgic for the model, but I view the underlying legacy implementation as an obstacle to the preservation of that model.
Interesting points, thanks. While I don't necessarily agree with some of the details I actually like that passion. Maybe I'll have to give Matrix a more honest try, always figured I will do that when I happen upon a community that uses it. Hey, at least I seem to be able to use that in my irssi and not some half-backed shiny web app.
> Actually I wondered if that might be the case so I checked TFM: https://freenode.net/kb/answer/registration
Plaintext negotiation is my complaint. I doubt we'd be discussing this if it was plaintext storage. Not even the most fanatical IRC proponent would be okay with that.
We are running our own IRC servers and you can't connect without using TLS, I still don't know what's your issue is with the registration ? You would need to have access to the machines that are running IRC servers to use that information. It's like saying that none of the standard authentication over the internet (login + password to your bank, your slack account, google cloud etc) using encrypted connection is not secure because you are entering password in plaintext.
> Where is your znc hosted? How much does it cost? Are you paying for a VPN service (please no)?
It's hosted at one of the largest datacenters in Europe. We are not using cloud. Cost is low, very low, compared to Google cloud/AWS we are paying around 50x times less for our whole infrastructure. But we digress now from the main discussion.
> Are you paying for a VPN service (please no)?
We are running our own VPN servers on dedicated hardware.
I agree with you on persistent logs, but I authenticate with an SSL client certificate, not a password. This is supported by several networks. Also, what do you mean by "plaintext"? Good id services will store a hashed password and the irc connection can be over SSL. That's no more plaintext than any web service login.
The difference being that there are absolutely no better options. Everyone agrees the login form model is insufficient and that's why anyone who takes personal security seriously now introduces a lot of infrastructure around their logins.
But aside, it seems like not all networks support TLS logins?
As it stands, I have no IRC equivalent of a 2FA key. I present a plaintext token and hope that it's all handled properly and that I'm not a victim of a password reuse attack.
Any web based solution is light years ahead on this.
> As it stands, I have no IRC equivalent of a 2FA key. I present a plaintext token and hope that it's all handled properly and that I'm not a victim of a password reuse attack.
> Any web based solution is light years ahead on this.
That's also the case for 99% of authentication in the web context. 2FA adoption is on the rise but by no means the standard. If it was a thing users asked for, there's no protocol reason a nickserv service and clients couldn't adopt a 2FA flow, even without breaking backwards-compatibility.
1 is trivially solvable on the server side by requiring TLS+SASL
2 is trivially solvable on the server side by writing logs
IRC is a protocol, not a product, and an IRCd author can add these features. The fact that it has not been done speaks to the demand for these features.
I would not call running those services "trivial", but yes. If you bolt actual authentication onto something below L7 of the protocol, then you get real authentication. However, it's difficult for permission models to properly integrate with this, which is why many servers still support nickserv.
> Logs
Yes if you sacrifice all privacy you can patch over this problem by running a local bot and then using extra software to republish it. I suppose that is a valid, if unsatisfying, answer.
> IRC is a protocol, not a product, and an IRCd author can add these features.
Except that to directly address these issues within the framework of IRC is impossible. Folks just push any problem they don't feel like solving down the stack, or hand tweaking of their IRCd in ways that most clients won't respect.
Using IRC to build a protocol (as anything other than the shallowest integration for a more robust chat backend) seems to be extremely niche.
>The fact that it has not been done speaks to the demand for these features
Alternative hypothesis: it's much easier to just go build something else rather than listen to folks list off a string of excuses rather than just amicably agree it's a nostalgia thing and it's not for everyone.
>However, it's difficult for permission models to properly integrate with this, which is why many servers still support nickserv.
freenode and Rizon both support SASL, and UnrealIRCd has support built in[1]. It's not 'bolted on' as you claim, and many networks support it.
>Yes if you sacrifice all privacy you can patch over this problem by running a local bot and then using extra software to republish it. I suppose that is a valid, if unsatisfying, answer.
You can add a module to an IRCd to log on the server. This is ideal in a work situation where people know they're being logged. This is not a client side method as you seem to imply.
>it's not for everyone
Nobody, especially the most 'hardcore' of IRC users I've met, would contend that everyone should be using IRC. Rather, what they're contending is that IRC has technical limitations and the people that use IRC _prefer_ having those technical limitations because their use does not require those features.
>Yes if you sacrifice all privacy you can patch over this problem by running a local bot and then using extra software to republish it. I suppose that is a valid, if unsatisfying, answer.
I don't understand, is this referring to running company chats on EFNet or Freenode or something? IRCd can be run locally, on an inside server or other controlled execution environment.
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 ...