IRC's operator model is pretty awful though.<p>In the 80s when IRC was designed, they didn't foresee the importance of channel #names. Today, we know that names are incredibly important (paying big bucks to keep your domain name in your control, as well as enforcing your names with trademark law where appropriate).<p>The fact that you can lose "control" of a #channel if you simply log off is a fundamental problem of IRC. Its a known problem: you have bouncers and services (ex: NameServ or ChanServ) to solve this problem.<p>---------<p>So "raw" public IRC doesn't work. At a minimum, we need NameServ and ChanServ (and probably a few other bots) before we can make a competent, modern IRC service.<p>I realize that's where IRC v3 was going (standardizing which bots were enabled). But it should also be noted that xmpp avoids the issue all together with a different channel security model.<p>-------<p>Hmmm, maybe there should be an IRC service with a policy to automate #op control to DNS lookups or something. That way, #channels can be connected to DNS lookups and unambiguous? I'm thinking something similar to email / DNSsec style lookups that proves ownership of a name.
I used this documentation to go from zero knowledge of IRC to writing my own client. I have been hanging on IRC using it ever since, it's pretty satisfying!
Question about the ascii diagrams: did you create them manually, or with a tool? I'm curious because I'm creating a tool that does this as well :)