I'm already benefiting from IRCv3's server time extension [1], since I use ZNC and get the actual timestamps for each message that I get from its buffer that way. You have capability negotiation [2] at the core of it all, anyway. So even if you end up not liking some of the new features, your client should ideally allow you to just turn them off.
Well there's still active discussion on how the extension should work. This needs to be squared away first since you'll need all server software and client software to agree.
There is, actually. IRC has no concept of timestamps. IRC has no concept of foreign metadata, even, so shoehorning isn't even possible without looking horrible.
Kiwi IRC actually implements this and has a ZNC module being released soon for it. Hopefully soon, other bouncers.
These type of specs and actually getting them implemented in clients and servers is exactly the type of things the irc.com foundation will be supporting.
The big thing I miss in IRC is that I can't just open my IRC client, connect to a channel, type a few messages, close the client again, do other stuff, come back a few hours (or even days) later, and see if there are any replies to it.
I know about IRC bouncers and all that, but I don't want to set up a server just for that, and managing them is a pain as well. I know about IRCCloud too, but I don't use chat often enough to justify $5/month (I'm poor, and I just want to chat occasionally).
I don't care much for Slack for many reasons, but at least I can actually use it. I find IRC to be functionally unusable because of this.
From a quick glance, it looks IRCv3 solves this with the chathistory extension/specification.[1] But AFAIK most (no?) servers implement this (yet) and the specification isn't finished either.
The new(ish) IRCv3 standard does not break compatibility with existing clients though. If they don't support all of its features, they just have less things displayed.
Not every new feature has to be a protocol extension though? Some clients just lack some sugar coating client-sided features. As for protocol extensions, you could always just disable them in-client on servers that don't support said extensions if anything. But my focus is on making more cleaned up IRC clients, a lot of them feel like they're stuck in time when I know there's lots of things that could be done to them to both make them user-friendlier for newcomers and make them a little more convenient to use.
IRC is a very ill-suited protocol for device <-> znc though. E.g. IIRC it sends you a constant 200 lines of history (whether you've read that history already or not), because that's all it can do.
Some of these are already in place, eg. IRCCloud can render simple markdown, supports push notifications, can show inline images, supports display pictures, Slack-like threads, emojis, etc...
Hopefully longer term we won't need to use IRCCloud/a bouncer to keep chat history. AFAIK an IRCv3 server should be able to offer that natively (to an IRCv3 client).
As for unencrypted TCP... a lot of IRC networks seem to offer TLS these days.
Not saying this is perfect -- far from it, but people are working on improving IRC!
IRCv3 tries to fix a lot of those concerns and provides a lot of features long due. If you have any specific concerns not yet addressed by IRCv3 I'd start talking about it in the issue tracker.
What!? That's completely the opposite to my experience! Essentially, after setting up ZNC to your liking, all you have to do in your client is change the irc server from say, irc.freenode.net to znc.yourserver.com:port and add a password for the server, username/freenode:password, done!
I thought it'd be annoying having to add servers through the ZNC interface (either web or SSH) but it automatically adds/removes them when you join/leave.
In terms of buffers, I generally don't have it set to 2000+, normally around 100 max. I'll just go through the logs if I really need to catch up.
[1] https://ircv3.net/specs/extensions/server-time [2] https://ircv3.net/specs/extensions/capability-negotiation
reply