Live data from Hacker News

IRC v3

ircv3.net

151–160 of 225 posts

Re: IRC v3

#151
post #74

Earlier quoted context omitted.

Logs can be append-only, while clients can still show edits. These aren't in conflict. It wouldn't have to be complex, either, and it certainly isn't useless (says me and a few other people already!). Quick example: I recently typed out about 10 long lines of business development chatter in Slack, the first of which contained a list of prospects. I realized I left a few out in my list, and edited the message to add t…

Whenever I see someone on my IRC channels type out 10 long lines of anything, I tell them to use some sort of pastebin instead.

Slack has a pastebin built in, too.

Re: IRC v3

#152

I don't feel like typing much because it's nap time but IRCv3 is an almost closed group of friends, mostly znc core developers, who have decided they can choose what the future of IRC looks like. They have put lots of pressure on and harassed other developers of clients and networks, sending them patches and infiltrating their devs if necessary, so their ideas are actually implemented. If you complain about those ide…

> I don't feel like typing much because it's nap time but IRCv3 is an almost closed group of friends, mostly znc core developers, who have decided they can choose what the future of IRC looks like.

This is how standards get built now. See also: systemd, R6RS.

Re: IRC v3

#153
post #84

Earlier quoted context omitted.

Glad to hear they updated the name. Riot.im sounds better for telling others to use it.

It's a wonderful name, indeed. "Let's riot!", I totally approve.

[deleted]

Re: IRC v3

#154

Earlier quoted context omitted.

It's not, but your comment made me smile. You seem to feel differently. Go ahead, tell me why it shouldn't be the case.

I'm not the person you asked, but I share their opinion because JS and websockets do not appear to have any obvious relationship or applicability to IRC.

A reason to do it is because most internet users >99.9% have a web browser. <0.01% have an irc client. You could argue that Twitter or Slack has sort of filled this niche for people who want to do #topic based chat but if the goal is to do it in an open protocol, then that's imo why it would be applicable to irc.

Re: IRC v3

#155
post #59

Earlier quoted context omitted.

Length negotiation has been discussed for years, but it’s not that easy. Imagine user A negotiates a length fo 1024 bytes with the server, user B negotiates a length of 2048 bytes. User B sends a message via the server to user A. What happens?

No, it isn't easy but that is what makes it the kind of thing that requires great spec work to accomplish. It would require proposing transitional steps and monitoring their adoption over a very long timeline. However reading their site more carefully I suppose their stated goal technically is to only provide extensions to the protocol. So the situation you describe already happens, user A has 512 bytes to send to th…

The prefix is discoverable by client A though: it can send a self-message and thereafter knows the maximum length it can send to any given target.

Re: IRC v3

#156
post #89
post #41

Earlier quoted context omitted.

"most people miss any conversations that don't happen in their business hours. This has huge effects on collaboration." Why don't you send them logs of the conversations?

Suddenly it's my job to bring everyone else up to speed on what happened in their off hours? I have a job to do. Slack and Rocket.Chat (and matrix and ...) both solve that problem and a lot of others without the legacy bullshit that IRC slops down the road. I'm sick of spending time working around what is an outdated and inadequate protocol because of momentum in my office.

You realize logging IRC and distributing said logs can be completely automatic, right? Anyone can set that up. It's honestly kind of humorous that you find this to be such a mountain to climb.

Re: IRC v3

#157

I'm not sure if this is the best approach. Matrix might be a better way to go, at least for some things. If you really want persistent history and persistent identity, I'm not sure why you bother with IRC at this point: both will always be second class there. Try XMPP, Matrix, Psyc, or whatever. Just so long as you can convince your friends to use it...

On IRC, your "persistent identity" was your user@hostname (and your nick is ephemeral). That's why the user@hostname is shown when a client joins a channel, or in WHO or WHOIS - and why bans match on nick!user@host.

This worked great when people were typically using IRC from their login on a server at their university (and this is also originally why IRC servers used the 'ident' protocol when you connect - to stop you spoofing other users on the same shared system).

It stopped being a viable persistent identity for all users when the @hostname part stopped being persistent - when people started gettting dynamically assigned addresses on internet connections at home.

Re: IRC v3

#158
post #74
post #44

Earlier quoted context omitted.

So logs are no longer append-only? This seems like a uselessly complex thing for all servers and client logs to support. Seems like it would break many things. What situation needs an edit feature? I can think of none, since a quick follow-up correction is simple. Also, edits would ruin many of the funny situations encountered on bash.org. :)

Logs can be append-only, while clients can still show edits. These aren't in conflict. It wouldn't have to be complex, either, and it certainly isn't useless (says me and a few other people already!). Quick example: I recently typed out about 10 long lines of business development chatter in Slack, the first of which contained a list of prospects. I realized I left a few out in my list, and edited the message to add t…

Personally, I would treat the chat like a forum post and take more time to confirm that what I was posting was accurate. I have never used chat as for business purposes though, so thanks for the insight.

I do wonder though, should IRC evolve to be like Slack or should it evolve idependently? I feel that the new features should be more vital, rather than "neat"... like maybe more focus on privacy and/or anonymity. Undoubtedly, I am just resisting change...

Re: IRC v3

#159
post #155

Earlier quoted context omitted.

No, it isn't easy but that is what makes it the kind of thing that requires great spec work to accomplish. It would require proposing transitional steps and monitoring their adoption over a very long timeline. However reading their site more carefully I suppose their stated goal technically is to only provide extensions to the protocol. So the situation you describe already happens, user A has 512 bytes to send to th…

The prefix is discoverable by client A though: it can send a self-message and thereafter knows the maximum length it can send to any given target.

They will only know the prefix for the server they are connected to. On a larger network such as Freenode, client B could be connected to another server with a different prefix length.

Re: IRC v3

#160
post #157

I'm not sure if this is the best approach. Matrix might be a better way to go, at least for some things. If you really want persistent history and persistent identity, I'm not sure why you bother with IRC at this point: both will always be second class there. Try XMPP, Matrix, Psyc, or whatever. Just so long as you can convince your friends to use it...

On IRC, your "persistent identity" was your user@hostname (and your nick is ephemeral). That's why the user@hostname is shown when a client joins a channel, or in WHO or WHOIS - and why bans match on nick!user@host. This worked great when people were typically using IRC from their login on a server at their university (and this is also originally why IRC servers used the 'ident' protocol when you connect - to stop yo…

...Exactly.
Post reply on HN