danieloaks

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.

May be worth digging through these tables a bit more if you're interested: https://ircv3.net/software/clients

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

inspircd++ Sadie and everyone who works on insp are great too <3

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 daniel@danieloaks.net

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.

I can't speak for their possible ircd transition plans but OFTC's been working on https://solanum.chat which has a wide range of IRCv3 support.

Yeah moved away from Ruby a while back. Took a little while to stabilise but the new app is a lot better these days.

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

Yeah, I admit the title's not great. I'll update it in the next few days, thanks for the feedback :)

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.

For now, yeah. Devs from various servers are experimenting with alternate s2s protocols aiming to solve this though.

Standardisation is weird in IRC. From what I've seen, most of it that has happened has been the result of one group implementing their custom command/extension and then a bunch of other vendors implementing it in the same way (as well as all the interesting politics behind it all). There's a surprising amount that's been mostly-standardised over time, and not just from formal standards groups like the IETF or IRCv3.

Related, I've been working on these sites for a while which I hope can be useful: http://defs.ircdocs.horse/ http://modern.ircdocs.horse/

Still, it's been really interesting to get into. It's nice seeing how things have gone so far and how they're going forward (and digging into the archives is always fun).

That's a really interesting look at the politics between those two. Applies to some stuff I'm involved in too. Useful link, thanks very much for sharing!

Same over here in Aus, those are standard hours for most every school I've seen.

The main way is the "Category: Standards Track" part at the top. There are a few different categories: Experimental, Informational, Historic, and Standards Track.

This may not be 100% accurate, but basically: Anyone can submit an Internet Draft for the Experimental or Information categories, whereas the Standards Track ones have to come through a more intensive process, an IETF working group, etc. The Standards Track ones are the ones that are technically 'standards', or which are intended to be standards.

That said, some non-Standards Track RFCs do end up getting widely implemented (such as IRC: https://tools.ietf.org/html/rfc1459 ), and an RFC being on the Standards Track doesn't necessarily mean everyone's going to implement it -- or at least not right away (such as IPv6: https://tools.ietf.org/html/rfc2460 ), so it's normally best to take a look around and see the real-world usage for the specific technology/RFC.

For a more in-depth explanation, the IETF is the best place to take a look: https://www.ietf.org/about/standards-process.html

Just have to say, thank you very much for creating this. Use it every for every single new repo I setup, saves loads of time. It's just awesome!

They're not a part of archive.org (just a totally separate group with similar interests, lead by Jason Scott). The specific project page is here: http://archiveteam.org/index.php?title=SourceForge

The best place to pop in is probably on IRC. For the Sourceforge project it's #coldstorage on EFnet, http://chat.efnet.org:9090/?nick=&channels=%23coldstorage&Lo... for the web client. Though note, the ArchiveTeam project seems to be paused right now.

Ditto, Explore is cool.

Regarding the project itself, the license is strange, but it's a nice little userscript.

I use <C-s> for my local machine, and I make the servers I login to use <C-a>. I bind the caps-lock key to ctrl, so it works out pretty well, and lets me work with both local and remote contexts at the same time fairly nicely.

Have to agree here. Your mileage may vary on the sponsor interviews at the end of the podcast, but the guest interview each week is generally pretty awesome, along with the news chatter. Great podcast, highly recommend giving it a try.