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

111–120 of 222 posts

Re: Absence of certain features in IRC considered a feature

#111

Post by kungtotte »

enlyth wrote: post #108
superkuh wrote: post #103

Earlier quoted context omitted.

But why? Why add extra steps and add in having to keep the code to adapt to APIs or URL paths that change every 6 months? It's not like keeping a browser and IRC client open are mutually exclusive. I personally just $ cp whatever.jpg ~/www/ because I host my static site from my home connection and have for 20 years. I know self-hosting is not for everyone but everyone self hosting would literally solve all the proble…

Because I want to be able to simply drag and drop an image for someone to see it immediately and not faff about with 15 extra steps of alt tabbing through browsers and copying links and waiting for uploads to finish.

There are several image hosts with tools available that make uploading as easy as passing a filename to a command or dropping it in a synced folder, so you're really just adding one step to the process of pasting an image into IRC.

Re: Absence of certain features in IRC considered a feature

#112

Post by lossolo »

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…

> If "we use plaintext passwords communicated to a faux user" is your idea of "solved" then we have very different standards.

plaintext? In our use case TLS usage is mandatory and passwords are not stored in plaintext. I think your knowledge about how IRC is used now is a little outdated.

> 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 address in the duration of writing this post.

VPN -> znc -> IRC

You don't need to be rich and lucky to replicate this. Signon time was from znc to irc, not from my home connection to irc.

Re: Absence of certain features in IRC considered a feature

#113

Post by mdellavo »

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.

the resource usage for a partially buried idling slack window with a bunch of animated emoji and gifs is absurd

Re: Absence of certain features in IRC considered a feature

#114

Post by KirinDave »

lossolo wrote: post #112
KirinDave wrote: post #84

Earlier quoted context omitted.

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

> If "we use plaintext passwords communicated to a faux user" is your idea of "solved" then we have very different standards. plaintext? In our use case TLS usage is mandatory and passwords are not stored in plaintext. I think your knowledge about how IRC is used now is a little outdated. > 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 addr…

> plaintext? TLS usage is mandatory and passwords are not stored in plaintext. I think your knowledge about how IRC is used now is a little outdated.

Actually I wondered if that might be the case so I checked TFM: https://freenode.net/kb/answer/registration

Plaintext negotiation is my complaint. I doubt we'd be discussing this if it was plaintext storage. Not even the most fanatical IRC proponent would be okay with that.

> TLS usage is mandatory and passwords are not stored in it plaintext. I think your knowledge about how IRC is used now is a little outdated.

> VPN -> znc -> IRC

Where is your znc hosted? How much does it cost? Are you paying for a VPN service (please no)?

Even having a decent in-home internet connection, a way to route traffic back into your network, and a raspberry pi to host it on is a tall order.

Re: Absence of certain features in IRC considered a feature

#115

Post by ganzuul »

la_barba wrote: post #102
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…

Couldn't you layer your own account management and other conveniences on top of IRC ? Like use the underlying chansrv tech for auth but add your own layer on top for password retrieval or 2FA. You could always run a server which has dedicated bots doing the bounce per user. That way you never have to auth directly with the server, etc. Maybe a little over-complicated, but it lets you use the existing tech which is al…

You can layer OTR over IRC, if you wish.

Re: Absence of certain features in IRC considered a feature

#116

Post by KirinDave »

aidenn0 wrote: post #97
KirinDave wrote: post #84

Earlier quoted context omitted.

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

The difference being that there are absolutely no better options. Everyone agrees the login form model is insufficient and that's why anyone who takes personal security seriously now introduces a lot of infrastructure around their logins.

But aside, it seems like not all networks support TLS logins?

As it stands, I have no IRC equivalent of a 2FA key. I present a plaintext token and hope that it's all handled properly and that I'm not a victim of a password reuse attack.

Any web based solution is light years ahead on this.

Re: Absence of certain features in IRC considered a feature

#117

Post by sirn »

KirinDave wrote: post #110
sirn wrote: post #101

Earlier quoted context omitted.

Japanese and Chinese in particular can compress a lot more meaning in a byte than many other languages[1]. I pick up a random article at Nikkei.com[2] and calculate number of bytes of the first paragraph, and it's only 449 bytes in UTF-8[3]. Chinese is even more efficient at this, as you can basically fit the whole news in a Tweet. [1]: Idiomatic Yojijukugo 四字熟語 is an extreme example for this, but there's non-idiom Y…

This is fair, I should have thought more about the list. For Japanese, I don't think the way people talk casually to one another is as amenable to compression as newspaper headlines But surely for Thai you're in a sub-optimal boat?

This is completely anecdotal, but I have an alternative Twitter account where I interact with Japanese people I know, and I rarely hit the 140 characters limit except when I’m in a heated debate (or when I’m VERY excited about something).

For Thai, yeah, this one is a little more complicated. I’ve commented about this in sibling thread.

Re: Absence of certain features in IRC considered a feature

#118

Post by tastroder »

KirinDave wrote: post #114
lossolo wrote: post #112

Earlier quoted context omitted.

> If "we use plaintext passwords communicated to a faux user" is your idea of "solved" then we have very different standards. plaintext? In our use case TLS usage is mandatory and passwords are not stored in plaintext. I think your knowledge about how IRC is used now is a little outdated. > 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 addr…

> plaintext? TLS usage is mandatory and passwords are not stored in plaintext. I think your knowledge about how IRC is used now is a little outdated. Actually I wondered if that might be the case so I checked TFM: https://freenode.net/kb/answer/registration Plaintext negotiation is my complaint. I doubt we'd be discussing this if it was plaintext storage. Not even the most fanatical IRC proponent would be okay with t…

> Actually I wondered if that might be the case so I checked TFM: https://freenode.net/kb/answer/registration

You can do all that over an encrypted connection [1] if you like. All this protocol nitpicking kind of ignores that IRC is a stack that is a) open to a multitude of clients and thus use cases (vs. all those fancy web-things that offer me either lockin and emojis or a lack of user base) and b) proven over decades. Yeah, it has it's inherited edge cases and downsides but this thread makes it seem like it's a stupid idea somebody came up with in 2 hours, which it is absolutely not.

[1] https://freenode.net/kb/answer/chat

Re: Absence of certain features in IRC considered a feature

#119

Post by ganzuul »

KirinDave wrote: post #70
asveikau wrote: post #65

Earlier quoted context omitted.

> No offline history: You have to have a client/bouncer running 24/24 if you want history. I would say it's even worse than this. Even if you attempt to have a client 24/7, the lack of an acknowledgement and re-transmit on lack of acknowledgement means that if you have any hiccup that causes you to need to reset the TCP connection, you can drop messages.

Indeed, the dependence on a persistent connection itself is an absolute non-starter for this feature. It's statistically guaranteed to fail, and IRC as a protocol spec is powerless to do anything other than shrug.

Having been on IRC for maybe two decades now, I find the impermanence to be part of IRC's charm. People engage with you when you ask them what has been going on; just like in real life.

It's a social protocol.

Re: Absence of certain features in IRC considered a feature

#120

Post by rakoo »

kungtotte wrote: post #111
enlyth wrote: post #108

Earlier quoted context omitted.

Because I want to be able to simply drag and drop an image for someone to see it immediately and not faff about with 15 extra steps of alt tabbing through browsers and copying links and waiting for uploads to finish.

There are several image hosts with tools available that make uploading as easy as passing a filename to a command or dropping it in a synced folder, so you're really just adding one step to the process of pasting an image into IRC.

Except I might not be working in a terminal, I might not have the file available locally (I personally don't have any stored on my computer). Like the poster above I'd like to drag and drop something from a tab to the conversation, and not have to deal with the steps between. That's what technology is about after all.
Post reply on HN