1 TODO/bugs in Irssi SILC client
2 ==============================
4 o /cumode for unknown nick does not give any error message (Fix this to
8 TODO/bugs In SILC Client Library
9 ================================
11 o The PRIVATE_MESSAGE_KEY packet is not handled (it is implemented
12 though). This should be added and perhaps new client operation
13 should be added to notify application that it was received and
14 set the key only if application wishes to set (accept the key) it
17 o Remove conn->current_channel.
19 o Additions to do after protocol version 1.1:
21 o Add support for list of errors in command replies. Protocol
25 TODO/bugs In SILC Server
26 ========================
28 o Configuration file additions (Do this to 0.8.x):
30 o Add incoming connection frequency, incoming connection frequency
31 for single IP address, key exchange frequency, key exchange
32 frequency for single IP. Add also frequency base.
34 o If server send CUMODE_CHANGE notify (like setting founder) to router
35 and router does not have founder on channel (founder is left or there's
36 no founder on channel at all), the router will accept the server's
37 founder mode change, even though it perhaps should not do that (Fix
40 o The router should check for validity of received notify packets from
41 routers (fix this to 0.9). Following NOTIFYs needs to be verified:
43 o JOIN (check that joining is allowed)
44 o SIGNOFF (maybe should check that notifier owns the client)
46 o Backup router related issues (Fix this to 1.0):
48 o Channel user mode changes are notified unnecessarely when
49 switching to backup router on router crash.
51 o Add a timeout to handling incoming JOIN commands. It should be
52 enforced that JOIN command is executed only once in a second or two
53 seconds. Now it is possible to accept n incoming JOIN commands
54 and process them without any timeouts. THis must be employed because
55 each JOIN command will create and distribute the new channel key
56 to everybody on the channel (Fix this to 1.0).
58 o Lots of statistics updating is missing around the server.
60 o If client's public key is saved in the server (and doing public key
61 authentication) then the hostname and the username information could
62 be taken from the public key. Should be a configuration option!
65 TODO/bugs In SILC Libraries
66 ===========================
68 o WIN32 silc_net_create_connection_async does not work the same way
69 than on Unix. Do it with threads on WIN32. The function works but
70 is not actually async currently (Fix this to 1.0).
73 TODO in Toolkit Documentation
74 =============================
76 Stuff that needs to be done in order to complete the Tooolkit Reference
77 Manual (Do these to 0.9 and 1.0).
79 o ROBOdoc documenting missing from lib/silcutil/silcbuffer.h.
81 o ROBOdoc documenting missing from lib/silcutil/silcdlist.h.
83 o ROBOdoc documenting missing from lib/silcutil/silcfileutil.h.
85 o ROBOdoc documenting missing from lib/silccrypt/silchash.h.
87 o ROBOdoc documenting missing from lib/silccrypt/silccipher.h.
89 o ROBOdoc documenting missing from lib/silccrypt/silcpkcs.h.
91 o Write "Programming with Toolkit" document, describing how to build
92 Toolkit, how the build system works, where is everything, how
93 new (external) projects can be glued into Toolkit (use irssi as an
94 example), and how external projects can use Toolkit without gluing into
95 it (how to link etc), debugging, architecture, types, etc.
97 o Write "Platform Implementations" document to describe what platforms
98 Toolkit support, what has been implemented, what has not been, what
99 works differently etc.
102 TODO in SILC Protocol
103 =====================
105 2. Define that WHOIS and IDENTIFY commands must send list of errors
106 if multiple Client ID (or Channel ID and Server ID for IDENTIFY) was
107 requested and was not found. Each unfound entry must cause an error
108 command reply to the sender. Also define that errors must be sent
109 *after* sending successfully found entries (this way receiver may
110 ignore them). To be included in protocol version 1.1.
112 4. Add "request parameters" or similar to the WHOIS command, which can
113 be used to request various parameters (something not returned by
114 standard WHOIS command) about clients (info that could be fetched
115 even from clients). Additional specification (or appendix) should
116 be done to define the payload and the parameters. It could be used
117 to make the WHOIS command support various search conditions as well.
118 This would be the way to extend the WHOIS command to support various
119 new features without always making the command incompatible to previous
120 version. To be included in protocol version 1.1.
122 17. Cell wide channel founder support, and permanent channels when
125 20. Services support?
127 21. Subscription/IRC's notify kind support?