TODO for Unreal Next:

Write in entries in this form:
==============================

* nick - date - priority - [ title ] Flag:
  description

Flags: 
   CLOSED 
     = Bug/Idea fixed/implemented. Bug/Idea is up for deletion
   OPEN 
     = Bug/Idea up for fixing
   IN-REPAIR <nick>
     = Bug/Idea In Progress/Repair by <nick>
   NO-PRODUCE
     = Bug/Idea is not able to be (re)produced
   POSTPONED
     = Bug/Idea is scheduled for another release/time

If you think that a priority should be higher, make it++

   Priority is 1..10, where 10 is highest, and 1 is lowest.
----
TODO :
----

* stskeeps - Tue Dec 12 2000 - 1 - [ IPv6 ] OPEN:
    Add IPv6 compatiblity (requested by many people). Must allow :'s in
    hostnames, will kill backwards compatiblity when IPv6 is enabled

* stskeeps - Tue Dec 12 2000 - 1 - [ Code ] OPEN:
    Split up code, and make the placement of functions more logic

* codemastr - Tue Dec 12 2000 - 4 - [ Zip_Links ] OPEN:
    Actually add this since it was planned for 3.0

* codemastr - Tue Dec 12 2000 - 5 - [ Dynconf Recode ] IN-REPAIR stskeeps:
    Dynconf has a bunch of bugs that can be resolved with a recode
    We are doing this with the newconf :) -stskeeps

* codemastr - Tue Dec 12 2000 - 8 - [ +I Fixes ]:
    +I still has some bugs that may cause desync and show users
    that the +I user is actually on the channel.

* stskeeps - Tue Dec 12 2000 - 1 - [ Bugfixes/Hash ] CLOSED stskeeps:
    Check for possible hash bug with del_from_client_table or something
    People still complain about crashes
    We might have fixed this with recent SERVER passwd fix and other passwd
    fixes


* stskeeps - Wed Dec 13 2000 - 10 - [ Bugfixes ] NO-PRODUCE:
[[r00t3d](~lok70@168.213.226.rox-62220)] The other one, is lets say you are on
          server (a), and you set +p to your channel. All the users on Server
          (b,c, etc..) when they do a /list can see the +p channel in the
          list. Now if I set it wih chanserv ie.. mlock +ntp, it doesn't do
          that.. ON all servers (a,b,c) no one sees the +p channel in /list
          unless they are in the channel allready. 
    Solution: Fix send_list to use PubChannel instead of SecretChannel
	(Unable to reproduce. +p channels are hidden on all servers -- codemastr)


* stskeeps - Wed Dec 13 2000 - 10 - [ Bugfixes ]:
[[r00t3d](~lok70@168.213.226.rox-62220)] If you are set +I (Tech
          Admin/Network Admin) and you are set +q/+a in a channel. When someone /whoises
          you hey see the channel names: *#channel ^#channel.
  Fix /whois ShowChannel code

* stskeeps - Wed Dec 13 2000 - 5 - [ Bugfixes ]:
[RexHsu(~webmin@202.109.72.rox-42822)] #TVB  H root@61.151.53.User-42432
          :0 none
[RexHsu(~webmin@202.109.72.rox-42822)] #TVB  H@
          ~webmin@202.109.72.User-42822 :0 none
[RexHsu(~webmin@202.109.72.rox-42822)] * End of /WHO list.
     Chinese nicks "clash", this is not the right nicks i typed in

* stskeeps - Wed Dec 13 2000 - 5 - [ Bugfixes ]:
[eYe-Man(none@of.your.fucking.business)] <eYe-Man> Can you show me how you
got
          OP?
[eYe-Man(none@of.your.fucking.business)] <Sexy_20> me i dont know how!!!!!
          even i dont see where i got OP
[eYe-Man(none@of.your.fucking.business)] <Sexy_20> or when some server gave
me
     SJOIN gives people ops? :P

* stskeeps - Thu Dec 14 2000 - 10 - [ Bugfixes ]
InTe[_:#roxnet> -oxygen.phrozen.org- *** Global -- from Irc.LinuxFreakz.Net:
                 No response from dumper.roxnet.org[130.240.202.121], closing
                 link
             Users can see that using +g ???
          FIXED: Sat Dec 30 2000 by stskeeps

* stskeeps - Fri Dec 14 2000 - 1 - [ SSL ]
	Challenge/Response kind of thing.
            
	/CHALLENGE nick keyname/commonidentifier type :b64text
	  type = 0, challenge type = 1, response
         Must be flood controlled in some way
         Can only work between servers and or U:lines and or 
           +z users

	Example:
          > :Stskeeps CHALLENGE RaYmAn rayman.pem 0 :0D0FE5F6D46
          < :RaYmAn CHALLENGE Stskeeps rayman.pem 1 :D0F5F543433
        
	The way this works is, that the challenger got RaYmAn's public RSA key
        and he needs to authenticate that he is really talking to RaYmAn (the
        real one). He then sends a random string to RaYmAn, encrypted with 
        RaYmAn's public key. RaYmAn then decrypts it using his private key, and
        then re-encrypts the random stuff using his private key, and sends back
        to Stskeeps, Sts then checks with decrypting the crypted text using the public
        key, and if its OK, then considers him OK. 

        We can use this for NickServ authentication using RSA keys, 
        or server<->server authentication, or /oper authentication
        (no more stolen passwords, yipieeeeeeee)

        This is also easily possible to add, in IRCii, in BitchX, EPIC, 
        mIRC (DLLs), etc.
        
        This is also good for raising security/authenticating to another level.
        Users can check if they are talking to the right person, NickServ databases
        no longer needs to have passwords, just use RSA keys

* stskeeps - Sun 17 Dec 2000 - 1 - [ General ]
          
         P:ip:W:*:port
           UnrealHTTPD!
         Sat 30 Dec 2000 - stskeeps - *cough* listen::option http ;)

* codemastr - Wed 20 Dec 2000 - 3 - [ General ]
	
	Recode badwords to allow a different replace word for each word

* codemastr - Wed 20 Dec 2000 - 1 - [ Install ]
	
	Add make install

* codemastr - Wed 20 Dec 2000 - 9 - [ Bugfixes ]

	connect to a server, /oper, then run telnet and link a server. Close the telnet but do NOT
 	send a SQUIT, the server displays no notice to opers that the server split.
          Stskeeps> +j? but yes, there's a bug there

        FIXED Sat 30 Dec 2000 by Stskeeps

* stskeeps - Sat Dec 23 2000 - 10 - [ Bugfixes ]
         There's some kind of bug that shows people being on same channel
         twice. I got a feeling its to do with JOIN/SJOIN as its only remote.
          [ Stskeeps  ] [@ChanServ  ] [@Fresh-Prin] [ Fresh-Prin] [@Fresh-Prin] 
         Same person 

* codemastr - Tue Dec 26 2000 - 6 - [ Bugfixes ]
	(too lazy to type it out)
	http://sourceforge.net/bugs/?func=detailbug&bug_id=126645&group_id=1968
	That fix will work except it needs to be modified so it checks remote
	before denying because of not being oper
* stskeeps - Wed Dec 27 2000 - 5 - [Configuration]
        Add a SWHOIS option to oper {} block, suggested by Robertsog
* codemastr - Tue Dec 26 2000 - 6 - [ Bugfixes ]
	(too lazy to type it out)
	http://sourceforge.net/bugs/?func=detailbug&bug_id=126645&group_id=1968
	That fix will work except it needs to be modified so it checks remote
	before denying because of not being oper
* stskeeps  - Sun Dec 30 2000 - 10 - [ Bugfixes ]
       /whois shows what channels +S are in
* codemastr - Tue Jan 03 2001 - 1 - [ Idea ]
	Add /kill logging option suggested by Cerb
