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

Absence of certain features in IRC considered a feature

drewdevault.com

Post reply on HN
Print view View original

91–100 of 222 posts

Re: Absence of certain features in IRC considered a feature

#91

Post by Karunamon »

lossolo wrote: post #69
maeln wrote: post #41

I love the simplicity of IRC, I still use it to this day, but I have to say, I understand why IRC cannot be used for any serious team communication. The two biggest pain point that I see is: 1. Because there is no real account management you don't have any proper authentication, which make administrating a channel real dodgy (even with network provided bots). 2. No offline history: You have to have a client/bouncer r…

1. Use nickserv and chanserv? This is solved problem. 2. This is also a solved problem, there are bots that log everything on the channel and then you can read/search through channel history from web interface. But mostly this is not needed as you can just spin znc for whole your team.

Re 1: Most users of Slack don't even use the slash commands, so I'd say that requiring what ammounts to CLI syntax to manage channels and accounts, something you get for free in a user-friendly way in most modern communication tools, is a nonstarter.

Re 2: ZNC works, but is a really trash user experience from both sides. For instance, you never really know if someone is there or not. Also no push messages, which breaks the "get this person's attention" thing that most people use it for.

And you get the same problem if for some reason the bouncer loses connectivity.

Re: Absence of certain features in IRC considered a feature

#92

Post by abstractbeliefs »

frou_dh wrote: post #88

Kooky "reaction GIFs" in work chat are so inane. I mean, there's certainly a time and a place for browsing funny GIFs on the web, but making it a first-class part of work chat is so juvenile it's unreal.

For what it's worth, that's not the intention on freenode's side - we want to sand off some of the rough edges. As an example, it would be nice to have a common flow for speaking to services.

Once we have some sensible way, then clients can sensibly opt to pop a dialog for new users allowing them to register an account with nickserv without having to fiddle away in a query.

Re: Absence of certain features in IRC considered a feature

#93

Post by Karunamon »

frou_dh wrote: post #88

Kooky "reaction GIFs" in work chat are so inane. I mean, there's certainly a time and a place for browsing funny GIFs on the web, but making it a first-class part of work chat is so juvenile it's unreal.

This mindset is alien to me. Humor is a generally positive thing and can't help but improve mental state while working.

Re: Absence of certain features in IRC considered a feature

#94

Post by Karunamon »

slezyr wrote: post #19

> IRC messages are always lines of characters terminated with a CR-LF (Carriage Return - Line Feed) pair, and these messages shall not exceed 512 characters in length, counting all characters including the trailing CR-LF. Thus, there are 510 characters maximum allowed for the command and its parameters. Yeah, lets just forget how painful it was for non english speaking users to use IRC. 255 characters for unicode and…

Don't most IRC clients nowadays query the max line length on connect (the capabilities output) and then just split up one message across multiple lines if you cross that limit? I haven't had to think about line length since the 90s.

Re: Absence of certain features in IRC considered a feature

#95

Post by abstractbeliefs »

superkuh wrote: post #52

It isn't that the features don't exist. I think most people on IRC just see the internet as their platform. Integrating image hosting into IRC seems absurd when there are perfectly good browsers and ways to host or self host images. Stuffing everything into one client, or worse, one corporation just restricts features and provides a single point of failure in both technical and censorship terms.

An example of how this could work is that a client could support receiving an image. When this happens, it could upload it to an image host of choice, get the url, and send that.

It's what users already do, but without having to pop a new tab, head to imgur, upload the image, and copy paste it back etc.

Re: Absence of certain features in IRC considered a feature

#96

Post by ohithereyou »

KirinDave wrote: post #72
lossolo wrote: post #69

Earlier quoted context omitted.

1. Use nickserv and chanserv? This is solved problem. 2. This is also a solved problem, there are bots that log everything on the channel and then you can read/search through channel history from web interface. But mostly this is not needed as you can just spin znc for whole your team.

1 doesn't really solve the problem. 2 is a problem with the architectural decisions modern IRC has inherited. It cannot be fixed because it depends on persistent TCP connections and that is not the way the internet works.

1 is trivially solvable on the server side by requiring TLS+SASL

2 is trivially solvable on the server side by writing logs

IRC is a protocol, not a product, and an IRCd author can add these features. The fact that it has not been done speaks to the demand for these features.

Re: Absence of certain features in IRC considered a feature

#97

Post by aidenn0 »

KirinDave wrote: post #84
lossolo wrote: post #79

Earlier quoted context omitted.

> doesn't really solve the problem. Care to elaborate? It solves authentication for us and we are using it for 10+ years like this. > is a problem with the architectural decisions modern IRC has inherited. It cannot be fixed because it depends on persistent TCP connections and that is not the way the internet works. Let me check my current znc IRC session signon: Wed Jul 18 07:43:12 So almost a year.

> Care to elaborate? It solves authentication for us and we are using it for 10+ years like this If "we use plaintext passwords communicated to a faux user" is your idea of "solved" then we have very different standards. > Let me check my current znc IRC session signon: Wed Jul 18 07:43:12 Congrats on being rich and lucky I guess? That's not a thing most folks can replicate at scale. I have had more than one IP addre…

I agree with you on persistent logs, but I authenticate with an SSL client certificate, not a password. This is supported by several networks. Also, what do you mean by "plaintext"? Good id services will store a hashed password and the irc connection can be over SSL. That's no more plaintext than any web service login.

Re: Absence of certain features in IRC considered a feature

#98

Post by ben509 »

chipotle_coyote wrote: post #78
KirinDave wrote: post #58

Now let's talk about the inherent lack of a good centralized identity service, the danger of the majority of IRC servers and clients being written in C and the inefficiency of the protocol itself for applications like high latency links? We might also talk about the lack of important modern features like basic negotiation of client encoding capabilities and what an absolute tire fire DCC-based features continue to be…

I'm not sure if "festues" is a word I don't recognize or a typo for a word that I can't mentally correct into something I'd recognize.

I think it was meant to be features.

Re: Absence of certain features in IRC considered a feature

#99

Post by KirinDave »

ohithereyou wrote: post #96
KirinDave wrote: post #72

Earlier quoted context omitted.

1 doesn't really solve the problem. 2 is a problem with the architectural decisions modern IRC has inherited. It cannot be fixed because it depends on persistent TCP connections and that is not the way the internet works.

1 is trivially solvable on the server side by requiring TLS+SASL 2 is trivially solvable on the server side by writing logs IRC is a protocol, not a product, and an IRCd author can add these features. The fact that it has not been done speaks to the demand for these features.

I would not call running those services "trivial", but yes. If you bolt actual authentication onto something below L7 of the protocol, then you get real authentication. However, it's difficult for permission models to properly integrate with this, which is why many servers still support nickserv.

> Logs

Yes if you sacrifice all privacy you can patch over this problem by running a local bot and then using extra software to republish it. I suppose that is a valid, if unsatisfying, answer.

> IRC is a protocol, not a product, and an IRCd author can add these features.

Except that to directly address these issues within the framework of IRC is impossible. Folks just push any problem they don't feel like solving down the stack, or hand tweaking of their IRCd in ways that most clients won't respect.

Using IRC to build a protocol (as anything other than the shallowest integration for a more robust chat backend) seems to be extremely niche.

>The fact that it has not been done speaks to the demand for these features

Alternative hypothesis: it's much easier to just go build something else rather than listen to folks list off a string of excuses rather than just amicably agree it's a nostalgia thing and it's not for everyone.

Re: Absence of certain features in IRC considered a feature

#100

Post by Pigo »

wayoutthere wrote: post #66
Pigo wrote: post #6

I'm glad Freenode has a user base for work related stuff, but I man do I miss when Undernet or Dalnet was still popular. I know I'll never run into my mother on IRC, and it is probably because of the format.

I used to run a server on Dalnet (then later on Espernet). Good times; nobody knew I was 15 so I learned a ton about programming from some smart people

This made me laugh, because I was quite young when I first got into it. Though I was never anything more than an op in a few channels.
Post reply on HN