1 TODO for 1.2 And Beyond
2 =======================
4 NOTE: Any item that doesn't have (***DONE) in it, isn't done yet. The
5 (***TESTING NEEDED) means that the item has been done but not yet properly
8 NOTE: A TODO entry does not mean that it is ever going to be done. Some
9 of the entries may be just ideas, good, bad or ugly. If you want to work
10 on some of the TODO entries simply let us know about it by dropping a note
11 to silc-devel mailing list or appear on 'silc' channel on SILCNet.
17 o SILC_PACKET_FLAG_ACK support. Implement ACK packet and packet payload
20 o All payload encoding routines should take SilcStack as argument.
22 o Remove SilcCommandCb from silccommand.h. (***DONE)
24 o All payload test routines into lib/silccore/tests/.
27 lib/silcclient, The Client Library
28 ==================================
30 o LIST command should take server name as argument, a server name whose
31 channels to list. This way it is possible to list channels from
32 any server in internet, eg. /LIST example.com.
34 o UDP SILC connection support to SILC server
36 o Giving WHOIS for nick that doesn't exist should remove any same
37 named entries from the client cache.
39 o peer-to-peer private messages
41 o Private message key request notification to application. See XXX in
44 o in JOIN notify handle resolving that timedout. Currently the user is
45 never joined the channel if this happens. What to do if message is
46 received from user that hasn't been resolved/joined?
48 o Connection option that attemps to connect to remot host with various
49 different mechanisms: UDP 706, TCP 706, TCP 80, TCP 443, UDP 7706 and
50 TCP 7706. This is the so called hole punching mechanism.
52 o Message ACKing support.
54 o in /cmode and /cumode with +r, maybe the public key and private key
55 could be just some "string", which would then match to "string.pub" and
58 o If the SILC Events (see below) are implemented, perhaps client library
59 should provide events so that application developer has a choice of
60 developing the SILC app with callbacks or with events.
62 o Ability to recover from rekey errors, at least try to.
64 o Add the SilcStream (socket stream) from the SilcPacketStream and
65 SilcSocket from the socket stream to SilcClientConnection for easier
66 access to them for programmers. Currently these have to be digged up
67 from the packet stream. (***DONE)
70 SFTP Library, lib/silcsftp/
71 ===========================
73 o Read prefetch (read-ahead, reading ahead of time). Maybe if this can
77 lib/silcske/silcske.[ch]
78 ========================
80 o Ratelimit to UDP/IP transport for incoming packets.
86 o Deprecate the old server. Write interface for the new lib/silcserver
87 server library. The interface should work on Unix/Linux systems.
89 o Consider deprecating also the old config file format and use XML
90 istead. This should require SILC XML API implementation first.
92 o The configuration must support dynamic router and server connections.
93 The silcd must work without specifying any servers or routers to
96 o The configuration must support specifying whether the server is
97 SILC Server or SILC Router. This should not be deduced from the
98 configuration as it was in < 1.2.
100 o The configuration must support specifying the ciphers and hmacs and
101 their order so that user can specify which algorithms take preference.
107 o Rewrite the entire server. Deprecate apps/silcd as the main server
108 implementation and create lib/silcserver/. It is a platform
109 independent server library. The apps/silcd will merely provide a
110 a simple interface for the library.
112 o Write the SILC Server library extensively using SILC FSM.
114 o Server library must support multiple networks. This means that one
115 server must be able to create multiple connections that each reach
116 different SILC network. This means also that all cache's etc. must
117 be either connection-specific or network-specific.
119 o Library must support dynamic router and server connections. This means
120 that connections are create only when they are needed, like when someone
121 says JOIN foo@foo.bar.com or WHOIS foobar@silcnet.org.
123 o Library must support server-to-server connections even though protocol
124 prohibits that. The responder of the connection should automatically
125 act as a router. The two servers create an own, isolated, SILC network.
126 To be used specifically with dynamic connections.
128 o Library must support multiple threads and must be entirely thread safe.
130 o Library must have support for SERVICE command.
132 o Both UDP and TCP support for incoming connecetions. Maintaining long
135 o The server must be able to run behind NAT device. This means that
136 Server ID must be based on public IP instead of private IP (See
137 also NAT detection protocol in SILC protocol specification).
139 o The following data must be in per-connection context: client id cache,
140 server id cache, channel id cache, all statistics must be
143 o The following data must be in per-thread context: command context
144 freelist/pool, pending commands, random number generator.
146 o Do inccoming packet processing in an own FSM thread in the
147 server-threads FSM. Same as in client library.
149 o Binding to other ports than 706 too. To allow easier traversing
150 through NATs and firewalls server should also bind to 80, 443 and 7706
151 by default (at least try to bind). Connections must work normally
152 even if they were established to some other port other than 706.
154 Connection option that attemps to connect to remot server with various
155 different mechanisms: UDP 706, TCP 706, TCP 80, TCP 443, UDP 7706 and
156 TCP 7706. This is the so called hole punching mechanism.
158 o Ability to recover from rekey errors, at least try to.
160 o Reference count all Silc*Entry structures.
162 o All channel names in any command (where appropriate) must be allowed to
163 be in format channel@server so that the server can be connected to do
164 the command for the channel. Change protocol if it doesn't allow it.
166 o All nicknames in any command (where appropriate) must be allowed to be
167 in format nick@server so that the server can be connected to do the
168 command for the nickname. Change protocol if it doesn't allow it.
170 Some issues that must be kept in mind from 1.0 and 1.1 silcd's:
172 o The server and router software MUST work out of the box. After
173 installation the server must not require any configuration to run the
174 most basic working configuration. No defining IP addresses, etc.
175 The server must work just by running it.
177 o The SERVER_SIGNOFF notify handing is not optimal, because it'll
178 cause sending of multiple SIGNOFF notify's instead of the one
179 SERVER_SIGNOFF notify that the server received. This should be
180 optimized so that the only SERVER_SIGNOFF is sent and not
181 SIGNOFF of notify at all (using SIGNOFF takes the idea about
182 SERVER_SIGNOFF away entirely).
184 o Another SERVER_SIGNOFF opt/bugfix: Currently the signoff is
185 sent to a client if it is on same channel as the client that
186 signoffed. However, the entire SERVER_SIGNOFF list is sent to
187 the client, ie. it may receive clients that was not on the
188 same channel. This is actually against the specs. It must be
189 done per channel. It shouldn't receive the whole list just
190 because one client happened to be on same channel.
192 o If client's public key is saved in the server (and doing public key
193 authentication) then the hostname and the username information could
194 be taken from the public key. Should be a configuration option!
196 o Add a timeout to handling incoming JOIN commands. It should be
197 enforced that JOIN command is executed only once in a second or two
198 seconds. Now it is possible to accept n incoming JOIN commands
199 and process them without any timeouts. THis must be employed because
200 each JOIN command will create and distribute the new channel key
201 to everybody on the channel.
203 o Related to above. If multiple JOINs are received in sequence perhaps
204 new key should be created only once, if the JOINs are handeled at the same
205 time. Now we create multiple keys and never end up using them because
206 many JOINs are processed at the same time in sequence. Only the last
207 key ends up being used.