Merge commit 'origin/silc.1.1.branch'
[silc.git] / TODO
diff --git a/TODO b/TODO
index 7ed56659ea7521b3930089779c6844db05725c20..e6950f06db8f133972622b978e342ba7981d623d 100644 (file)
--- a/TODO
+++ b/TODO
-TODO for Irssi SILC Client 1.0
-==============================
+TODO for 1.2 And Beyond
+=======================
 
- o Support to set arbitrary pulic key in CMODE.
+NOTE: Any item that doesn't have (***DONE) in it, isn't done yet.  The
+(***TESTING NEEDED) means that the item has been done but not yet properly
+tested.
 
- o INVITE/BAN by public key file.
+NOTE: A TODO entry does not mean that it is ever going to be done.  Some
+of the entries may be just ideas, good, bad or ugly.  If you want to work
+on some of the TODO entries simply let us know about it by dropping a note
+to silc-devel mailing list or appear on 'silc' channel on SILCNet.
 
- o Signed message payload handling on UI
 
- o bugs parsing nicknames with @ in NICK_CHANGE
+lib/silccore
+============
 
- o Testing - See test plan:
-     http://silcnet.org/docs/silc-client-1.0-test.pdf
-     http://silcnet.org/docs/silc-client-1.0-test.ps
+ o SILC_PACKET_FLAG_ACK support.  Implement ACK packet and packet payload
+   to silcpacket.c.
 
+ o All payload encoding routines should take SilcStack as argument.
 
-TODO for SILC Server 1.0
-========================
+ o Remove SilcCommandCb from silccommand.h. (***DONE)
+
+ o All payload test routines into lib/silccore/tests/.
+
+
+lib/silcclient, The Client Library
+==================================
+
+ o LIST command should take server name as argument, a server name whose
+   channels to list.  This way it is possible to list channels from
+   any server in internet, eg.  /LIST example.com.
+
+ o UDP SILC connection support to SILC server
+
+ o Giving WHOIS for nick that doesn't exist should remove any same
+   named entries from the client cache.
+
+ o peer-to-peer private messages
+
+ o Private message key request notification to application.  See XXX in
+   client_prvmsg.c.
+
+ o in JOIN notify handle resolving that timedout.  Currently the user is
+   never joined the channel if this happens.  What to do if message is
+   received from user that hasn't been resolved/joined?
+
+ o Connection option that attemps to connect to remot host with various
+   different mechanisms: UDP 706, TCP 706, TCP 80, TCP 443, UDP 7706 and
+   TCP 7706.  This is the so called hole punching mechanism.
+
+ o Message ACKing support.
 
- o 1.2 backup router support
+ o in /cmode and /cumode with +r, maybe the public key and private key
+   could be just some "string", which would then match to "string.pub" and
+   "string.prv".
 
- o Testing
+ o If the SILC Events (see below) are implemented, perhaps client library
+   should provide events so that application developer has a choice of
+   developing the SILC app with callbacks or with events.
 
+ o Ability to recover from rekey errors, at least try to.
 
-TODO/bugs In SILC Libraries
+ o Add the SilcStream (socket stream) from the SilcPacketStream and
+   SilcSocket from the socket stream to SilcClientConnection for easier
+   access to them for programmers.  Currently these have to be digged up
+   from the packet stream. (***DONE)
+
+
+SFTP Library, lib/silcsftp/
 ===========================
 
- o WIN32 silc_net_create_connection_async does not work the same way
-   than on Unix.  Do it with threads on WIN32.  The function works but
-   is not actually async currently (Fix this to 0.9.x).
+ o Read prefetch (read-ahead, reading ahead of time).  Maybe if this can
+   be done easily.
+
+
+lib/silcske/silcske.[ch]
+========================
+
+ o Ratelimit to UDP/IP transport for incoming packets.
+
+
+apps/silcd
+==========
+
+ o Deprecate the old server.  Write interface for the new lib/silcserver
+   server library.  The interface should work on Unix/Linux systems.
+
+ o Consider deprecating also the old config file format and use XML
+   istead.  This should require SILC XML API implementation first.
+
+ o The configuration must support dynamic router and server connections.
+   The silcd must work without specifying any servers or routers to
+   connect to.
+
+ o The configuration must support specifying whether the server is
+   SILC Server or SILC Router.  This should not be deduced from the
+   configuration as it was in < 1.2.
+
+ o The configuration must support specifying the ciphers and hmacs and
+   their order so that user can specify which algorithms take preference.
+
+
+lib/silcserver
+==============
+
+ o Rewrite the entire server.  Deprecate apps/silcd as the main server
+   implementation and create lib/silcserver/.  It is a platform
+   independent server library.  The apps/silcd will merely provide a
+   a simple interface for the library.
+
+ o Write the SILC Server library extensively using SILC FSM.
+
+ o Server library must support multiple networks.  This means that one
+   server must be able to create multiple connections that each reach
+   different SILC network.  This means also that all cache's etc. must
+   be either connection-specific or network-specific.
+
+ o Library must support dynamic router and server connections.  This means
+   that connections are create only when they are needed, like when someone
+   says JOIN foo@foo.bar.com or WHOIS foobar@silcnet.org.
+
+ o Library must support server-to-server connections even though protocol
+   prohibits that.  The responder of the connection should automatically
+   act as a router.  The two servers create an own, isolated, SILC network.
+   To be used specifically with dynamic connections.
+
+ o Library must support multiple threads and must be entirely thread safe.
+
+ o Library must have support for SERVICE command.
+
+ o Both UDP and TCP support for incoming connecetions.  Maintaining long
+   term UDP sessions.
+
+ o The server must be able to run behind NAT device.  This means that
+   Server ID must be based on public IP instead of private IP (See
+   also NAT detection protocol in SILC protocol specification).
+
+ o The following data must be in per-connection context: client id cache,
+   server id cache, channel id cache, all statistics must be
+   per-connection.
+
+ o The following data must be in per-thread context: command context
+   freelist/pool, pending commands, random number generator.
+
+ o Do inccoming packet processing in an own FSM thread in the
+   server-threads FSM.  Same as in client library.
+
+ o Binding to other ports than 706 too.  To allow easier traversing
+   through NATs and firewalls server should also bind to 80, 443 and 7706
+   by default (at least try to bind).  Connections must work normally
+   even if they were established to some other port other than 706.
+
+   Connection option that attemps to connect to remot server with various
+   different mechanisms: UDP 706, TCP 706, TCP 80, TCP 443, UDP 7706 and
+   TCP 7706.  This is the so called hole punching mechanism.
+
+ o Ability to recover from rekey errors, at least try to.
+
+ o Reference count all Silc*Entry structures.
+
+ o All channel names in any command (where appropriate) must be allowed to
+   be in format channel@server so that the server can be connected to do
+   the command for the channel.  Change protocol if it doesn't allow it.
+
+ o All nicknames in any command (where appropriate) must be allowed to be
+   in format nick@server so that the server can be connected to do the
+   command for the nickname.  Change protocol if it doesn't allow it.
 
+ Some issues that must be kept in mind from 1.0 and 1.1 silcd's:
 
-TODO in Toolkit Documentation
-=============================
+ o The server and router software MUST work out of the box.  After
+   installation the server must not require any configuration to run the
+   most basic working configuration.  No defining IP addresses, etc.
+   The server must work just by running it.
 
-Stuff that needs to be done in order to complete the Tooolkit Reference
-Manual (Do these to 0.9.x).
+ o The SERVER_SIGNOFF notify handing is not optimal, because it'll
+   cause sending of multiple SIGNOFF notify's instead of the one
+   SERVER_SIGNOFF notify that the server received.  This should be
+   optimized so that the only SERVER_SIGNOFF is sent and not
+   SIGNOFF of notify at all (using SIGNOFF takes the idea about
+   SERVER_SIGNOFF away entirely).
 
- o Document the "notify" and "command_reply" client operations variable 
-   argument lists for all possible notify types and command replys.
+ o Another SERVER_SIGNOFF opt/bugfix:  Currently the signoff is
+   sent to a client if it is on same channel as the client that
+   signoffed.  However, the entire SERVER_SIGNOFF list is sent to
+   the client, ie. it may receive clients that was not on the
+   same channel.  This is actually against the specs.  It must be
+   done per channel.  It shouldn't receive the whole list just
+   because one client happened to be on same channel.
 
- o Write "Programming with Toolkit" document, describing how to build
-   Toolkit, how the build system works, where is everything, how
-   new (external) projects can be glued into Toolkit (use irssi as an
-   example), and how external projects can use Toolkit without gluing into
-   it (how to link etc), debugging, architecture, types, etc.
+ o If client's public key is saved in the server (and doing public key
+   authentication) then the hostname and the username information could
+   be taken from the public key.  Should be a configuration option!
 
- o Write "Platform Implementations" document to describe what platforms
-   Toolkit support, what has been implemented, what has not been, what
-   works differently etc.
+ o Add a timeout to handling incoming JOIN commands.  It should be
+   enforced that JOIN command is executed only once in a second or two
+   seconds.  Now it is possible to accept n incoming JOIN commands
+   and process them without any timeouts.  THis must be employed because
+   each JOIN command will create and distribute the new channel key
+   to everybody on the channel.
 
- o Searching of predefined keywords, exact and partial matches (would be 
-   nice).
+ o Related to above.  If multiple JOINs are received in sequence perhaps
+   new key should be created only once, if the JOINs are handeled at the same
+   time.  Now we create multiple keys and never end up using them because
+   many JOINs are processed at the same time in sequence.  Only the last
+   key ends up being used.