Absence of certain features in IRC considered a feature(drewdevault.com)
drewdevault.com
Absence of certain features in IRC considered a feature
https://drewdevault.com/2019/07/01/Absence-of-features-in-IRC.html
221 comments
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.
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.
If I wanted real world conversation, I can drop into a conference call, I don't need IRC for that.
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.
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.
> Chats in organizations are specifically for
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.
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.
So your bigcorp does not require any chatlogs or did they phase out email entirely for chat? Or both?
Logs for regular chat are removed after a very limited amount of time.
So you do need logs, just not forever.
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.
And then lots of people have bouncers to be there 24x7.
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.
It's not about scrolling up, it's about search. Which is another thing that IRC, even with a bouncer, is not good at.
> reading up the logs for even a single channel isn't a reasonable way to invest your time.
I'm beginning to feel this way about everything. Reddit, Twitter, social media in general...
The hoarder mentality likes for this stuff to still exist in the hopes it might one day be useful. In fact, it has very little value.
Snapchat got it right when they started with ephemerality.
I'm beginning to feel this way about everything. Reddit, Twitter, social media in general...
The hoarder mentality likes for this stuff to still exist in the hopes it might one day be useful. In fact, it has very little value.
Snapchat got it right when they started with ephemerality.
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.
One of the nice things about the IRC bridges between Matrix and big IRC networks is that you can experience IRC from the comfort of Matrix.
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.
https://github.com/ircv3/ircv3-specifications/milestone/4/
https://github.com/ircv3/ircv3-specifications/milestone/4/
IRCv3, InspIRCd, and other IRC projects are now getting funding to push their development.
https://irc.com/lets-take-irc-further
Latest update from the team: https://irc.com/blog/2019-04-Development_updates
https://irc.com/lets-take-irc-further
Latest update from the team: https://irc.com/blog/2019-04-Development_updates
> Though I’m not sure when it will be implemented
Presumably, when some random IRCd hacker decides to spend their spare time doing so. Most of the IRCds are FOSS, no?
Presumably, when some random IRCd hacker decides to spend their spare time doing so. Most of the IRCds are FOSS, no?
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.
https://github.com/ircv3/ircv3-specifications/pull/393
https://github.com/ircv3/ircv3-specifications/pull/393
> 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.
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.
Indeed, the dependence on a persistent connection itself is an absolute non-starter for this feature.
It's statistically guaranteed to fail, and IRC as a protocol spec is powerless to do anything other than shrug.
It's statistically guaranteed to fail, and IRC as a protocol spec is powerless to do anything other than shrug.
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.
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.
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.
It's a social protocol.
It's a social protocol.
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."
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 are correct. IRC is not airtight.
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.
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.
I did change careers to escape that...
I did change careers to escape that...
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.
Now in a real life situation you can mishear or fail to hear. But technology can make this better.
I meant to address the second issue you bring up; that you ask if you missed anything during the period.
I might not want a 24/7 archive. Especially not for all the silly things I said in my teens.
I might not want a 24/7 archive. Especially not for all the silly things I said in my teens.
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.
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.
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.
IRC remains popular, so same to you buddy.
IRC remains popular, so same to you buddy.
> 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.
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.
For chat persistence, you can use TheLounge [1]
[1] - https://thelounge.chat/ https://github.com/thelounge/thelounge
[1] - https://thelounge.chat/ https://github.com/thelounge/thelounge
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.
https://thelounge.chat/docs/configuration#maxhistory
https://thelounge.chat/docs/configuration#maxhistory
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.
You can layer OTR over IRC, if you wish.
"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.
"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.
> 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
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.
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.
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.
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.
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. 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.
1: At the client level, sure. Where's the ChanServ/NickServ/OperServ GUI (that interoperates with the 5 or 6 most common service packages?)
2: Which ties right back into point 1 that setting this up is not user-friendly.
2: Which ties right back into point 1 that setting this up is not user-friendly.
1 doesn't really solve the problem.
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.
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.
> doesn't really solve the problem.
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
So almost a year.
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
So almost a year.
> 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.
> 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? 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? 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.
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.
> 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.
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.
> 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.
> Actually I wondered if that might be the case so I checked TFM: https://freenode.net/kb/answer/registration
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.
[1] https://freenode.net/kb/answer/chat
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.
[1] https://freenode.net/kb/answer/chat
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. :)
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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. 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?
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?
The article here claims that IRC is better than Matrix because Matrix supports pasting long snippets and IRC doesn't. The author furthermore claims that Matrix users are being a "nuisance" by posting long snippets to IRC with a link fallback, like this:
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.
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.
The issue with the "long message" thing is not pastes; it's that Matrix is misconfigured by default. When a user types a short but multi-line message, Matrix forces IRC users to click the link to see it, whereas sending multiple messages to IRC would be better. Or the beginning of the message, then the link, so at least we know if we're interested in the content.
I have seen a user who had half their messages replaced by a link, that was unreadable.
I have seen a user who had half their messages replaced by a link, that was unreadable.
I expanded on this here:
https://lists.sr.ht/~sircmpwn/public-inbox/%3Ca6e64b69-c0cf-...
https://lists.sr.ht/~sircmpwn/public-inbox/%3Ca6e64b69-c0cf-...
That seems like an extremely handwavy motivation, not much of an elaboration.
> 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.
> 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.
Worth drawing attention to: many users are familiar and comfortable with the way that Twitter handles embedded content, which is more-or-less the solution that you said would be "less of a concern for you".
I think this could prove to be a good compromise. https://i.imgur.com/O1qw0dI.png
I think this could prove to be a good compromise. https://i.imgur.com/O1qw0dI.png
It isn't that the features don't exist. I think most people on IRC just see the internet as their platform. Integrating image hosting into IRC seems absurd when there are perfectly good browsers and ways to host or self host images. Stuffing everything into one client, or worse, one corporation just restricts features and provides a single point of failure in both technical and censorship terms.
An example of how this could work is that a client could support receiving an image. When this happens, it could upload it to an image host of choice, get the url, and send that.
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.
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've scripted things like that in irssi the past (although using scp and one server I own, not imgur, but that shouldn't be massively harder). Most IRC clients are trivially scriptable.
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'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've scripted things... Most IRC clients are trivially scriptable.
Because all people find it valuable to find out how IRC clients are scriptable, figuring out all the moving parts to the clients' scripting interface, to a third-party API (if it exists), etc. etc.
Or, you know, use Slack or Discord :)
Because all people find it valuable to find out how IRC clients are scriptable, figuring out all the moving parts to the clients' scripting interface, to a third-party API (if it exists), etc. etc.
Or, you know, use Slack or Discord :)
That's not equivalent though, with IRC scripting you can do whatever you want. With Slack or Discord you do whatever Slack or Discord allows you to do. You also don't have to worry about features becoming unavailable or gimped in the future.
It is equivalent. It is also the reason why Slack and others have taken the world by storm, and why IRC and XMPP are more or less dying. Because Slack (and FB messenger, and Apple Messages, and Discord, and... and...) provide an out-of-the-box experience immediately available to anyone (including non-programmers or programmers who couldn’t care less about scripting a yet another barebones app).
And the problems continue beyond just scripting another app. The world is mobile, and old protocols have missed the memo.
And the problems continue beyond just scripting another app. The world is mobile, and old protocols have missed the memo.
> It is also the reason why Slack and others have taken the world by storm
The same thing could have been said about messaging clients like ICQ, AIM, MSN messenger etc. vs IRC, but none of them remain while IRC is still actively used.
The same thing could have been said about messaging clients like ICQ, AIM, MSN messenger etc. vs IRC, but none of them remain while IRC is still actively used.
But why? Why add extra steps and add in having to keep the code to adapt to APIs or URL paths that change every 6 months? It's not like keeping a browser and IRC client open are mutually exclusive.
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.
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.
"Just run your own home web server to share images in chat" is the kind of self-parodic response that's made Slack so successful in contrast.
It's at the same level as "just run curlftpfs on a remote server and trivially run CVS on it" (https://news.ycombinator.com/item?id=9224). The HN crowd is quick to find a good reason why the proposed solution isn't the correct one, but unfortunately it's only true in very niche cases. When it's working for the 80% we're always complaining about it not working for the 20%.
It's really not. Everyone thinks it's super complicated and dangerous because everyone is thinking about running a webserver, a database, and some active scripting language.
Just running a webserver is dead simple. The only technical stumbling block would be forwarding the port from the router and a good chunk of internet users understand that.
Just running a webserver is dead simple. The only technical stumbling block would be forwarding the port from the router and a good chunk of internet users understand that.
> Just running a webserver is dead simple.
You can't seriously say that and talk about port forwarding in the next sentence. Some people still think internet is the web is Google is Facebook. Some people (understandably) don't want to have something running 24/7. Most people won't be able to maintain their server, turning them into the biggest botnet ever created. I'd love the internet to be more decentralized, but this is just not reasonable.
You can't seriously say that and talk about port forwarding in the next sentence. Some people still think internet is the web is Google is Facebook. Some people (understandably) don't want to have something running 24/7. Most people won't be able to maintain their server, turning them into the biggest botnet ever created. I'd love the internet to be more decentralized, but this is just not reasonable.
I can. Lets use an metaphor. Forwarding ports is the replacing turn signal bulbs in car of computing. Yes, it is too much for some people. But it is objectively simple and anyone could do it.
People who are absolutely ignorant and incapable of learning aren't who I'm talking about. Most people can learn to change a turn signal bulb.
And no, running a static webserver will not cause vulnerabilities. Again, like in my prior comment, that only happens when you use some complex combination of webserver, database, and scripting language. A static webserver is significantly more secure than opening up a page in your browser with javascript enabled.
People who are absolutely ignorant and incapable of learning aren't who I'm talking about. Most people can learn to change a turn signal bulb.
And no, running a static webserver will not cause vulnerabilities. Again, like in my prior comment, that only happens when you use some complex combination of webserver, database, and scripting language. A static webserver is significantly more secure than opening up a page in your browser with javascript enabled.
Or just send it to any of the bazillion websites that offer image hosting.
Because I want to be able to simply drag and drop an image for someone to see it immediately and not faff about with 15 extra steps of alt tabbing through browsers and copying links and waiting for uploads to finish.
There are several image hosts with tools available that make uploading as easy as passing a filename to a command or dropping it in a synced folder, so you're really just adding one step to the process of pasting an image into IRC.
Except I might not be working in a terminal, I might not have the file available locally (I personally don't have any stored on my computer). Like the poster above I'd like to drag and drop something from a tab to the conversation, and not have to deal with the steps between. That's what technology is about after all.
If you don't have it locally, then it's probably on the web with an URL, you can paste the URL directly on IRC.
The\lounge does exactly that. problem solved.
well, it's an entirely client side thing to have, so the "why" very much comes down to the developers balance on adding extra code for extra convenience. The developer might like it personally, or they might find it's a feature that their users want, or both.
As an example, I have my thinkpads prtscr button hooked up to automatically capture the screen, upload to 0x0.st, put the url into my clipboard, and then alert dunst to pop a notification that it's done.
It takes a very common 60 second process and makes it almost as fast as prtscr, ctrl+v
As an example, I have my thinkpads prtscr button hooked up to automatically capture the screen, upload to 0x0.st, put the url into my clipboard, and then alert dunst to pop a notification that it's done.
It takes a very common 60 second process and makes it almost as fast as prtscr, ctrl+v
I agree, however a simple image copy paste would see a ton of use.
...and a ton of hate.
...and a ton of hate.
> IRC messages are always lines of characters terminated with a CR-LF (Carriage Return - Line Feed) pair, and these messages shall not exceed 512 characters in length, counting all characters including the trailing CR-LF. Thus, there are 510 characters maximum allowed for the command and its parameters.
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.
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.
As a user of non-English languages, this is not really a problem in practice. We settled on UTF-8 years ago. My second language is pratically the worst case for bumping up against these limits and I never have an issue with them.
Really. So you don't think Japanese folks just don't run into problems? Or Koreans? Or anyone using a primarily upper Unicode alphabet that is phonetic?
Japanese and Chinese in particular can compress a lot more meaning in a byte than many other languages[1]. I pick up a random article at Nikkei.com[2] and calculate number of bytes of the first paragraph, and it's only 449 bytes in UTF-8[3]. Chinese is even more efficient at this, as you can basically fit the whole news in a Tweet.
[1]: Idiomatic Yojijukugo 四字熟語 is an extreme example for this, but there's non-idiom Yojijukugo too, e.g. 日米関係 is a 12 bytes word that translates to "United States-Japan relations"
[2]: https://www.nikkei.com/article/DGXMZO46571150V20C19A6000000/
[3]: It describes how people are walking around the park in Chicago on Jun 13 to catch a rare Pokemon with a one line interview of a son of Mr. Stuart from California.
(I speak three languages: Thai, English, Japanese)
[1]: Idiomatic Yojijukugo 四字熟語 is an extreme example for this, but there's non-idiom Yojijukugo too, e.g. 日米関係 is a 12 bytes word that translates to "United States-Japan relations"
[2]: https://www.nikkei.com/article/DGXMZO46571150V20C19A6000000/
[3]: It describes how people are walking around the park in Chicago on Jun 13 to catch a rare Pokemon with a one line interview of a son of Mr. Stuart from California.
(I speak three languages: Thai, English, Japanese)
This is fair, I should have thought more about the list.
For Japanese, I don't think the way people talk casually to one another is as amenable to compression as newspaper headlines
But surely for Thai you're in a sub-optimal boat?
For Japanese, I don't think the way people talk casually to one another is as amenable to compression as newspaper headlines
But surely for Thai you're in a sub-optimal boat?
This is completely anecdotal, but I have an alternative Twitter account where I interact with Japanese people I know, and I rarely hit the 140 characters limit except when I’m in a heated debate (or when I’m VERY excited about something).
For Thai, yeah, this one is a little more complicated. I’ve commented about this in sibling thread.
For Thai, yeah, this one is a little more complicated. I’ve commented about this in sibling thread.
I tried to rig up a Shavian chat group and we just hit the wall over and over. It was frustrating so we moved to Matrix.
私の二番目の言語は日本語だよ
I do operate a Korean IRC network and a message cut in the middle (often between UTF-8 boundaries, making clients guessing a wrong encoding from time to time) is a typical sightseeing.
This makes it all the more baffling to me. You get 510 a line, but for a channel with a modest name in any other language, you get much less than that.
Let's just use a modest channel name like "#𐑥𐑨𐑔 𐑯 𐑕𐑲𐑧𐑯𐑕". I've now got a base 45 bytes without any message at all. If I want to aim a message at someone I have even less than that. Your pithy reply with a similarly modest title is 20% of the total allocation for a line, half of which is just overhead.
We run into line limits talk about category theory in #haskell even in English and folks are quite good at compressing contexts. The only alternative is to slice your messages across lines and make a confusing experience for participants.
Let's just use a modest channel name like "#𐑥𐑨𐑔 𐑯 𐑕𐑲𐑧𐑯𐑕". I've now got a base 45 bytes without any message at all. If I want to aim a message at someone I have even less than that. Your pithy reply with a similarly modest title is 20% of the total allocation for a line, half of which is just overhead.
We run into line limits talk about category theory in #haskell even in English and folks are quite good at compressing contexts. The only alternative is to slice your messages across lines and make a confusing experience for participants.
I remember when this was a significant problem but with the rise of UTF-8 it is less so (even if that is strictly against the letter of the spec, it works fine in practice). Are there languages where the 510 bytes per message are a significant limitation?
I can only speak from experience, but Thai language uses 3 bytes per character in UTF-8 and rely on vowels and tone marks to compose a word, so the number of bytes can grow pretty quick. A headline of an article in Thai have a good chance of exceeding 510 bytes.
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).
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).
Isn't a major problem that the client cannot know how long the message can be because it's prefixed on the server side again (which counts into the 510 bytes).
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.
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.
Cyrillic symbols are encoded in UTF-8 with two bytes. You limited with 255 characters.
Don't most IRC clients nowadays query the max line length on connect (the capabilities output) and then just split up one message across multiple lines if you cross that limit? I haven't had to think about line length since the 90s.
Kooky "reaction GIFs" in work chat are so inane. I mean, there's certainly a time and a place for browsing funny GIFs on the web, but making it a first-class part of work chat is so juvenile it's unreal.
Tangentially, blog posts peppered with Tumblr-style gifs is the worst thing when trying to read the content. Thankfully it seems to be a trend that is dying off, but I don't understand how people read text without being distracted by the bright and bouncy gifs sandwiching it.
For what it's worth, that's not the intention on freenode's side - we want to sand off some of the rough edges. As an example, it would be nice to have a common flow for speaking to services.
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.
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.
This mindset is alien to me. Humor is a generally positive thing and can't help but improve mental state while working.
> can't help but improve mental state
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.
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.
>Throwing them into the oncall production ops channel and context switch everyone so they can see Homer back into a hedge is another.
This is part of the reason I like the "reactji" of slack / discord / etc. They don't cause a new message notification.
Because of that, they're less interruptive, and you can do some interesting, useful things. Like lightweight interaction - we "seed" an up/down arrow pair for voting, people just click one. Or controlling bots more easily - we use one to add Qs to a queue, others to shut them up when they're being noisy, or there's fancier options: https://codeascraft.com/2018/10/10/etsys-experiment-with-imm...
This is part of the reason I like the "reactji" of slack / discord / etc. They don't cause a new message notification.
Because of that, they're less interruptive, and you can do some interesting, useful things. Like lightweight interaction - we "seed" an up/down arrow pair for voting, people just click one. Or controlling bots more easily - we use one to add Qs to a queue, others to shut them up when they're being noisy, or there's fancier options: https://codeascraft.com/2018/10/10/etsys-experiment-with-imm...
How is that really any different from someone engaging in off-topic banter in an IRC channel? Humans are being human and I don't really see how the problem as you describe it is somehow specific to non-IRC mediums.
> Humor is a generally positive thing and can't help but improve mental state while working.
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.
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 just turn off notifications on Slack and only pay attention to it when I choose to. As a result, someone being silly with reaction emojis or memes in a channel just doesn't really bother me.
I'm glad Freenode has a user base for work related stuff, but I man do I miss when Undernet or Dalnet was still popular. I know I'll never run into my mother on IRC, and it is probably because of the format.
I used to run a server on Dalnet (then later on Espernet). Good times; nobody knew I was 15 so I learned a ton about programming from some smart people
I think it's the opposite; I was never accepted on Espernet precisely because they could somehow smell I was older. That community was pretty young.
I'm pretty sure Dinnerbone was around 18? at the start of Bukkit.
I'm pretty sure Dinnerbone was around 18? at the start of Bukkit.
This made me laugh, because I was quite young when I first got into it. Though I was never anything more than an op in a few channels.
As an aside since you brought up Undernet: Their CService website[1] has been down for weeks now. As far as I know, that's the only way to even register with X. I'm not sure if this is being worked around, somehow, or if UnderNet is just being left to die.
[1] https://cservice.undernet.org/
[1] https://cservice.undernet.org/
Undernet has always been flaky.
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.
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.
It amuses me a little that this mirrors how Undernet itself got started - in that case, by the ops of #hottub on Dalnet.
There's a certain whimsical botanical style to the way in which IRC networks tended to grow large enough to start budding off new networks, some of which were able to find sufficient purchase to grow large themselves and repeat the cycle anew.
There's a certain whimsical botanical style to the way in which IRC networks tended to grow large enough to start budding off new networks, some of which were able to find sufficient purchase to grow large themselves and repeat the cycle anew.
I too miss the good old days of Undernet, where Romanian criminals would show off hacked systems, or DDOS other IRC users.
I miss the wild west, sue me. My entire life wasn't on whatever system I was using, so it wouldn't have mattered if someone messed it up. I don't miss the hardware of the time, but at least the web wasn't sterilized and owned by a few companies.
Correct, today’s internet has been taken over by companies and search engines by seo spam. But if there was anyone left enjoying tue good ole days of lawlessness, irc would still be a thing.
I don't know where you went, but there are still plenty of people using IRC. Not as many as were in the past, but it's still popular enough with the crowd of people I hang around.
Out of curiosity, what servers do you frequent? Or is it more personal servers that you and your friends run?
It was a particularly good MMORPG.
I've certainly encountered channels where lack of image embedding is less of a feature and more of a mental health necessity!
Lacking support for pretty much everything other than lines of text alongside a handle enables one of my favorite aspects of IRC: a 10-row terminal is more than sufficient for the entire client UI.
This really comes back to the Capability vs. Suitability model that Gary Bernhardt has spoken about: https://www.youtube.com/watch?v=NftT6HWFgq0
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.
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.
We are running our own IRC server (UnrealIRCd + Anope for services) for 10+ years. We have bots for gitlab/github, schedulers, management bots (you can basically control whole infrastructure and all services from IRC), event logging channels, alerting, jobs/tasks bots, status checking etc. all with authentication and authorization.
This is working well for us, without any issues for years.
This is working well for us, without any issues for years.
IRCv3 notwithstanding, the protocol from a software engineering point of view is horrible. It doesn't support asynchronous operations because responses cannot be tied to their corresponding requests, and many commands, successful or not, require a human to parse. Too bad that IRCnet only runs whatever has been written down in an official IETF RFC.
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.
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.
IRC is one of the few Internet venues I still frequent. Been using it since 1998. Some years ago an important (but small, private) channel moved from EFnet to Freenode, so that is the network I now use. Seeing Freenode IRCops looking to fix what ain't broken ("but it's opt-in" they'll say..) makes me have doubts about the move. If this sounds "get off my lawn" to you, you're getting it.
You're welcome to come chat to me in ###kline over there, there's some useful upstream discussion on it here as well: https://cmpwn.com/@kline/102333166678467931
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.
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.
What are some good channels to visit in 2019? I feel like most of the ones I used to frequent are dead silent now. And my small friend channels have since moved to Discord.
I guess the programming language related ones are a good start. In my experience they have a high signal-to-noise ratio. Otherwise, it depends on your interests... you can always start your own, making sure it's good... There is/was a /list command, but I never really used it as all the good channels were at least +s ;) It's all word of mouth, really.
I think if most people saw the limitations of irc as the author then it would still be the dominant protocol
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.
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.
For mobile, I had a bouncer setup that would keep me up to date whenever someone would message or mention me. I could pull up AndChat and connect right up to all of my channels, I was never actually offline. I had an icon on my taskbar that would connect me to my VPN and pull up irssi. I see now that there is a cloud client for mobile called "IRC Cloud", it sounds like a one step setup kind of bouncer for someone that doesn't have an always online machine to run a bouncer on.
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.
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.
I agree, IRC, it is what it is, it's done, if you want something else, you want something else, not IRC.
This reminds me of what Apple does to the SMS/MMS ecosystem.
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.
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.
The idea of embedding links to multimedia is a good one. They just need to form an open standard for encoding media and rich text in text streams, and let clients parse the standard and decide how to format it. Text clients could remove any multimedia/rich text, GUI users could render it all, blind users would receive alt-tags in a way that's easily spoken by TTS, etc. Because it's a standard for encoding media in a text stream, you don't have to change the IRC protocol, just add a plugin to the client. You could even format it so the simplest clients could just strip everything but the text.
Something like:
Something like:
%M!i=//shrt.url/j3f87h38f;t=fr,bb;a=Kitten Mittens!
Finally, there is an elegant, comfortable mitten for cats.
Formatting is pure fluff - it's convenient to have bold/italic/spoiler/code tags, and it is possible to implement them in a TUI without degrading anybody's experience. Link tags are not really necessary and a lot of clients don't even have them.
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.
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 like IRC a lot. Simple, light, and a very good example of the minimalist principle that "less is more".
Anyone else still using microsoft comic chat?
It's dangerous to go alone. Take this.
https://gist.github.com/richardg867/bb19ca2b03545f71ae15
http://www.mermeliz.com/cchat.htm
https://gist.github.com/richardg867/bb19ca2b03545f71ae15
http://www.mermeliz.com/cchat.htm
P.S. A friend pointed out that the migration of non-hackers away from IRC is like a reverse Eternal September, which sounds great
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.)
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.)
Well, the the article pointed out one way... Have a community somewhat gated by the need for technical proficiency, and have a bigger, shinier, "popcorn internet" alternative (facebook) to bait the normies away from it. For example, suckless programs are configured by compiling them from source. This is for several reasons, but one explicit one is that it keeps away less technical users, keeping the userbase "small and elite".
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.
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.
Tilde servers were sort of the start in my mind of things like that, as is SDF
I only know SDF as the abbreviation of the Sol Defense Force from the Robotech anime translations.
The article doesn't talk about the best feature of Slack: a consistent message history for all the users. In IRC messages can easily get lost due to network splits or client disappearing. Not having everyone with the same message timeline can make some conversations quite awkward.
This is really the only feature I miss in IRC.
This is really the only feature I miss in IRC.
I have experienced symptoms far worse than netsplit on Slack on at least four occasions in two and a half years of usage for work, with messages getting lost, duplicated and reordered, differently in different clients, and generally with no obvious indication that things are broken, unlike with netsplit where you’d see a bunch of parts/quits signalling the problem. Eventually it decides on what I hope is a consistent history, but even that only works because the clients are slaves to the server and don’t cache things.
I don't want a coherent message history. Nicknames not being 'owned' by anybody (on servers that don't implement services) and incoherence of message histories means that deniability is still alive and well in real time communications.
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.
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.
In exchange, you have gut-wrenching systemwide outages of Slack once in a while. The CAP theorem says you can't have it both ways. News from 3 days ago: https://news.ycombinator.com/item?id=20303479
There are many ways in which I prefer IRC to Slack, and I agree with Sir_Cmpwn's general premise that some of Slack's features are more trouble than they're worth. (Slack's threaded replies are definitely one of them, and while I've seen better implementations in IRC-like systems, "just don't thread replies" is so far the best implementation I've seen.) But the problem you're describing here is arguably one of Slack's advantages, not a disadvantage.
Are you living in a world without netsplits?
Netsplits are pretty rare these days.
Yeah? I just counted six netsplits in the past 24 hours that affected a channel I'm on on IRCnet.
I still love IRC. My second home.
I still love IRC. My second home.
This is because of IRCnet is operated by multiple entities and has rather peculiar links, other networks are not like this.
http://dx.fi/alt/ircmap/fdp.png here’s a map of IRCnet, they’re really going out of their way to generate netsplits.
A network operated by a single entity doesn’t need such a silly amount of nodes, you can support hundreds of thousands of IRC uses on a single server.
http://dx.fi/alt/ircmap/fdp.png here’s a map of IRCnet, they’re really going out of their way to generate netsplits.
A network operated by a single entity doesn’t need such a silly amount of nodes, you can support hundreds of thousands of IRC uses on a single server.
Ability to remove spam messages would be awesome, these days it is very hard to deal with on a public channels. Also log out of the box. None of them are distraction. And proper authentication out of the box. Better design for poor, unstable connections, i.e.
mobile phones.
[deleted]
Perhaps a side pan for embeds makes sense. upload images or code snippets by providing irc style references in the chat while not interrupting the flow of conversation because images and whatnot are expanded on the embed pane.
Counterpoint: The lack of accessibility in Slack does not mean it shouldn't be solved. Baby with the bathwater. Why dump all of slack when instead we can work on an accessible interface.
I just use https://www.irccloud.com/ and it's the best of both wordls ¯\_(ツ)_/¯
Now let's talk about the inherent lack of a good centralized identity service, the danger of the majority of IRC servers and clients being written in C and the inefficiency of the protocol itself for applications like high latency links? We might also talk about the lack of important modern features like basic negotiation of client encoding capabilities and what an absolute tire fire DCC-based features continue to be due to the "just link to an external website" mentality that stifles all discussion of replacements?
I'm not sure if "festues" is a word I don't recognize or a typo for a word that I can't mentally correct into something I'd recognize.
This is called being stubborn.
If you don’t adapt, you die. Wanna die? Sure, no one is stopping you.
If you don’t adapt, you die. Wanna die? Sure, no one is stopping you.
Have the author tried to write bots for Matrix? It's much simpler than for IRC and doesn't require a persistent connection.
I don't think the author would agree its much simpler: https://drewdevault.com/2018/03/10/How-to-write-an-IRC-bot.h...
[deleted]
IRCv3 is a scourge because of this. They’re looking to bloat the protocol. IRC is good because it’s IRC.
IRC was made a spec in 1993. Not 2003, or even 2013.
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.
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.
What you're after is called XMPP.
No, it isn't. XMPP was designed primarily as an IM protocol to replace proprietary messengers like AIM and ICQ, not as a service for group chats. It's a flawed protocol even for IM, and its conference features verge on broken. (For example: A user's visible presence in a conference is neither necessary nor sufficient for them to send and/or receive messages in the conference.)
I love this blog. When I read it I find myself repeatedly smashing the table with my fists and shouting "YES! OH MAN, YES!".
> "Remember that not everyone is like you."
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.
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.
> Buy a new computer
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.
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.
Well, I consider stuff like the absence of server-side friend lists, server-rendered embeds and formatted messages a bug at best, though in IRC's case it's simply the lack of ability because the protocol is horribly outdated, modern approaches and limitations could afford a lot of QoL improvements.
IRC is forever tainted by graybeards that won't give up their terminal clients. People who want to get work done have moved on. The next generation of developers have no interest in IRC. It's a dead end.
I think you misunderstand the real quality of running an IRC client from anywhere on anything. I don't need to carry around a $4000 laptop to get my work done when I can use my home dev server from anywhere using a 10-year old Thinkpad junker. Break it? Pitch it and buy another for less than $100 on ebay.
Saying Slack requires a $4000 laptop is a bit of hyperbole don't you think? I've used the Slack web client on a $300 Chromebook and it was just fine.
You don't need that for Slack but if you want a quality machine to carry around to handle your workload, that's the price neighborhood.
Why should text chat need more than a 'terminal client'?
The bigger point is that 'text chat' is antiquated and unnecessarily limited, and that the advent of "richer" text chat is a gigantic improvement in communications efficiency.
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.
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.
Heaven forbid the simple chat application isn't some damn Electron app that needs 2GB of memory and burns CPU constantly.
It seems that the author references different IRC clients but at the same time ignores (can't say if on purpose or not) the fact that there are also alternative Slack clients which address many of the pain points.
But that doesn't prevent other people from relying on these features.
You mean bootleg clients that will break randomly. Meanwhile a playing visible GIF in the official client still throttles a CPU core.
I mean all IRC clients are 3rd party so I'm surprised that your sentiment towards 3rd party Slack clients is so bad. I've been using wee-slack for a while now and I have very few complaints.
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.
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.
> I mean all IRC clients are 3rd party so I'm surprised that your sentiment towards 3rd party Slack clients is so bad.
The difference between IRC and Slack is that IRC is seen as a standard protocol while for Slack the network protocol is an inofficial implementation detail and any use other than of the official client is unsupported. I'm not very familiar with Slack, but I've heard about Whatsapp users being banned just for the crime of using an alternative client. That's the difference between an open protocol and a proprietary one.
The difference between IRC and Slack is that IRC is seen as a standard protocol while for Slack the network protocol is an inofficial implementation detail and any use other than of the official client is unsupported. I'm not very familiar with Slack, but I've heard about Whatsapp users being banned just for the crime of using an alternative client. That's the difference between an open protocol and a proprietary one.
Huh? The network protocol for Slack is JSON over WebSockets and is completely documented and supported [1]. You don't need a Slack SDK to speak to Slack and can do it with any plain WebSocket library.
Obviously Slack doesn't provide support for 3rd party clients; how could they? But they do provide support to the developers of those clients using their API.
[1] https://api.slack.com/rtm
Obviously Slack doesn't provide support for 3rd party clients; how could they? But they do provide support to the developers of those clients using their API.
[1] https://api.slack.com/rtm
I'm going to remind you of this comment in 5 years.
I mean if Slack didn't end up ruining their API in the name of greater development flexibility I'm not sure I could even comprehend it.
But that's the thing, I think Slack is a fundamentally inappropriate tool for FOSS work or public communications. Anyone who stakes their long-term community on a single company's proprietary product is asking to be hurt down the road. But I don't think IRC is the right alternative because the UX is so newcomer unfriendly and requires so many disparate 3rd party services to be useful. I would much rather see communities standardize on something like Riot or Mattermost with OpenID.
Simultaneously, I think that Slack (and its contemporaries) are a breath of fresh air for internal team/office chat. Sure it's expensive, and like all corporate-y things you have to keep a little distance so you can migrate when they get shitty, but we can at least acknowledge that it's a damn slick product.
But that's the thing, I think Slack is a fundamentally inappropriate tool for FOSS work or public communications. Anyone who stakes their long-term community on a single company's proprietary product is asking to be hurt down the road. But I don't think IRC is the right alternative because the UX is so newcomer unfriendly and requires so many disparate 3rd party services to be useful. I would much rather see communities standardize on something like Riot or Mattermost with OpenID.
Simultaneously, I think that Slack (and its contemporaries) are a breath of fresh air for internal team/office chat. Sure it's expensive, and like all corporate-y things you have to keep a little distance so you can migrate when they get shitty, but we can at least acknowledge that it's a damn slick product.
The difference is that the IRC standard is decades old and stable and made for "independent" clients.
Slack is Young and evolving and driven by a single company which wants to push their client
Slack is Young and evolving and driven by a single company which wants to push their client
This is all very true but they're also a company that wants to push their API since that's where most of their stickyness comes from as a business.
IRC definitely has stability going for it but it also means it has been unable to adapt to user requirements changing over time. The most usable IRC client right now is IRCCloud which is good, but it doesn't inspire much hope because it's only usable since they completely plaster over the protocol in their UI.
In this model there's nothing special about IRC except that it's a common denominator protocol for a few networks that use it. If we were choosing a inter-network protocol I don't think anyone today would come up with IRC.
IRC definitely has stability going for it but it also means it has been unable to adapt to user requirements changing over time. The most usable IRC client right now is IRCCloud which is good, but it doesn't inspire much hope because it's only usable since they completely plaster over the protocol in their UI.
In this model there's nothing special about IRC except that it's a common denominator protocol for a few networks that use it. If we were choosing a inter-network protocol I don't think anyone today would come up with IRC.
> This is all very true but they're also a company that wants to push their API since that's where most of their stickyness comes from as a business.
This is what people said about Twitter as well ;)
And slack, for instance, discontinued their IRC gateways as that limited their possibilities to "innovate" and I can image Slack, being pushed by shareholders, restricting free add-ons to getting data into slack (from Version control, business tools, task trackers, ...) but restricting getting data out to more expensive tiers (making transition of Slack harder)
But there are the key difference between open and proprietary protocols: Open protocols are slow to evolve (see also the state of mail protocols ... where innovation happens mostly in Gmail's protocols, not SMTP/imap/...) but allow wide variety of clients, while proprietary systems can evolve faster, but are more limited in clients.
This is what people said about Twitter as well ;)
And slack, for instance, discontinued their IRC gateways as that limited their possibilities to "innovate" and I can image Slack, being pushed by shareholders, restricting free add-ons to getting data into slack (from Version control, business tools, task trackers, ...) but restricting getting data out to more expensive tiers (making transition of Slack harder)
But there are the key difference between open and proprietary protocols: Open protocols are slow to evolve (see also the state of mail protocols ... where innovation happens mostly in Gmail's protocols, not SMTP/imap/...) but allow wide variety of clients, while proprietary systems can evolve faster, but are more limited in clients.
Well yeah, I'm in no way saying that people in the OSS world should standardize on single company's proprietary protocol and platform and if IRC is the only thing people from two projects can agree to speak then it's what we've got.
But we really need to stop trying to make IRC 'work' and build something more usable that can interop with existing IRC networks (hi Matrix!). IRC is fundamentally not a good enough protocol for how people people chat today but it's easy for people who have been using it for 20 years and have a lot of pride and machismo sunk into figuring it to dismiss outsiders that are struggling and believe that if you pile enough barely-working brittleware on top that it can sorta-kinda work like Slack or Mattermost.
But we really need to stop trying to make IRC 'work' and build something more usable that can interop with existing IRC networks (hi Matrix!). IRC is fundamentally not a good enough protocol for how people people chat today but it's easy for people who have been using it for 20 years and have a lot of pride and machismo sunk into figuring it to dismiss outsiders that are struggling and believe that if you pile enough barely-working brittleware on top that it can sorta-kinda work like Slack or Mattermost.
There were attempts to replace IRC with more modern (back in those days ...) architecures. For instance jabber/xmpp. But between IRC and commercial alternatives it hardly played a role. (I see more usage of commercial jabber extensions in Cisco than jabber itself these days)
The author references different IRC clients as being societal forces that tends to curtail adoption of certain features.
The official Slack client sets the tone for usage there.
The official Slack client sets the tone for usage there.
[deleted]
To stefan's point, Slack clients are unofficial and unsupported software built on top of proprietary protocols which are subject to change at any time according to the whims of a private company which has their bottom line at heart instead of your communication needs.
So, I long for the days of the ITU when communications interoperability was mandatory, not optional.
I don't disagree with you on that - but that's not written in your post so my point still stands.
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
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
They can crack down on alternative clients at any time they want. You are living on borrowed time. A guest who is wild camping in their gated community walled garden private property.
I also agree with you. It was painful when e.g. Twitter basically killed 3rd party apps.
What happens here is that I don’t see any significant portion of Slack users moving to IRC anytime soon. Therefore, if you’re forced to use Slack, you should know that alternative clients are available as of today.
What happens here is that I don’t see any significant portion of Slack users moving to IRC anytime soon. Therefore, if you’re forced to use Slack, you should know that alternative clients are available as of today.
>I don't disagree with you on that - but that's not written in your post so my point still stands.
I kind of feel like the second-to-last paragraph of my article does address this.
I kind of feel like the second-to-last paragraph of my article does address this.
And even more so to the point, you can't self host slack and have absolute root level to the OS it's running on admin control. For somebody who knows what's they're doing it takes maybe 45 minutes to set up a basic ircd-hybrid daemon on Debian or centos.
If you use a high level language like Python you could almost write an IRC server in 45 minutes.
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 ...