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 Current protocol version is 1.0. However, it is far from being perfect,
106 and needs to include additional features. Following protocol TODO entries
107 describe new stuff to be added to protocol versions 1.x.
109 1. Re-define the Status Payload: it is now 16 bits, split it into two
110 8 bits fields. First field includes status types from 0 - 9 and
111 10 - n *if* it is not an list of errors. If it is list of errors then
112 the first field includes 1, 2 and/or 3, and the second field includes
113 the error status 10 - n. This way it is possible to send multiple
114 errors (list of errors) and we have a way to tell the receiver that
115 there will be other errors as well. The second field is used only
116 if there is list of errors. If normal status, or normal (single)
117 error status the second field is set to zero, and must be ignored.
118 Hence, the status works same way as now except for list of errors.
119 To be included in protocol version 1.1.
121 2. Define that WHOIS and IDENTIFY commands must send list of errors
122 if multiple Client ID (or Channel ID and Server ID for IDENTIFY) was
123 requested and was not found. Each unfound entry must cause an error
124 command reply to the sender. Also define that errors must be sent
125 *after* sending successfully found entries (this way receiver may
126 ignore them). To be included in protocol version 1.1.
128 4. Add "request parameters" or similar to the WHOIS command, which can
129 be used to request various parameters (something not returned by
130 standard WHOIS command) about clients (info that could be fetched
131 even from clients). Additional specification (or appendix) should
132 be done to define the payload and the parameters. It could be used
133 to make the WHOIS command support various search conditions as well.
134 This would be the way to extend the WHOIS command to support various
135 new features without always making the command incompatible to previous
136 version. To be included in protocol version 1.1.
138 17. Cell wide channel founder support, and permanent channels when
141 18. Describe the SSH public key, X509, OpenPGP and SPKI certificates
142 encoding format in SKE (from their respective definitions).
144 o Inviting and banning by public key should be made possible. To be
145 included in protocol version 1.2.
147 o UTF-8 support/requirement for nicknames & channel names. UTF-8 support
148 in terminals and OS's are so hazy that this matter is left for
149 consideration in next version of the protocol (1.2). For good UTF-8
150 reference and tutorial see: http://www.cl.cam.ac.uk/~mgk25/unicode.html.
151 What should CLI application do if it receives nickname that it cannot
152 display without messing up the terminal? If UTF-8 is mandatory in
153 SILC then SILC clients cannot be allowed to start on terminals that do
154 not support UTF-8 (which renders 98% of users unable to use CLI SILC
155 app without hacking their environment). See also site
156 http://gratrix.net/unicode/