Live data from Hacker News

IRCv3

ircv3.net

51–60 of 97 posts

Re: IRCv3

#51

Earlier quoted context omitted.

And by "improve" everyone understands "get more complicated and bloated" :-P

Yes, by innovating and giving people the user experiences they want. IRC is a joke once you’re used to Slack, especially in an organization that uses it well.

I appreciate having a streamlined chat application, but understand that others feel differently. IRC applications are much better on resource consumption and snappier in my experience, but aren't all that practical on a mobile device.

Naturally, how each of us feels about that experience is subjective. So setting that aside, the part about IRC that I haven't seen handled with Slack is being a one-stop shop. With IRC, I can discover and access multiple communities within a single server at once. The most popular servers can be connected to and browsed with a click in most IRC applications. With Slack, I need to find a project's Slack workspace, request an invitation, then go through the process of adding it to each of my clients. I'd love to see the equivalent of a FreeNode workspace where I can join an OCaml channel and a Ruby channel without going through all of the above and dealing with walled-off communities.

Revisiting resource consumption, I've opted out of communities that moved to Slack because once I hit around 10 workspaces, the Slack app slowed to a crawl and guzzled RAM. To be fair, that's gotten a lot better in recent years, but I still find managing several workspaces to just be too much cognitive overhead. I may only be in one channel on each workspace, but I can't easily switch between them. With IRC, doing a "/join ##ocaml" is super fast, barely consumes additional resources, and adds a new tab to my main interface for fast switching between channels.

Re: IRCv3

#52

Earlier quoted context omitted.

> I'll take excellent SNR over the sort of focus on end user experience you're talking about The kind of SNR that causes an attempted takeover? As IRC has depopulated it's been increasingly inhabited by a particular type of person and has a particular culture. That's fine, but ascribing some technical superiority to it because of your cultural preferences doesn't make sense. IRC attracts a certain type of user who pe…

>The kind of SNR that causes an attempted takeover? As IRC has depopulated it's been increasingly inhabited by a particular type of person and has a particular culture. If you mean anime subbers, 4channers, and the warez/pirate crowd , they've all moved to Discord or Telegram. The only ones left are the technically inclined folk who adopted the platform at its genesis (i.e. #c, #perl, etc.)

No I mean the technically inclined. Adding a layer of gatekeeping just means folks who are okay with that keeping make it across. IRC has a very particular culture.

Re: IRCv3

#53

Earlier quoted context omitted.

> I'll take excellent SNR over the sort of focus on end user experience you're talking about The kind of SNR that causes an attempted takeover? As IRC has depopulated it's been increasingly inhabited by a particular type of person and has a particular culture. That's fine, but ascribing some technical superiority to it because of your cultural preferences doesn't make sense. IRC attracts a certain type of user who pe…

You're being disingenuous. IRC has been right at the center of the vast majority of non-enterprise technical communities and especially opensource for the last 25 years. Say what you will about culture but this is a fact and I don't see it changing. Slack and Teams are gimmicks at best. Matrix unusable for me, every single one of my peers and, apparently, the vast majority of said technical communities that keep thei…

We recently switched to use self-hosted Mattermost plus Matterbridge[1] to connect with IRC, Telegram, Discord, etc. There is also an amazing console client - Matterhorn[2].

[1] https://github.com/42wim/matterbridge

[2] https://github.com/matterhorn-chat/matterhorn

Re: IRCv3

#54

Earlier quoted context omitted.

I don't really care much about the protocol myself. I'm never going to be speaking "raw IRC" at any point, so why does it matter? I understand that you want to keep protocol simplicity high to make it easier on implementers, but other than just enough to encourage implementation, I don't see the need. We're talking about human chat applications here. Machine chat can use simpler protocols of course, like a light laye…

I've interacted with IRC servers via telnet a ton of times. But overall I think that era of protocol design is unfortunately long passed (looking at you SMTP)

My dream is we move away from overly complex layers on top of HTTP and move to open simple protocols.

Re: IRCv3

#55
post #16

Given that Matrix seems to be quite successful these days, and afaict is basically a next-gen IRC, is there any compelling reason to push IRC?

It helps that IRC is extremely simple. Most servers you can connect to and chat using telnet if you're so inclined.

Why should I care? I will never be inclined to connect to IMs via telnet. I just want something that works on mobile without holding a connection open and that supports media uploads.

Re: IRCv3

#56
post #2

I really want the IRC protocol to decouple its sessions from the TCP connection and move to using HTTP as a transport, even if the only api verb is "send" and the only response is "receive output buffer". I used to really love IRC, and think it could undergo a resurgence given the right upgrades.

Not everything has to run on top of HTTP or use json. IRCv3 gets a lot more right than wrong.

Using HTTP would be an absolutely massive improvement for IRC. IRC is essentially useless on mobile without having some man in the middle server to convert IRC to http.

It's even pretty useless on laptops or desktops that aren't always running.

Re: IRCv3

#57
post #2

I really want the IRC protocol to decouple its sessions from the TCP connection and move to using HTTP as a transport, even if the only api verb is "send" and the only response is "receive output buffer". I used to really love IRC, and think it could undergo a resurgence given the right upgrades.

Many modern IRCDs expose a websocket connection, if that's HTTP enough

Does the web socket let you see the history while your device was sleeping?

Re: IRCv3

#58
post #2

I really want the IRC protocol to decouple its sessions from the TCP connection and move to using HTTP as a transport, even if the only api verb is "send" and the only response is "receive output buffer". I used to really love IRC, and think it could undergo a resurgence given the right upgrades.

What upgrades do you think should be added? I miss the environment of IRC 25 years ago. Its something that no messenging application has really been able to replicate for me.

At a bare minimum it needs to be redesigned for modern computers. We have left the days where user all use desktops which sit online always and hold an open connection. IRC needs to support something HTTP like with history.

Re: IRCv3

#59

Earlier quoted context omitted.

Not everything has to run on top of HTTP or use json. IRCv3 gets a lot more right than wrong.

Using HTTP would be an absolutely massive improvement for IRC. IRC is essentially useless on mobile without having some man in the middle server to convert IRC to http. It's even pretty useless on laptops or desktops that aren't always running.

Quassel and the mobile Quasseldroid app fix that and more :) They add a lot of mod cons like infinite scrollback, persistent connection and multi network bouncing with a really good UI.

Re: IRCv3

#60
post #16

Given that Matrix seems to be quite successful these days, and afaict is basically a next-gen IRC, is there any compelling reason to push IRC?

Matrix seems to lack a good high density client. The only one that's really full featured is Element but it's very consumerish and uses lots of screen space. As soon as you bridge multiple IRC networks and have lots of other chats open, the chat list becomes really messy imo.
Post reply on HN