X-Git-Url: http://git.silcnet.org/gitweb/?p=silc.git;a=blobdiff_plain;f=TODO;h=e6950f06db8f133972622b978e342ba7981d623d;hp=e1c30b328f58a8ef9a9a301eb2113f60a1b252a8;hb=HEAD;hpb=c257b555225193e54d85daf541d29578b3c93882 diff --git a/TODO b/TODO index e1c30b32..e6950f06 100644 --- a/TODO +++ b/TODO @@ -1,54 +1,207 @@ -TODO for SILC Client 1.0 branch -=============================== +TODO for 1.2 And Beyond +======================= - o Bugs reported on the mailing list that will be fixed eventually. - The numbers are arbitrary and assigned by me (c0ffee), bugs in - parentheses are fixed. +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. - (#1 Ignore ALL doesn't ignore target using /me) - #2 specification of the silc network - (#3 expired private key dialogue doesn't work) - #4 silc client allows setting non-utf8 topics - #5 SILC-client displaying wrong totals with /names +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. -TODO for SILC Server 1.0 -======================== +lib/silccore +============ + + 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. + + 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 BUG: silc_idlist_del_client had been called but sock->user_data remained - and pointed to invalid pointer. Where it was called is not known. + 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 Basic UTF-8 stringprep profile that makes sure UTF-8 strings are - as defined in spec-08 section 3.13. + 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 Server sometimes connects more than once to router and keeps - connecting even though connection exists. + o Message ACKing support. - o Testing + 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 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. -TODO/bugs In SILC Libraries + o Ability to recover from rekey errors, at least try to. + + 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 Test cases for all payload encoding and decoding routins in lib/silccore/ + 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. - o Test cases for math library routines in lib/silcmath/ + Some issues that must be kept in mind from 1.0 and 1.1 silcd's: - o Implement new version of SFTP protocol (missing versions 4 and 5, we - have version 3). + 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. + 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). -TODO in Toolkit Documentation -============================= + 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. -Stuff that needs to be done in order to complete the Toolkit Reference -Manual (Do these to 0.9.x). + 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 "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 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.