X-Git-Url: http://git.silcnet.org/gitweb/?a=blobdiff_plain;f=TODO;h=5842ba8918598d1e7315168152c3eaa9d6827ea5;hb=805fddcf6431e784f9f77114782a90c9d12f9cbe;hp=fba20ff25a1c5cd48bcfbdf12fb392c0f6d81536;hpb=e1d9ce9886ca71287f2634784fb766fad31b7744;p=silc.git diff --git a/TODO b/TODO index fba20ff2..e6950f06 100644 --- a/TODO +++ b/TODO @@ -1,150 +1,207 @@ -TODO/bugs in Irssi SILC client -============================== +TODO for 1.2 And Beyond +======================= - o /cumode for unknown nick does not give any error message (Fix this to - 1.0). +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. +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/bugs In SILC Client Library -================================ - o The PRIVATE_MESSAGE_KEY packet is not handled (it is implemented - though). This should be added and perhaps new client operation - should be added to notify application that it was received and - set the key only if application wishes to set (accept the key) it - (Do this to 1.0). +lib/silccore +============ - o Remove conn->current_channel. + o SILC_PACKET_FLAG_ACK support. Implement ACK packet and packet payload + to silcpacket.c. - o Additions to do after protocol version 1.1: + o All payload encoding routines should take SilcStack as argument. - o Add support for list of errors in command replies. Protocol - TODO entry 1. + o Remove SilcCommandCb from silccommand.h. (***DONE) + o All payload test routines into lib/silccore/tests/. -TODO/bugs In SILC Server -======================== - o Configuration file additions (Do this to 0.8.x): +lib/silcclient, The Client Library +================================== - o Add incoming connection frequency, incoming connection frequency - for single IP address, key exchange frequency, key exchange - frequency for single IP. Add also frequency base. + 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 If server send CUMODE_CHANGE notify (like setting founder) to router - and router does not have founder on channel (founder is left or there's - no founder on channel at all), the router will accept the server's - founder mode change, even though it perhaps should not do that (Fix - this to 0.9). + o UDP SILC connection support to SILC server - o The router should check for validity of received notify packets from - routers (fix this to 0.9). Following NOTIFYs needs to be verified: + o Giving WHOIS for nick that doesn't exist should remove any same + named entries from the client cache. - o JOIN (check that joining is allowed) - o SIGNOFF (maybe should check that notifier owns the client) + o peer-to-peer private messages - o Backup router related issues (Fix this to 1.0): + o Private message key request notification to application. See XXX in + client_prvmsg.c. - o Channel user mode changes are notified unnecessarely when - switching to backup router on router crash. + 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 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 (Fix this to 1.0). + 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 Lots of statistics updating is missing around the server. + o Message ACKing support. - 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 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. + 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 1.0). + 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. -TODO in Toolkit Documentation -============================= + o Consider deprecating also the old config file format and use XML + istead. This should require SILC XML API implementation first. -Stuff that needs to be done in order to complete the Tooolkit Reference -Manual (Do these to 0.9 and 1.0). + o The configuration must support dynamic router and server connections. + The silcd must work without specifying any servers or routers to + connect to. - o ROBOdoc documenting missing from lib/silcutil/silcbuffer.h. + 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 ROBOdoc documenting missing from lib/silcutil/silcdlist.h. + o The configuration must support specifying the ciphers and hmacs and + their order so that user can specify which algorithms take preference. - o ROBOdoc documenting missing from lib/silcutil/silcfileutil.h. - o ROBOdoc documenting missing from lib/silccrypt/silchash.h. +lib/silcserver +============== - o ROBOdoc documenting missing from lib/silccrypt/silccipher.h. + 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 ROBOdoc documenting missing from lib/silccrypt/silcpkcs.h. + o Write the SILC Server library extensively using SILC FSM. - 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 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 Write "Platform Implementations" document to describe what platforms - Toolkit support, what has been implemented, what has not been, what - works differently etc. + 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. -TODO in SILC Protocol -===================== + o Library must support multiple threads and must be entirely thread safe. -Current protocol version is 1.0. However, it is far from being perfect, -and needs to include additional features. Following protocol TODO entries -describe new stuff to be added to protocol versions 1.x. + o Library must have support for SERVICE command. - 2. Define that WHOIS and IDENTIFY commands must send list of errors - if multiple Client ID (or Channel ID and Server ID for IDENTIFY) was - requested and was not found. Each unfound entry must cause an error - command reply to the sender. Also define that errors must be sent - *after* sending successfully found entries (this way receiver may - ignore them). To be included in protocol version 1.1. + o Both UDP and TCP support for incoming connecetions. Maintaining long + term UDP sessions. - 4. Add "request parameters" or similar to the WHOIS command, which can - be used to request various parameters (something not returned by - standard WHOIS command) about clients (info that could be fetched - even from clients). Additional specification (or appendix) should - be done to define the payload and the parameters. It could be used - to make the WHOIS command support various search conditions as well. - This would be the way to extend the WHOIS command to support various - new features without always making the command incompatible to previous - version. To be included in protocol version 1.1. + 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). - 17. Cell wide channel founder support, and permanent channels when - founder mode set. + 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. - 20. Services support? + o The following data must be in per-thread context: command context + freelist/pool, pending commands, random number generator. - 21. Subscription/IRC's notify kind support? + o Do inccoming packet processing in an own FSM thread in the + server-threads FSM. Same as in client library. - 22. Session detachment/resume? + 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. - 23. Message blocking via user modes (which could be expanded via - services, but basic blocking would be a feature)? + 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 Inviting and banning by public key should be made possible. To be - included in protocol version 1.2. + 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: + + 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). + + 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 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 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 UTF-8 support/requirement for nicknames & channel names. UTF-8 support - in terminals and OS's are so hazy that this matter is left for - consideration in next version of the protocol (1.2). For good UTF-8 - reference and tutorial see: http://www.cl.cam.ac.uk/~mgk25/unicode.html. - What should CLI application do if it receives nickname that it cannot - display without messing up the terminal? If UTF-8 is mandatory in - SILC then SILC clients cannot be allowed to start on terminals that do - not support UTF-8 (which renders 98% of users unable to use CLI SILC - app without hacking their environment). See also site - http://gratrix.net/unicode/ + 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.