Hacker News Reader

Comment by gumby | Hacker News Reader

I find it weird that email started as an open protocol; various companies tried to make their own private communities but those eventually dwindled and transferred to SMTP.

Why did realtime chat fail to take the same path? I assumed it would.

View on HN

Technically, it did: Internet Relay Chat (IRC) has been an RFC for over a quarter of a century. To me, at least, it's an interesting question why IRC never really broke out of "only nerds need apply" status.

Because:

* No clients support multimedia - animated GIFs, videos, audio, images, video/audio calls - only Quassel has web previews and that's about it

* E2E encryption doesn't exist properly

* Signing up to protect usernames is a pain in the ass, especially if people span networks and assuming networks even have something like NickServ

* Users are require to have a bouncer to have some chat persistence

* No clients offer convenience features such as search

* It's a pain in the ass to manage channels to just chat

* Clients can't handle mobile connections well

I'm sure I've forgotten other problems the protocol has.

I'm not sure any of those are issues that couldn't have been addressed by now through a new version of the protocol, though; what I'm trying to get it is that it's sort of weird to me that IRC in 2019 isn't materially different than IRC in 1994. IRCv3 addresses a whole lot of those problems, for instance, and there's nothing that technically could have prevented it from addressing them 10 years ago.

IRCv3 brings a bunch of really nice features I'm so happy to have, but it's really the clients that need a lot of work in addition to just IRCv3 features. Image, video and audio inlining is still something that no client does and the standard can't help with and that's a huge con for most users.

What the standard could help with is standardizing markdown formatting, some method of E2E encryption, better SASL (with registration, key rollover/update and distribution between your clients).

> * No clients support multimedia - animated GIFs, videos, audio, images, video/audio calls - only Quassel has web previews and that's about it

Textual supports a bunch of inline media: https://help.codeux.com/textual/release-notes/Release-Notes%...

Unfortunately Textual is MacOS only?

Yes, that is the case, and is unfortunate for the IRC ecosystem, but it's not the case that "no clients support multimedia".

Given OSX's marketshare it's only a rounding error away from being "no clients support multimedia" unfortunately.

IRC is about as featureful as the telegraph, I'm pretty sure that's why so few people bother with it and while interfaces (bots that relay messages to other platforms and back) exist plenty, pretty much everyone would rather use something with at least scrollback without bouncer. Probably also file transfer, (video) calling, screen sharing, typing notifications, read receipts, etc.

There are clients that does file transfer etc, for example Mirc. IRC can be extended with just about anything, using a direct connection (P2P), although you might need to use the same client.

Direct Client Connections (DCC) became infeasible about 20 years ago with the proliferation of NAT routers. The workarounds (connection tracking and rewriting) never arrived for the masses.

I think IPv6 was designed to not need NAT, so once we get IPv6 we will see cool new protocols again. Only problem is we developers make software insecure by listening on all IP's instead of just private. And without a password! Having your security camera or what not accessible from the Internet should really be opt-in. It's our own fault that everything is NAT:ed, and that the only open ports in the firewall are 80,443. We need more peer pressure between developers in order to make things secure by default, and not allow insecure by convenience.

Default IPv4 (for consumers) is a single IP with masq/NAT. Then with user authorization add port forwarding as needed.

Default IPv6 (for consumers) is block all incoming (except for traffic related to outgoing). Then with user authorization add allow rules as needed.

So basically no difference between IPv4 vs IPv6.

If you default firewall on IPv6 is allow all... buy a better router/firewall.

We would not need a router or firewall. Probably not a wifi either. All stationary devices will be wired in. And mobiles would use 6G or 7G. Where I live (sweden) you can already get 10Gbe. Now imagine the possibilities. For example VR with less then a ms latency to closest datacenter. Where your device is just a thin client. Microsoft are already planning to build a DC near major cities, hopefully they are up to something cool.

I've often wondered about this too. IRC was amazing and then it stagnated. Perhaps not ambitious enough governance / leadership over the project? Lack of (financial) incentives?

I don't really know the structure/contributors of the project except for the beginning (not when it stagnated later on), but perhaps if Jarkko Oikarinen had been as driven as Linus Torvalds, we would live in a different reality when it comes to instant messaging

If you think about it, nothing really like IRC exists nowadays. Slack is similar, but it's more of a work tool, and it has a much smaller userbase than any of the other mass communication tools (~10M).

I'd say there's simply no great demand for real-time chatting with large groups of people.

I think this is a good explanation. https://signal.org/blog/the-ecosystem-is-moving/

I would have to guess because open protocols lead to implementations which trade speed for interoperability, which is OK for e-mail, but not for realtime applications.

I don’t think it was a technical issue. On the mail side it was a social issue — first gatewaying to the internet, then a desire to use a variety of clients.

FWIW, XMPP appears to have reasonable performance.

Reply on news.ycombinator.com