Live data from Hacker News

IRC v3

ircv3.net

71–80 of 225 posts

Re: IRC v3

#71

I second a comment made below regarding https://matrix.org/ . I've used IRC for years and still use it almost daily - but come on Mosh + tmux + ec2 just to have permanent chat history? I seriously can't advocate this crap to anyone in 2016. It's too little, too late.

Well, yeah. When I was a teenager my group of friends used to use a QNet IRC chat for communications. Most on mIRC and such clients. Today it's pretty much all nerds. I do enjoy IRC, and pretty much live inside my tmux session, but I don't think I can recommend it to anyone who isn't already probably using it.

>Today it's pretty much all nerds

Probably says more about your social circle than IRC. There's a lot of channels and if hookers and blow are more your speed than say, gentoo, you can certainly find a channel primarily discussing them.

Re: IRC v3

#72
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?

User A gets two messages like SMS that can be joined? Or is that too naive?

What if the message is a configuration message that can’t be split?

And how would it be split?

Or should there be a mechanism for reassembling message frames?

Re: IRC v3

#73
post #59

My favourite bit is how they skipped adding length negotiation and it is causing them problems already. See the brief discussion of size limit on http://ircv3.net/specs/core/message-tags-3.2.html Adding tags forced them to increase message length because of how IRC messages are hilariously limited to 512 bytes in all directions. In the existing protocol you already have to guess how long your messages are allowed to…

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 the server, but the server has 512-prefix_length bytes to send to B. This is a flaw in the original protocol and the currently accepted solution is to truncate server-side(what to do is not stated explicitly, though it is implied that you probably shouldn't wrap messages). But fixing it is probably out of scope.

Re: IRC v3

#74
post #44
post #21

Earlier quoted context omitted.

> Are irc clients supposed to magically redraw the buffer and edit logs??! Who speaks about magic? Just send a message with the original ID and make the difference. Mark it in the UI, and redisplay it.

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 them in. Without editing, I'd have to have either posted the complete list again or added them in as a second comment. Editing the original message is simply a lot less confusing.

Re: IRC v3

#76
I used IRC for over 10 years, but after using Slack for 1 it just felt outdated to me.

Offline messages and simulatnous logins from multiple places are just two features I was missing in IRC and didn't even know till I had them, haha.

But yeah, IRC networks just worked as message broker and not as databases, so I never thought about it.

Re: IRC v3

#77

Looking at homepages of various IRC clients, I feel like I am back to 5 years ago when jQuery UI is still a thing: http://ircv3.net/software/clients.html Equally out-of-date are the screenshots of the clients on the homepages. I don't think I will ever see an IRC desktop or web client that has decent UI according to today's standard. Then again probably I am too young to be their target audience. Edit: Okay there are…

Have a look at Textual (macOS):

https://www.codeux.com/textual/

Re: IRC v3

#79
post #76

I used IRC for over 10 years, but after using Slack for 1 it just felt outdated to me. Offline messages and simulatnous logins from multiple places are just two features I was missing in IRC and didn't even know till I had them, haha. But yeah, IRC networks just worked as message broker and not as databases, so I never thought about it.

I use ZNC, so logging in from multiple places works well.

Re: IRC v3

#80
post #42

Looking at homepages of various IRC clients, I feel like I am back to 5 years ago when jQuery UI is still a thing: http://ircv3.net/software/clients.html Equally out-of-date are the screenshots of the clients on the homepages. I don't think I will ever see an IRC desktop or web client that has decent UI according to today's standard. Then again probably I am too young to be their target audience. Edit: Okay there are…

Try taking a look at The Lounge, it aims to be rather modern. https://thelounge.github.io

Nice, this may make me finally move on from irssi
Post reply on HN