Hacker News Reader

Comment by dijit | Hacker News Reader

And I’ve been running an irc network myself for more than half that. It’s hard to beat the effective simplicity even if it’s janky to use and limited in functionality.

That said I wish IRCv3 was coming sooner. The ability to replay messages and handle TCP connection loss somewhat grafefully has an immesurable appeal; because despite how fast the internet gets; it never seems to get more reliable for individual long lived connections.

Edit: shameless self promotion if you want to use my network for your own needs or meet my 350+ friends then point your favourite irc client to irc.drk.sc/+6697 (ssl-only)

View on HN

Mind if I ask what server you use? I currently use ngircd when I do use a server, just find it easier, I dont have any services for accounts setup is the only downside for me but usually they seem to be a pain (never is it just an apt install) and I did have a bouncer setup ages back, I wish more people were IRC friendly.

IRCv3 really needs to hurry up, we need at least simpler account registration and all that as part of the client if possible, it could go a long way.

Another thing I wish would happen is for a WebSockets compatible spec for IRC so you can just use it in-browser without a "bridge" and it could be easier for most newcomers to just spin that up and connect.

We're using inspircd, mostly because it's quite orthogonal and follows the RFC's the closest. Their project is actually part of the IRCv3 working group. So the alpha/main branch of their repo has many IRCv3 features.

But we're using atheme for the accounts backend- something I actually think could be improved upon tremendously actually

> Another thing I wish would happen is for a WebSockets compatible spec for IRC so you can just use it in-browser without a "bridge" and it could be easier for most newcomers to just spin that up and connect.

I know some people who could work on this as an IRC module you just load; if they had time. It's something I would also like as it would enable a new generation of electron/web applications for IRC. And, hey.. it works for slack :)

> I know some people who could work on this as an IRC module you just load; if they had time. It's something I would also like as it would enable a new generation of electron/web applications for IRC. And, hey.. it works for slack :)

Totally agree, but just as important it works REALLY well for Discord! They're unlike Slack in that you don't even need an account to start seeing a server (or used to be?) you just join and oh look, you can post, want an account? You can register! Oh look you're hooked, bam! Then the rest is things a clean UI could handle like displaying images in the client and videos (I know some IRC clients already display images).

I do yearn for the ultimate IRC UI driven client, it's almost Quassel for me.

> Totally agree, but just as important it works REALLY well for Discord! They're unlike Slack in that...

But they're just like slack in that they have a non free server code you can't run yourself, and a non free client binary you can't modify to work around the myriad UI frustrations, and use a non free protocol underneath that relies on free software people to write the integrations back into published, free, open specification protocols.

We're actually putting together a Websocket spec at the moment for IRCv3. There has been a few experiments and an implementation that has been getting used more frequently has proven to be helpful here.

https://github.com/kiwiirc/webircgateway

This is awesome, I'm really hoping this spec becomes adopted by all major IRCd's

Still no end to end encryption.

Ircv3 would have been good 10years ago. IRC is great but everything has it's time. Even the web has it's time.

E2E is (and should be) client side dependent.

OTR exists for most (if not all) clients, also you can do DCC direct messages, which bypass the server completely, if you:

A) don't mind leaking your IP to your chat partner and

B) force your client to encrypt the traffic.

E2E should be for all client to client communication. OTR is opportunistic. Good many many years ago but not enough for this day and age. When you think of a protocol's viability,consider how we'll be stuck with it for decades (like irc and email). Non-e2e support is intolerable.

I hate to be "that guy" but why don't you build it? there's nothing about the protocol that prevents you. And if you want it baked in (cipher negotiation) why not talk to the IRCv3 people?

I'm nobody. The point of a protocol is for others to use it. Also,there are 'ok' alternatives for messaging like signal and wire. But yeah,i don't want to spend all my time working on something no one will use :-)

Reply on news.ycombinator.com