updates.
[silc.git] / TODO
diff --git a/TODO b/TODO
index 8d3dc4d280f9f904eab2f958e9727bc5773404d1..c28ff5541253e9d478719850d3af4e3451479d51 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,9 +1,57 @@
-TODO/bugs In SILC Client Library
-================================
+TODO/bugs in Irssi SILC client
+==============================
+
+ o Giving KILL command crashes the client.
+
+ o Waiting the answer for accepting new key after the protocol has
+   timeout and then ansering Y will crash the client.
+
+ o Add PERL scripting support from Irssi CVS.
 
  o Add local commands to list the current server and client public keys
    that the user has.  And a local command to dump the contents of the
-   public key to the screen.
+   public key to the screen.  Something like LISTKEYS, SHOWKEY...
+
+ o We should get rid of the clientconfig.[ch] in Irssi SILC and move the
+   cipher, hash, hmac and pkcs configuration to the Irssi SILC's config
+   file.
+
+ o Extend the /HELP command to support sub commands or something.  So
+   that user can say /help set mutual_authentication they would get
+   help of the mutual_authentication setting.
+
+ o Set different kind of settings, like, /set mutual_authentication,
+   /set key_exchange_timeout, /set conn_auth_timeout etc etc.
+
+ o Add KNOCKOUT local command.  It should kick an client from channel and
+   set a ban for it for number of seconds.
+
+ o Add KICKBAN local command.  Kicks and bans the specified client.
+
+ o Do some /set show_mail_notification that would show a notification
+   on screen when new email is received.
+
+
+TODO/bugs In SILC Client Library
+================================
+
+ o All protocol execution timeouts are hard coded. They should be 
+   configurable and the Irssi SILC client should be able to set them
+   with for example /set key_exchange_timeout etc.  The silc_client_alloc
+   should take a Params structure or something as argument.
+
+ o silc_client_close_connection leaks memory.  Read the XXX from code.
+
+ o Some of the ops->say's should be removed and moved to the application
+   from the library.  Go through these.
+
+ o The client library must manage somehow when receiving client that has
+   same nickname, same server, same username but different Client ID than
+   what we have in the cache.  It is now assumed that they are different
+   client but it might not be.  It should at least number the clients
+   using the client->num so that they can be accessed from the user
+   interface separately or it could just remove the old client unless
+   it is on some channels.
 
  o Add client library parameters or options that handle what kind of
    messages the library should print out (using `say' client operation,
@@ -12,13 +60,13 @@ TODO/bugs In SILC Client Library
    but all error printing should be handled by the library, etc...
    This is not a showstopper.
 
- o Input line on UI is buggy.  Cursor movement etc bugs.  Too lazy to
-   fix it.
-
 
 TODO/bugs In SILC Server
 ========================
 
+ o Seems that router does not announce its client to the connecting
+   server when server announces its clients on the channel.
+
  o When server quits and all clients of that server are removed from all
    channels the channel keys are re-generated for all clients.  This is
    a bug and should be done only once per channel after all clients of
@@ -37,12 +85,6 @@ TODO/bugs In SILC Server
    own resolver stuff (through scheduler, if possible without writing
    too much own stuff) or use threads.
 
- o The ID List must be optimized.  When the lists grow the searching
-   becomes a lot slower and is some cases the lists are searched many
-   times, like with channel messages (twice at least).  Some sort of
-   hash tables should replace the lists.  Thus, the ID cache should be
-   rewritten to use hash tables internally.
-
  o The backup router support described in the protocol specification
    should be done at some point.
 
@@ -69,17 +111,15 @@ TODO/bugs In SILC Server
 TODO/bugs In SILC Libraries
 ===========================
 
+ o The timeout calculation can go negative at least on BSD, so rewrite
+   in in lib/silcutil/silcschdule.c.
+
  o Incomplete IPv6 support:
 
        o All network routines in lib/silcutil/silcnet.[ch] does not
          support IPv6.
-
- o Hash tables must be implemented.  The requirement for this is that
-   the hash table is collision resistant so that it can be used in 
-   critical positions as well.  It probably works the 95% of the time
-   fine without collisions but the last 5% of the cases must be
-   handled.  Maybe two interfaces could be done, one for normal static
-   hash tables and one for collision resistant hash table.
+       o silc_id_render supports only IPv4 based ID's in the file
+         lib/silcutil/silcutil.c.
 
  o Compression routines are missing.  The protocol supports packet
    compression thus it must be implemented.  SILC Comp API must be
@@ -90,6 +130,34 @@ TODO/bugs In SILC Libraries
  o The CAST cipher is not compiled currently due to compilation errors;
    check those.  Cast is in lib/silccrypt/cast.c.
 
+ o All payload parsing (decoding) functions should take unsigned char *
+   and uint32 as data and data length as arguments.  Now some of the
+   routines do already that but most of the routines use SilcBuffer.
+   The SilcBuffer ones should be removed since buf->data and buf->len
+   is more convenient to use.  However, the silc_buffer_[un]format
+   routines support only SilcBuffer so they would require reallocation
+   of SilcBuffer.  Maybe support for raw data (and not just SilcBuffer)
+   should be added silc_buffer_[un]format_? routines.  These are currently
+   only cosmetic changes but at some point must be done to make the
+   payload interfaces consistent.
+
+ o Add builtin SOCKS and HTTP Proxy support, well the SOCKS at least.
+   SILC currently supports SOCKS4 and SOCKS5 but it needs to be compiled
+   in separately.
+
+
+TODO In SILC Protocol
+=====================
+
+ o pp-03 draft:
+
+       o Add SILC_MESSAGE_FLAG_SIGNED flag that indicates that the
+         messages is signed with the senders private key and thus can
+         be verified with its public key.  This is especially handy
+         feature when sending privat messages without having negotiated
+         private keys, thus the servers decrypts and re-ecnrypts the
+         messages.  Other applications exists as well.
+
 
 TODO After 1.0
 ==============