TODO/bugs in Irssi SILC client
==============================
- o Do not let irssi update the status bar on JOIN until the join command
- is successful, so that it does not update that I'm on the channel
- even though I could not join the channel.
+ 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 The CMODE notify handling in client library may return NULL
- client entry pointer to the application (when server was the CMODE's
- executor). Fix this somehow.
+ o The QUIT command should wait for servers disconnection (at least for
+ a while) before exiting the application.
- o Add PERL scripting support from Irssi CVS.
+ o Add local command to switch the channel's private key when channel has
+ several private keys. Currently sending channel messages with many
+ keys is not possible because changing the key is not possible by the
+ user.
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. 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 Add PERL scripting support from Irssi CVS.
o Extend the /HELP command to support sub commands or something. So
that user can say /help set mutual_authentication they would get
TODO/bugs In SILC Client Library
================================
- o Library should save the cumode and not start from 0 everytime then
- CUMODE is issued. A mechanism of getting the channel entry for
- CMODE and CUMODE by the command reply identifier must be added.
- Otherwise saving the modes for the channels and channel user
- entries are impossible since server does not send Channel ID as
- command reply in these commands.
-
- 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 The public key authentication is missing for example in OPER and SILCOPER
+ commands. See the XXX's in the lib/silcclient/command.c.
o The client library must manage somehow when receiving client that has
same nickname, same server, same username but different Client ID than
o silcd/serverid.c and its routines supports only IPv4.
- o DNS/IP lookup blocks the server. This must be fixed. Check the
- resolver stuff (resolver(3), resolver(5)). Either we have to do the
- own resolver stuff (through scheduler, if possible without writing
- too much own stuff) or use threads.
-
o The backup router support described in the protocol specification
should be done at some point.
TODO/bugs In SILC Libraries
===========================
+ o Move all utility stuff to undef lib/silcutil/. This includes trq,
+ dotconf and zlib.
+
o Incomplete IPv6 support:
o All network routines in lib/silcutil/silcnet.[ch] does not
in separately.
+TODO/Bugs in native WIN32 support (libraries)
+=============================================
+
+ o silc_net_create_connection_async does not work the same way than on
+ Unix. Do it with threads on WIN32.
+
+
TODO In SILC Protocol
=====================
TODO After 1.0
==============
- o Pthreads support. A lot of problems are solved with server (and with
- client as well) if we add pthread support. We can forget things such
- as non-blocking connecting etc, and we can do things such as DNS/IP
- lookups async. The server itself also benefits great deal from
- threads, especially from performance point of view.
-
- But, this is not a small task and almost entire SILC Library has to
- be made re-entrant. Own API is probably added for the threads support
- to make changes in the future as painless as possible. So the API
- would have things like silc_mutex_lock, silc_mutex_unlock and
- friends...
-
o X.509 certificate support. SILC protocol supports certificates and
it would be great to have support for them. This is a big task as
support has to be made for ASN.1 as well. I've looked into OpenSSL