$Id: TODO,v 1.95 2003/04/05 14:21:53 kreator Exp $

Today's MOTD
------------
A pessimist is a man who has been compelled to live with an optimist.
		-- Elbert Hubbard


Pending bugs:
-------------
*) forcenick
*) 20 nicknames problem
*) > I plan on just setting the nickflood level higher in config.h, but
   could there be a configurable option via a operserv set command?
   Also, are there docs on what each operserv set variable is? Some of them
   are obvious, and then again, some aren't...
*) [21:15] :: monolith: trace is showing a blank field for channels
   [21:15] :: monolith: when using -long
*) [23:18] :: monolith: hey buddy, i noticed that the OPERWALL/WALLOPS
   thing wasn't in your latest cvs
*) (12:20:45) :: monolith: about the logon news thing
   (12:20:50) :: monolith: will there ever be a way to do that via operserv?
   (12:21:01) :: monolith: editing the file is really a pain bcoz we don't
   wanna give out shell access to all the opers
*) (11:00:00) andrew: /msg chanserv halfop #channel nick does not work...it
   gives an error -ChanServ- Unknown command [halfop]
*) oper can't setup anything with other nicks
*) check dccprocess with similar bug as botprocess..
*) o_match - fix to add *! and similar stuff
*) set allowguardchannel 0 -> part all channels immediately
*) nickserv and chanserv have to be always enabled - fix this.
*) channel modes don't always get synced on restart
*) fix invalid gnote count
*) clear modes doesn't clear limit
*) check for OnAccessList() without master nick call - only when necessary
*) remember to transfer access list in DeleteLink()
*) seems it is possible that nickname stays ghosted more than necessary if
   nick QUITs
*) send all mlock modes on channel creation
*) OperServ does not completely support hybrid7 modes yet, (for example
   .channel command or SECURE)
*) sed helpfiles so that they have proper time values
   NOTE: this should be done via %v or %t.. something like it
*) stuff from tools/* like encryptconf, encryptdb and doencrypt still do
   not support MD5
*) add flag for keeping other people's channel/nick status when
   reconnecting - i find it annonying to look at forced synching


Features yet to come:
---------------------
*) (13:37:00) padde: Any chance there could be coded an option, that would
   allow to specify a range of ports to be used to DCC services?
   (13:37:00) padde: would be usefull if the services is behind firewall
*) (23:37:25) andrew: hello
   (23:37:47) andrew: i'm just wondering if hybserv can be configured to
   block nicks that contain explicit words?
*)PuNkSterQFeTus: Heres an idea
  PuNkSterQFeTus: Instead of just /kill chan
  PuNkSterQFeTus: how about adding /kline chan
*) hide nick options..
*) save auth users before restart/die with a small ts..
*) blackbook for all operserv commands. searcheable, add, remove, list.
*) adx wishlist:
  1)
  <adx> for example, to create a new operserv's command
  <adx> "RESTRICT"
  <adx> you pass the mask, for example *!*@you.are.a.bad.guy
  <adx> then you can set some restrictions
  <adx> for example
  <adx> -nonickreg
  <adx> -max 5 (connections)
  <adx> -nolink
  <adx> etc...
  2)
  <adx> the other thing is ChanServ's AKICK
  <adx> couldn't we do it like with operserv's gline
  <adx> that is, to implement an expiring akick?
  <adx> for example, you set an AKICK for 3 weeks
  3)
  put operserv glines in oper.db
*) force nick change - via plain old hacks
*) choose NOTICES/MESSAGES to communicate with services
*) rewrite documentation
   ----> work in progress (Hwy)
*) add SVSNICK, SWHOIS, etc. for other IRCDs
*) modularisation (_very_ unlikely to happen)
*) completely document API
   ----> work in progress (Janos)
*) localisation
*) misc stuff:
   private notes on channel and user records, available only to staff
   PGP/GPG keys per user
   multiple URL's, multiple email addresses (with limits)
   geek code
*) use btree&mmap (additionally use adns and glib)
*) improve block allocator
*) add cidr & ranged ip's
*) add tcpwrap capatibilities
*) ziplinks (perhaps use servlink?)
*) ideas by "John Binder" <jbinder@kgazd.bme.hu>:
   flood ctrl for services itself
   flood ctrl for channels: public flood, join-part flood, kick flood,
    deop flood, nick flood -> however, for some features it is obvious
    that chanserv/operserv will have to reside on channels, which I
    dislike (-kre)
   ----> work in progress (KrisDuv)
   ----> work in progress (ike)
*) implement modes flood trigger (and below)
*) add some features from http://www.appwatch.com/Linux/App/879/data.html
*) be compatibile with other ircds (!!)
   ----> work in progress (me)
*) umode +g ACCEPT list (BR's idea)
