21–30 of 97 posts
I really want the IRC protocol to decouple its sessions from the TCP connection and move to using HTTP as a transport, even if the only api verb is "send" and the only response is "receive output buffer". I used to really love IRC, and think it could undergo a resurgence given the right upgrades.
(Disclaimer: I’m a developer of RobustIRC)
Given that Matrix seems to be quite successful these days, and afaict is basically a next-gen IRC, is there any compelling reason to push IRC?
Because Matrix basically has one decent server implementation and one decent client, both provided by the same company, and even that client is some godawful Element thing. I run a Matrix homeserver and use it daily but frankly, I prefer IRC.
Given that Matrix seems to be quite successful these days, and afaict is basically a next-gen IRC, is there any compelling reason to push IRC?
Because Matrix basically has one decent server implementation and one decent client, both provided by the same company, and even that client is some godawful Element thing. I run a Matrix homeserver and use it daily but frankly, I prefer IRC.
This is a fair criticism, but IRC is decades old while Matrix is what, 3-5 years old? Give it time and choice of clients and servers will only improve.
One of the things I really appreciate about IRC is the raw simplicity of the protocol. I hope that does not get lost in an effort to modernize.
I don't really care much about the protocol myself. I'm never going to be speaking "raw IRC" at any point, so why does it matter? I understand that you want to keep protocol simplicity high to make it easier on implementers, but other than just enough to encourage implementation, I don't see the need. We're talking about human chat applications here. Machine chat can use simpler protocols of course, like a light laye…
One of the things I really appreciate about IRC is the raw simplicity of the protocol. I hope that does not get lost in an effort to modernize.
I don't really care much about the protocol myself. I'm never going to be speaking "raw IRC" at any point, so why does it matter? I understand that you want to keep protocol simplicity high to make it easier on implementers, but other than just enough to encourage implementation, I don't see the need. We're talking about human chat applications here. Machine chat can use simpler protocols of course, like a light laye…
Given that Matrix seems to be quite successful these days, and afaict is basically a next-gen IRC, is there any compelling reason to push IRC?
It helps that IRC is extremely simple. Most servers you can connect to and chat using telnet if you're so inclined.
As others have pointed out, there's also a pretty decent range of very usable "daily driver" clients these days (Element, weechat, FluffyChat, nheko, Quaternion, NeoChat all spring to mind). 2nd generation servers are also progressing well (Dendrite in Go & Conduit in Rust).
[deleted]
> Oh nice it appears to be the active version now As far as I know, none of the big classic IRC networks (IRCnet, EFnet, Undernet, OFTC) have transitioned to ircv3
I really want the IRC protocol to decouple its sessions from the TCP connection and move to using HTTP as a transport, even if the only api verb is "send" and the only response is "receive output buffer". I used to really love IRC, and think it could undergo a resurgence given the right upgrades.
Given that Matrix seems to be quite successful these days, and afaict is basically a next-gen IRC, is there any compelling reason to push IRC?
Because Matrix basically has one decent server implementation and one decent client, both provided by the same company, and even that client is some godawful Element thing. I run a Matrix homeserver and use it daily but frankly, I prefer IRC.
[deleted]
> Oh nice it appears to be the active version now As far as I know, none of the big classic IRC networks (IRCnet, EFnet, Undernet, OFTC) have transitioned to ircv3