IRC Services Technical Reference Manual

11. Future work

11-1. Design issues
11-2. User interface issues
    11-2-1. NickServ issues
    11-2-2. ChanServ issues
    11-2-3. MemoServ issues
    11-2-4. OperServ issues
    11-2-5. StatServ issues
    11-2-6. Other issues
    11-2-7. Rejected suggestions

Previous section: Compilation | Table of Contents

11-1. Design issues

Services currently operates under the assumption that enough memory will be available for its needs, and simply aborts the program in most cases if a memory allocation fails (the smalloc() function). On modern systems this should be true most of the time anyway, but a better design would eliminate smalloc() and friends, and instead degrade gracefully when out of resources (for example, returning an "internal error" or "out of resources" message to a pseudoclient command).
Services ignores the possibility of truncation when using the snprintf() and vsnprintf() functions. In most cases, such truncation would only result in the user seeing a truncated response string, and I have (at least in recent development) made an effort to check for overflow in security-related situations before calling snprintf(), but I cannot rule out the possibility that some security issues related to string truncation exist. The code should be rewritten to (1) use an snprintf() that follows the POSIX standard of returning the number of bytes that would be written given an infinite buffer and (2) check the return value for overflow where pertinent.
As also mentioned in section 10-5, the module callback implementation relies on the very flaky assumption that any type can be passed through a void * and come out unscathed on the other side, regardless of the parameter types used by the called function. This happens to work on the Intel x86 architecture because everything is 32 bits, and on the AMD x86-64 architecture because the first five parameters (the maximum supported for callbacks in the current implementation) are passed in registers rather than on the stack, but there is no guarantee that this will also work on future (or other existing) architectures. The implementation also assumes that a function can be passed more parameters than it actually accepts without any harm. One possible alternative is to use variadic argument lists, but this would require changing all callback functions to take a va_list argument and retrieve the arguments manually; due to the amount of work this would take, the current implementation has been left alone for this release, and a redesign is left for future work.
Services defines its own types for integers of specific sizes: int8, uint32, and the like. The standard header file stdint.h declares similar types, using names like int8_t and uint32_t; however, these are not used because this header file did not exist (or was not standardized, at least) during the early stages of Services' development, when the need for sized integer types arose. Changing the code to use the standard types would remove the need to define those types in the configure script.
It has been suggested from time to time that Services use a full-fledged database management system such as MySQL for database storage, to allow easy access to the data by other programs such as CGI scripts on a web server. In fact, the major services programs I am aware of which are currently (October 2007) under development seem to be taking this route. However, Services has been designed from the start with the assumption that its data will never be modified by any outside process, and in fact, even the change from periodic expiration to expiration on access made during 5.0 alpha development caused several dangling-pointer bugs to surface. Attempting to use external databases that could be modified by other programs within the current Services framework would at best cause such modified data to be overwritten when Services saved its databases, and at worst cause Services to crash when it tried to access data that had been modified without its knowledge. That said, this design decision enforces a single-threaded execution model for the entire program, and for that reason alone is a good target for redesign. (With respect to read-only access to Services data, XML-based data export was added in version 5.0.)
In relation to the above, XML has also been suggested as a native database format. I have been reluctant to do this, both from the practical point of view that writing the databases in a textual format takes considerably longer than doing so in a binary format and would impair Services' responsiveness, and because I see XML as a data interchange format rather than a data storage format and believe that the two should be handled separately. However, the former issue may well be moot for smaller networks, and the latter is a matter of taste; in addition, the current XML import and export modules lack the flexibility of the database system, as discussed at the top of section 8-4-1, so I leave this issue here for consideration.
Currently, Services records all log messages to a single log file, in a format intended for human perusal rather than machine processing. This could be improved with an "event log" system and logging modules, whereby a common log function is called with some sort of event identifier and event data, and the log module(s) then perform appropriate actions; this would allow, for example, the creation of a log file with all nickname-related events stored in a format easily parsable by other programs, or the creation of an online "log channel" to which nickname and channel operations are sent.
ChanServ currently requires a password for founder-level access to registered channels. However, since those privileges are also granted to the founder him/herself upon nickname identification, channel passwords could be considered optional; deliberately not setting a password on a channel would thus prevent the channel from being taken over by password theft. However, the password also serves as an extra measure to prevent accidental dropping of channels (the DROP command requires password authentication), so an alternate method would have to be considered if channel passwords were made optional.
As mentioned in section 7-4-1-4, it may be desirable to include "successor" channels in a user's owned-channel count. This would alleviate the potential for a channel with a successor to nonetheless disappear on deletion of the founder's nickname (because the successor owned too many channels at that particular time).
Services has used a level-based access system since its inception, in which channel users are assigned a single numeric access level; this level then determines what privileges (if any) the user is allowed on the channel. While more flexible than a simple system like the XOP command set, the use of numbers can prove confusing and difficult to understand, and there is no way to selectively grant higher-level privileges without also granting lower-level ones. A system such as the "role" system used in PTlink Services 3.x, in which privileges are individually granted to users, could help solve these problems.
The use of binary bitfields to represent channel modes allows for efficient processing; however, it causes problems when changing from one protocol to another, because channels' mode lock data is stored using those same bitfields. One way around this is to simply export and re-import the data using XML (which is probably a good idea in any case, to compensate for things like different processing of nicknames and channel names). An alternative approach would be to store the modes as strings, at the cost of additional processing and storage requirements. Still another approach might define a common set of mode bits among all protocols, allowing other protocols' modes to be interpreted properly; in essence, the set of modes defined in the core mode handling would be the union of all those defined in the standard protocol modules, rather than the intersection. However, this would require wider data fields to handle the necessity of giving every mode its own unique bit, and would leave third-party protocol modules without a way to express their own custom modes. The wisdom of including protocol-specific data in the Services core is also questionable.
The OperServ privilege system is currently very coarse. It essentially provides only three distinct classes: no privileges, Services operator, and Services administrator. (The super-user class is identical to the administrator class except for the ability to modify the Services administrator list and to bypass the NSSecureAdmins security restrictions.) Moreover, the privileges granted to Services operators are very limited, while those granted to Services administrators are extremely powerful, leaving no "middle ground". At least one user of Services has noted that the inability to view user information, for example to resolve disputes between users, without also granting full administrator privileges is problematic. Services would benefit from a review of these privilege classes; for example, it might be wise to require super-user privileges for dangerous commands such as JUPE and SHUTDOWN, which would then allow the administrator class to be used for tasks such as viewing user information.
Related to the above, it might be useful to allow OperServ privileges and related commands (such as NickServ and ChanServ FORBID or INFO ALL) to be assigned to different classes based on configuration settings. For example, one network might decide to allow Services operators to use information retrieval commands (currently limited to Services administrators), while another might choose to let all IRC operators use the OperServ AKILL command. Note that allowing this sort of configuration will require dynamically-generated help messages (since the required privilege class may change at runtime), in addition to new OperServ privilege-checking functions similar to is_services_oper() and is_services_admin().
Configuration directives have been added somewhat haphazardly over the course of Services' development, and could probably use a review and overhaul. In particular, there are several "negative options", including NoBouncyModes, NoSplitRecovery, and NoAdminPasswordCheck, which were added as negatives to avoid changing Services' behavior in the middle of a release series. These have the unintuitive effect that enabling the option disables a particular behavior; ideally, such options should be written as positives (e.g., BouncyModeCheck or SplitRecovery) and enabled in the default configuration file.
As described in section 10-3-2, the module compilation process makes use of several time-consuming tricks to simplify the individual modules' Makefiles. However, version 3.81 of GNU make introduced the special target .SECONDEXPANSION, which causes dependency lists in subsequent rules to be expanded twice; for example, a rule
%.so: %.o $$(OBJECTS-$$@)
(note the escaped $ characters, to prevent expansion on the first pass) would do what it looks like—supply a dependency list using a variable name derived from the target module name. Use of this feature could substantially simplify the modules/Makerules file, at the expense of incompatibility with versions 3.79 and 3.80 of GNU make.

There are also several issues listed in Appendix D of the user's manual.

11-2. User interface issues

A number of possible functionality additions or changes have been considered by the author or suggested by users over the years. These are summarized by subsystem below, in no particular order.

11-2-1. NickServ issues

Allow certain nicknames (specified by wildcard mask) to be used but not registered. Suggested by Mark Hetherington <mark@ctcp.net>
Include successor channels in the output of the LISTCHANS command. Suggested by Marc-Andre A. Fuentes <nothing@psychopat.org>
When using the nickserv/mail-auth module, perform a DNS (MX) lookup on the domain in the E-mail address given to the REGISTER or SET EMAIL address before actually trying to send the authentication code message. Suggested by Brian <n1uro@n1uro.com>
Include Services administrator or operator status in the output from the INFO command. Suggested by Yusuf Iskenderoglu <uhc0@stud.uni-karlsruhe.de>
When the NSForceNickChange configuration option is set, have the GHOST command change target users' nicks rather than killing them outright. Suggested by Mark Hetherington <mark@ctcp.net>
An option to warn users via E-mail when a nickname is about to expire. Suggested by Hans v Steenbergen <thebeast@xs4all.nl>
An option to allow users to change their "fake usermask" (username and hostname shown in /whois output) to their registered E-mail address, on servers supporting such a feature.
Allow Services administrators to modify other nicknames' access lists. Suggested by Mauritz Antunes <mauritz@brasnet.org>
An option to limit the set of languages users are allowed to select with SET LANGUAGE. Suggested by Mauritz Antunes <mauritz@brasnet.org>

11-2-2. ChanServ issues

Better integration of channel keys with ChanServ; for example, authorized users should have a way to enter even if a channel key is set, much like they can use the UNBAN or INVITE commands to get around channel bans or mode +i.
An option to autokill users entering a forbidden channel (e.g., to efficiently remove botnets from a network).
Allow autokick exceptions. Suggested by Dionisios K. <admin@vonitsanet.gr>
A configuration option listing channel modes that uers are not allowed to change, like a mode lock enforced on all channels. Suggested by <medice@gmx.at>
A ChanServ LINK command, like the NickServ command of the same name but for channels. Suggested by Craig McLure <Craig@chatspike.net>
A VERBOSE option, causing ChanServ to send notices (like for OPNOTICE) to the channel for all ChanServ commands. Suggested by <martin@e-tech.us>
A command to look up channels by E-mail address. Suggested by Finny Merrill <griever@t2n.org>
More intelligent handling of a missing "#" in the channel name parameter for REGISTER. Suggested by <jollino@sogno.net>
A better method of determining a channel's "last-used" time than the last time a user was auto-opped (but avoiding overly sensitive schemes that update the last-used time even for spambots).
An option to send an explanatory notice to a user who tries to use a restricted ChanServ command on a channel with the SECURE option set, without identifying for their nickname.
Record the nickname of the user that added each access entry and the last time the access entry was used.
Display access entries ordered by level.
Allow modification of (adding modes from or removing modes to) channel mode locks, rather than wholesale replacement only.
When switching IRC server types that do not share the same set of channel modes, graceful degradation of locked modes not available with the new protocol. Suggested by Yusuf Iskenderoglu <uhc0@stud.uni-karlsruhe.de>
Treat the /topic IRC command identically to the ChanServ TOPIC command when determining whether to allow a topic change on a channel with TOPICLOCK set. Suggested by Casey <caseyclaydon@fastmail.com.au>

11-2-3. MemoServ issues

A setting to reverse the meaning of the ignore list, so that only users on the list are allowed to send memos.

11-2-4. OperServ issues

A command to kill nicknames matching a wildcard or regular expression. Suggested by Guy Antony Halse <guy@rucus.ru.ac.za>
An option to send a notice to autokilled users of the autokill expiration time before performing the actual kill. Suggested by <saturn@jetirc.net>
The ability to use full regular expressions, not just simple wildcards, in autokill and other wildcard masks. Suggested by Aragon Gouveia <aragon@phat.za.net>

11-2-5. StatServ issues

Keep track of the number of users per domain on each server. Suggested by Ali Sor <alisor@softhome.net>
Keep track of statistics such as the number of joins and kicks for each channel and the number of connections made by each user or nickname. Suggested by <Georges@Berscheid.lu>

11-2-6. Other issues

An option or module to log all WALLOPS (and GLOBOPS, etc.) messages. Suggested by Andrew Kempe.
An in-program method to clear one or more databases (currently, this can only be done by removing the corresponding database files). Suggested by <RealCFC@chatfirst.com>
A network status page, possibly with graphs (see for example irc.netsplit.de). Suggested by <jollino@sogno.net>
An option to autokill users who are killed repeatedly for bad passwords. Suggested by Jonathan Morton <chromi@cyberspace.org>
The ability to reconnect to the uplink server if disconnected.
A way to send commands to OperServ (or possibly other pseudoclients) from another process.

11-2-7. Rejected suggestions

In addition to the above, the author has explicitly rejected a few feature suggestions as unnecessary or inappropriate for inclusion in Services; however, they are recorded here for the consideration of future developers.

Automatic opping/voicing/etc. of users on channel access list changes. For example, automatically setting +o on a user added to the access list with auto-op privileges. While this is certainly not a useless feature, access list changes are typically one-time events, and do not warrant the added complexity of including such a feature; the user can be manually opped or voiced just as easily.
Allow identification to multiple nicknames. This can result in ambiguities when handling channel access levels. For example, suppose a user has identified to two nicknames, GoodNick and BadNick. If on a certain channel, GoodNick has an access level of 50 but BadNick has an access level of -10, what access level should the user be granted? The answer varies with the particular channel and user, and rather than attempting to invent a system of options and rules to handle every possible circumstance, Services simply disallows identification to multiple nicknames entirely. (Services will remember whether a user has identified for a nickname if the user temporarily switches to another nickname.)
A channel option or configuration file setting to make ChanServ join channels, or a BotServ pseudoclient to do the same thing. This is one of the most common feature requests, but it has consistently been rejected as incompatible with the design of Services as a streamlined network tool rather than a users' toy, and also because standard bots can provide equivalent functionality much more flexibly than a single Services pseudoclient could.

Previous section: Compilation | Table of Contents