[HN Gopher] IRCv3
___________________________________________________________________
IRCv3
Author : xvilka
Score : 78 points
Date : 2021-05-19 17:36 UTC (5 hours ago)
(HTM) web link (ircv3.net)
(TXT) w3m dump (ircv3.net)
| Yoric wrote:
| 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?
| floren wrote:
| 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.
| jszymborski wrote:
| Have you tried the CLI clients like gomuks[0]? They give a
| very IRC feel to Matrix imo.
|
| [0] https://matrix.org/docs/projects/client/gomuks
| Kudos wrote:
| I use Fluffychat on mobile and Fractal on Gnome. Fluffychat
| is excellent, but Fractal is still lacking e2ee support
| (there's a rewrite on the way with support already in place).
| gpanders wrote:
| > 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.
| alekratz wrote:
| It helps that IRC is extremely simple. Most servers you can
| connect to and chat using telnet if you're so inclined.
| Arathorn wrote:
| Matrix is pretty simple too; one HTTP hit to send a message;
| one HTTP hit to receive a message. c.f.
| https://news.ycombinator.com/item?id=20949477
|
| 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).
| dang wrote:
| A couple of past threads:
|
| _IRC v3_ - https://news.ycombinator.com/item?id=12671063 - Oct
| 2016 (217 comments)
|
| _IRCv3_ - https://news.ycombinator.com/item?id=11005999 - Jan
| 2016 (77 comments)
| sneak wrote:
| 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.
| tastyfreeze wrote:
| What upgrades do you think should be added? I miss the
| environment of IRC 25 years ago. Its something that no
| messenging application has really been able to replicate for
| me.
| pantalaimon wrote:
| What's the advantage of using HTTP?
| sneak wrote:
| 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.
| swiley wrote:
| 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.
| sneak wrote:
| 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.
| toast0 wrote:
| 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.
| progval wrote:
| > 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.
| Karrot_Kream wrote:
| 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).
| metroholografix wrote:
| Not everything has to run on top of HTTP or use json.
|
| IRCv3 gets a lot more right than wrong.
| otherflavors wrote:
| Many modern IRCDs expose a websocket connection, if that's HTTP
| enough
| secure wrote:
| RobustIRC does this:
| https://robustirc.net/docs/robustsession.html
|
| (Disclaimer: I'm a developer of RobustIRC)
| danieloaks wrote:
| 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.
| disposekinetics wrote:
| 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.
| Karrot_Kream wrote:
| 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.
| VectorLock wrote:
| I've interacted with IRC servers via telnet a ton of times.
| But overall I think that era of protocol design is
| unfortunately long passed (looking at you SMTP)
| t-writescode wrote:
| Writing bots from scratch in a new language is more fun when
| parsing is easy.
| mjevans wrote:
| 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.
| [deleted]
| zokier wrote:
| > 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
| Macha wrote:
| However, many of them support independently some of the
| features that IRCv3 is merging in, such as SASL, SNI,
| capability negotiation, etc.
| danieloaks wrote:
| 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.
| xeeeeeeeeeeenu wrote:
| 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
___________________________________________________________________
(page generated 2021-05-19 23:01 UTC)