Live data from Hacker News

Simplicity of IRC

susam.net

91–100 of 250 posts

Re: Simplicity of IRC

#91
I am if the opinion that IRCv3 is horrid and has taken the email route of (forgive the language) "polishing turd". You cannot have a secure irc that is backwards compatible, you can have separate default ports and uri schemes like http vs https, but you can't connect to http and opportunistically redirect 301 to https and call that an improvement of securiry because it is actually worsening security by introducing false assurances of securiry.

I also believe it is possible to have a protocol that has proper E2EE and simple enough to where you can use netcant and one other tool to use IRC.

Trust-on-first-use authentication (like signal or ssh) is also terrible in practice on its own. Keep it simple. Let the servers handle public key distribution and certification so that compromise of the server/mesaaging infrastructure is required to mount identity attacks, then do the normal TOFU authentication so users won't have to trust middleware. Have a commandline tool that "connects" to the other user (like ssh or sendmail) and opens a socket/fd you can use with a proper frontend or just echo/netcat to it.

Re: Simplicity of IRC

#92
post #87

I love IRC, unfortunately it doesn't work properly with smartphones because they have a "loose" connectivity (4G towers data etc). I'm not sure IRC apps can deal with this already. It would be nice to have some update to the IRC RFC. If it was well supported for smartphones, I'm still wondering if it would cause some bandwidth costs to servers. EDIT: I know about bouncers, but I would prefer to do without.

You can use IRC bouncer for that. e.g. https://wiki.znc.in/ZNC

Re: Simplicity of IRC

#93
I miss IRC. The simplicity in design is one thing. I think the other part I miss is the pseudonyms and having an identity not be directly attached is another.

I remember joining so many IRC channels to learn about everything in college. You'd get help and be humbled by the many regular names in each channel. There was more of a human element to it as most people simply acted as extensions of themselves.

You think about Slack, Discord, and Teams today and there's a whole corporate or personal identity attached behind each name. You can't always act like you would in IRC. You can't always be blunt and to the point. You can't call someone an idiot or to RTFM in the most sincere way possible.

When things were simple with a single pseudonym and a message, things were great. Now things are much more complex. Threads, DMs, notifications of mentions, bots, gifs, etc. It's definitely been changing quickly, but it was nice when everyone's attention was in one place instead of fragmented in each of these new apps that are just glorified IRC.

Re: Simplicity of IRC

#94
post #87

I love IRC, unfortunately it doesn't work properly with smartphones because they have a "loose" connectivity (4G towers data etc). I'm not sure IRC apps can deal with this already. It would be nice to have some update to the IRC RFC. If it was well supported for smartphones, I'm still wondering if it would cause some bandwidth costs to servers. EDIT: I know about bouncers, but I would prefer to do without.

If you are into self-hosting, thelounge is a great web-based IRC client that works well on my iPhone. It does its magic by staying connected to servers on the backend, similar to a bouncer.

Re: Simplicity of IRC

#95
post #87

I love IRC, unfortunately it doesn't work properly with smartphones because they have a "loose" connectivity (4G towers data etc). I'm not sure IRC apps can deal with this already. It would be nice to have some update to the IRC RFC. If it was well supported for smartphones, I'm still wondering if it would cause some bandwidth costs to servers. EDIT: I know about bouncers, but I would prefer to do without.

You can use IRC bouncer for that. e.g. https://wiki.znc.in/ZNC

It's not free, and it add hardware and software and bandwidth.

Re: Simplicity of IRC

#97
post #3

Same with SMTP and POP, I would routinely send or get email via telnet when I wanted to debug or delete some messages. They're all very simple protocols.

In my experience, email protocols are anything but simple as soon as some security or authentication comes into play.

Depends on the auth mechanisms in use, the simplest ones are still still pretty straightforward. Nowadays you just use the TLS equivalent of telnet (openssl s_client).

POP3:

  1. run openssl s_client -connect myserver.example.com:995
  2. enter two commands: "user myusername" "pass mypassword"
  3. profit
SMTP & AUTH PLAIN is only slightly more complicated but similarly just an additional protocol command, connecting with s_client. (You need to generate the auth string in another shell window with: echo -ne "\0username\0password"|openssl base64)

Re: Simplicity of IRC

#98
post #88
post #61

Earlier quoted context omitted.

I've not used teams, but both slack and Google chat make it very easy to post messages, a simple curl call has often been more than enough in lots of scripts

That is, unless the enterprise has policies to abide by disallowing API calls, in which case you're stuck with the official client and vetted integrations. Same for mobile, the advantage vanishes once enterprise requires your (usually personal) phone to be surrendered to corp IT via MDM (which I sure as hell won't do). The whole value proposition of Slack and Teams for their customers is control.

Would IRC even work in that nameless enterprise?

Re: Simplicity of IRC

#99
post #2

Nice article, thanks :-) I grew up with IRC and realize that it isn't the same any longer. It isn't the place where everyone is, which some social networks seem to be today. The local communities on IRC, a channel for a town used to be the place to be and meet others.

IRC is probably used by more people now than ever before, though in a very different way than before. The whole of Twitch's chat infrastructure is running on it and it have hundreds of thousands of concurrent users. Though for most people it is running though a websocket instead of a raw socket, but the commands are the same a long way

Re: Simplicity of IRC

#100
IRC, the protocol, is really simple. It's so simple it's almost the most minimal chat protocol you could possibly layer on top of TCP - it's literally a live message routing protocol with the least support for the notion of persistent users possible.

There was a joke on bash.org that IRC is basically multiplayer Telnet and ... they aren't really too far off.

This has good and bad things about it:

Good: it's extremely flexible.

Good: it's extremely efficient - your major IRC servers at there peak were probably one machine, possibly single core, and handled 20,000+ active connections. Protocol is extremely proxyable and tunnelable.

Good: It works well over dialup. If you can get .002Mbit/sec between you and the server you can use IRC.

Bad: no real concept of identity - everything is based on IP addresses and current connections. Connection drops, you're gone. Things have arisen to address this (NickServ, etc.) and using a bouncer has always been a thing.

Good: no real concept of identity - if your IP is cloaked or you're not accessing from your home IP, you're very anonymous.

Bad: First user on a channel is it's op and it's owner and can control the channel. If all ops connections drop, someone can take it over. DoSes/DDoSes to disrupt channels have been a thing. Things have arisen to address this on modern IRC (ChanServ) but before then, any really serious channel had to have a network of bots with out-of-band coordination to protect it (eggdrop).

Bad: Doesn't support file transfer directly. This is done with another protocol DCC which is hard to work with over firewalls, etc.

Bad: Media and link support is up to clients and requires non-IRC protocols to be effective. You're not posting pictures in IRC channels unless you are using a client that supports it such as thelounge, and even then what thelounge does is upload your pictures to a local server.

Good: Mature IRC clients give you a lot of control.

Bad: Mature IRC clients are complicated.

Bad: IRC is one of those protocols that arose before encryption was considered a basic need. Modern IRC supports SSL but all it takes is one client connecting non-SSL to ruin it like email, unless the server is SSL only.

Bad: Mature IRC servers tend to be from the age where the Internet was ruled by universities. So, DNS is relied on for security and identity far more than it should be. Configuration of mature IRC server daemons I find somewhat complex and difficult.

Post reply on HN