That's being worked on and there are already irc daemons that support it (but it's all a bit bolted on until the standard for that is ratified).
However it is also a feature that has to be enabled by the server operator and here you may run into different opinions if this should be a thing or not.
I don't think that's really feasible with IRC unless you invent your own extension to the standard and then convince every other IRC client to adopt it.
Thanks, I should probably look into that... I already have a pandora and slack window open all the time, and to add gitter.im to the mix, it's rarely open... I kind of wish I could just do it all from IRC.
I'm starting to think that creating a newer, extensible IRC client might be an opportunity.
A good IRC server, not client library - I want something where I can basically register channels and react to events in those channels. There's things like Twisted but it's very low level.
I've got a few applications I'd like to use it for, things like voip.ms's SMS. There are some extremely good IRC client and bot libraries, but nothing quite like I'd want on the server side.
I've been considering implementing it myself, but I keep bouncing back and forth about learning Rust first or just doing it in Python and calling it a day... Then I get big lofty ideas about a common IRC server being run by a daemon where other processes would connect to it via some IPC and have a nice client library where they could register channels and have control over just those channels.
That's just wrapping IRC in an actually usable protocol. At that point you aren't using IRC. Might as well use something like Matrix and be able to take advantage of a better protocol.
I really want the IRC protocol to decouple its sessions from the TCP connection and move to using HTTP as a transport, even if the only api verb is "send" and the only response is "receive output buffer".
I used to really love IRC, and think it could undergo a resurgence given the right upgrades.
I didn't say you should; rather, my point is that the problems with IRC mostly happen at the client level rather than the protocol level. Of course, it is also hard to ensure that a dominant client vendor does not start trying to add backwards-incompatible changes to the protocol. This has already happened once, and it's why the character U+0001 is now responsible for /me.
I think ideally such a client could be implemented as a plugin to an extensible terminal emulator, which might help to keep the project small and prevent Jabberification.
STUN/TURN is not a requirement, but most users will have issues if you don't add those services to the mix.
reply