This document is a "living repository" of suggested changes to
srvx; it includes changes that have been made, changes that will be
made, and changes that have been suggested but which we do not plan to
implement. It also provides an explanation if we have rejected a
suggested change. (Version legend: green means implemented; yellow
means planned; magenta means not planned.)
| Change name/description | Version |
|---|
| Maximum visitors tracking | 1.0 |
| ChanServ now keeps track of the maximum number of people to be in the channel at one time ("visitors"). |
| Gags and Trusts have reasons and durations | 1.0 |
| Gags now have durations as well as reasons, and trusted hosts now have both. |
| !set setters | 1.1 |
Allows co-owners and owners to restrict !set use to master or above, co-owner or above, or owner only. |
| !togop | 1.1 |
New command: !togop; turns on or off ChanServ's auto-op (or auto-voice, for peons) and infoline broadcasting. |
| !suspend | 1.1 |
A master or above in a channel can !suspend <nick|*handle> (and !unsuspend <nick|*handle>) the access of a user ranked below them. |
| !csuspend/!cunsuspend | 1.1 |
| Global notices broadcast to staff when a channel is suspended or unsuspended. Channel suspension command renamed, made to take a duration (can be 0 for "forever") and a reason. |
| !adduser/!deluser | 1.1 |
New command: !adduser <level> <nick|*handle>. New command: !deluser <nick|*handle>, replacing previous !del<level> commands. |
| !giveownership | 1.1 |
New command: !giveownership <nick|*handle> gives ownership of the channel to the person you specify, and demotes you to co-owner. Can only be used by channel owner. |
| !register and !move create channels | 1.1 |
!register <#channel> and !move <#channel1> <#channel2> will now create channels; they do not need to exist already. They will refuse to create any channel on OpServ's "bad word" list or in the do-not-register list. |
| Automatic topic refresh | 1.1 |
If the channel owner may, using the !set topicrefresh option, tell ChanServ to automatically set a channel's topic to the default topic every 3, 6, 12 or 24 hours (synced to service's local time). |
| DNR channels | 1.1 |
ChanServ maintains a do-not-register (DNR) channel list (via the !noregister and !allowregister commands). Each DNR entry contains a channel name (or channel pattern or handle name) and a reason. Non-staff are unable to register DNR channels, and staff are only able to register them by passing a third "force" argument to !register. If the "force" argument is omitted, or the registrar is not staff, ChanServ tells the staff member it is a DNR channel (or handle). |
| ban and user trimming | 1.1 |
ChanServ keeps track of the last time a user was in a channel, and now the last time an addban was triggered. The command !trim <type> <duration> will remove users or bans older than the specified age -- for example, !trim users 1M will remove any users not seen in one month. |
| Per-channel notes | 1.1 |
ChanServ now tracks per-channel notes. Network admins (OpServ access >=800) may define a "note type," which includes who may set the note for a channel (network staff or channel setters -- set !set setters above), who may see it (network staff, channel users, or anyone), and the maximum length for the note. This allows channels to publicize information like their home page or what games/mods they play. |
| Channel CTCP reactions | 1.1 |
ChanServ can now, on a per-channel basis, react when people send non-ACTION CTCPs to the channel. (CTCP ACTION is the way that /me works, so it is excluded from this treatment.) The channel owner can allow anyone, no one, or only users with at least a certain level of access in the channel, to CTCP the channel. If a disallowed user does CTCP the channel, ChanServ will either kick, kickban, or timed ban the offending user (timed bans may be either short or long, with global configuration for those durations). See !set CTCPUsers and !set CTCPReaction. |
| !opchan more liberal | 1.1 |
!opchan can now be used by co-owners and owners in a channel, but only once each time a server links to the network. This gives them more power to correct network desyncs. |
| Customizable staff epithets | 1.1 |
Senior network staff (OpServ access >= 800 by default) can use NickServ's oset command to set epithets for staff. These are what are shown when doing !access on the user, and are still followed by one of (IRCOp), (network helper) or (support helper). |
| Additional helper level | 1.1 |
Helpers (privileged non-IRC-operator users) are now split into two classes: network helpers and support helpers. Network helpers may use the !god command as before; for support helpers, security override is turned on automatically when they join a named "support channel" (and turned off when they leave that channel). Handle flag +h indicates support helpers, and handle flag +H indicates network helpers. |
| Improved table output | 1.1 |
There is improved code to display table-like output, such as that in OpServ's command index. (The function table_send() replaces column_send().) |
| Email allowauth and password reset | 1.1 |
| NickServ can now track the user's email address (after it has been verified using a "cookie"). The user can then be authenticated or perform a password change using email-sent cookies. Several anti-abuse measures are implemented. |
| Auto-gag for password guessing | 1.1 |
| A user "guessing" passwords (getting many handle passwords incorrect in short span of time) is automatically gagged for 30 minutes. |
| /msg NickServ merge ... | 1.1 |
Network staff can /msg NickServ merge <nick|*handle1> <nick|*handle2>. This will "merge" handle1's channel access into handle2 and unregister handle1. It is staff-only to prevent abuse when a handle is stolen. |
| ?trace domains | 1.1 |
New ?trace action domains with optional parameter depth (default value 2). Will show counts of users in each domain up to depth components long that match the search. For example, ?trace domains depth 1 will show how many users are connected from each TLD. |
| Bad-word exceptions | 1.1 |
Specific channels may be exempted from the bad-word lists. For example, if "free" is an existing bad word, ?addbad free except #freebsd will add #freebsd as a not-bad channel. |
| Index connected users by hostname | 1.1 |
| List users connected from a given host, not just their count. This lets OpServ's excess-connection warning code send warnings to all users on a host, and speeds up some searches. |
| Nick-based alerts | 1.1 |
| srvx-1.0 checks alerts when the user connects, and not when they change nicks. If the criteria include nick, this allows people to evade the alert. srvx-1.1 will check alerts that include nick criteria when they change nicks. |
| Proper net.burst tracking | 1.1 |
| srvx now tracks netbursts in per-server state. This fixes several things; most notably, OpServ will not treat the burst as a new-user flood. ChanServ will also kick users riding a netsplit to evade a ban. |
| Wording clarifications | 1.1 |
| Various messages and warnings were unclear. These have been changed where we notice them (or were pointed to unclear text), but there are probably more left. One notable example is renaming "handle" to "account." Ongoing change. |
| Merge channels | 1.1 |
| Staff will be able to merge two channels together, much like handle merges work. Users in both will keep the greater access (and setinfo), the more recent seen time, etc. Bans in both will keep the longer duration, the more recent trigger time, etc., up to the maximum bans allowed. |
| Support/question queue service | 1.1 |
srvx now includes a support/question queue and time tracking bot (the HelpServ module). /msg OpServ helpserv help for an introduction to setting up and using it. |
| Multi-protocol support | 1.2, 2.0 |
The protocol used to talk to servers is configurable. In 1.2, it must be chosen when you run the configure script. In 2.0, it is set in srvx.conf. Currently supported protocols are P10 (for Undernet-derived ircds) and Bahamut (for the Bahamut ircd). Other protocols will be supported as demand and implementer time allows.
Part of this corrects a bug in the P10 support where srvx considered #{code} and #[code] to be different even though ircu considers them identical. Another part of this adds the ability for srvx to use the correct network time instead of its local machine time. |
| Simpler channel greetings | 1.2 |
Instead of three options (Greeting, Greet and GreetUsers) to control whether users see one greeting, there are two (Greeting and UserGreeting) to control whether users see two. This allows the greeting sent to people on the channel's userlist to be different from that sent to everyone else. |
| Channel suspensions preserved | 1.2 |
Suspensions for a channel are preserved until it is unregistered, and visible to network staff, channel co-owners and owner(s) by using the !info command. Other users will only see a suspension if the channel is currently suspended. The time the suspension was set (and when it was removed, if it was removed by hand) are also recorded. |
| "Ghost" kills | 1.2 |
There is a configurable option ("ghost_kills" in srvx.conf) that allows users to request a /KILL from NickServ for users who are authed to their account (using the ghost command). This allows you to disconnect a "ghost" that has not yet timed out. Note that this is very different from nick ownership, since it will only work on users who have authed to your account. |
| Account flags for community announcements | 1.2 |
A user may set an option on their accounts (/msg NickServ set announcements) that indicates whether they wish to receive community announcements from Global. The "announcements_default" option in srvx.conf gives the default for users who are not authed or who have not set the option (so it may be either opt-in or opt-out on a network-wide basis). The Global target announcement will send messages to those who have opted in or who have not opted out (depending on the network configuration). |
| Bad word exemptions are global | 1.2 |
Exemptions to the bad-word list now apply to all bad words rather than just one. For example, if "free" and "bs" are both in the bad-word list, "#freebsd" would have to have been listed as an exemption in both. In 1.2, it only has to be listed once. A new command (addexempt) has been added to replace the old (addbad ... except). |
| OpServ channel searching | 1.2 |
A new command (csearch) has been added to show channels which match certain criteria -- for example, a name or topic matching a certain mask, at least/at most/exactly N users, or with a timestamp at least/at most/exactly N seconds ago. |
| Pluggable service commands | 1.2 |
| It should be possible to authenticate with ChanServ instead of NickServ, or get handle information through ChanServ or OpServ, and so forth. Due to differences in the command dispatch mechanism, this requires a rewrite of the commands. |
| Improved aliasing | 1.2 |
Once "pluggable service commands" (above) is implemented, improved aliasing support should follow naturally. This will allow, for example, aliasing !addop User to !adduser op User or aliasing ?chankill #badguys You are all bad guys. to ?trace kill channel #badguys reason You are all bad guys.. (Currently, only the command names can be aliased; it is impossible to manipulate the argument list.) |
| Internationalization/Localization | 2.0 |
| The current services do not have one particularly good place that can be used to implement I18N or L10N (and implementing it in multiple places would be a fragile design). srvx-2.0 will provide that. |
| DCC/telnet support/IPC interface | 2.0 |
| The current event core makes it hard to have multiple connections at the same time. srvx-2.0 will have a better polling loop and a better internal structure for IPC-type operations (so that, for example, a web script can check passwords for users, or otherwise update the user's information). |
| Loadable modules | 2.0 |
| It should be possible to implement services (or commands, or IPC interfaces) as loadable modules (.so or .dll). |
| Automated spam kickbans | |
ChanServ might kick or ban users who advertise in a channel or who "spam" the same text quickly.
Why not implement?
Advertising is too hard to identify; even people argue over what constitutes advertising. Accurate spam detection takes more memory than we wish to spend -- upwards of 500 bytes per user/channel pair on the network; a large network might have 100,000 or more user/channel pairs at any time, so this would be at least 50 MB of memory for spam detection. |
| Bans by regular expression (regexp) | |
ChanServ could permit bans to be defined by regular expression.
Why not implement?
There are several reasons to not implement this feature. One is speed concerns; another is how it would interact with the ircd.
For speed concerns, it boils down to backtracking and pattern matching; some regexps can take a very long time to match against any string. Standard regexp libraries do not have any way to limit the search time spent on those. In contrast, the worst case for standard IRC masks is easy to detect and work around.
For ircd interaction concerns, there are significant problems when services want to ban in a way that the ircd does not natively support; the services must continually update the ircd ban list to match its idea of who can or cannot join. Since the ircd will not ban these users, it is still possible to join the channel with them (at least for a brief period of time). |
| Bans by account name | |
ChanServ could permit certain accounts to be banned from the channel, no matter what nickname, ident or hostname was used by people authenticated to that account.
Why not implement?
The same "ircd interaction" reasons from above (bans by regular expression) apply to this: since the ircd does not (and can not) enforce such bans, ChanServ would have to continually update them. In addition, this sort of ban is also very easy to evade; the banned user only has to connect to IRC again, but not authenticate with NickServ or AuthServ, and they can join the channel. |
