* Browsing sometimes returns *two sets* of results.

* Configurable block/ban/discipline reasons.

* Block file handling/regexp is horribly CPU intensive, would a rewrite or
  optimization on regex.c be possible?  Looks like it's straight from
  GNU, perhaps just update, or a different implimentation.

* Flags should to be synched between servers in login.c. this is done with the
  friend and the muzzled flag, but not with the criminal flag (or is it useless
  to sync the criminal flag between the servers?)
  ( TT: The ON_CRIMINAL flag is to save the state of the user over the time, because
        if the user is kickbanned immediately there would be no chance to get a look
        onto the rest of his files and to justify the ban. If the ON_CRIMINAL flag 
        would be replicated to the other servers they would not know of any other
        restrictions (logintime e.g.) and would kickban the user immediately.
        Sure enough the ON_CRIMINAL should be handled like ON_MUZZLED when 
        the user logs off. This would cause the users file list to be logged 
        immediately on *any* server.
  )
  The flags should be checked in login.c and set to 0 if the user has a level
  > User because they are useless for mod+.
  ( TT: If a mod+ shares kiddyporn then I'm the first to rip his balls off - right after demoting him ;-)

* Now, to audit log_message_level calls and see what we need to re-
  categorize, there are bound to be a few.

* Impliment some sort of timer on clone checking, clone_grace_time might
  be a good var, so allow registration to pass before a server kills a
  clone which might very well be mod+

* If user specifies libsize or files for ejection, but not the other,
  there is no ejection.  We need if files = 0 use libsize, if libsize
  = 0 use files, etc logic.

* Possible protnet bug:  Server kept setting a user back to admin
  but ran with --disable-protnet

* eject_also_bans bans people on other servers, needs isuser(con)
  Or not?  Anyone else seen this?
  07/22/2002 TT: There are two places where eject_internal is called. 
  abuse.c (line 251) and login.c (line 161) do their checking
  of ISUSER(con) before calling eject_internal().
  Remember that eject_internal() does no checking by definition as 
  this would lead to some specialized behavior and would make it 
  unflexible i.e. noone would ever know if we do not eject foreign users
  for some reason in the future.
  02/08/2002 L: The kills tell that the ban is made. I propose to make
  a new flag to let the user choose if he wants the abuse bans local or
  network-wide. btw: we have a mailinglist for this kind of talk ;)

* Add a secondary, local-only ban list.
  02/08/2002 L: work in progress. new handlers/numerics to add/remove?

* Show memory usage in /ad stats.  Grab code from main.c:496
  or so and apply it to mem_used in server_usage.c:52
  Works fine, but teknap won't show >0 memory :(

* Brush up clone handling. There are two kinds of clones.
  Clones who want to draw ressources for their own advantage
  and clones who result from a ip connection sharing firewall.
  The first are easily detected be concerning their # of files
  shared. The second almost ever have different number of
  files and should not be ejected.
  Maybe the check should have some % range in which the 
  number of shared files may differ.

* New variable "eject_bans_ip". This should set the 
  tban issued by the server to "*!no.shares.from.thisip"
  instead to "user!*". In this way a user has to disconnect
  and to obtain a new address from his ISP when kicked from
  the server due to leeching. This variable should be configurable
  during runtime.

* New variable "eject_when_in_chat" to avoid setting
  people to "friend+" when some people just enter the 
  server for chatting. This might well be abused so 
  the server should check the occurance of chat messages
  from this client. Default value should be 0 to retain
  identical behaviour over the versions.
  This variable should be configurable during runtime.

* Fix IP/mask settings for dlines and such. Code is totally broken

* Rehashing invalid_nicks and invalid_clients will kill netwide users
  when initially it only rejects those users from logging on.
  FIXED:  But need to check

* Make remote searches obey filters ( don't they already? )

* Add serverside bzip2 compression.

* Send a configurable Privmsg on connect as a lot of people 
  are not reading ( or are unable to read ) the MOTD

* Send a configurable Privmsg on channel join to refer 
  to the charta of a channel

* A configurable entry of a webpage in config ( I think this 
  would not be neccessary when ppl use the MOTD )

* Automatic channel join on connect.

* On a second thought the replication mechanism in opennap 
  is suboptimal. Only updates and inserts are handled 
  more or less satisfactory.
  Deletes are only handled when all servers are connected.
  As soon as a server disconnects from the net it pollutes
  the userdb and banlist with new entries which were 
  deleted on the other servers previously.
  e.g. You delete a ban on a server which is not connected
  to the other network. As soon as this server reconnects
  this ban will be inserted in your banlist again.
  So this behavior enforces the implementation of "deletion flags".
  When implementing "deletion flags", then "version ids" and 
  "server ids" on records become mandatory also.
  Imagine that you've deleted a ban record from your server.
  But on another server this ban record is updated.
  So you have a replication conflict which is only solveable by
  having a version ID together with a server ID of this record.
  So two records with the same version number but different 
  original servers will indicate such an action.
  Still unsolved in this concept is the handling of *real* 
  replication conflicts. e.g. on server A a user is demoted 
  to leech and on server B a user is promoted to mod.
  
* When a MX-User gets a privmsg concerning his abuse then this user
  will probably not read it.
  MX has a default setting not to read privmsgs when they are not from:
   a) Users in the hotlist
   b) Users in the download queue
  As the hotlist is serverbased a possibility exists to send a 
  privmsg from a user in the hotlist of the user mentioned.

* Add caching of searches on the peer servers.
  This might help to build low budget hubs
  which need a lot less bandwidth.
  Currently a hub with 6 peers has roughly 
  900 Megs a day.

* Rework the caching from linked lists to hashes. CPU usage is quite too 
  high with lists.

* Rework some of the permissions. 
  * Shutdown server for LEVEL_ADMIN?
  * Announces for LEVEL_MOD

* Add account locking procedure for users >= LEVEL_MOD. If a 
  configurable count of wrong password attempts has been made
  the account is banned until another elite unbans it or the connection
  is made from 127.0.0.1 (added 05/31/2002: Or a certain period expires).

* add a timeout to check for blocked server connect() call

* desync between servers can happen if a +REGISTERED channel is created on a
  split server which contains no users on the other side of the split.
  currently the channel has to exist for the mode to be changed, so the
  +REGISTERED sent upon link will get dropped.  this is easy to fix as all
  you have to do is reset the REGISTERED bit on the server after it is
  relinked, but is there a better way to handle this case?

* fix memory leak with routing-only server

* throttle searches to lagging servers

* revise fast_snprintf()

* add MSG_SERVER_SYNC_END so that server's know when they are completely
  synced with each other, and can begin sending remote search requests

* still having cpu use problems with -DHAVE_POLL=1 !!!
