DesertBus/txircd — pull request #151 by ElementalAlchemist (2013-05-21 22:32:41+00:00)
Title: Modular txircd (mtxircd)

This pull request is to merge the modular txircd (mtxircd) fork of txircd back into mainline.

Although we discussed this a bit last night, I wanted to use this space to mention a number of the changes from the original txircd 0.0.1 as run during last year's Desert Bus. The biggest thing, of course, is that this version reimplements all those features in a more modular way, but that's far from the only change, so here we go.

- Modularity: The biggest and most obvious change from the directory structure is the addition of modules. All commands and modes are implemented as modules and can be reloaded on the fly. The module API as it currently exists is documented in module_api_desc.txt. If you'd like, we can discuss the Spawner class at a time when you aren't distracted by the fact that I had to implement Diffie-Hellman myself in DB services. :P Although I try to keep state out of modules where it makes sense (i.e. in IRCUser.cache or IRCChannel.cache, since that was the sole purpose of those caches), modules may have an internal state that needs to be maintained. If you'd like to try to move that state out of modules, you may find it easier to start with existing facilities--restructuring IRCD.serialized_data, a dictionary of values written to disk (on shutdown and every five minutes by a LoopingCall), of course being careful that it doesn't contain special types like CaseInsensitiveDictionary, and making further use of IRCD.module_data_cache, whose current purpose is mainly to facilitate sharing of data between modules (e.g. CAP uses this a lot). Since our discussion, I identified a couple places where within the module itself was not the best place to keep that data (one of which I somehow had forgotten about IRCChannel.cache???), and so I've moved a couple of these already. Others (e.g. DB Services) may be a bit of a harder sell. (On the upside, I didn't have to ask for schema changes or anything, so...) If you really want to go for this, I'm sure you'll figure something out. Go ahead and do what you need to with modules, as long as no current functionality is lost. Even if it's completely changed, try to give all the current functionality some space in its new form.

- Enhanced compliance with the modern IRC ecosystem: In addition to full RFC 1459 support (we only got most of it in the original txircd), we now also have full IRCv3.1 compliance and partial IRCv3.2 compliance. I pondered adding message tags from 3.2, but I'd have to hack around twisted's sendMessage function, so I'm putting it off for the future. 3.2 compliance isn't all that common yet, anyway. (3.1 compliance is the current standard, although slowly but surely 3.2 compliance will become more common.) I want to try to do message intents (obviously after message tags) when I stop being lazy and figure out how I want to do the conversion from CTCP. This is low priority in any case so it probably won't be done for a while, which is fine.
For reference: http://ircv3.atheme.org

- SASL Authentication: Although SASL is part of IRCv3.1 and technically already mentioned, SASL doesn't mean much as far as IRCds go--largely they pass it off to services. Hence, this is listed here separately as more of a services feature than an IRCd feature. DB Services implements two common (I believe the two most common) mechanisms and one that I don't think is super commonly supported by clients but was easily implemented and should be. The implemented mechanisms are currently PLAIN, DH-BLOWFISH, and EXTERNAL. (The DH-BLOWFISH mechanism explains the crypto in DB services, and it's still such a shame I had to do Diffie-Hellman myself. :/) I want to add DH-AES when I can find a client that implements it so I can test and make sure it's not broken. The DH part is the same as in DH-BLOWFISH so it's already half implemented anyway and is probably going to become a common mechanism over time. (Really fancy ones like ECDSA-NIST256P-CHALLENGE are ones I'm not worried about for a while, even if they are more secure, especially due to the fact that the only software I know of currently that implements it is atheme, and like zero clients. Irssi can with a script, but we'll wait on that one.)

- ChanServ: On the subject of services, there's a ChanServ now. Mostly it makes things more customizable and makes it easier to branch out later if we want to make this a general built-in IRC services package type deal, since the base of ChanServ is already there. If we want to keep this going, the addition of new services should be fairly simple under the current modular setup.

- data.yaml, a database file for serialized data: Overwriting the configuration file to write persistent data to it in the original txircd was an awful idea. I've gone ahead and removed everything that writes to the config file.

- Performance: I still want to profile the code, and maybe I'll wait until everything is refactored since everything is going to be refactored, but what remained of the old stats code has been fully removed (to, according to our conversation, your great joy :P).

- Separation from the policy of strict oper-override: All the abilities are still there, but not in the same override fashion, mostly because override sucks. The list of sa* modules has been expanded for your enjoyment, and now includes the likes of SAKICK, SAMODE, and SATOPIC to replace their older oper-override equivalents. I prefer this sort of thing especially in general more than just for Desert Bus, but since one of the objectives of the project is to be a general-purpose IRC server that's easy to adapt for Desert Bus purposes, I figured I'd go for it anyway. If you want, we can discuss my hatred for oper-override over a more controlled override system like this (where you can still override when necessary, but you won't accidentally trigger it).

- Reduced bugs and cleanness: Since I nearly rewrote most of the code, I believe everything that directly modifies any of the channel lists is gone except for IRCUser.join and IRCUser.leave, so I expect that the channel list desync bug that caused us so many problems last year is gone. Also, the awful mode class has been removed and replaced with simple dictionaries. Status modes are kept in the channel data in the user class to avoid having to keep track of nick changes and such to keep statuses sane. I don't know what all other bugs are lying around the original txircd, but I like to think that this avoids a number of them. This isn't to say that mtxircd is bug free--I keep finding occasional various bugs, so it's safe to say that there are still a good number of bugs lying around until we get around to extensive testing.

This is probably not an exhaustive list, but most certainly this list is long enough by now, and I believe it encompasses everything I wanted to say. Server-to-server is coming soon; other than that, I look forward to seeing where this next step in txircd goes.