terminal-wise, irssi and weechat are the traditional ones recommended these days. but there's a couple newer ones like catgirl: https://git.causal.agency/catgirl/about/ and some rust ones out there.
GUI-wise there's HexChat, mIRC, Quassel, lots of interesting options to look at.
Yeah we didn't need to agree in writing because I didn't sign anything giving them access, control, ownership, or anything else over my IRC projects. They offered to purchase one of them at one point, but I respectfully declined.
Ah! So what we have right now is a websocket API (so clients can speak IRC via websockets), and our default config basically turns the ircd into a 'bouncer' (it automatically stays online all the time, caches message history, plays it to you when you join and all that).
We're looking at some new persistence capabilities and caps to speed up connection, which should (hopefully, eventually) provide something similar to that c2s bouncer api in terms of speed: https://github.com/ergochat/ergo/issues?q=is%3Aopen+is%3Aiss...
Always up to take on and look at suggestions though :D
It depends. There's a lot of people on/around IRC who really like it (see libera and all the other networks), and yeah there definitely are people spinning up new smaller networks. Especially with things like https://sr.ht/~emersion/gamja/ and self-hosted https://kiwiirc.com/ , as well as really polished client experiences like irccloud, it's easier to convince people to join in.
Right now I'm working with a dev from libera on a client that aims to replicate a lot of things experience-wise from newer chat services. Hoping that with that, smaller self-contained servers can become more of a norm~ But for now, your best bets for finding activity are probably Libera and a couple of the other larger networks.
To be fair there was also collaboration between PIA and Linux Mint while I worked at PIA. That'd probably be a question best answered by the Mint people who're involved
Oh haha, hey! I was employed by Andrew across a fair few of his companies (I didn't know Shells.com was owned by him while I was working there though). Buuuut this is entirely unrelated to him, same as my other project https://ircdocs.horse/
It's totally fair to make that link, but I very explicitly told everyone over at LTM/H (including PIA and Handshake) that Oragono/Ergo and ircdocs were not work projects in any way. And while I was working on Shells.com, I was very explicit that I wouldn't be touching any IRC stuff for money while there.
But yeah, it's definitely good to be wary of these kinda links, given what happened to snoo's and fn/libera's team. If you wanna ask any more questions about my stuff in particular, feel free to ask here or send me a mail at [email protected]
For what it's worth, we've been throwing around a websocket standard that should be supported across a range of servers. On the decoupling sessions from the TCP connection side, the server that I work on (Oragono https://oragono.io ) does this by default, and I've heard that InspIRCd has plans to do work on this issue as well. Definitely a lotta fun stuff in this area.
For the most part, the Foundation's just a project to support existing projects and developers who use the IRC protocol. This can mean providing financial support, access to more business-oriented resources like designers/legal/etc, as well as simply improving the quality of protocol documentation out there (the part I'm handling).
In terms of strict protocol improvements, the IRCv3 WG is the real place where that's going on, the most authoritative thing in terms of introducing new stuff across the IRC infrastructure these days: https://ircv3.net/
But, for new developers looking to get into IRC today, the resources aren't as available as they could be. Sure, there's a bunch of code to look at, libraries you can use to get started that seem to work fine. But when you wanna start digging into the wire protocol, how particular commands or functions work, how to actually approach writing a client/server from scratch, all you have are either the RFCs, some newer resources like the ircdocs/IRCv3, or stuff spread across 20+ year-old textfiles and pages all across the net. My intention for the documentation side of the Foundation is to build up information on how to use/parse commands and numerics, how widely they're used (in terms of software support), and how to really dig into and approach development with the protocol – since that feels like the more valuable information to be out there right now for new devs. It'll be linked to and public sometime soon, it's just that building up a swathe of documentation large enough to show we're serious about it takes some time (if you want those docs to be decent-quality, at least).
For what it's worth, I'm both the primary writer/maintainer of the Foundation's developer docs work, and the maintainer of the more community effort https://ircdocs.horse/ , so hopefully I'm on the right track with supporting devs in the protocol documentation sense.
If there's any questions or suggestions for directions to take on this (stuff that you, as a dev, would find useful for writing IRC software), please let me know! Even if it's not there for initial launch there's a fair backlog of stuff I'm looking to make up with this project.
Can't speak for software but in the case of these specs, 'Modern' in the title pokes fun at the fact that the core protocol specifications most people refer to are around 25 and 18 years old, respectively. RFC 1459, very commonly referred to and still the first reference for a lot of IRC software authors, came out before I had my first birthday!
For what it's worth, there's been a bunch of work around backlogs (to simplify bouncers, though if more niche IRCds wanted to incorporate it natively that'd work too). CTCP isn't great, but the simplified CTCP I-D improves things for clients. DCC I'm documenting, hoping we can replace it with something more appropriate and/or extend DCC as it currently exists in a backwards-compatible way (there's a loooot of debate and discussion on DCC in the v3 WG. once we fix up a bunch of misc protocol stuff it's definitely something we'll approach).
For sure, simplicity is better than complexity. A fair amount of the v3 work aims to simplify things that are already done in a bunch of vendor-specific ways and bring them all under one clean, well-specified roof. Always happy for extra help there :)
These specifications just capture how the IRC protocol currently operates, so that isn't described here (isn't widespread afaict, and there isn't a clear 'winner' in terms of implementations/mindshare). The issue with something like E2E encryption is getting rough consensus with all the vendors, which is what the IRCv3 WG focuses on: http://ircv3.net/
There's been a number of E2E encryption methods proposed in the past such as SSL/TLS DCC (which doesn't do certificate verification from what I've seen, so that's not too useful here), FiSH and OTR are already used decently out there but I'm not aware of any widely-available, simple-to-implement specification for clients to look at. There's another interesting proposal here, but it hasn't gained traction as of yet:
http://blog.bjrn.se/2009/01/proposal-for-better-irc-encrypti...
Yep, pretty much. Unfortunately the protocol's gotten fairly complex without standardisation to keep everyone on the same track. I do my best to simplify the text where I can, but a little more in-depth and correct is better than something simpler that doesn't match real-world implementations.
edit: With regards to encryption and backlog, they're being worked on in the IRCv3 WG, worth checking out if you're interested in changing the protocol for the better:
http://ircv3.net
Thanks, I'm glad it's useful! Feel free to check out this page for some other useful links if you dev on it in the future: https://ircdocs.horse/info/ :)
The first page I wrote when I was making the site was this one (https://ircdocs.horse/specs/) – and the initial drafts were a fair bit screechier than what's there now. I wanted people to know that everything on ircdocs is pretty much just my thoughts (as opposed to the more consensus-based approach of IRCv3), and figured the horse TLD would make people take it less seriously.
Didn't exactly work out, now that a fair number of devs are using it as a legit protocol reference. Still, gives the site some decent character and makes it memorable :P
Thanks for posting this here! I will admit, it's hard to know when to start posting it around, but this is already a fair bit more accurate than the traditional RFCs in a lot of ways. It's also lead to an Internet-Draft around CTCP being submitted here:
https://tools.ietf.org/html/draft-oakley-irc-ctcp-01
If anyone's interested in contributing or asking questions, just reach out!
This project (ircdocs) works in tandem with IRCv3. ircdocs tends to focus on currently-implemented stuff (such as the linked Modern docs), where v3 focuses more on establishing rough consensus around new specifications and features.
GUI-wise there's HexChat, mIRC, Quassel, lots of interesting options to look at.
May be worth digging through these tables a bit more if you're interested: https://ircv3.net/software/clients