Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IRC v3

ircv3.net

Post reply on HN
Print view View original

201–210 of 225 posts

Re: IRC v3

#201

Post by Frondo »

bcook wrote: post #187
Frondo wrote: post #168

Earlier quoted context omitted.

Forum posts generally can be edited, too.

Right, but forums are a much slower, more "official" communication medium, so the edit feature makes more sense. I see chat like in-person communication where editing something already said is impossible.

I think we're at the vi/emacs point of this discussion. Editing messages works well for me and my team, and we're glad of the feature. You don't have to like it, and I wouldn't force you to edit messages. The world supports both and we both win. :)

Re: IRC v3

#202

Post by lfowles »

caf wrote: post #163
lfowles wrote: post #159

Earlier quoted context omitted.

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.

The prefix doesn't involve the server. The prefix that's prepended to your messages when another server passes them on to a client is ":nick!user@host " and is the same for all messages that you originate. (On Freenode and other networks with a similar service, your hostname can be changed by services, but the client is notified of this and can update its knowledge about the prefix).

D'oh, you're right! I looked at a non message command to refresh my memory.

Re: IRC v3

#203

Post by Gruselbauer »

Teckla wrote: post #196
crooked-v wrote: post #151

Earlier quoted context omitted.

Slack has a pastebin built in, too.

Slack has a pastebin built in, too. I'm not sure why your comment was down voted, but as both an IRC and Slack user, I have to say I love Slack's built in pastebin.

https://www.glowing-bear.org/ introduces pastebin for IRC. And a ton of other Slack-esque features. Generally very great software.

Re: IRC v3

#204

Post by Gruselbauer »

rat87 wrote: post #182
Gruselbauer wrote: post #90

Earlier quoted context omitted.

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

Can't tell if you're being sarcastic or not.

Absolutely not. It's got a bit of an edge without seeming like something an angry teenager came up with - murder.im or so, "Riot" doesn't have only inherently negative associations -, it's short, easy to remember... it would've been a great name for many software projects, but especially for collaborative, communicative software I find it to be a stellar choice.

Re: IRC v3

#205

Post by Gruselbauer »

lorenzhs wrote: post #101
Gruselbauer wrote: post #92

Earlier quoted context omitted.

Does it still work if you've got WeeChat customised or does it need to be vanilla? I'd like to keep using it from a shell while on a decent machine, but would absolutely not mind the option to connect from mobile clients.

Dev here. It's completely independent of your config. Indeed many things carry over to Glowing Bear automatically, such as scripts that modify the lines (colorize_nicks.py) or create new text buffers (like highmon or grep.py), filters, triggers, etc.

Did check it out. Absolutely amazing project and if anyone still reads through this chat, absolutely what a modern IRC experience should be like in my view. Effortlessly does a lot of the things people on here like about Slack.

I like WeeChat as a client, it's fast and lean and works inside the tmux session that pretty governs my digital life both private and professionally. Alas, it's not always accessible. Getting Putty to reliably work with tmuxed ncurses apps is a nightmare for example, imho.

Glowing Bear solves this brilliantly. It looks great, you get features like inline display of media and is easily secured with certificates from Let's Encrypt.

Thank you, devs. This'll make my "newly discovered FOSS projects of the year" list for sure.

Re: IRC v3

#206

Post by sli »

frumiousirc wrote: post #188
lovesIRC wrote: post #37

Earlier quoted context omitted.

I use KiwiIRC each and everyday. It's one of the nicest looking and easiest to setup web frontend for my hybrid-ircd setup. Sadly it's just a small group of friends and an OLD eggdrop bot that runs a crusty old megahal.mod as entertainment. I haven't found anything that runs as well and can create humerous replies since then. Hopefully the old code will continue to compile for awhile. Anyway, I strayed off topic. I t…

> megahal I have been running https://github.com/pteichman/cobe for a number of years and once in a lucky while it approaches the sentience of a drunk howler monkey.

I've been running this in a Telegram bot while simultaneously building a corpus library from the Simple English Wikipedia and the results have pretty pretty amusing thus far.

Re: IRC v3

#207

Post by superkuh »

Karunamon wrote: post #197
superkuh wrote: post #161

Earlier quoted context omitted.

I don't know about you but I have all of those things simply by leaving my bog standard IRC client connected to the networks. IRC is not a limited protocol. What is happening is that people are using limited computers and networks (smart phones) that aren't capable of the same thing a 1990s computer was.

Which only means the use case for the average user changed and the protocol failed to keep up. And you speak as if the few things I mentioned were the only things that IRC can't do that literally all of its competitors can, rather than a small sample of missing features. Let's see, in addition to what's above, off the top of my head: * Video chat / screen sharing * Audio chat * First class support for connectors to e…

> video, audio, screen sharing

You know what else IRC can't do? Be a version control system. And it can't be a webserver, or do GPU accelerated machine learning, or act as a spreadsheet.

As for "First class support" I'd argue that those kind of things make for a less flexible chat system. It's like having a strongly typed classes instead of everything as strings; like Powershell vs a unix shell.

REST API? Ah yes, in 2016 everything needs to be HTTP, I forgot.

Re: IRC v3

#208

Post by majewsky »

grizzles wrote: post #154
charonn0 wrote: post #138

Earlier quoted context omitted.

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.

Okay, but in which way is JS and WebSockets relevant to the IRC core protocol, if you usually have a proxy (such as KiwiIRC) which speaks IRC in the backend and HTTP/JS/websockets/whatever in the frontend.

Re: IRC v3

#209

Post by anindha »

From https://matrix.org/docs/guides/faq.html/

"IRCv3 exists and is addressing some of these issues; this is great news and we wish them well. It’s almost a contradiction in terms to get competitive between openly interoperable communication projects - we look forward to increasing the richness of MatrixIRC bridges as the project progresses."

Why not merge the two projects or just focus on one? WebRTC seems to be a better protocol right now.

Re: IRC v3

#210

Post by Karunamon »

superkuh wrote: post #207
Karunamon wrote: post #197

Earlier quoted context omitted.

Which only means the use case for the average user changed and the protocol failed to keep up. And you speak as if the few things I mentioned were the only things that IRC can't do that literally all of its competitors can, rather than a small sample of missing features. Let's see, in addition to what's above, off the top of my head: * Video chat / screen sharing * Audio chat * First class support for connectors to e…

> video, audio, screen sharing You know what else IRC can't do? Be a version control system. And it can't be a webserver, or do GPU accelerated machine learning, or act as a spreadsheet. As for "First class support" I'd argue that those kind of things make for a less flexible chat system. It's like having a strongly typed classes instead of everything as strings; like Powershell vs a unix shell. REST API? Ah yes, in…

Your snarky strawmen address none of my points and will not be responded to.

I'm very curious how you think user registration and an API make for a less flexible system. What exactly are you wanting to do with Slack that the existence of an API and a registration system prevent you from doing or get in your way of doing?

And considering that Slack is generally accessed via HTTP, it kind of makes sense for it to have a sane HTTP interface, something for which every language has decent tooling for...

Post reply on HN