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.
IRCv3
11–20 of 97 posts
Re: IRCv3
#12Earlier quoted context omitted.
I can reverse proxy it, I can dockerize it, I don't have to modify my firewall, I can TLS-SNI vhost it, I can decouple the TLS keys from the daemon process by terminating TLS on a different container, I can connect to it from weird LANs that filter non-HTTP, I can drop the TCP connections from my mobile device without dropping my whole login session, et c.
I don't know what makes http important for reverse proxy or docker. I've reveres proxied and dockerized apps that listen on normal TCP port.
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 more common and easy.
Re: IRCv3
#13[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
Re: IRCv3
#14Earlier quoted context omitted.
I don't know what makes http important for reverse proxy or docker. I've reveres proxied and dockerized apps that listen on normal TCP port.
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…
Indeed, and it's because TCP is not meant to deal with that sort of proxy-ing and framing. HTTP is specifically an L7 protocol and that makes it a good spot to do things like framing and signalling (through headers and such).
Re: IRCv3
#15One 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 layer atop MQTT, or the existing base XMPP spec.
Re: IRCv3
#16Given 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?
Re: IRCv3
#17Earlier quoted context omitted.
I don't know what makes http important for reverse proxy or docker. I've reveres proxied and dockerized apps that listen on normal TCP port.
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…
Is proxy protocol really a terrible hack? (Ok the part where it expects the header to be in a single packet and have no other data kind of is, but that usually works out ok) It's a way to pass some meta data at the beginning of the session and you can configure it.
Alternatively, if your proxy and origin are on the same ethernet broadcast domain, you could just change the destination ethernet address and resend the packet as-is, or stick it in an IPIP tunnel.
Re: IRCv3
#18Given 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.
Re: IRCv3
#19Given 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.
Re: IRCv3
#20Earlier quoted context omitted.
I don't know what makes http important for reverse proxy or docker. I've reveres proxied and dockerized apps that listen on normal TCP port.
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.