Live data from Hacker News

IRCv3

ircv3.net

41–50 of 97 posts

Re: IRCv3

#41
post #32

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.

IRCv3 is written to be backwards compatible so it makes sense to have a ton of optional stuff - considering it is backwards compatible, everything is optional :-P.

And it makes sense, IRC is already out there and has a ton of servers and clients working, you can't split that community based on the client they're using otherwise you're just creating yet another isolated chat protocol like a ton others before it.

Re: IRCv3

#42
post #39
post #20

Earlier quoted context omitted.

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

How is this more hacky than X-Forwarded-For + X-Forwarded-Host + X-Forwarded-Proto?

Re: IRCv3

#43

Earlier quoted context omitted.

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.

So let those who need it use existing HTTP IRC gateways or write their own. IRC is flexible enough to accommodate this which is testament to how resilient and extensible the protocol has proven to be over the decades.

I see no reason whatsoever to make HTTP a core requirement.

Re: IRCv3

#44

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

Yes, by innovating and giving people the user experiences they want.

IRC is a joke once you’re used to Slack, especially in an organization that uses it well.

Re: IRCv3

#45

Earlier quoted context omitted.

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.

So let those who need it use existing HTTP IRC gateways or write their own. IRC is flexible enough to accommodate this which is testament to how resilient and extensible the protocol has proven to be over the decades. I see no reason whatsoever to make HTTP a core requirement.

Which is why everyone uses Slack, Teams etc and IRC is irrelevant.

Because there wasn't enough focus on end user experience.

Re: IRCv3

#46

Earlier quoted context omitted.

So let those who need it use existing HTTP IRC gateways or write their own. IRC is flexible enough to accommodate this which is testament to how resilient and extensible the protocol has proven to be over the decades. I see no reason whatsoever to make HTTP a core requirement.

Which is why everyone uses Slack, Teams etc and IRC is irrelevant. Because there wasn't enough focus on end user experience.

"Everyone". Obviously not. Having used IRC for 25 years, I'll take excellent SNR over the sort of focus on end user experience you're talking about.

Re: IRCv3

#47

Earlier quoted context omitted.

Which is why everyone uses Slack, Teams etc and IRC is irrelevant. Because there wasn't enough focus on end user experience.

"Everyone". Obviously not. Having used IRC for 25 years, I'll take excellent SNR over the sort of focus on end user experience you're talking about.

> I'll take excellent SNR over the sort of focus on end user experience you're talking about

The kind of SNR that causes an attempted takeover? As IRC has depopulated it's been increasingly inhabited by a particular type of person and has a particular culture. That's fine, but ascribing some technical superiority to it because of your cultural preferences doesn't make sense. IRC attracts a certain type of user who persists despite its UX; it's not technologically superior. The rest of us who aren't in that culture go elsewhere, to a network that fulfills our needs. Like Matrix (or even XMPP for some).

Re: IRCv3

#48

Earlier quoted context omitted.

"Everyone". Obviously not. Having used IRC for 25 years, I'll take excellent SNR over the sort of focus on end user experience you're talking about.

> I'll take excellent SNR over the sort of focus on end user experience you're talking about The kind of SNR that causes an attempted takeover? As IRC has depopulated it's been increasingly inhabited by a particular type of person and has a particular culture. That's fine, but ascribing some technical superiority to it because of your cultural preferences doesn't make sense. IRC attracts a certain type of user who pe…

>The kind of SNR that causes an attempted takeover? As IRC has depopulated it's been increasingly inhabited by a particular type of person and has a particular culture.

If you mean anime subbers, 4channers, and the warez/pirate crowd , they've all moved to Discord or Telegram. The only ones left are the technically inclined folk who adopted the platform at its genesis (i.e. #c, #perl, etc.)

Re: IRCv3

#49

Earlier quoted context omitted.

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.

This should fix the “broken enterprise network” problem:

https://www.stunnel.org/

Listen on port 443; problem solved until they switch to server allow lists.

Re: IRCv3

#50

Earlier quoted context omitted.

"Everyone". Obviously not. Having used IRC for 25 years, I'll take excellent SNR over the sort of focus on end user experience you're talking about.

> I'll take excellent SNR over the sort of focus on end user experience you're talking about The kind of SNR that causes an attempted takeover? As IRC has depopulated it's been increasingly inhabited by a particular type of person and has a particular culture. That's fine, but ascribing some technical superiority to it because of your cultural preferences doesn't make sense. IRC attracts a certain type of user who pe…

You're being disingenuous. IRC has been right at the center of the vast majority of non-enterprise technical communities and especially opensource for the last 25 years.

Say what you will about culture but this is a fact and I don't see it changing. Slack and Teams are gimmicks at best. Matrix unusable for me, every single one of my peers and, apparently, the vast majority of said technical communities that keep their center of operations firmly entrenched in IRC.

Post reply on HN