This header is hopelessly outdated. Don't treat it as gospel. Preferably talk to me first. -- asuffield Stuff we hope you'll help with. Just pick something and send us a patch. Please format your patch just like the other ones in debian/patches. Email your patches to patches@openprojects.net. . Not yet started. - In progress. + Done (or thought to be done), will be removed when confirmed and added to the changelog. Coding guidelines: In general, all patches which produce new channel and user modes should propagate across servers both initially and on server reconnect. All logging should be global. Release critical ~~~~~~~~~~~~~~~~ None, presently. None of the features listed in this file are critical to releasing. (Nothing should ever be added to this section again, new features are not release critical). Important ~~~~~~~~~ DIFFWALLS- Several categories of WALLOPS messages will be added. At least one category will be available for use by end users and will be throttled. The throttling for that category will be "one message maximum every five minutes across the whole network" and "one message maximum every six hours per host." That's tentative. And if it's abused, we'll come up with a work-around. Anyway, several categories of WALLOPS, clearly labeled, and each category can be turned off by the user via a unique usermode character. One of them will be for network news. We'll keep network-wide statistics on how many users have each usermode turned on. Probably counted the way LUSERS is counted. USER_CLOAK. User cloaking. Needs a champion to pick it up. The algorithm is: usermode +a users see all real user@host. A channel mode, +a, is also created, the use of which is similar to +o. Only ops in a channel (and O-line users with both godops and +a) may set a user in a channel to +a. Channel mode +a shows real user@host for all users on the channel where you have +a. The act of setting you +a is only visible to the setter and the person being set. Chanops may set themselves +a but do not start out that way, hence do not see real user@host in their channels. Operand of +a channel mode should be a nick!user@host mask and hence, for predictability, users should be checked against this list and a flag set on their arrival in channel. Reality check this approach, bans are essentially already done this way. +a should be a channel flag like +ovh, not a channel mask like +bdeI -- asuffield (Old patch is useless with 1.1, so resetting to . from -) NEUTRALKICK- Replacement of standard KICK command behavior with lower-temperature "part with neutral message." There's an experimental command REMOVE to test a way of doing this one with clients, sending PART instead of KICK. We can transfer the behaviour when we're satisfied most clients are happy with it. -- asuffield LISTGROUPS. Channels will be given affiliation with one or more /LIST groups. Users will only be able to see them if they specify a token on /LIST. Examples: /list dev, /list support, /list social. List group "public" is listed when the user specifies no group. Channels can't be placed into groups with a channel op command; the channel owner will make a request of some sort, designed to be fairly simple to execute, and staff will add the channel, probably through OPERSERV until NOSERVICES is implemented. I would be inclined to leave this until NOSERVICES is done anyway. -- asuffield NO_THROTTLE- User mode to turn off throttling, research whether this is necessary and implement if so. I think a channel mode would be more valuable, to turn off anti-flud code, for channels such as #flood. I don't think that throttling can be safely turned off, +F already turns off anti-flud code for a user (when they are sending, not receiving). -- asuffield However it is trivial, so I'm implementing it. Channel deactivation should also be possible. -- asuffield CHANSUMMARY. The topic will no longer be displayed on a LIST. It will be replaced by a channel summary which will be produced by channel owner and vetted by staff. Where topic may be a comment about current channel activity, the channel summary is a fixed description of the channel. Normal ~~~~~~ REMOVE_WHR. Look at removing the bitchx "IRC Whore" message. Somebody please tell me what on earth this means -- asuffield DEFINE_HUP. See about what should be rehashed on SIGHUP. Have to rethink this when noservices is done anyway -- asuffield HUSH_MODE. "I am a spambot, don't let me do stuff" user mode. More info required (specifically, what is this supposed to do? As written, it's just plain wrong - anti-spambot stuff has got nothing to do with umodes) -- asuffield LIMBO_MODE. Problem users are fed into a "#limbo" sort of channel where they can be interviewed by staff for disposition. Old channel state is saved, users are parted from old channels. Post-interview resolution can be "restore state", "drop from #limbo channel" or "GLINE." Possibly a limited version of this patch can be implemented for channel owners as well, where users are passed for disposition but only removed from a single channel, and possible dispositions do not include GLINE unless this is done on multiple channels. It's worth noting that for channel LIMBOMODE, unless the user has caused problems on multiple channels, server staff are essentially acting in a "last ditch catalyst" consulting mode for the channel owners. In this mode catalysts become carriers for the reputations of the people so dispatched and should be careful in their analysis of situations. I propose this be made a special sort of user mode, only set by suitably empowered opers, which sends out PARTs for the user on all channels and prevents them from doing anything, with the exception that an oper may INVITE them someplace. Not sure if this is the ideal way to implement it. I see no need for a limited version for a single channel, this effect can be achieved with the existing features. -- asuffield MODE_4_PLUS- Research any problems in bumping the mode changes per client past 4. Not sure who/why this was put back. I've removed the limit on the _number_ of mode changes per client entirely in 1.1, and add it back in a per-client configurable manner if needed later. -- asuffield NOSERVICES- The complete distribution of hybserv functionality to the servers. The intended technique: Servers may contain additional code to maintain a local database of "static" channel and user attributes (those currently maintained by services). This database may be implemented via a fairly simple and standard Unix database library (i.e., .dbm). Through a suitable abstraction layer so it can be swapped with something else later if necessary. -- asuffield Records sent between servers will have additional timestamping (creation and last update timestamps) for static attributes. Servers may be listed as "authoritative", in which case they are allowed to respond when they have an earlier creation timestamp or a later update timestamp for an entity, by broadcasting the overriding record to allow servers to resync. Resync for an entity may also be kicked off manually by administrative command. Any server may request an update for an entity from the server at its immediate connection point. Special servers may be created for web interfaces and for backup and restore and query; these may be authoritative or not. A non-authoritative server may request an update for an entity only when it is connected to a network containing at least one authoritative server. Public keys will be used per-entity to validate updates and sign database records. Reality check processor requirements. Make authentication modular, and allow "connected via SSL" as a method? -- asuffield Some sort of mechanism for varying the speed with which an authoritative server responds to prevent update floods? The emphasis of existing IRC features may be changed over time to make more data static and less dynamic, in order to reduce sync bursts. A genuinely new server will have a pretty large initial sync burst, but it's possible it could start with a seed copy of the database ported from an authoritative server to reduce this time. Might as well automate that and have it go download a (compressed) database image automatically. -- asuffield Only active entities need have their static attribute data synced, as an operational minimum. Partially pending for 1.1. This will have to be examined later and rewritten in a less prosaic manner. -- asuffield TEXTARCHIVE. Public channel logging to allow logs to be placed on an archival web site. The intent is to make those logs public, and public comment on this would be appreciated. Here's how it is intended to work. In order to archive a channel, a channel mode must be set by the owners. It's likely that the use of this mode will be restricted to registered channels. The operation of the channel mode will be static, i.e., not rescinded if the channel is empty. It may only be rescinded explicitly by channel owners. When a client enters an archived channel, an informative message will be provided, probably including the URL of the index page for the archives. A method for sending unarchived messages to the channel, usable only by channel operations staff, will be provided. To address privacy issues, a user mode will be available which, when set by a client, will result in that client not being able to enter any channel which is being archived. An informative message will be provided to the client when an attempt is made to join a channel whose traffic is being archived. INVISCHMOD. The capability of making channel mode changes invisible to users not capable of making such changes. These would include +a-a+o-o. Hide the ops while you're at it, and everything that entails. Then tie it to a channel mode. Or something in noservices. -- asuffield CAPABILITY- Replacement of the O-line regime with a system of capabilities (in the general sense). Depends on PASSWORD. Pending for 1.1 -- asuffield PASSWORD- Allow users to sign on as identified users with no race conditions. Realistically depends on NOSERVICES. Pending for 1.1 -- asuffield Wishlist ~~~~~~~~ RANDPING. Before the IRC server sends anything to the user, it should have received a reply to a ping sent with a random string as the token. As well, all pings should be random strings. This prevents 1) someone from blindly spoofing an ip and 2) makes it slightly harder to take over someone's connection. It does neither. This wouldn't actually gain anything. -- asuffield GETTEXT. Anyone willing to convert hybrid to gettext? Yaright? Anyway, this should be done in form_str() and get_str() and/or the data structures in messages[_cust].tab. Basically, finish moving all the strings to get_str() first. That said, gettext is needless effort, just translate messages_cust.tab as appropriate. Note that this is set by the server and not the client. Doing it on a per-client basis is more interesting, but not a job for gettext. -- asuffield DOCUMENT. Documentation is needed for server installation and maintenance, capabilities use ("O-line functions, logging and display"), channel administration and end-user operation. doc/sgml/dancer-oper-guide.sgml is, while sparse, adequete for now. dancer-user-guide.sgml is very much incomplete, but should be enough for OPN to move to dancer from ircu. -- asuffield JOINFLOOD- JOIN flood control. Possible auto-KNOCK. Hybrid already has partial JOIN/QUIT flood control. Look into extending it so that it covers multiple clients joining the same channel -- asuffield IPV6_EVAL. IPv6 support, evaluate difficulty. Hybrid-7 has it, but not likely for 1.1 because of the sheer amount of other stuff that is already pending. -- asuffield PLUSCHANNEL. Implement '+' channels (no ops on join, default mode of +nt). A partial patch in the patches directory was removed. It's in the attic. It's not complete and may be highly out of date. If services' features to do similar things proves inadequete, I would rather have a channel mode for this (can be set by ops, can only be unset by opers, cannot be set on registered channels). Not that I really like + channels anyway. -- asuffield (Partial patch is totally useless for 1.1, so setting the status of this item back to . from -) Obsolete ~~~~~~~~ (This section is for historical things that are no longer sufficiently accurate to be useful) MD5_EVAL. Audit MD5 crypt support to see if anything is missing. This item will have to be rewritten when the new pluggable auth system is complete. Until then it's impossible to audit anything. -- asuffield AUDITQRACE. Is there a race condition which sometimes results in messages getting through to the channel when the user is quieted and/or channel +n mode is turned on? Audit. Anybody got any details on this one? From the way it's stated it doesn't sound important. -- asuffield (This is almost certainly irrelevant given that code is being completely rewritten for 1.1) LOGDISPFLAG. Clean up logging, display and flags. Add a separate flag space for logging options per client. Move over any user flags that are clearly logging flags. Make log entries and server messages look exactly the same for each type of log entry (except that log entries have timestamps). Add a logging line to the servers, of which more than one may be specified, which includes a set of logging flags and a destination file for the log entries. Make sure that all capabilities for O: line users are controlled by a flag. Make sure that O: line contains two extra tokens, "allowed logging flags" and "default logging flags". Make sure that all flags on O: lines correspond exactly to either usermode flags or userlogging flags. Create a new validation mechanism in the code so that usermode and userlogging flags can be tested in a uniform, easy way. As this item becomes higher-priority it may be split out into separate tasks. A "likely fork" item, though patches will be provided back to the hybrid team. This description will need to be rewritten for capabilities and noservices. -- asuffield REGNICKCHAR. Users not yet identified on a registered nick will have their nicks prefaced with "~". This character will only be seen by users with a new mode character turned on. The mode character will not be on by default. All masks which include the nick will act as if the mode character is turned on. All "simple nick" constructions" will ignore it. Users with the mode character on will see a nick rename when the user identifies. This might be facilitated by adding a umode for "unregistered" which services would set, much like +e works for identified users. -- asuffield I originally intended this idea to be used until noservices could be implemented. Since noservices has been brought up the priority list and will be in the next release, this is no longer necessary - more graceful solutions are possible. -- asuffield ACTIVEBAN. Unless a particular channel mode is set, the behavior of a ban (MODE +b) has changed. In the new behavior, the user is parted with an explanatory message. The channel mode to restore the original behavior is optional and will probably be deprecated eventually. Obsoleted by noservices (which implies this behaviour, bans are/will be static) -- asuffield ENHCHMODE. A user mode for O-line users will be provided which will allow them to provide enhanced features such as PERMCHAN. The emphasis is on controlling access to features whose use of resources may potentially lend themselves to denial attacks. Right now all these features are classified under TWHEELS -- asuffield This should be fundamentally implied by the user capabilities system (when it's finished) -- asuffield EDCHMODE. A user mode for O-line users will be provided which will allow them to set channel LISTGROUPS and CHANSUMMARY. These are network-wide features designed to provide uncluttered information about on-topic channels on the network. The only other way to set these values is via a server hack, normally done through services, and not provided directly to channel owners. Rather than doing it via services, add a new command for it. Having services additionally store this data is secondary (see: NOSERVICES). -- asuffield Obsoleted for the same reasons as ENHCHMODE -- asuffield BANSTAY_LMT. Add a channel mode which sets a time interval after ban at which any remaining users will be parted. The time interval defaults to zero. Depends on NEUTRALKICK. ACTIVEBAN probably precludes this. -- asuffield Complete ~~~~~~~~ SILENCE+ Implement silence command, accepting hostmasks. Appears complete and unsilences appear to propagate and work fine. HUNT_AUDIT+ Start looking at which commands will run remotely for non-O-line users. Remove this capability wherever possible, carefully examining the ramifications. MOTD is the initial example. The call to hunt_server() implements this magic. NO_REG_BLK+ A user mode which prevents messages from users who are not registered and identified. FWDBAN_PROP+ The forwarding part of a forwarding ban does not propagate from server to server, and needs to. It should also appear in a channel ban listing and in the mode change message when the ban is issued. FORWARD_MSG+ A new numeric should be selected and for each channel forward that occurs between the time that a user issues a JOIN and the final, different channel is joined, a message with that numeric should be sent to the client which specifies both the old and the new channel name. FORWARD_LIM+ Rather than having separate limits, ban forwarding and invite forwarding should use a single total limit. Conceptually they are both different ways to implement a single feature, channel forwarding. MAP_COMMAND+ MAP command. Includes a list of unconnected servers at the end. MAPINDENT+ The MAP command did not indent properly. All of the server connection lines appeared flat, making hubbing difficult to recognize in a hurried emergency situation. O_FLAG_SPEC+ Replacement of the current flag specification mechanism for the O: line. The new mechanism will not use the difference between upper and lower case semantically. It replaces a single flag field with two fields: "allowed flags" and "default flags". Any flags not allowed and not available to normal users are denied. Of the allowed flags, only the ones in the "default flags" field will be set automatically when the user becomes +o. INVITE_FWD+ Invite channel forwarding. If specified, users who would otherwise receive a message indicating that the channel was invite-only, will instead be joined to the specified channel. They will appear to have joined the channel they were forwarded to, not the one they intended to join. THIS FEATURE DOES NOT YET SEEM TO FUNCTION. PLEASE FIX. Effects on diverse clients are still unknown, please test. BAN_FORWARD+ Ban channel forwarding. The ability to preface a ban with a #channel, so that users who match this ban will be joined to the specified channel instead of being given a message indicating they are banned. Functions similarly to INVITEFWD above. Effects on diverse clients are still unknown, please test. PREVENTMODE+ For all user modes except for +i and +w, the user should not be able to set these user modes unless OPERed, each of these modes must be revoked, but with a single informative message explaining that the mode letters are no longer allowed. *Not* one one message per mode. Someone please fix this patch so it gives the output of the error when a mode dosen't exist. QUITUSERTXT+ Make sure patch to prefix user quit messages is applied, so that you can always tell the difference between a user quit message and a server message. PARTUSERTXT+ Make sure patch to prefix user part messages is applied, so that you can always tell the difference between a user part message and a server message. QUIETCHMODE+ Add the opposite channel mode to +v, perhaps +q/Q, which quiets a nick!user@hostmask whether +m is in effect or not. This mode would not ban but would prevent nick changes. For various reasons, including the fact that bans when BANSTAYLMT may result in part after a time interval, this would be a good thing to have. Note that users should be checked against this list when they arrive on channel and a flag set accordingly, to provide for predictable CPU bandwidth in channel processing. Reality check this approach, bans are already essentially done this way. FORWARDMODE+ Channel forwarding through +b and +f requires a specific channel mode to be set. This mode cannot be set by channel owners. TWHEELS+ A user mode for O-line users will be provided which will allow them to provide experimental features such as FORWARDMODE. The emphasis is on limiting access to these features and working with channels which use them in order to gather information on their best and most effective use. Wider access may be provided later. SORTSERV+ Sort the servers by name as they are read in from configuration. This has the useful effect of making the "disconnected server" section of the MAP listing easier to read in a hurry. TIME_INVITE+ Time invites. A mechanism for adding a time limit to a +I invite. Two time limits are provided, a time-out value for the invitation itself which begins when the +I is added, and a time-out for the visit, which begins when the user enters the channel. Both counters are reset if they are ticking when another +I is issued for the user and host. There is not currently a timeout for the length of time a person can stay in a channel with +I, because I don't want to overcomplicate it and it's illogical anyway. INVITE takes an extra parameter of the length of time a person may stay in the channel, use this for temporary invitations. If it proves to be a problem, we can reconsider this approach. -- asuffield NOCTCP_MODE+ A user mode which prevents the user from either sending or receiving private CTCP (and hence DCC). State of the mode flag be changed by the user. MAP_ADDPING+ Ping times by each host on the MAP command. PERMCHAN+ The "+P" channel mode will no longer be settable by the user. It will indicate that this channel will not expire when all users leave it. Probably it will generate a "channel line" in each servers config file when set. Until NOSERVICES, it's expected that staff will set this flag via services; afterwards, via command. This will have to be reconsidered for noservices -- asuffield PERMBANCT+ For "+P" channels, a different, extremely large +b/+I max count. (32 for -P, 500 for +P?. Separate limit for +b and +I.) ...and it becomes a configurable number for noservices -- asuffield