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

121–130 of 222 posts

Re: Absence of certain features in IRC considered a feature

#121

Post by KirinDave »

sirn wrote: post #117
KirinDave wrote: post #110

Earlier quoted context omitted.

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.

I tried to rig up a Shavian chat group and we just hit the wall over and over. It was frustrating so we moved to Matrix.

Re: Absence of certain features in IRC considered a feature

#122

Post by tastroder »

KirinDave wrote: post #116
aidenn0 wrote: post #97

Earlier quoted context omitted.

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

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

That's also the case for 99% of authentication in the web context. 2FA adoption is on the rise but by no means the standard. If it was a thing users asked for, there's no protocol reason a nickserv service and clients couldn't adopt a 2FA flow, even without breaking backwards-compatibility.

Re: Absence of certain features in IRC considered a feature

#123

Post by KirinDave »

tastroder wrote: post #118
KirinDave wrote: post #114

Earlier quoted context omitted.

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

It's not that it's stupid. It's that it's antiquated in a bad way. The network architecture of server networks is similarly ridiculous by modern standards.

Re: Absence of certain features in IRC considered a feature

#124

Post by glacials »

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…

The author specifically calls out ephemerality as a feature of IRC.

If it's easy to get history people will assume everyone is reading what they're typing. This would make people feel obligated to play catch-up every time they miss some messages due to being AFK or in the zone.

By making history hard to obtain, IRC simulates real-world conversation -- you're either in the room or you're not.

Re: Absence of certain features in IRC considered a feature

#125

Post by tastroder »

KirinDave wrote: post #123
tastroder wrote: post #118

Earlier quoted context omitted.

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

It's not that it's stupid. It's that it's antiquated in a bad way. The network architecture of server networks is similarly ridiculous by modern standards.

Yeah, sorry, I guess I just don't get this animosity towards a protocol that, to me, still has a bunch of upsides over other alternatives that actually have a userbase (again, userbase that's relevant to me). IRC and the associated ecosystem might be ancient but it feels like it adopts (slowly but surely) and puts me more in control than the weird commercial alternatives that crop up every few years. With the added bonus of still running after decades instead of going under and burrying my data (or putting workload on me).

The network architecture was ridiculous 20 years ago, it still works. That's one of those things where I feel like "cool, if it's really broken enough, write a new backend and maintain compatbility to my stuff. I'm a user and don't care about your architecture". I'll gladly admit that there's a non-trivial amount of nostalgia in that logic though. :)

Re: Absence of certain features in IRC considered a feature

#126

Post by ekianjo »

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.

The\lounge does exactly that. problem solved.

Re: Absence of certain features in IRC considered a feature

#128

Post by KirinDave »

tastroder wrote: post #125
KirinDave wrote: post #123

Earlier quoted context omitted.

It's not that it's stupid. It's that it's antiquated in a bad way. The network architecture of server networks is similarly ridiculous by modern standards.

Yeah, sorry, I guess I just don't get this animosity towards a protocol that, to me, still has a bunch of upsides over other alternatives that actually have a userbase (again, userbase that's relevant to me). IRC and the associated ecosystem might be ancient but it feels like it adopts (slowly but surely) and puts me more in control than the weird commercial alternatives that crop up every few years. With the added b…

You can run your own matrix servers and they address most of the issues you can find with IRC. It's true that for a short while Matrix had some privacy concerns, and I'm relieved that they're being answered within a reasonable timeframe.

IRC's network architecture only survives because people tolerate it. Even slightly animosity from the community brings it down hard every time.

I think what's valuable is the chatroom model, which is largely dead outside of Telegram (which is, I agree, unusable from a user privacy and control standpoint). Part of the reason I'm passionate about this is that I want the model to be robust and well-maintained. I am nostalgic for the model, but I view the underlying legacy implementation as an obstacle to the preservation of that model.

Re: Absence of certain features in IRC considered a feature

#130

Post by tastroder »

KirinDave wrote: post #128
tastroder wrote: post #125

Earlier quoted context omitted.

Yeah, sorry, I guess I just don't get this animosity towards a protocol that, to me, still has a bunch of upsides over other alternatives that actually have a userbase (again, userbase that's relevant to me). IRC and the associated ecosystem might be ancient but it feels like it adopts (slowly but surely) and puts me more in control than the weird commercial alternatives that crop up every few years. With the added b…

You can run your own matrix servers and they address most of the issues you can find with IRC. It's true that for a short while Matrix had some privacy concerns, and I'm relieved that they're being answered within a reasonable timeframe. IRC's network architecture only survives because people tolerate it. Even slightly animosity from the community brings it down hard every time. I think what's valuable is the chatroo…

Interesting points, thanks. While I don't necessarily agree with some of the details I actually like that passion. Maybe I'll have to give Matrix a more honest try, always figured I will do that when I happen upon a community that uses it. Hey, at least I seem to be able to use that in my irssi and not some half-backed shiny web app.
Post reply on HN