1 APPLICATION LAYER PROTOCOL FOR THE CITADEL SYSTEM
2 (c) 1995-2006 by Art Cancro et. al. All Rights Reserved
8 This is an attempt to document the application layer protocol used by the
9 Citadel system, beginning with version 4.00, which is the first version
10 to implement a client/server paradigm. It is intended as a resource for
11 programmers who intend to develop their own Citadel clients, but it may have
15 IMPORTANT NOTE TO DEVELOPERS!
16 -----------------------------
18 Anyone who wants to add commands or other functionality to this protocol,
19 *please* get in touch so that these efforts can be coordinated. New
20 commands added by other developers can be added to this document, so we
21 don't end up with new server commands from multiple developers which have
22 the same name but perform different functions. If you don't coordinate new
23 developments ahead of time, please at least send in an e-mail documenting
24 what you did, so that your new commands can be added to this document.
26 The coordinator of the Citadel project is Art Cancro
27 <ajc@uncensored.citadel.org>.
30 CONNECTING TO A SERVER
31 ----------------------
33 The protocols used below the application layer are beyond the scope of this
34 document, but we will briefly cover the methodology employed by Citadel.
36 Citadel offers its client protocol using TCP/IP. It does so via a
37 multithreaded server listening on a TCP port. Local connections may also
38 be made using the same protocol using Unix domain sockets.
40 The port number officially assigned to Citadel by the IANA is 504/tcp. Since
41 our application layer assumes a clean, reliable, sequenced connection, the use
42 of UDP would render the server unstable and unusable, so we stick with TCP.
48 The native character set for the Citadel system is UTF-8. Unless otherwise
49 specified, all data elements are expected to be in the UTF-8 character set.
50 Specifically, all non-MIME messages should be assumed to be in UTF-8. MIME
51 messages may be in whatever character set is specified by the MIME header, of
52 course; however, some clients (such as WebCit) will automatically convert
53 messages from other character sets before displaying them.
56 GENERAL INFORMATION ABOUT THE SERVER
57 ------------------------------------
59 The server is connection-oriented and stateful: each client requires its own
60 connection to a server process, and when a command is sent, the client must
61 read the response, and then transfer data or change modes if necessary.
63 The application layer is very much like other Internet protocols such as SMTP
64 or NNTP. A client program sends one-line commands to the server, and the
65 server responds with a three-digit numeric result code followed by a message
66 describing what happened. This cycle continues until the end of the
69 Unlike protocols such as FTP, all data transfers occur in-band. This means
70 that the same connection that is used for exchange of client/server
71 messages, will also be used to transfer data back and forth. (FTP opens a
72 separate connection for data transfers.) This keeps protocol administration
73 straightforward, as it can traverse firewalls without any special protocol
74 support on the firewall except for opening the port number.
80 The server will respond to all commands with a 3-digit result code, which
81 will be the first three characters on the line. The rest of the line may
82 contain a human-readable string explaining what happened. (Some client
83 software will display some of these strings to the user.)
85 The first digit is the most important. The following codes are defined for
86 this position: ERROR, OK, MORE_DATA, LISTING_FOLLOWS, and SEND_LISTING.
88 The second and third digits may provide a reason as to why a command
89 succeeded or failed. See ipcdef.h for the available codes.
91 ERROR means the command did not complete.
92 OK means the command executed successfully.
93 MORE_DATA means the command executed partially. Usually this means that
94 another command needs to be executed to complete the operation. For example,
95 sending the USER command to log in a user usually results in a MORE_DATA
96 result code, because the client needs to execute a PASS command to send the
97 password and complete the login.
98 LISTING_FOLLOWS means that after the server response, the server will
99 output a listing of some sort. The client *must* read the listing, whether
100 it wants to or not. The end of the listing is signified by the string
101 "000" on a line by itself.
102 SEND_LISTING is the opposite of LISTING_FOLLOWS. It means that the client
103 should begin sending a listing of some sort. The client *must* send something,
104 even if it is an empty listing. Again, the listing ends with "000" on a line
106 BINARY_FOLLOWS and SEND_BINARY mean that the client must immediately send
107 or receive a block of binary data. The first parameter will always be the
109 ASYNC_MESSAGE_FOLLOWS means that an asynchronous, or unsolicited, message
110 follows. The next line will be one of the above codes, and if a data transfer
111 is involved it must be handled immediately. Note that the client will not
112 receive this type of response unless it indicates to the server that it is
113 capable of handling them; see the writeup of the ASYN command later in this
119 Zero or more parameters may be passed to a command. When more than one
120 parameter is passed to a command, they should be separated by the "|"
123 In this example, we're using the "SETU" command and passing three
124 parameters: 80, 24, and 260.
126 When the server spits out data that has parameters, if more than one
127 parameter is returned, they will be separated by the "|" symbol like
130 In this example, we just executed the "GETU" command, and it returned us
131 an OK result code (the '2' in the 200) and three parameters: 80, 24, and
138 This is a listing of all the commands that a Citadel server can execute.
143 This command does nothing. It takes no arguments and always returns
144 OK. It is intended primarily for testing and development, but it might also
145 be used as a "keep alive" command to prevent the server from timing out, if
146 it's running over a transport that needs this type of thing.
149 ECHO (ECHO something)
151 This command also does nothing. It simply returns OK followed by whatever
157 Terminate the server connection. This command takes no arguments. It
158 returns OK and closes the connection immediately.
163 Log out the user without closing the server connection. It always returns
164 OK even if no user is logged in.
167 USER (send USER name)
169 The first step in logging in a user. This command takes one argument: the
170 name of the user to be logged in. If the user exists, a MORE_DATA return
171 code will be sent, which means the client should execute PASS as the next
172 command. If the user does not exist, ERROR + NO_SUCH_USER is returned.
177 The second step in logging in a user. This command takes one argument: the
178 password for the user we are attempting to log in. If the password doesn't
179 match the correct password for the user we specified for the USER command,
180 ERROR + PASSWORD_REQUIRED is returned. If a USER command has not been
181 executed yet, ERROR + USERNAME_REQUIRED is returned. If a user is already
182 logged in, ERROR + ALREADY_LOGGED_IN is returned. If the password is
183 correct, OK is returned and the user is now logged in... and most of the
184 other server commands can now be executed. Along with OK, the following
185 parameters are returned:
187 0 - The user's name (in case the client wants the right upper/lower casing)
188 1 - The user's current access level
191 4 - Various flags (see citadel.h)
193 6 - Time of last call (UNIX timestamp)
196 NEWU (create NEW User account)
198 This command creates a new user account AND LOGS IT IN. The argument to
199 this command will be the name of the account. No case conversion is done
200 on the name. Note that the new account is installed with a default
201 configuration, and no password, so the client should immediately prompt the
202 user for a password and install it with the SETP command as soon as this
203 command completes. This command returns OK if the account was created and
204 logged in, ERROR + ALREADY_EXISTS if another user already exists with this
205 name, ERROR + NOT_HERE if self-service account creation is disabled,
206 ERROR + MAX_SESSIONS_EXCEEDED if too many users are logged in, ERROR +
207 USERNAME_REQUIRED if a username was not provided, or ERROR + ILELGAL_VALUE
208 if the username provided is invalid. If OK, it will also return the same
209 parameters that PASS returns.
211 Please note that the NEWU command should only be used for self-service
212 user account creation. For administratively creating user accounts, please
213 use the CREU command.
216 SETP (SET new Password)
218 This command sets a new password for the currently logged in user. The
219 argument to this command will be the new password. The command always
220 returns OK, unless the client is not logged in, in which case it will return
221 ERROR + NOT_LOGGED_IN, or if the user is an auto-login user, in which case
222 it will return ERROR + NOT_HERE.
225 CREU (CREate new User account)
227 This command creates a new user account AND DOES NOT LOG IT IN. The first
228 argument to this command will be the name of the account. No case conversion
229 is done on the name. Note that the new account is installed with a default
230 configuration, and no password. The second argument is optional, and will be
231 an initial password for the user. This command returns OK if the account was
232 created, ERROR + HIGHER_ACCESS_REQUIRED if the user is not an Aide, ERROR +
233 USERNAME_REQUIRED if no username was specified, or ERROR + ALREADY_EXISTS if
234 another user already exists with this name.
236 Please note that CREU is intended to be used for activities in which a
237 system administrator is creating user accounts. For self-service user
238 account creation, use the NEWU command.
241 LKRN (List Known Rooms with New messages)
243 List known rooms with new messages. If the client is not logged in, ERROR +
244 NOT_LOGGED_IN is returned. Otherwise, LISTING_FOLLOWS is returned, followed
245 by the room listing. Each line in the listing contains the full name of a
246 room, followed by the '|' symbol, and then a number that may contain the
249 #define QR_PERMANENT 1 /* Room does not purge */
250 #define QR_PRIVATE 4 /* Set for any type of private room */
251 #define QR_PASSWORDED 8 /* Set if there's a password too */
252 #define QR_GUESSNAME 16 /* Set if it's a guessname room */
253 #define QR_DIRECTORY 32 /* Directory room */
254 #define QR_UPLOAD 64 /* Allowed to upload */
255 #define QR_DOWNLOAD 128 /* Allowed to download */
256 #define QR_VISDIR 256 /* Visible directory */
257 #define QR_ANONONLY 512 /* Anonymous-Only room */
258 #define QR_ANON2 1024 /* Anonymous-Option room */
259 #define QR_NETWORK 2048 /* Shared network room */
260 #define QR_PREFONLY 4096 /* Preferred status needed to enter */
261 #define QR_READONLY 8192 /* Aide status required to post */
263 Then it returns another '|' symbol, followed by a second set of bits comprised
266 #define QR2_SYSTEM 1 /* System room; hide by default */
267 #define QR2_SELFLIST 2 /* Self-service mailing list mgmt */
269 Other bits may be defined in the future. The listing terminates, as with
270 all listings, with "000" on a line by itself.
272 Starting with version 4.01 and above, floors are supported. The first
273 argument to LKRN should be the number of the floor to list rooms from. Only
274 rooms from this floor will be listed. If no arguments are passed to LKRN, or
275 if the floor number requested is (-1), rooms on all floors will be listed.
277 The third field displayed on each line is the number of the floor the room
278 is on. The LFLR command should be used to associate floor numbers with
281 The fourth field displayed on each line is a "room listing order." Unless
282 there is a compelling reason not to, clients should sort any received room
283 listings by this value.
285 The fifth field is a special bit bucket containing fields which pertain to
286 room access controls:
288 #define UA_KNOWN 2 /* Known room */
289 #define UA_GOTOALLOWED 4 /* Access will be granted to this room
290 * if the user calls it up by name */
291 #define UA_HASNEWMSGS 8 /* Unread messages exist in room */
292 #define UA_ZAPPED 16 /* Zapped from known rooms list */
294 The sixth field is the user's current view for the room. (See VIEW command)
295 The seventh field is the *default* view for the room. (See VIEW command)
296 The eigth field is a unix timestamp which reflects the last time the room
297 was modified (created, edited, posted in, deleted from, etc.)
300 LKRO (List Known Rooms with Old [no new] messages)
302 This follows the same usage and format as LKRN.
305 LZRM (List Zapped RooMs)
307 This follows the same usage and format as LKRN and LKRO.
310 LKRA (List All Known Rooms)
312 Same format. Lists all known rooms, with or without new messages.
315 LRMS (List all accessible RooMS)
317 Again, same format. This command lists all accessible rooms, known and
318 forgotten, with and without new messages. It does not, however, list
319 inaccessible private rooms.
322 LPRM (List all Public RooMs)
324 Again, same format. This command lists all public rooms, and nothing else.
325 Unlike the other list rooms commands, this one can be executed without logging
329 GETU (GET User configuration)
331 This command retrieves the screen dimensions and user options for the
332 currently logged in account. ERROR + NOT_LOGGED_IN will be returned if no
333 user is logged in, of course. Otherwise, OK will be returned, followed by
334 four parameters. The first parameter is the user's screen width, the second
335 parameter is the user's screen height, and the third parameter is a bag of
336 bits with the following meanings:
338 #define US_LASTOLD 16 /* Print last old message with new */
339 #define US_EXPERT 32 /* Experienced user */
340 #define US_UNLISTED 64 /* Unlisted userlog entry */
341 #define US_NOPROMPT 128 /* Don't prompt after each message */
342 #define US_DISAPPEAR 512 /* Use "disappearing msg prompts" */
343 #define US_PAGINATOR 2048 /* Pause after each screen of text */
345 There are other bits, too, but they can't be changed by the user (see below).
348 SETU (SET User configuration)
350 This command does the opposite of SETU: it takes the screen dimensions and
351 user options (which were probably obtained with a GETU command, and perhaps
352 modified by the user) and writes them to the user account. This command
353 should be passed three parameters: the screen width, the screen height, and
354 the option bits (see above). It returns ERROR + NOT_LOGGED_IN if no user is
355 logged in, and ERROR + ILLEGAL_VALUE if the parameters are incorrect.
357 Note that there exist bits here which are not listed in this document. Some
358 are flags that can only be set by Aides or the system administrator. SETU
359 will ignore attempts to toggle these bits. There also may be more user
360 settable bits added at a later date. To maintain later downward compatibility,
361 the following procedure is suggested:
363 1. Execute GETU to read the current flags
364 2. Toggle the bits that we know we can toggle
365 3. Execute SETU to write the flags
367 If we are passed a bit whose meaning we don't know, it's best to leave it
368 alone, and pass it right back to the server. That way we can use an old
369 client on a server that uses an unknown bit without accidentally clearing
370 it every time we set the user's configuration.
375 This command is used to goto a new room. When the user first logs in (login
376 is completed after execution of the PASS command) this command is
377 automatically and silently executed to take the user to the first room in the
378 system (usually called the Lobby).
380 This command can be passed one or two parameters. The first parameter is,
381 of course, the name of the room. Although it is not case sensitive, the
382 full name of the room must be used. Wildcard matching or unique string
383 matching of room names should be the responsibility of the client.
385 Note that the reserved room name "_BASEROOM_" can be passed to the server
386 to cause the goto command to take the user to the first room in the system,
387 traditionally known as the Lobby>. As long as a user is logged in, a
388 GOTO command to _BASEROOM_ is guaranteed to succeed. This is useful to
389 allow client software to return to the base room when it doesn't know
392 There are also several additional reserved room names:
393 "_MAIL_" goes to the user's inbox (i.e. the Mail> room).
394 "_TRASH_" goes to the user's personal trashcan room (trash folder).
395 "_BITBUCKET_" goes to a room that has been chosen for messages without a home.
396 "_CALENDAR_" goes to the user's primary personal calendar.
397 "_CONTACTS_" goes to the user's primary personal address book.
398 "_NOTES_" goes to the user's primary personal notes room.
399 "_TASKS_" goes to the user's primary personal task list.
402 The second (and optional) parameter is a password, if one is required for
403 access to the room. This allows for all types of rooms to be accessed via
404 this command: for public rooms, invitation-only rooms to which the user
405 has access, and preferred users only rooms to which the user has access, the
406 room will appear in a room listing. For guess-name rooms, this command
407 will work transparently, adding the room to the user's known room list when
408 it completes. For passworded rooms, access will be denied if the password
409 is not supplied or is incorrect, or the command will complete successfully
410 if the password is correct.
412 The third (and also) optional parameter is a "transient" flag. Normally,
413 when a user enters a private and/or zapped room, the room is added to the
414 user's known rooms list. If the transient flag is set to non-zero, this is
415 called a "transient goto" which causes the user to enter the room without
416 adding the room to the known rooms list.
418 The possible result codes are:
420 OK - The command completed successfully. User is now in the room.
421 (See the list of returned parameters below)
423 ERROR - The command did not complete successfully. Check the second and
424 third positions of the result code to find out what happened:
426 NOT_LOGGED_IN - Of course you can't go there. You didn't log in.
427 PASSWORD_REQUIRED - Either a password was not supplied, or the supplied
428 password was incorrect.
429 ROOM_NOT_FOUND - The requested room does not exist.
431 The typical procedure for entering a passworded room would be:
433 1. Execute a GOTO command without supplying any password.
434 2. ERROR + PASSWORD_REQUIRED will be returned. The client now knows that
435 the room is passworded, and prompts the user for a password.
436 3. Execute a GOTO command, supplying both the room name and the password.
437 4. If OK is returned, the command is complete. If, however,
438 ERROR + PASSWORD_REQUIRED is still returned, tell the user that the supplied
439 password was incorrect. The user remains in the room he/she was previously
442 When the command succeeds, these parameters are returned:
443 0. The name of the room
444 1. Number of unread messages in this room
445 2. Total number of messages in this room
446 3. Info flag: set to nonzero if the user needs to read this room's info
447 file (see RINF command below)
448 4. Various flags associated with this room. (See LKRN cmd above)
449 5. The highest message number present in this room
450 6. The highest message number the user has read in this room
451 7. Boolean flag: 1 if this is a Mail> room, 0 otherwise.
452 8. Aide flag: 1 if the user is either the Room Aide for this room, *or* is
453 a regular Aide (this makes access checks easy).
454 9. The number of new Mail messages the user has (useful for alerting the
455 user to the arrival of new mail during a session)
456 10. The floor number this room resides on
457 11. The *current* "view" for this room (see views.txt for more info)
458 12. The *default* "view" for this room
459 13. Boolian flag: 1 if this is the user's Trash folder, 0 otherwise.
461 The default view gives the client a hint as to what views the user should
462 be allowed to select. For example, it would be confusing to allow messages
463 in a room intended for calendar items. The server does not enforce these
464 restrictions, though.
467 MSGS (get pointers to MeSsaGeS in this room)
469 This command obtains a listing of all the messages in the current room
470 which the client may request. This command may be passed a single parameter:
471 either "all", "old", or "new" to request all messages, only old messages, or
472 new messages. Or it may be passed two parameters: "last" plus a number, in
473 which case that many message pointers will be returned; "first" plus a
474 number, for the corresponding effect; or "gt" plus a number, to list all
475 messages in the current room with a message number greater than the one
476 specified. If no parameters are specified, "all" is assumed.
478 The third argument, may be either 0 or 1. If it is 1, this command behaves
479 differently: before a listing is returned, the client must transmit a list
480 of fields to search for. The field headers are listed below in the writeup
481 for the "MSG0" command.
483 The optional fourth argument may also be either 0 or 1. If it is 1, the
484 output of this command will include not only a list of message numbers, but
485 a simple header summary of each message as well. This is somewhat resource
486 intensive so you shouldn't do this unless you absolutely need all the headers
487 immediately. The fields which are output (in the usual delimited fashion, of
488 course) are: message number, timestamp, display name, node name, Internet
489 email address (if present), subject (if present).
491 This command can return three possible results. ERROR + NOT_LOGGED_IN will
492 be returned if no user is currently logged in. Otherwise, LISTING_FOLLOWS
493 will be returned, and the listing will consist of zero or more message
494 numbers, one per line. The listing ends, as always, with the string "000"
495 alone on a line by itself. The listed message numbers can be used to request
496 messages from the system. If "search mode" is being used, the server will
497 return START_CHAT_MODE, and the client is expected to transmit the search
498 criteria, and then read the message list.
500 Since this is somewhat complex, here are some examples:
502 Example 1: Read all new messages
505 Server: 100 Message list...
511 Example 2: Read the last five messages
514 Server: 100 Message list...
522 Example 3: Read all messages written by "IGnatius T Foobar"
525 Server: 800 Send template then receive message list
526 Client: from|IGnatius T Foobar
540 Note that in "search mode" the client may specify any number of search
541 criteria. These criteria are applied with an AND logic.
544 MSG0 (read MeSsaGe, mode 0)
546 This is a command used to read the text of a message. "Mode 0" implies that
547 other MSG commands (MSG1, MSG2, etc.) will probably be added later on to read
548 messages in more robust formats. This command should be passed two arguments.
549 The first is the message number of the message being requested. The second
550 argument specifies whether the client wants headers and/or message body:
554 3 = Headers only, with MIME information suppressed (this runs faster)
556 If the request is denied, ERROR + NOT_LOGGED_IN or ERROR + MESSAGE_NOT_FOUND
557 will be returned. Otherwise, LISTING_FOLLOWS will be returned, followed by
558 the contents of the message. The following fields may be sent:
560 type= Formatting type. The currently defined types are:
561 0 = "traditional" Citadel formatting. This means that newlines should be
562 treated as spaces UNLESS the first character on the next line is a space. In
563 other words, only indented lines should generate a newline on the user's screen
564 when the message is being displayed. This allows a message to be formatted to
565 the reader's screen width. It also allows the use of proportional fonts.
566 1 = a simple fixed-format message. The message should be displayed to
567 the user's screen as is, preferably in a fixed-width font that will fit 80
569 4 = MIME format message. The message text is expected to contain a header
570 with the "Content-type:" directive (and possibly others).
572 msgn= The message ID of this message on the system it originated on.
573 path= An e-mailable path back to the user who wrote the message.
575 time= The date and time of the message, in Unix format (the number of
576 seconds since midnight on January 1, 1970, GMT).
578 from= The name of the author of the message.
579 rcpt= If the message is a private e-mail, this is the recipient.
580 room= The name of the room the message originated in.
581 node= The short node name of the system this message originated on.
582 hnod= The long node name of the system this message originated on.
583 zaps= The id/node of a message which this one zaps (supersedes).
585 part= Information about a MIME part embedded in this message.
586 pref= Information about a multipart MIME prefix such as "multipart/mixed"
587 or "multipart/alternative". This will be output immediately prior
588 to the various "part=" lines which make up the multipart section.
589 suff= Information about a multipart MIME suffix. This will be output
590 immediately following the various "part=" lines which make up the
593 text Note that there is no "=" after the word "text". This string
594 signifies that the message text begins on the next line.
597 WHOK (WHO Knows room)
599 This command is available only to Aides. ERROR + HIGHER_ACCESS_REQUIRED
600 will be returned if the user is not an Aide. Otherwise, it returns
601 LISTING_FOLLOWS and then lists, one user per line, every user who has
602 access to the current room.
605 INFO (get server INFO)
607 This command will *always* return LISTING_FOLLOWS and then print out a
608 listing of zero or more strings. Client software should be written to expect
609 anywhere from a null listing to an infinite number of lines, to allow later
610 backward compatibility. The current implementation defines the following
611 parts of the listing:
613 Line 0 - Your unique session ID on the server
614 Line 1 - The node name of the Citadel server
615 Line 2 - Human-readable node name of the Citadel server
616 Line 3 - The fully-qualified domain name (FQDN) of the server
617 Line 4 - The name of the server software, i.e. "Citadel 4.00"
618 Line 5 - (The revision level of the server code) * 100
619 Line 6 - The geographical location of the site (city and state if in the US)
620 Line 7 - The name of the system administrator
621 Line 8 - A number identifying the server type (see below)
622 Line 9 - The text of the system's paginator prompt
623 Line 10 - Floor Flag. 1 if the system supports floors, 0 otherwise.
624 Line 11 - Paging level. 0 if the system only supports inline paging,
625 1 if the system supports "extended" paging (check-only and
626 multiline modes). See the SEXP command for further information.
627 Line 12 - The "nonce" for this session, for support of APOP-style
628 authentication. If this field is present, clients may authenticate
630 Line 13 - Set to nonzero if this server supports the QNOP command.
631 Line 14 - Set to nonzero if this server is capable of connecting to a
632 directory service using LDAP.
633 Line 15 - Set to nonzero if this server does *not* allow self-service
634 creation of new user accounts.
635 Line 16 - The default timezone for calendar items which do not have any
636 timezone specified and are not flagged as UTC. This will be a
637 zone name from the Olsen database.
639 *** NOTE! *** The "server type" code is intended to promote global
640 compatibility in a scenario in which developers have added proprietary
641 features to their servers or clients. We are attempting to avoid a future
642 situation in which users need to keep different client software around for
643 each Citadel they use. *Please*, if you are a developer and plan to add
644 proprietary features:
646 -> Your client programs should still be able to utilize servers other than
648 -> Clients other than your own should still be able to utilize your server,
649 even if your proprietary extensions aren't supported.
650 -> Please contact Art Cancro <ajc@uncensored.citadel.org> and obtain a unique
651 server type code, which can be assigned to your server program.
652 -> If you document what you did in detail, perhaps it can be added to a
653 future release of the Citadel program, so everyone can enjoy it. Better
654 yet, just work with the Citadel development team on the main source tree.
656 If everyone follows this scheme, we can avoid a chaotic situation with lots
657 of confusion about which client program works with which server, etc. Client
658 software can simply check the server type (and perhaps the revision level)
659 to determine ahead of time what commands may be utilized.
661 Please refer to "developers.txt" for information on what codes belong to whom.
665 RDIR (Read room DIRectory)
667 Use this command to read the directory of a directory room. ERROR + NOT_HERE
668 will be returned if the room has no directory, ERROR + HIGHER_ACCESS_REQUIRED
669 will be returned if the room's directory is not visible and the user does not
670 have Aide or Room Aide privileges, ERROR + NOT_LOGGED_IN will be returned if
671 the user is not logged in; otherwise LISTING_FOLLOWS will be returned,
672 followed by the room's directory. Each line of the directory listing will
673 contain three fields: a filename, the length of the file, and a description.
675 The server message contained on the same line with LISTING_FOLLOWS will
676 contain the name of the system and the name of the directory, such as:
678 uncensored.citadel.org|/usr/local/citadel/files/my_room_directory
681 SLRP (Set Last-message-Read Pointer)
683 This command marks all messages in the current room as read (seen) up to and
684 including the specified number. Its sole parameter is the number of the last
685 message that has been read. This allows the pointer to be set at any
686 arbitrary point in the room. Optionally, the parameter "highest" may be used
687 instead of a message number, to set the pointer to the number of the highest
688 message in the room, effectively marking all messages in the room as having
689 been read (ala the Citadel <G>oto command).
691 The command will return OK if the pointer was set, or ERROR + NOT_LOGGED_IN
692 if the user is not logged in. If OK is returned, it will be followed by a
693 single argument containing the message number the last-read-pointer was set to.
696 INVT (INViTe a user to a room)
698 This command may only be executed by Aides, or by the room aide for the
699 current room. It is used primarily to add users to invitation-only rooms,
700 but it may also be used in other types of private rooms as well. Its sole
701 parameter is the name of the user to invite.
703 The command will return OK if the operation succeeded. ERROR + NO_SUCH_USER
704 will be returned if the user does not exist, ERROR + HIGHER_ACCESS_REQUIRED
705 will be returned if the operation would have been possible if the user had
706 higher access, and ERROR + NOT_HERE may be returned if the room is not a
710 KICK (KICK a user out of a room)
712 This is the opposite of INVT: it is used to kick a user out of a private
713 room. It can also be used to kick a user out of a public room, but the
714 effect will only be the same as if the user <Z>apped the room - a non-stupid
715 user can simply un-zap the room to get back in.
718 GETR (GET Room attributes)
720 This command is used for editing the various attributes associated with a
721 room. A typical "edit room" command would work like this:
722 1. Use the GETR command to get the current attributes
723 2. Change some of them around
724 3. Use SETR (see below) to save the changes
725 4. Possibly also change the room aide using the GETA and SETA commands
727 GETR takes no arguments. It will only return OK if the SETR command will
728 also return OK. This allows client software to tell the user that he/she
729 can't edit the room *before* going through the trouble of actually doing the
730 editing. Possible return codes are:
732 ERROR+NOT_LOGGED_IN - No user is logged in.
733 ERROR+HIGHER_ACCESS_REQUIRED - Not enough access. Typically, only aides
734 and the room aide associated with the current room, can access this command.
735 OK - Command succeeded. Parameters are returned.
737 If OK is returned, the following parameters will be returned as well:
739 0. The name of the room
740 1. The room's password (if it's a passworded room)
741 2. The name of the room's directory (if it's a directory room)
742 3. Various flags (bits) associated with the room (see LKRN cmd above)
743 4. The floor number on which the room resides
744 5. The room listing order
745 6. The default view for the room (see views.txt)
746 7. A second set of flags (bits) associated with the room
749 SETR (SET Room attributes)
751 This command sets various attributes associated with the current room. It
752 should be passed the following arguments:
754 0. The name of the room
755 1. The room's password (if it's a passworded room)
756 2. The name of the room's directory (if it's a directory room)
757 3. Various flags (bits) associated with the room (see LKRN cmd above)
758 4. "Bump" flag (see below)
759 5. The floor number on which the room should reside
760 6. The room listing order
761 7. The default view for the room (see views.txt)
762 8. A second set of flags (bits) associated with the room
764 *Important: You should always use GETR to retrieve the current attributes of
765 the room, then change what you want to change, and then use SETR to write it
766 all back. This is particularly important with respect to the flags: if a
767 particular bit is set, and you don't know what it means, LEAVE IT ALONE and
768 only toggle the bits you want to toggle. This will allow for upward
771 The _BASEROOM_, user's Mail> and Aide> rooms can only be partially edited.
772 Any changes which cannot be made will be silently ignored.
774 If the room is a private room, you have the option of causing all users who
775 currently have access, to forget the room. If you want to do this, set the
776 "bump" flag to 1, otherwise set it to 0.
781 This command is used to get the name of the Room Aide for the current room.
782 It will return ERROR + NOT_LOGGED_IN if no user is logged in, or OK if the
783 command succeeded. Along with OK there will be returned one parameter: the
784 name of the Room Aide. A conforming server must guarantee that the user is
790 The opposite of GETA, used to set the Room Aide for the current room. One
791 parameter should be passed, which is the name of the user who is to be the
792 new Room Aide. Under Citadel, this command may only be executed by Aides
793 and by the *current* Room Aide for the room. Return codes possible are:
794 ERROR + NOT_LOGGED_IN (Not logged in.)
795 ERROR + HIGHER_ACCESS_REQUIRED (Higher access required.)
796 ERROR + NOT_HERE (Room cannot be edited.)
797 OK (Command succeeded.)
800 ENT0 (ENTer message, mode 0)
802 This command is used to enter messages into the system. It accepts four
805 0 - Post flag. This should be set to 1 to post a message. If it is
806 set to 0, the server only returns OK or ERROR (plus any flags describing
807 the error) without reading in a message. Client software should, in fact,
808 perform this operation at the beginning of an "enter message" command
809 *before* starting up its editor, so the user does not end up typing a message
810 in vain that will not be permitted to be saved. If it is set to 2, the
811 server will accept an "apparent" post name if the user is privileged enough.
812 This post name is arg 5.
813 1 - Recipient (To: field). This argument is utilized only for private
814 mail. It is ignored for public messages. It contains, of course, the name
815 of the recipient(s) of the message.
816 2 - Anonymous flag. This argument is ignored unless the room allows
817 anonymous messages. In such rooms, this flag may be set to 1 to flag a
818 message as anonymous, otherwise 0 for a normal message.
819 3 - Format type. Any valid Citadel format type may be used (this will
820 typically be 0; see the MSG0 command above).
821 4 - Subject. If present, this argument will be used as the subject of
823 5 - Post name. When postflag is 2, this is the name you are posting as.
824 This is an Aide only command.
825 6 - Do Confirmation. NOTE: this changes the protocol semantics! When
826 you set this to nonzero, ENT0 will reply with a confirmation message after
827 you submit the message text. The reply code for the ENT0 command will be
828 START_CHAT_MODE instead of SEND_LISTING.
829 7 - Recipient (Cc: field). This argument is utilized only for private
830 mail. It is ignored for public messages. It contains, of course, the name
831 of the recipient(s) of the message.
832 8 - Recipient (Bcc: field). This argument is utilized only for private
833 mail. It is ignored for public messages. It contains, of course, the name
834 of the recipient(s) of the message.
835 9 - Exclusive message ID. When a message is submitted with an Exclusive
836 message ID, any existing messages with the same ID will automatically be
837 deleted. This is only applicable for Wiki rooms; other types of rooms either
838 ignore the supplied ID (such as message boards and mailboxes) or derive the
839 ID from a UUID native to the objects stored in them (such as calendars and
842 Possible result codes:
843 OK - The request is valid. (Client did not set the "post" flag, so the
844 server will not read in message text.) If the message is an e-mail with
845 a recipient, the text that follows the OK code will contain the exact name
846 to which mail is being sent. The client can display this to the user. The
847 implication here is that the name that the server returns will contain the
848 correct upper and lower case characters. In addition, if the recipient is
849 having his/her mail forwarded, the forwarding address will be returned.
850 SEND_LISTING - The request is valid. The client should now transmit
851 the text of the message (ending with a 000 on a line by itself, as usual).
852 START_CHAT_MODE - The request is valid. The client should now transmit
853 the text of the message, ending with a 000 on a line by itself. After
854 transmitting the 000 terminator, the client MUST read in the confirmation
855 from the server, which will also end with 000 on a line by itself. The format
856 of the confirmation appears below.
857 ERROR + NOT_LOGGED_IN - Not logged in.
858 ERROR + HIGHER_ACCESS_REQUIRED - Higher access is required. An
859 explanation follows, worded in a form that can be displayed to the user.
860 ERROR + NO_SUCH_USER - The specified recipient does not exist.
862 The format of the confirmation message, if requested, is as follows:
863 Line 1: The new message number on the server for the message. It will be
864 positive for a real message number, or negative to denote
865 that an error occurred. If an error occurred, the message was
867 Line 2: A human-readable confirmation or error message.
868 Line 3: The resulting Exclusive UID of the message, if present.
869 (More may be added to this in the future, so do not assume that there will
870 only be these lines output. Keep reading until 000 is received.)
873 RINF (read Room INFormation file)
875 Each room has associated with it a text file containing a description of
876 the room, perhaps containing its intended purpose or other important
877 information. The info file for the Lobby> (the system's base room) is
878 often used as a repository for system bulletins and the like.
880 This command, which accepts no arguments, is simply used to read the info
881 file for the current room. It will return LISTING_FOLLOWS followed by
882 the text of the message (always in format type 0) if the request can be
883 honored, or ERROR if no info file exists for the current room (which is
884 often the case). Other error description codes may accompany this result.
886 When should this command be used? This is, of course, up to the discretion
887 of client software authors, but in Citadel it is executed in two situations:
888 the first time the user ever enters a room; and whenever the contents of the
889 file change. The latter can be determined from the result of a GOTO command,
890 which will tell the client whether the file needs to be read (see GOTO above).
893 DELE (DELEte a message)
895 Delete one or more messages from the current room. The one argument that
896 should be passed to this command is a message number, or a list of message
897 numbers separated by commas, to be deleted.
899 The return value will be OK if one or more messages were deleted, or an ERROR
900 code. If the delete is successful, the messages' reference counts are
901 decremented, and if the reference count reaches zero, the messages are removed
902 from the message base.
905 MOVE (MOVE or copy a message to a different room)
907 Move or copy a message to a different room. This command expects to be
908 passed three arguments:
909 0: the message number(s) of the message to be moved or copied.
910 1: the name of the target room.
911 2: flag: 0 to move the message, 1 to copy it without deleting from the
914 This command never creates or deletes copies of a message; it merely moves
915 around links. When a message is moved, its reference count remains the same.
916 When a message is copied, its reference count is incremented.
918 You can move/copy multiple messages with a single command by separating the
919 message numbers with commas; for example: MOVE 112,113,114|Trash|0
922 KILL (KILL current room)
924 This command deletes the current room. It accepts a single argument, which
925 should be nonzero to actually delete the room, or zero to merely check
926 whether the room can be deleted.
928 Once the room is deleted, the current room is undefined. It is suggested
929 that client software immediately GOTO another room (usually _BASEROOM_)
930 after this command completes.
932 Possible return codes:
934 OK - room has been deleted (or, if checking only, request is valid).
935 ERROR+NOT_LOGGED_IN - no user is logged in.
936 ERROR+HIGHER_ACCESS_REQUIRED - not enough access to delete rooms.
937 ERROR+NOT_HERE - this room can not be deleted.
940 CRE8 (CRE[ate] a new room)
942 This command is used to create a new room. Like some of the other
943 commands, it provides a mechanism to first check to see if a room can be
944 created before actually executing the command. CRE8 accepts the following
947 0 - Create flag. Set this to 1 to actually create the room. If it is
948 set to 0, the server merely checks that there is a free slot in which to
949 create a new room, and that the user has enough access to create a room. It
950 returns OK if the client should go ahead and prompt the user for more info,
951 or ERROR or ERROR+HIGHER_ACCESS_REQUIRED if the command will not succeed.
952 1 - Name for new room.
953 2 - Access type for new room:
955 1 - Private; can be entered by guessing the room's name
956 2 - Private; can be entered by knowing the name *and* password
957 3 - Private; invitation only (sometimes called "exclusive")
958 4 - Personal (mailbox for this user only)
959 3 - Password for new room (if it is a type 2 room)
960 4 - Floor number on which the room should reside (optional)
961 5 - Set to 1 to avoid automatically gaining access to the created room.
962 6 - The default "view" for the room.
964 If the create flag is set to 1, the room is created (unless something
965 went wrong and an ERROR return is sent), and the server returns OK, but
966 the session is **not** automatically sent to that room. The client still
967 must perform a GOTO command to go to the new room.
970 FORG (FORGet the current room)
972 This command is used to forget (zap) the current room. For those not
973 familiar with Citadel, this terminology refers to removing the room from
974 a user's own known rooms list, *not* removing the room itself. After a
975 room is forgotten, it no longer shows up in the user's known room list,
976 but it will exist in the user's forgotten room list, and will return to the
977 known room list if the user goes to the room (in Citadel, this is
978 accomplished by explicitly typing the room's name in a <.G>oto command).
980 The command takes no arguments. If the command cannot execute for any
981 reason, ERROR will be returned. ERROR+NOT_LOGGED_IN or ERROR+NOT_HERE may
982 be returned as they apply.
984 If the command succeeds, OK will be returned. At this point, the current
985 room is **undefined**, and the client software is responsible for taking
986 the user to another room before executing any other room commands (usually
987 this will be _BASEROOM_ since it is always there).
990 MESG (read system MESsaGe)
992 This command is used to display system messages and/or help files. The
993 single argument it accepts is the name of the file to display. IT IS CASE
994 SENSITIVE. Citadel looks for these files first in the "messages"
995 subdirectory and then in the "help" subdirectory.
997 If the file is found, LISTING_FOLLOWS is returned, followed by a pathname
998 to the file being displayed. Then the message is printed, in format type 0
999 (see MSG0 command for more information on this). If the file is not found,
1002 There are some "well known" names of system messages which client software
1003 may expect most servers to carry:
1005 hello - Welcome message, to be displayed before the user logs in.
1006 changepw - To be displayed whenever the user is prompted for a new
1007 password. Warns about picking guessable passwords and such.
1008 register - Should be displayed prior to the user entering registration.
1009 Warnings about not getting access if not registered, etc.
1010 help - Main system help file.
1011 goodbye - System logoff banner; display when user logs off.
1012 roomaccess - Information about how public rooms and different types of
1013 private rooms function with regards to access.
1014 unlisted - Tells users not to choose to be unlisted unless they're
1015 really paranoid, and warns that aides can still see
1016 unlisted userlog entries.
1018 Citadel provides these for the Citadel Unix text client. They are
1019 probably not very useful for other clients:
1021 mainmenu - Main menu (when in idiot mode).
1026 saveopt - Options to save a message, abort, etc.
1027 entermsg - Displayed just before a message is entered, when in
1031 GNUR (Get Next Unvalidated User)
1033 This command shows the name of a user that needs to be validated. If there
1034 are no unvalidated users, OK is returned. Otherwise, MORE_DATA is returned
1035 along with the name of the first unvalidated user the server finds. All of
1036 the usual ERROR codes may be returned as well (for example, if the user is
1037 not an Aide and cannot validate users).
1039 A typical "Validate New Users" command would keep executing this command,
1040 and then validating each user it returns, until it returns OK when all new
1041 users have been validated.
1044 GREG (Get REGistration for user)
1046 This command retrieves the registration info for a user, whose name is the
1047 command's sole argument. All the usual error messages can be returned. If
1048 the command succeeds, LISTING_FOLLOWS is returned, followed by the user's name
1049 (retrieved from the userlog, with the right upper and lower case etc.) The
1050 contents of the listing contains one field per line, followed by the usual
1051 000 on the last line.
1053 The following lines are defined. Others WILL be added in the futre, so all
1054 software should be written to read the lines it knows about and then ignore
1055 all remaining lines:
1060 Line 4: Street address or PO Box
1061 Line 5: City/town/village/etc.
1062 Line 6: State/province/etc.
1064 Line 8: Telephone number
1065 Line 9: Access level
1066 Line 10: Internet e-mail address
1069 Users without Aide privileges may retrieve their own registration using
1070 this command. This can be accomplished either by passing the user's own
1071 name as the argument, or the string "_SELF_". The command will always
1072 succeed when used in this manner, unless no user is logged in.
1075 VALI (VALIdate user)
1077 This command is used to validate users. Obviously, it can only be executed
1078 by users with Aide level access. It should be passed two parameters: the
1079 name of the user to validate, and the desired access level
1081 If the command succeeds, OK is returned. The user's access level is changed
1082 and the "need validation" bit is cleared. If the command fails for any
1083 reason, ERROR, ERROR+NO_SUCH_USER, or ERROR+HIGHER_ACCESS_REQUIRED will be
1087 EINF (Enter INFo file for room)
1089 Transmit the info file for the current room with this command. EINF uses
1090 a boolean flag (1 or 0 as the first and only argument to the command) to
1091 determine whether the client actually wishes to transmit a new info file, or
1092 is merely checking to see if it has permission to do so.
1094 If the command cannot succeed, it returns ERROR.
1095 If the client is only checking for permission, and permission will be
1096 granted, OK is returned.
1097 If the client wishes to transmit the new info file, SEND_LISTING is
1098 returned, and the client should transmit the text of the info file, ended
1099 by the usual 000 on a line by itself.
1104 This is a simple user listing. It always succeeds, returning
1105 LISTING_FOLLOWS followed by zero or more user records, 000 terminated. The
1106 fields on each line are as follows:
1111 4. Date/time of last login (Unix format)
1114 7. Password (listed only if the user requesting the list is an Aide)
1116 Unlisted entries will also be listed to Aides logged into the server, but
1117 not to ordinary users.
1119 The LIST command accepts an optional single argument, which is a simple,
1120 case-insensitive search string. If this argument is present, only usernames
1121 in which the search string is present will be returned. It is a simple
1122 substring search, not a regular expression search. If this string is empty
1123 or not present, all users will be returned.
1126 REGI (send REGIstration)
1128 Clients will use this command to transmit a user's registration info. If
1129 no user is logged in, ERROR+NOT_LOGGED_IN is returned. Otherwise,
1130 SEND_LISTING is returned, and the server will expect the following information
1131 (terminated by 000 on a line by itself):
1134 Line 2: Street address or PO Box
1135 Line 3: City/town/village/etc.
1136 Line 4: State/province/etc.
1138 Line 6: Telephone number
1139 Line 7: e-mail address
1143 CHEK (CHEcK various things)
1145 When logging in, there are various things that need to be checked. This
1146 command will return ERROR+NOT_LOGGED_IN if no user is logged in. Otherwise
1147 it returns OK and the following parameters:
1149 0: Number of new private messages in Mail>
1150 1: Nonzero if the user needs to register
1151 2: (Relevant to Aides only) Nonzero if new users require validation
1152 3: The user's preferred Internet e-mail address
1155 DELF (DELete a File)
1157 This command deletes a file from the room's directory, if there is one. The
1158 name of the file to delete is the only parameter to be supplied. Wildcards
1159 are not acceptable, and any slashes in the filename will be converted to
1160 underscores, to prevent unauthorized access to neighboring directories. The
1161 possible return codes are:
1163 OK - Command succeeded. The file was deleted.
1164 ERROR+NOT_LOGGED_IN - Not logged in.
1165 ERROR+HIGHER_ACCESS_REQUIRED - Not an Aide or Room Aide.
1166 ERROR+NOT_HERE - There is no directory in this room.
1167 ERROR+FILE_NOT_FOUND - Requested file was not found.
1172 This command is similar to DELF, except that it moves a file (and its
1173 associated file description) to another room. It should be passed two
1174 parameters: the name of the file to move, and the name of the room to move
1175 the file to. All of the same return codes as DELF may be returned, and also
1176 one additional one: ERROR+NO_SUCH_ROOM, which means that the target room
1177 does not exist. ERROR+NOT_HERE could also mean that the target room does
1178 not have a directory.
1181 NETF (NETwork send a File)
1183 This command is similar to MOVF, except that it attempts to send a file over
1184 the network to another system. It should be passed two parameters: the name
1185 of the file to send, and the node name of the system to send it to. All of
1186 the same return codes as MOVF may be returned, except for ERROR+NO_SUCH_ROOM.
1187 Instead, ERROR+NO_SUCH_SYSTEM may be returned if the name of the target
1190 The name of the originating room will be sent along with the file. Most
1191 implementations will look for a room with the same name at the receiving end
1192 and attempt to place the file there, otherwise it goes into a bit bucket room
1193 for miscellaneous files. This is, however, beyond the scope of this document;
1194 see elsewhere for more details.
1197 RWHO (Read WHO's online)
1199 Displays a list of all users connected to the server. No error codes are
1200 ever returned. LISTING_FOLLOWS will be returned, followed by zero or more
1201 lines containing the following three fields:
1203 0 - Session ID. Citadel fills this with the pid of a server program.
1205 2 - The name of the room the user is currently in. This field might not
1206 be displayed (for example, if the user is in a private room) or it might
1207 contain other information (such as the name of a file the user is
1209 3 - (server v4.03 and above) The name of the host the client is connecting
1210 from, or "localhost" if the client is local.
1211 4 - (server v4.04 and above) Description of the client software being used
1212 5 - The last time, locally to the server, that a command was received from
1213 this client (Note: NOOP's don't count)
1214 6 - The last command received from a client. (NOOP's don't count)
1215 7 - Session flags. These are: + (spoofed address), - (STEALTH mode), *
1216 (posting) and . (idle).
1217 8 - Actual user name, if user name is masqueraded and viewer is an Aide.
1218 9 - Actual room name, if room name is masqueraded and viewer is an Aide.
1219 10 - Actual host name, if host name is masqueraded and viewer is an Aide.
1220 11 - Nonzero if the session is a logged-in user, zero otherwise.
1222 The listing is terminated, as always, with the string "000" on a line by
1226 OPEN (OPEN a file for download)
1228 This command is used to open a file for downloading. Only one download
1229 file may be open at a time. The only argument to this command is the name
1230 of the file to be opened. The user should already be in the room where the
1231 file resides. Possible return codes are:
1234 ERROR+NOT_HERE (no directory in this room)
1235 ERROR+FILE_NOT_FOUND (could not open the file)
1239 If the file is successfully opened, OK will be returned, along with the
1240 size (in bytes) of the file, the time of last modification (if applicable),
1241 the filename (if known), and the MIME type of the file (if known).
1244 CLOS (CLOSe the download file)
1246 This command is used to close the download file. It returns OK if the
1247 file was successfully closed, or ERROR if there wasn't any file open in the
1251 READ (READ from the download file)
1253 Two arguments are passed to this command. The first is the starting position
1254 in the download file, and the second is the total number of bytes to be
1255 read. If the operation can be performed, BINARY_FOLLOWS will be returned,
1256 along with the number of bytes to follow. Then, immediately following the
1257 newline, will be that many bytes of binary data. The client *must* read
1258 exactly that number of bytes, otherwise the client and server will get out
1261 If the operation cannot be performed, any of the usual error codes will be
1265 UOPN (OPeN a file for Uploading)
1267 This command is similar to OPEN, except that this one is used when the
1268 client wishes to upload a file to the server. The first argument is the name
1269 of the file to create, and the second argument is a one-line comment
1270 describing the contents of the file. Only one upload file may be open at a
1271 time. Possible return codes are:
1274 ERROR+NOT_HERE (no directory in this room)
1275 ERROR+FILE_NOT_FOUND (a name must be specified)
1276 ERROR (miscellaneous errors)
1277 ERROR+ALREADY_EXISTS (a file with the same name already exists)
1280 If OK is returned, the command has succeeded and writes may be performed.
1283 UCLS (CLoSe the Upload file)
1285 Close the file opened with UOPN. An argument of "1" should be passed to
1286 this command to close and save the file; otherwise, the transfer will be
1287 considered aborted and the file will be deleted. This command returns OK
1288 if the operation succeeded or ERROR if it did not.
1291 WRIT (WRITe to the upload file)
1293 If an upload file is open, this command may be used to write to it. The
1294 argument passed to this command is the number of bytes the client wishes to
1295 transmit. An ERROR code will be returned if the operation cannot be
1298 If the operation can be performed, SEND_BINARY will be returned, followed
1299 by the number of bytes the server is expecting. The client must then transmit
1300 exactly that number of bytes. Note that in the current implementation, the
1301 number of bytes the server is expecting will always be the number of bytes
1302 the client requested to transmit, but the client software should never assume
1303 that this will always happen, in case changes are made later.
1306 QUSR (Query for a USeR)
1308 This command is used to check to see if a particular user exists. The only
1309 argument to this command is the name of the user being searched for. If
1310 the user exists, OK is returned, along with the name of the user in the userlog
1311 (so the client software can learn the correct upper/lower casing of the name
1312 if necessary). If the user does not exist, ERROR+NO_SUCH_USER is returned.
1313 No login or current room is required to utilize this command.
1316 OIMG (Open an IMaGe file)
1318 Open an image (graphics) file for downloading. Once opened, the file can be
1319 read as if it were a download file. This implies that an image and a download
1320 cannot be opened at the same time. OIMG returns the same result codes as OPEN.
1322 All images will be in GIF (Graphics Interchange Format). In the case of
1323 Citadel, the server will convert the supplied filename to all lower case,
1324 append the characters ".gif" to the filename, and look for it in the "images"
1325 subdirectory. As with the MESG command, there are several "well known"
1326 images which are likely to exist on most servers:
1328 hello - "Welcome" graphics to be displayed alongside MESG "hello"
1329 goodbye - Logoff banner graphics to be displayed alongside MESG "goodbye"
1330 background - Background image (usually tiled) for graphical clients
1332 The following "special" image names are defined in Citadel server version
1335 _userpic_ - Picture of a user (send the username as the second argument)
1336 _floorpic_ - A graphical floor label (send the floor number as the second
1337 argument). Clients which request a floor picture will display
1338 the picture *instead* of the floor name.
1339 _roompic_ - A graphic associated with the *current* room. Clients which
1340 request a room picture will display the picture in *addition*
1341 to the room name (i.e. it's used for a room banner, as
1342 opposed to the floor picture's use in a floor listing).
1345 NETP (authenticate as network session with connection NET Password)
1347 This command is used by client software to identify itself as a transport
1348 session for Citadel site-to-site networking. It should be called with
1349 two arguments: the node name of the calling system, and the "shared secret"
1350 password for that connection. If the authentication succeeds, NETP will
1351 return OK, otherwise, it returns ERROR.
1354 NSYN (Network SYNchronize room)
1356 This command can be used to synchronize the contents of a room on the
1357 network. It is only usable by Aides. It accepts one argument: the name of
1358 a network node (which must be a valid one).
1360 When NSYN is run, the *entire* contents of the current room will be spooled
1361 to the specified node, without regard to whether any of the messages have
1362 already undergone network processing. It is up to the receiving node to
1363 check for duplicates (the Citadel networker does handle this) and avoid
1366 The command returns OK upon success or ERROR if the user is not an Aide.
1369 NUOP (Network Upload OPen file)
1371 Open a network spool file for uploading. The client must have already
1372 identified itself as a network session using the NETP command. If the command
1373 returns OK, the client may begin transmitting IGnet/Open spool data using
1374 a series of WRIT commands. When a UCLS command is issued, the spooled data
1375 is entered into the server if the argument to UCLS is 1 or discarded if the
1376 argument to UCLS is 0. If the client has not authenticated itself with a
1377 NETP command, ERROR+HIGHER_ACCESS_REQUIRED will be returned.
1380 NDOP (Network Download OPen file)
1382 Open a network spool file for downloading. The client must have already
1383 identified itself as a network session using the NETP command. If the command
1384 returns OK, the client may begin receiving IGnet/Open spool data using
1385 a series of READ commands. When a CLOS command is issued, the spooled data
1386 is deleted from the server and may not be read again. If the client has not
1387 authenticated itself with a NETP command, ERROR+HIGHER_ACCESS_REQUIRED will
1391 LFLR (List all known FLooRs)
1393 On systems supporting floors, this command lists all known floors. The
1394 command accepts no parameters. It will return ERROR+NOT_LOGGED_IN if no
1395 user is logged in. Otherwise it returns LISTING_FOLLOWS and a list of
1396 the available floors, each line consisting of three fields:
1398 1. The floor number associated with the floor
1399 2. The name of the floor
1400 3. Reference count (number of rooms on this floor)
1403 CFLR (Create a new FLooR)
1405 This command is used to create a new floor. It should be passed two
1406 arguments: the name of the new floor to be created, and a 1 or 0 depending
1407 on whether the client is actually creating a floor or merely checking to
1408 see if it has permission to create the floor. The user must be logged in
1409 and have Aide privileges to create a floor.
1411 If the command succeeds, it will return OK followed by the floor number
1412 associated with the new floor. Otherwise, it will return ERROR (plus perhaps
1413 HIGHER_ACCESS_REQUIRED, ALREADY_EXISTS, or INVALID_FLOOR_OPERATION)
1414 followed by a description of why the command failed.
1419 This command is used to delete a floor. It should be passed two
1420 argument: the *number* of the floor to be deleted, and a 1 or 0 depending
1421 on whether the client is actually deleting the floor or merely checking to
1422 see if it has permission to delete the floor. The user must be logged in
1423 and have Aide privileges to delete a floor.
1425 Floors that contain rooms may not be deleted. If there are rooms on a floor,
1426 they must be either deleted or moved to different floors first. This implies
1427 that the Main Floor (floor 0) can never be deleted, since Lobby>, Mail>, and
1428 Aide> all reside on the Main Floor and cannot be deleted.
1430 If the command succeeds, it will return OK. Otherwise it will return
1431 ERROR (plus perhaps HIGHER_ACCESS_REQUIRED or INVALID_FLOOR_OPERATION)
1432 followed by a description of why the command failed.
1437 Edit the parameters of a floor. The client may pass one or more parameters
1440 1. The number of the floor to be edited
1441 2. The desired new name
1443 More parameters may be added in the future. Any parameters not passed to
1444 the server will remain unchanged. A minimal command would be EFLR and a
1445 floor number -- which would do nothing. EFLR plus the floor number plus a
1446 floor name would change the floor's name.
1448 If the command succeeds, it will return OK. Otherwise it will return
1449 ERROR (plus perhaps HIGHER_ACCESS_REQUIRED or INVALID_FLOOR_OPERATION)
1452 IDEN (IDENtify the client software)
1454 The client software has the option to identify itself to the server.
1455 Currently, the server does nothing with this information except to write
1456 it to the syslog to satisfy the system administrator's curiosity. Other
1457 uses might become apparent in the future.
1459 The IDEN command should contain five fields: a developer ID number (same as
1460 the server developer ID numbers in the INFO command -- please obtain one if
1461 you are a new developer), a client ID number (which does not have to be
1462 globally unique - only unique within the domain of the developer number),
1463 a version number, a free-form text string describing the client, and the name
1464 of the host the user is located at.
1466 It is up to the server to determine whether to accept the host name or to
1467 use the host name it has detected itself. Generally, if the client is
1468 running on a trusted host (either localhost or a well-known publically
1469 accessible client) it should use the host name transmitted by IDEN,
1470 otherwise it should use the host name it has detected itself.
1472 IDEN always returns OK, but since that's the only way it ever returns
1473 there's no point in checking the result code.
1476 IPGM (identify as an Internal ProGraM)
1478 IPGM is a low-level command that should not be used by normal user clients.
1479 It is used for various utilities to communicate with the server on the same
1480 host. For example, the "sendcommand" utility logs onto the server as an
1481 internal program in order to run arbitrary server commands. Since user clients
1482 do not utilize this command (or any of its companion commands), developers
1483 writing Citadel-compatible servers need not implement it.
1485 The sole argument to IPGM is the system's internal program password. This
1486 password is generated by the setup program and stored in the config file.
1487 Since internal programs have access to the config file, they know the correct
1490 IPGM returns OK for a correct authentication or ERROR otherwise.
1493 CHAT (enter CHAT mode)
1495 This command functions differently from every other command in the system. It
1496 is used to implement multi-user chat. For this to function, a new transfer
1497 mode, called START_CHAT_MODE, is implemented. If a client does not support
1498 chat mode, it should never send a CHAT command!
1500 In chat mode, messages may arrive asynchronously from the server at any
1501 time. The client may send messages at any time. This allows the arrival of
1502 messages without the client having to poll for them. Arriving messages will
1503 be of the form "user|message", where the "user" portion is, of course, the
1504 name of the user sending the message, and "message" is the message text.
1506 Chat mode ends when the server says it ends. The server will signal the end
1507 of chat mode by transmitting "000" on a line by itself. When the client reads
1508 this line, it must immediately exit from chat mode without sending any
1509 further traffic to the server. The next transmission sent to the server
1510 will be a regular server command.
1512 The Citadel server understands the following commands:
1513 /quit - Exit from chat mode (causes the server to do an 000 end)
1514 /who - List users currently in chat
1515 /whobbs - List users currently in chat and elsewhere
1516 /me - Do an irc-style action.
1517 /join - Join a new "room" in which all messages are only heard by
1518 people in that room.
1519 /msg - /msg <user> <msg> will send the msg to <user> only.
1520 /help - Print help information
1521 NOOP - Do nothing (silently)
1523 Any other non-empty string is treated as message text and will be broadcast
1524 to other users currently in chat.
1527 SEXP (Send instant message)
1529 This is one of two commands which implement instant messages (also known
1530 as "paging"). Commands ending in "...EXP" are so-named because we called
1531 them "express messages" before the industry standardized on the term
1532 "instant messages." When an instant message is sent, it will be
1533 logged in user to another. When an instant message is sent, it will be
1534 displayed the next time the target user executes a PEXP or GEXP command.
1536 The SEXP command accepts two arguments: the name of the user to send the
1537 message to, and the text of the message. If the message is successfully
1538 transmitted, OK is returned. If the target user is not logged in or if
1539 anything else goes wrong, ERROR is returned.
1541 If the server supports extended paging, sending a zero-length message
1542 merely checks for the presence of the requested user without actually sending
1543 a message. Sending a message consisting solely of a "-" (hyphen) will cause
1544 the server to return SEND_LISTING if the requested user is logged in, and the
1545 client can then transmit a multi-line page.
1547 The reserved name "broadcast" may be used instead of a user name, to
1548 broadcast an instant message to all users currently connected to the server.
1550 Do be aware that if an instant message is transmitted to a user who is logged
1551 in using a client that does not check for instant messages, the message will
1552 never be received. Also, instant messages are NOT sent via the following
1553 transports: SMTP, POP3.
1556 PEXP (Print instant messages) ***DEPRECATED***
1558 This command is deprecated; it will eventually disappear from the protocol and
1559 its use is not recommended. Please use the GEXP command instead.
1561 Called without any arguments, PEXP simply dumps out the contents
1562 of any waiting instant messages. It returns ERROR if there is a problem,
1563 otherwise it returns LISTING_FOLLOWS followed by all messages.
1565 So how does the client know there are instant messages waiting? It could
1566 execute a random PEXP every now and then. Or, it can check the byte in
1567 server return code messages, between the return code and the parameters. In
1568 much the same way as FTP uses "-" to signify a continuation, Citadel uses
1569 an "*" in this position to signify the presence of waiting instant messages.
1572 EBIO (Enter BIOgraphy)
1574 Transmit to the server a free-form text file containing a little bit of
1575 information about the user for other users to browse. This is typically
1576 referred to as a 'bio' online. EBIO returns SEND_LISTING if it succeeds,
1577 after which the client is expected to transmit the file, or any of the usual
1578 ERROR codes if it fails.
1581 RBIO (Read BIOgraphy)
1583 Receive from the server a named user's bio. This command should be passed
1584 a single argument - the name of the user whose bio is requested. RBIO returns
1585 LISTING_FOLLOWS plus the bio file if the user exists and has a bio on file.
1586 The return has the following parameters: the user name, user number, access
1587 level, date of last call, times called, and messages posted. This command
1588 returns ERROR+NO_SUCH_USER if the named user does not exist.
1590 RBIO no longer considers a user with no bio on file to be an error condition.
1591 It now returns a message saying the user has no bio on file as the text of the
1592 bio. This allows newer servers to operate with older clients.
1595 STEL (enter STEaLth mode)
1597 When in "stealth mode," a user will not show up in the "Who is online"
1598 listing (the RWHO server command). Only Aides may use stealth mode. The
1599 STEL command accepts one argument: a 1 indicating that the user wishes to
1600 enter stealth mode, or a 0 indicating that the user wishes to exit stealth
1601 mode. STEL returns OK if the command succeeded, ERROR+NOT_LOGGED_IN if no
1602 user is logged in, or ERROR+HIGHER_ACCESS_REQUIRED if the user is not an Aide;
1603 followed by a 1 or 0 indicating the new state.
1605 If any value other than 1 or 0 is sent by the client, the server simply
1606 replies with 1 or 0 to indicate the current state without changing it.
1608 The STEL command also makes it so a user does not show up in the chat room
1612 LBIO (List users who have BIOs on file)
1614 This command is self-explanatory. Any user who has used EBIO to place a bio
1615 on file is listed. LBIO almost always returns LISTING_FOLLOWS followed by
1616 this listing, unless it experiences an internal error in which case ERROR
1620 MSG2 (read MeSsaGe, mode 2)
1622 MSG2 follows the same calling convention as MSG0. The difference between
1623 the two commands is that MSG2 outputs messages in standard RFC822 format
1624 rather than in Citadel proprietary format.
1626 This command was implemented in order to make various gateway programs
1627 easier to implement, and to provide some sort of multimedia support in the
1628 future. Keep in mind that when this command is used, all messages will be
1629 output in fixed 80-column format.
1632 MSG3 (read MeSsaGe, mode 3 -- internal command)
1634 MSG3 is for use by internal programs only and should not be utilized by
1635 user-mode clients. It does require IPGM authentication. MSG3 follows the
1636 same calling convention as the other MSG commands, but upon success returns
1637 BINARY_FOLLOWS followed by a data block containing the _raw_ message format
1641 TERM (TERMinate another session)
1643 In a multithreaded environment, it sometimes becomes necessary to terminate
1644 a session that is unusable for whatever reason. The TERM command performs
1645 this task. Naturally, only Aides can execute TERM. The command should be
1646 called with a single argument: the session ID (obtained from an RWHO command)
1647 of the session to be terminated.
1649 TERM returns OK if the session was terminated, or ERROR otherwise. Note that
1650 a client program is prohibited from terminating the session it is currently
1656 DOWN (shut DOWN the server)
1658 This command, which may only be executed by an Aide, immediately shuts down
1659 the server. It is only implemented on servers on which such an operation is
1660 possible, such as a multithreaded Citadel engine. The server does not restart.
1661 DOWN returns OK if the user is allowed to shut down the server, in which case
1662 the client program should expect the connection to be immediately broken.
1665 SCDN (Schedule or Cancel a shutDowN)
1667 SCDN sets or clears the "scheduled shutdown" flag. Pass this command a 1 or
1668 0 to respectively set or clear the flag. When the "scheduled shutdown" flag is
1669 set, the server will be shut down when there are no longer any users logged in.
1670 Any value other than 0 or 1 will not change the flag, only report its state.
1671 No users will be kicked off the system, and in fact the server is still
1672 available for new connections. The command returns ERROR if it fails;
1673 otherwise, it returns OK followed by a number representing the current state
1677 HALT (HALT the server without shutting it down)
1679 Identical to the DOWN command, except instead of exiting, the server process
1680 cleans up and then suspends indefinitely. This could potentially be useful for
1681 shutdown scripts that don't want init to automatically respawn another citserver
1685 EMSG (Enter a system MeSsaGe)
1687 This is the opposite of the MESG command - it allows the creation and editing
1688 of system messages. The only argument passed to EMSG is the name of the
1689 file being transmitted. If the file exists in any system message directory
1690 on the server it will be overwritten, otherwise a new file is created. EMSG
1691 returns SEND_LISTING on success or ERROR+HIGHER_ACCESS_REQUIRED if the user
1694 Typical client software would use MESG to retrieve any existing message into
1695 an edit buffer, then present an editor to the user and run EMSG if the changes
1699 UIMG (Upload an IMaGe file)
1701 UIMG is complemenary to OIMG; it is used to upload an image to the server.
1702 The first parameter supplied to UIMG should be 0 if the client is only checking
1703 for permission to upload, or 1 if the client is actually attempting to begin
1704 the upload operation. The second argument is the name of the file to be
1705 transmitted. In Citadel, the filename is converted to all lower case,
1706 appended with the characters ".gif", and stored in the "images" directory.
1708 UIMG returns OK if the client has permission to perform the requested upload,
1709 or ERROR+HIGHER_ACCESS_REQUIRED otherwise. If the client requested to begin
1710 the operation (first parameter set to 1), an upload file is opened, and the
1711 client should begin writing to it with WRIT commands, then close it with a
1714 The supplied filename should be one of:
1716 -> _userpic_ (Server will attempt to write to the user's online photo)
1717 -> Any of the "well known" filenames described in the writeup for the
1721 HCHG (Hostname CHanGe)
1723 HCHG is a command, usable by any user, that allows a user to change their RWHO
1724 host value. This will mask a client's originating hostname from normal
1725 users; access level 6 and higher can see, in an extended wholist, the actual
1726 hostname the user originates from.
1728 The format of an HCHG command is:
1732 If a HCHG command is successful, the value OK (200) is returned.
1735 RCHG (Roomname CHanGe)
1737 RCHG is a command, usable by any user, that allows a user to change their RWHO
1738 room value. This will mask a client's roomname from normal users; access
1739 level 6 and higher can see, in an extended wholist, the actual room the user
1742 The format of an RCHG command is:
1746 If a RCHG command is successful, the value OK (200) is returned.
1749 UCHG (Username CHanGe)
1751 UCHG is an aide-level command which allows an aide to effectively change their
1752 username. If this value is blank, the user goes into stealth mode (see
1754 will show up as being from the real username in this mode, however. In
1755 addition, the RWHO listing will include both the spoofed and real usernames.
1757 The format of an UCHG command is:
1761 If a UCHG command is successful, the value OK (200) is returned.
1764 TIME (get server local TIME)
1766 TIME returns OK followed by the current time measured in seconds since
1767 00:00:00 GMT, Jan 1, 1970 (standard Unix format).
1769 This is used in allowing a client to calculate idle times.
1772 AGUP (Administrative Get User Parameters)
1773 ASUP (Administrative Set User Parameters)
1775 These commands are only executable by Aides and by server extensions running
1776 at system-level. They are used to get/set any and all parameters relating to
1777 a user account. AGUP requires only one argument: the name of the user in
1778 question. SGUP requires all of the parameters to be set. The parameters are
1779 as follows, and are common to both commands:
1783 2 - Flags (see citadel.h)
1788 7 - Timestamp of last call
1789 8 - Purge time (in days) for this user (or 0 to use system default)
1791 Upon success, AGUP returns OK followed by all these parameters, and ASUP
1792 simply returns OK. If the client has insufficient access to perform the
1793 requested operation, ERROR+HIGHER_ACCESS_REQUIRED is returned. If the
1794 requested user does not exist, ERROR+NO_SUCH_USER is returned.
1798 GPEX (Get Policy for message EXpiration)
1800 Returns the policy of the current room, floor, or site regarding the automatic
1801 purging (expiration) of messages. The following policies are available:
1802 0 - Fall back to the policy of the next higher level. If this is a room,
1803 use the floor's default policy. If this is a floor, use the system
1804 default policy. This is an invalid value for the system policy.
1805 1 - Do not purge messages automatically.
1806 2 - Purge by message count. (Requires a value: number of messages)
1807 3 - Purge by message age. (Requires a value: number of days)
1809 The format of this command is: GPEX <which>
1810 The value of <which> must be one of: "room" "floor" "site" "mailboxes"
1812 If successful, GPEX returns OK followed by <policy>|<value>.
1816 SPEX (Set Policy for message EXpiration)
1818 Sets the policy of the current room, floor, or site regarding the automatic
1819 purging (expiration) of messages. See the writeup for the GPEX command for
1820 the list of available policies.
1822 The format of this command is: SPEX <which>|<policy>|<value>
1823 The value of <which> must be one of: "room" "floor" "site" "mailboxes"
1825 If successful, GPEX returns OK; otherwise, an ERROR code is returned.
1829 CONF (get or set global CONFiguration options)
1831 Retrieves or sets various system-wide configuration and policy options. This
1832 command is only available to Aides. The sole parameter accepted is a command,
1833 which should be either GET or SET. If the GET command succeeds, CONF will
1834 return LISTING_FOLLOWS followed by the fields described below, one line at a
1835 time. If the SET command succeeds, CONF will return SEND_LISTING and expect
1836 the fields described below, one line at a time (don't worry about other fields
1837 being added in the future; if a 'short' configuration list is sent, the missing
1838 values at the end will be left unchanged on the system). If either command
1839 fails for any reason, ERROR is returned.
1841 The configuration lines are as follows:
1844 1. Fully qualified domain name
1845 2. Human-readable node name
1846 3. Landline telephone number of this system
1847 4. Flag (0 or 1) - creator of private room automatically becomes room aide
1848 5. Server connection idle timeout (in seconds)
1849 6. Initial access level for new users
1850 7. Flag (0 or 1) - require registration for new users
1851 8. Flag (0 or 1) - automatically move Problem User messages to twit room
1852 9. Name of twit room
1853 10. Text of <more> prompt
1854 11. Flag (0 or 1) - restrict access to Internet mail
1855 12. Geographic location of this system
1856 13. Name of the system administrator
1857 14. Number of maximum concurrent sessions allowed on the server
1858 15. (placeholder -- this field is no longer in use)
1859 16. Default purge time (in days) for users
1860 17. Default purge time (in days) for rooms
1861 18. Name of room to log instant messages to (or a zero-length name for none)
1862 19. Access level required to create rooms
1863 20. Maximum message length which may be entered into the system
1864 21. Minimum number of worker threads
1865 22. Maximum number of worker threads
1866 23. Port number for POP3 service
1867 24. Port number for SMTP service
1868 25. Flag (0 or 1) - strict RFC822 adherence - don't correct From: forgeries
1869 26. Flag (0 or 1) - allow Aides to zap (forget) rooms
1870 27. Port number for IMAP service
1871 28. How often (in seconds) to run the networker
1872 29. Flag (0 or 1) - disable self-service new user registration
1873 30. (placeholder -- this field is no longer in use)
1874 31. Hour (0 through 23) during which database auto-purge jobs are run
1875 32. Name of host where an LDAP service may be found
1876 33. Port number of LDAP service on above host
1879 36. Password for LDAP Bind DN
1880 37. Server IP address to listen on (or "0.0.0.0" for all addresses)
1881 38. Port number for SMTP MSA service
1882 39. Port number for IMAPS (SSL-encrypted IMAP)
1883 40. Port number for POP3S (SSL-encrypted POP3)
1884 41. Port number for SMTPS (SSL-encrypted SMTP)
1885 42. Flag (0 or 1) - enable full text search index
1886 43. Flag (0 or 1) - automatically cull database log files
1887 44. Flag (0 or 1) - enable IMAP "instant expunge" of deleted messages
1888 45. Flag (0 or 1) - allow unauthenticated SMTP clients to spoof my domains
1889 46. Flag (0 or 1) - perform journaling of email messages
1890 47. Flag (0 or 1) - perform journaling of non-email messages
1891 48. Address to which journalized messages are to be sent
1892 49. Default time zone (Olsen database name) for unzoned calendar items
1893 50. Port number for Postfix TCP Dict (http://www.postfix.org/tcp_table.5.html)
1895 CONF also accepts two additional commands: GETSYS and PUTSYS followed by an
1896 arbitrary MIME type (such as application/x-citadel-internet-config) which
1897 provides a means of storing generic configuration data in the Global System
1898 Configuration room without the need to add extra get/set commands to the
1901 Please note that the LDAP-specific configs have no effect on Citadel servers
1902 in which LDAP support is not enabled.
1906 MSG4 (read MeSsaGe, mode 4 -- output in preferred MIME format)
1908 This is the equivalent of MSG0, except it's a bit smarter about messages in
1909 rich text formats. Immediately following the "text" directive, the server
1910 will output RFC822-like MIME part headers such as "Content-type:" and
1911 "Content-length:". MIME formats are chosen and/or converted based on the
1912 client's preferred format settings, which are set using the MSGP command,
1915 The MSG4 command also accepts an optional second argument, which may be the
1916 MIME part specifier of an encapsulated message/rfc822 message. This is useful
1917 for fetching the encapsulated message instead of the top-level message, for
1918 example, when someone has forwarded a message as an attachment. Note that the
1919 only way for the client to know the part specifier is to fetch the top-level
1920 message and then look for attachments of type message/rfc822, and then call
1921 MSG4 again with that part specifier.
1926 MSGP (set MeSsaGe Preferred MIME format)
1928 Client tells the server what MIME content types it knows how to handle, and
1929 the order in which it prefers them. This is similar to an HTTP "Accept:"
1932 The parameters to a MSGP command are the client's acceptable MIME content
1933 types, in the order it prefers them (from most preferred to least preferred).
1934 For example: MSGP text/html|text/plain
1936 The MSGP command always returns OK.
1940 OPNA (OPeN Attachment)
1942 Opens, as a download file, a component of a MIME-encoded message. The two
1943 parameters which must be passed to this command are the message number and the
1944 name of the desired section. If the message or section does not exist, an
1945 appropriate ERROR code will be returned; otherwise, if the open is successful,
1946 this command will succeed returning the same information as an OPEN command.
1949 GEXP (Get instant messages)
1951 This is a more sophisticated way of retrieving instant messages than the old
1952 PEXP method. If there are no instant messages waiting, PEXP returns ERROR;
1953 otherwise, it returns LISTING_FOLLOWS and the following arguments:
1955 0 - a boolean value telling the client whether there are any additional
1956 instant messages waiting following this one
1957 1 - a Unix-style timestamp
1958 2 - flags (see server.h for more info)
1959 3 - the name of the sender
1960 4 - the node this message originated on (for future support of PIP, ICQ, etc.)
1962 The text sent to the client will be the body of the instant message.
1964 So how does the client know there are instant messages waiting? It could
1965 execute a random GEXP every now and then. Or, it can check the byte in
1966 server return code messages, between the return code and the parameters. In
1967 much the same way as FTP uses "-" to signify a continuation, Citadel uses
1968 an "*" in this position to signify the presence of waiting instant messages.
1971 FSCK (check message base reference counts)
1973 Verify, via the long way, that all message referenmce counts are correct. If
1974 the user has permission to do this then LISTING_FOLLOWS is returned, followed
1975 by a transcript of the run. Otherwise ERROR is returned.
1978 DEXP (Disable receiving instant messages)
1980 DEXP sets or clears the "disable instant messages" flag. Pass this command a
1981 1 or 0 to respectively set or clear the flag. When the "disable instant
1982 messages" flag is set, no one except Aides may send the user instant messages.
1983 Any value other than 0 or 1 will not change the flag, only report its state.
1984 The command returns ERROR if it fails; otherwise, it returns OK followed by a
1985 number representing the current state of the flag.
1988 REQT (REQuest client Termination)
1990 Request that the specified client (or all clients) log off. Aide level
1991 access is required to run this command, otherwise ERROR+HIGHER_ACCESS_REQUIRED
1994 The REQT command accepts one parameter: the session ID of the client which
1995 should be terminated, or 0 for all clients. When successful, the REQT command
1998 It should be noted that REQT simply transmits an instant message to the
1999 specified client(s) with the EM_GO_AWAY flag set. Older clients do not honor
2000 this flag, and it is certainly possible for users to re-program their client
2001 software to ignore it. Therefore the effects of the REQT command should be
2002 considered advisory only. The recommended implementation practice is to first
2003 issue a REQT command, then wait a little while (from 30 seconds up to a few
2004 minutes) for well-behaved clients to voluntarily terminate, and then issue a
2005 TERM command to forcibly disconnect the client (or perhaps a DOWN command, if
2006 you are logging off users for the purpose of shutting down the server).
2009 SEEN (set or clear the SEEN flag for a message)
2011 Beginning with version 5.80, Citadel supports the concept of setting or
2012 clearing the "seen" flag for each individual message, instead of only allowing
2013 a "last seen" pointer. In fact, the old semantics are implemented in terms
2014 of the new semantics. This command requires two arguments: the number of the
2015 message to be set, and a 1 or 0 to set or clear the "seen" bit.
2017 This command returns OK, unless the user is not logged in or a usage error
2018 occurred, in which case it returns ERROR. Please note that no checking is
2019 done on the supplied data; if the requested message does not exist, the SEEN
2020 command simply returns OK without doing anything.
2023 GTSN (GeT the list of SeeN messages)
2025 This command retrieves the list of "seen" (as opposed to unread) messages for
2026 the current room. It returns OK followed by an IMAP-format message list.
2029 SMTP (utility commands for the SMTP gateway)
2031 This command, accessible only by Aides, supports several utility operations
2032 which examine or manipulate Citadel's SMTP support. The first command argument
2033 is a subcommand telling the server what to do. The following subcommands are
2036 SMTP mx|hostname (display all MX hosts for 'hostname')
2037 SMTP runqueue (attempt immediate delivery of all messages
2038 in the outbound SMTP queue, ignoring any
2039 retry times stored there)
2042 STLS (Start Transport Layer Security)
2044 This command starts TLS on the current connection. The current
2045 implementation uses OpenSSL on both the client and server end. For future
2046 compatibility all clients must support at least TLSv1, and servers are
2047 guaranteed to support TLSv1. During TLS negotiation (see below) the server
2048 and client may agree to use a different protocol.
2050 The server returns ERROR if it does not support SSL or SSL initialization
2051 failed on the server; otherwise it returns OK. Once the server returns OK and
2052 the client has read the response, the server and client immediately negotiate
2053 TLS (in OpenSSL, using SSL_connect() on the client and SSL_accept() on the
2054 server). If negotiation fails, the server and client should attempt to resume
2055 the session unencrypted. If either end is unable to resume the session, the
2056 connection should be closed.
2058 This command may be run at any time.
2061 GTLS (Get Transport Layer Security Status)
2063 This command returns information about the current connection. The server
2064 returns OK plus several parameters if the connection is encrypted, and ERROR
2065 if the connection is not encrypted. It is primarily used for debugging. The
2066 command may be run at any time.
2068 0 - Protocol name, e.g. "SSLv3"
2069 1 - Cipher suite name, e.g. "ADH-RC4-MD5"
2070 2 - Cipher strength bits, e.g. 128
2071 3 - Cipher strength bits actually in use, e.g. 128
2074 IGAB (Initialize Global Address Book)
2076 This command creates, or re-creates, a database of Internet e-mail addresses
2077 using the vCard information in the Global Address Book room. This procedure
2078 is normally run internally when the server determines it necessary, but is
2079 also provided as a server command to be used as a troubleshooting/maintenenance
2080 tool. Only a system Aide can run the command. It returns OK on success or
2084 QDIR (Query global DIRectory)
2086 Look up an internet address in the global directory. Any logged-in user may
2087 call QDIR with one parameter, the Internet e-mail address to look up. QDIR
2088 returns OK followed by a Citadel address if there is a match, otherwise it
2089 returns ERROR+NOT_LOGGED_IN.
2092 ISME (find out if an e-mail address IS ME)
2094 This is a quickie shortcut command to find out if a given e-mail address
2095 belongs to the user currently logged in. Its sole argument is an address to
2096 parse. The supplied address may be in any format (local, IGnet, or Internet).
2097 The command returns OK if the address belongs to the user, ERROR otherwise.
2100 VIEW (set the VIEW for a room)
2102 Set the preferred view for the current user in the current room. Please see
2103 views.txt for more information on views. The sole parameter for this command
2104 is the type of view requested. VIEW returns OK on success or ERROR on failure.
2107 QNOP (Quiet No OPeration)
2109 This command does nothing, similar to the NOOP command. However, unlike the
2110 NOOP command, it returns *absolutely no response* at all. The client has no
2111 way of knowing that the command executed. It is intended for sending
2112 "keepalives" in situations where a full NOOP would cause the client protocol
2115 Naturally, sending this command to a server that doesn't support it is an
2116 easy way to mess things up. Therefore, client software should first check
2117 the output of an INFO command to ensure that the server supports quiet noops.
2121 ICAL (Internet CALendaring commands)
2123 This command supports a number of subcommands which are used to process the
2124 calendaring/scheduling support in Citadel. Here are the subcommands which
2128 Test server for calendaring support. Always returns OK unless the server
2129 does not have the calendar module enabled.
2131 ICAL respond|msgnum|partnum|action
2132 Respond to a meeting request. 'msgnum' and 'partnum' refer to a MIME-encoded
2133 meeting invitation in the current room. 'action' must be set to either
2134 "accept" or "decline" to determine the action to take. This subcommand will
2135 return either OK or ERROR.
2137 ICAL conflicts|msgnum|partnum
2138 Determine whether an incoming VEVENT will fit in the user's calendar by
2139 checking it against the existing VEVENTs. 'msgnum' and 'partnum' refer to
2140 a MIME-encoded meeting invitation in the current room (usually the inbox).
2141 This command may return ERROR if something went wrong, but usually it will
2142 return LISTING_FOLLOWS followed by a list of zero or more conflicting
2143 events. A zero-length list means that there were no conflicts.
2145 ICAL handle_rsvp|msgnum|partnum
2146 Handle an incoming "reply" (or RSVP) to a meeting request you sent out.
2147 'msgnum' and 'partnum' refer to a MIME-encoded reply in the current room.
2148 'action' must be set to either "update" or "ignore" to determine the action
2149 to take. If the action is "update" then the server will hunt for the meeting
2150 in the user's Calendar> room, and update the status for this attendee. Either
2151 way, the reply message is deleted from the current room. This subcommand will
2152 return either OK or ERROR.
2154 ICAL freebusy|username
2155 Output the free/busy times for the requested user. If the user specified
2156 has a calendar available, this command will return LISTING_FOLLOWS and a
2157 compound VCALENDAR object. That object, in turn, will contain VEVENT
2158 objects that have been stripped of all properties except for the bare
2159 minimum needed to learn free/busy times (such as DTSTART, DTEND, and
2160 TRANSP). If there is no such user, or no calendar available, the usual
2161 ERROR codes will be returned.
2164 Readers who are paying attention will notice that there is no subcommand to
2165 send out meeting invitations. This is because that task can be handled
2166 automatically by the Citadel server. Issue this command with <bool> set to 1
2167 to enable Server Generated Invitations. In this mode, when an event is saved
2168 to the user's Calendar> room and it contains attendees, Citadel will
2169 automatically turn the event into calendar REQUEST messages and mail them
2170 out to all listed attendees. If for some reason the client needs to disable
2171 Server Generated Invitations, the command may be sent again with <bool> = 0.
2174 Output the contents of the entire calendar (assuming we are in a calendar
2175 room) as one big data stream. All of the events (or tasks, etc.) in the room
2176 are combined into a single VCALENDAR object, which is then serialized and
2177 transmitted to the client. This is suitable for subscribing to a calendar
2178 in third-party software. This command will output LISTING_FOLLOWS followed
2179 by the calendar data stream, or ERROR if the requested operation is not
2183 Delete the entire contents of a calendar room and replace it with the calendar
2184 supplied by a client-input data stream. This is suitable for publishing a
2185 calendar from third-party software. This command will output SEND_LISTING and
2186 then expect the client to transmit the calendar data stream. Alternatively,
2187 it will return ERROR if the requested operation is not permitted.
2191 MRTG (Multi Router Traffic Grapher)
2193 Multi Router Traffic Grapher (please see http://www.mrtg.org for more info) is
2194 a tool which creates pretty graphs of network activity, usually collected from
2195 routers using SNMP. However, its ability to call external scripts has spawned
2196 a small community of people using it to graph anything which can be graphed.
2197 The MRTG command can output Citadel server activity in the format MRTG expects.
2199 This format is as follows:
2204 Line 3: uptime of system
2205 Line 4: name of system
2208 MRTG accepts two different keywords. "MRTG users" will return two variables,
2209 the number of connected users and the number of active users. "MRTG messages"
2210 will return one variable (and a zero in the second field), showing the current
2211 highest message number on the system. Any other keyword, or a missing keyword,
2212 will cause the MRTG command to return an ERROR code.
2214 Please get in touch with the Citadel developers if you wish to experiment with
2219 GNET (Get NETwork configuration for this room)
2220 SNET (Set NETwork configuration for this room)
2222 These commands get/set the network configuration for the current room. Aide
2223 or Room Aide privileges are required, otherwise an ERROR code is returned.
2224 If the command succeeds, LISTING_FOLLOWS or SEND_LISTING is returned. The
2225 network configuration for a specific room includes neighbor nodes with whom
2226 the room is shared, and mailing list recipients. The format of the network
2227 configuration is described in the file "netconfigs.txt".
2231 ASYN (ASYNchronous message support)
2233 Negotiate the use of asynchronous, or unsolicited, protocol messages. The
2234 only parameter specified should be 1 or 0 to indicate that the client can or
2235 cannot handle this type of messages. The server will reply OK followed by a
2236 1 or 0 to tell the client which mode it is now operating in.
2238 If the command is not available on the server (i.e. it returns ERROR), or
2239 if the command has not been executed by the client, it should be assumed that
2240 this mode of operation is NOT in effect.
2242 The client may also send any value other than 0 or 1 to simply cause the
2243 server to output its current state without changing it.
2245 When asynchronous protocol mode is in effect, the client MUST handle any
2246 asynchronous messages as they arrive, before doing anything else.
2250 AUTO (AUTOcompletion of email addresses)
2252 The AUTO command is used by clients which want to request a list of email
2253 recipients whose names or email addresses match a partial string supplied by
2254 the client. This string is the only parameter passed to this command. The
2255 command will return ERROR if no user is logged in or if no address book could
2256 be found; otherwise, it returns LISTING_FOLLOWS followed by zero or more
2257 candidate recipients.
2261 SRCH (SeaRCH the message base)
2263 This command's implementation is incomplete and will be documented when it
2264 is finished. The current implementation accepts a search string as its sole
2265 argument, and will respond with LISTING_FOLLOWS followed by a list of
2266 messages (globally, not just in the current room) which contain ALL of the
2267 words in the search string. If the client desires an "exact phrase" match,
2268 it must then slow-search the text of each returned message for the exact
2269 string. The client should also compare the returned message numbers against
2270 those which actually exist in the room or rooms being searched. In
2271 particular, clients should avoid telling the user about messages which exist
2272 only in rooms to which the user does not have access.
2274 Again, keep in mind that this is a temporary implementation and is not
2275 guaranteed to continue to exist in this form.
2279 EUID (get message number using an EUID)}
2281 Returns the message number, if present, of the message in the current room
2282 which is indexed using the supplied EUID (exclusive message ID). There can be
2283 only one message in a room with any given EUID; if another message arrives
2284 with the same EUID, the existing one is replaced. This makes it possible to
2285 reference things like calendar items using an immutable URL that does not
2286 change even when the message number changes due to an update.
2288 The format of this command is: EUID <euid>
2290 If successful, EUID returns OK followed by a message number.
2291 If no message exists in the current room with the supplied EUID, the command
2292 returns ERROR+MESSAGE_NOT_FOUND.
2298 ASYNCHRONOUS MESSAGES
2299 ---------------------
2301 When the client protocol is operating in asynchronous mode (please refer to
2302 the writeup of the ASYN command above), the following messages may arrive at
2306 902 (instant message arriving)
2308 One or more instant messages have arrived for this client.