Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IRCv3

ircv3.net

Post reply on HN
Print view View original

31–40 of 97 posts

Re: IRCv3

#31

Post by xeeeeeeeeeeenu »

danieloaks wrote: post #27
zokier wrote: post #13

Earlier quoted context omitted.

> 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 can't speak for their possible ircd transition plans but OFTC's been working on https://solanum.chat which has a wide range of IRCv3 support.

Libera (de facto successor of freenode) is already using it:

    21:43 [libera] -!- Your host is zirconium.libera.chat[46.16.175.175/6667], running version solanum-1.0-dev
Also, I'm not sure how up to date it is, but here's the list of networks that support at least some subset of IRCv3: https://ircv3.net/support/networks

Re: IRCv3

#32

Post by mjevans »

disposekinetics wrote: post #11

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.

The last time I looked at IRCv3 I was disappointed by how much was an optional extension.

My opinion is that a strong 'minimum' protocol is critical to interoperability and opportunities for federated protocols to function well across providers. I recall that was the main, non XML, reason that XMPP failed. Of course I also dislike XML as a data storage / transmission format.

Re: IRCv3

#33

Post by Karrot_Kream »

t-writescode wrote: post #24
Karrot_Kream wrote: post #15

Earlier quoted context omitted.

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…

Writing bots from scratch in a new language is more fun when parsing is easy.

Yeah but this is such a niche usecase. Also, Matrix uses an HTTP API and almost every language at least has a binding to libcurl, so it's trivial to get something up for Matrix as well. If you're not into the ascetic appeal of writing bytes raw onto a socket, then IRC just seems silly these days.

Re: IRCv3

#34

Post by threeseed »

metroholografix wrote: post #6
sneak wrote: post #2

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.

Not everything has to run on top of HTTP or use json. IRCv3 gets a lot more right than wrong.

If you want adoption within the enterprise then you really need to use HTTP.

And these days even most SMBs are taking network security seriously and blocking non HTTP ports.

Re: IRCv3

#35

Post by sneak »

danieloaks wrote: post #28
sneak wrote: post #2

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.

For what it's worth, we've been throwing around a websocket standard that should be supported across a range of servers. On the decoupling sessions from the TCP connection side, the server that I work on (Oragono https://oragono.io ) does this by default, and I've heard that InspIRCd has plans to do work on this issue as well. Definitely a lotta fun stuff in this area.

Websockets over http over sockets is silly. There's no point in moving a socket based protocol to a websocket; if you're going to change it, make it just use HTTP and skip the terrible hack that is websockets in the first place.

I like oragono and also wrote an ircd in go, and was inspired a bit by some of the project's code.

Re: IRCv3

#36

Post by badsectoracula »

gpanders wrote: post #23
floren wrote: post #18

Earlier quoted context omitted.

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.

> 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 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.

And by "improve" everyone understands "get more complicated and bloated" :-P

Re: IRCv3

#37

Post by sneak »

secure wrote: post #21
sneak wrote: post #2

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.

RobustIRC does this: https://robustirc.net/docs/robustsession.html (Disclaimer: I’m a developer of RobustIRC)

This is super cool! Where do you irc?

Re: IRCv3

#38

Post by threeseed »

pantalaimon wrote: post #5
sneak wrote: post #2

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.

What's the advantage of using HTTP?

Whether you are in an enterprise, university, airport, internet cafe, restrictive country etc. HTTP traffic just works.

No one is going to open up non-standard ports especially not for IRC which most people aren't familiar with.

Re: IRCv3

#39

Post by sneak »

progval wrote: post #20
sneak wrote: post #12

Earlier quoted context omitted.

Reverse proxying non-http protocols and preserving the client ip back to the backing service involves a terrible hack called Proxy Protocol that IIRC haproxy invented to work around the fact that TCP-directly protocols don't normally allow you to carry metadata (like HTTP does in headers). https://www.haproxy.com/blog/haproxy/proxy-protocol/ It's messy. The tooling around TLS and reverse proxying for HTTP is much mor…

> preserving the client ip back to the backing service involves a terrible hack called Proxy Protocol No need for that, there's an IRC extension to indicate the source IP to the backend: https://ircv3.net/specs/extensions/webirc It's supported by all the major IRCd implementations these days.

Terrible hacky custom extensions like this is precisely why I just want to talk to it via HTTP.

Re: IRCv3

#40

Post by badsectoracula »

Karrot_Kream wrote: post #15
disposekinetics wrote: post #11

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…

Back when i was in highschool i wrote a few IRC clients just to learn socket programming in Delphi and later C and Java. I always appreciated how easy it is to get a simple client running.
Post reply on HN