docs/server_tokens.txt

   1 This is a list of all tokens used by InspIRCd at the time of writing for server to server communication. Module coders may find this information
   2 useful when syncronising module data between different servers on the mesh. All tokens are case sensitive. Token names are given, however these are
   3 just a way of identifying the token, so if you hear developers talking of the 'CHGNAME token' you can be sure they are talking about the 'a' symbol.
   4
   5 Modules should try to avoid low ascii values. The only illegal token characters are ASCII 0, ASCII 13, and ASCII 10.
   6
   7 --------------------------------------------------------------------------------
   8 Compatibility Translations
   9
  10 InspIRCd will translate some RFC-style commands into mesh tokens, to maintain compatibility with some services packages. This only occurs if the
  11 server is a U-type link (see the tokens below for an explaination). The translated commands are:
  12
  13     * 433 - Translated to *
  14     * 432 - Translated to *
  15     * PING - Translated to *
  16     * NOTICE - Translated to V
  17     * PRIVMSG - Translatd to P
  18     * QUIT - Translated to Q
  19     * SQUIT - Translated to &
  20     * SVSMODE - Translated to m
  21     * SVS2MODE - Translated to m
  22     * MODE - Translated to m
  23     * KICK - Translated to k
  24     * KILL - Translated to K
  25     * SVSJOIN - Translated to J
  26
  27 --------------------------------------------------------------------------------
  28 Mesh Tokens
  29 --------------------------------------------------------------------------------
  30 AuthCookie: - Token
  31
  32 Syntax: - <authcookie> <servername> :<serverdesc>
  33
  34 When a server links into the mesh, it passes an Auth Cookie with its link request (in an S token). All other servers on the mesh respond by connecting
  35 back to the initiating server and issuing this token with a valid auth cookie. If the auth cookie is valid, the server accepts their mesh link,
  36 otherwise it rejects it.
  37 --------------------------------------------------------------------------------
  38 Inbound Server: S Token
  39
  40 Syntax: S <servername> <password> <port> :<description>
  41
  42 To initiate a mesh link, a server must connect to the port given in its <connect> tag, and issue this command. The port number is the port number the
  43 initiator is listening on for incoming server connections, it must be provided so that other servers in the mesh can link back and issue auth cookies.
  44 This is known as an 'active' connect, e.g. the initiator always uses the uppercase S token.
  45 --------------------------------------------------------------------------------
  46 Set version reply: v Token
  47
  48 Syntax: v <servername> <arbitary version string>
  49
  50 This token indicates the version string of a server on the mesh. Rather than send it each time it is requested, inspircd simply updates the mesh with
  51 its details either on bursting or if/when the data changes.
  52 --------------------------------------------------------------------------------
  53 Outbound Server: s Token
  54
  55 Syntax: s <servername> <password> <port> :<description>
  56
  57 Upon receiving a valid S token, if the password and servername are accepted, the receiving server replies with this token. It is a different token to
  58 S to avoid loops, and diffrentiate between initiator and receiver in the linking process. Once the initiator accepts the s token, the link is
  59 established and the burst begins.
  60 --------------------------------------------------------------------------------
  61 Non-Mesh Server: U Token
  62
  63 Syntax: U <servername> <password> :<description>
  64
  65 The U token is similar to the S token in that it initiates a server to server link, but it is designed primarily to link systems which are not able to
  66 become a fully meshed node, for example IRC Services packages. Upon a successful "U type" (as this is known) authentication, the other servers are
  67 informed of the introduction of the server via means of a H token, but will never connect back to it, they will route all messages via its uplink
  68 (messier than meshing it, but if the application is physically incapapable of joining the mesh, this is what must be done).
  69 --------------------------------------------------------------------------------
  70 Error: E Token
  71
  72 Syntax: E :<error message>
  73
  74 The E token indicates a protocol error, or invalid credentials etc, and immediately after an E token the connection is dropped. Failure to
  75 authenticate during a link is usually the cause of such tokens being sent.
  76 --------------------------------------------------------------------------------
  77 Begin Netburst: Y Token
  78
  79 Syntax: Y <time>
  80
  81 The Y token indicates the start of the netburst. The time value is used simply to correctly calculate the length of the burst (a similar token is sent
  82 at the end of the netburst which also contains a time, allowing the delta to match up correctly without clock syncronization)
  83 --------------------------------------------------------------------------------
  84 Set Auth Cookie: ~ Token
  85
  86 Syntax: ~ <new auth cookie>
  87
  88 The ~ token adds a new auth cookie to the servers allowed list. A server may permit multiple auth cookies at any one time to cope with resyncs.
  89 --------------------------------------------------------------------------------
  90 Begin Mesh: + Token
  91
  92 Syntax: + <servername> <portnumber> <authcookie>
  93
  94 When a server successfully initiates a connection, it sends this token out to all servers it already has in its mesh, which inform all the servers to
  95 connect back upon the servername given, on the port provided, using the given auth cookie. When this occurs all servers will send the "-" token to it
  96 upon connection.
  97 --------------------------------------------------------------------------------
  98 Send Routing Table: $ Token
  99
 100 Syntax: $ <source server> <reachable server> [<reachable server>...]
 101
 102 The $ token is a means of transmitting routing tables around the mesh. A server sends a list of servers it can reach directly. These tables are
 103 updated periodically. If a server cannot be reached directly, the ircd will scan the routing tables it has looking for an ircd which can reach it
 104 directly, and inform that server to route the message for it.
 105 --------------------------------------------------------------------------------
 106 SQUIT: & Token
 107
 108 Syntax: & <servername>
 109
 110 The & symbol is sent by a server when it leaves the mesh, or by servers which detect that other servers are completely unroutable. Upon receipt of an
 111 & symbol, the local server will instantly and recursively (according to its routing table) remove all users along that route.
 112 --------------------------------------------------------------------------------
 113 Reroute: R Token
 114
 115 Syntax: R <target-server> <anything>
 116
 117 This is the R or 'reroute' token, which indicates the <anything> provided should be instantly routed to <target-server> and only to <target-server>
 118 without processing it any further. Usually the server will receive these if it is the only available and direct route to <target-server>.
 119 --------------------------------------------------------------------------------
 120 PONG: ? Token
 121
 122 Syntax: ?
 123
 124 This token is used as a PONG, and has no parameters or responses. Only locally connected servers send pings (! token) to their peers, so no source is
 125 required.
 126 --------------------------------------------------------------------------------
 127 NOP: * or : Token
 128
 129 Syntax: *|:
 130
 131 This token is a NOP (No-Operation) message.
 132 --------------------------------------------------------------------------------
 133 USER: N Token
 134
 135 Syntax: N <time> <nick> <host> <displayed-host> <ident> <modes> <ipaddress> <server> :<GECOS>
 136
 137 This token introduces a new user into the network. The server specified by <server> is responsible for all local checking of that user's actions, such
 138 as channel joins, PINGs, QUITs etc. The <time> value is a unix epoch time, and the <ipaddress> field is the user's ip address in dotted decimal
 139 (1.2.3.4) form.
 140 --------------------------------------------------------------------------------
 141 CHGNAME: a Token
 142
 143 Syntax: a <nick> :<GECOS>
 144
 145 Change realname (GECOS) of a connected user.
 146 --------------------------------------------------------------------------------
 147 CHGHOST: b Token
 148
 149 Syntax: b <nick> :<displayed-host>
 150
 151 Change the displayed hostname of a connected user (vhost) to the one provided. No checking of this value is done, it is up to the local server to
 152 check this value before sending it out onto the mesh.
 153 --------------------------------------------------------------------------------
 154 TOPIC: t Token
 155
 156 Syntax: t <nick> <channel> :<topic>
 157
 158 This token indicates a user set or changed a channel topic. This token should not be used in netjoins, the T token (with a timestamp) should be used
 159 instead to check which topic 'wins'.
 160 --------------------------------------------------------------------------------
 161 INVITE: i Token
 162
 163 Syntax: i <nick> <source> <channel>
 164
 165 Invite a user to a channel. The user specified by <nick> is invited to channel <channel> by <source>.
 166 --------------------------------------------------------------------------------
 167 KICK: k Token
 168
 169 Syntax: k <source> <dest> <channel> :<reason>
 170
 171 This token indicates a user was kicked from a channel.
 172 --------------------------------------------------------------------------------
 173 NICK: n Token
 174
 175 Syntax: n <old nick> <new nick>
 176
 177 Indicates a nickchange.
 178 --------------------------------------------------------------------------------
 179 JOIN: J Token
 180
 181 Syntax: J <nick> [permissions]<channel> [[permissions]<channel>...]
 182
 183 This token indicates that a user is joining one or more channels, and indicates their privilages upon said channel. For example: "J MrFoo @#bar +#qux
 184 #baz".
 185 --------------------------------------------------------------------------------
 186 SERVERTOPIC: T Token
 187
 188 Syntax: T <settime> <nick> <channel> :<topic>
 189
 190 This token indicates the server set or changed a channel topic. This token should be used in netjoins to check which topic 'wins'.
 191 --------------------------------------------------------------------------------
 192 SERVERMODE: M Token
 193
 194 Syntax: M <target> <modes> [mode-parameters]
 195
 196 This token sets channel or user modes (depending upon the target given). The server sets the modes with this token as opposed to the 'm' token (lower
 197 case 'm') in which a user sets the modes.
 198 --------------------------------------------------------------------------------
 199 MODE: m Token
 200
 201 Syntax: m <source> <target> <modes> [mode-parameters]
 202
 203 This token sets channel or user modes (depending upon the target given). The user given as <source> sets the modes with this token. You cannot specify
 204 <source> as a server, for this you must use the M token instead.
 205 --------------------------------------------------------------------------------
 206 PRIVMSG: P Token
 207
 208 Syntax: P <source> <target> :<text>
 209
 210 The P token indicates a PRIVMSG between a user and a channel or other user. Target may be either a channel, or a user, source may only be a user.
 211 --------------------------------------------------------------------------------
 212 NOTICE: V Token
 213
 214 Syntax: V <source> <target> :<text>
 215
 216 The V token indicates a NOTICE between a user and a channel or other user. Target may be either a channel, or a user, source may only be a user.
 217
 218 As of 1.0 Beta 4, there are two special cases for the V token, in which the target may be one of:
 219
 220     * "*" - Specify a target of * to send the notice to all users upon that server.
 221     * "@*" - Specify this target to send to all opers upon that server and place the nickname of the originator within the body of the notice.
 222
 223 --------------------------------------------------------------------------------
 224 PART: L Token
 225
 226 Syntax: L <nick> <channel> :<reason>
 227
 228 This token indicates a user is leaving a channel with the given reason. The reason field is not optional, if there is no reason the field is just a
 229 colon (":").
 230 --------------------------------------------------------------------------------
 231 QUIT: Q Token
 232
 233 Syntax: Q <nick> :<reason>
 234
 235 The Q token indicates a user is quitting. The reason given is not optional, if none is specified the field contains just a colon symbol (":").
 236 --------------------------------------------------------------------------------
 237 Non-Mesh-Add: H Token
 238
 239 Syntax: H <servername>
 240
 241 Adds a U-Type server to the map without any other information. This is used to maintain links to services.
 242 --------------------------------------------------------------------------------
 243 KILL: K Token
 244
 245 Syntax: K <source> <nick> :<reason>
 246
 247 This token is the KILL token, which indicates a user is to be KILLed. Its use generates a QUIT token from the local server. Source may only be a user,
 248 not a server, as server kills are always handled locally.
 249 --------------------------------------------------------------------------------
 250 WALLOPS: @ Token
 251
 252 Syntax: @ <source> :<text>
 253
 254 This token sends a global WALLOPS. Source may only be a user, not a server.
 255 --------------------------------------------------------------------------------
 256 GLINE: # Token
 257
 258 Syntax: # <mask> <who-set-it> <time-set> <duration> :<reason>
 259
 260 Adds a permenant or timed G-Line to all servers on the mesh. The mask contains both the ident and hostname in ident@host form. <who-set-it> is
 261 arbitary text, and can be a user or a server.
 262 --------------------------------------------------------------------------------
 263 UNGLINE: . Token
 264
 265 Syntax: . <mask> <who>
 266
 267 Removes a G-Line from all servers on the mesh.
 268 --------------------------------------------------------------------------------
 269 QLINE: { Token
 270
 271 Syntax: { <mask> <who-set-it> <time-set> <duration> :<reason>
 272
 273 Adds a permenant or timed Q-Line to all servers on the mesh. The mask contains a nickname pattern. <who-set-it> is arbitary text, and can be a user or
 274 a server.
 275 --------------------------------------------------------------------------------
 276 UNQLINE: [ Token
 277
 278 Syntax: [ <nickmask> <who>
 279
 280 Removes a Q-Line from all servers on the mesh.
 281 --------------------------------------------------------------------------------
 282 ZLINE: } Token
 283
 284 Syntax: } <mask> <who-set-it> <time-set> <duration> :<reason>
 285
 286 Adds a permenant or timed Z-Line to all servers on the mesh. The mask contains an ip address mask. <who-set-it> is arbitary text, and can be a user or
 287 a server. If duration is 0, the ban is permenant.
 288 --------------------------------------------------------------------------------
 289 UNZLINE: ] Token
 290
 291 Syntax: ] <mask> <who>
 292
 293 Deletes a Z-Line from all servers on the mesh.
 294 --------------------------------------------------------------------------------
 295 OPERTYPE: | Token
 296
 297 Syntax: | <nick> <opertype>
 298
 299 Sets the opertype of an oper to the given string. This is done so that all ircds are aware of what the oper types of each oper is globally.
 300 Configuration of oper types and classes should match network wide.
 301 --------------------------------------------------------------------------------
 302 End-Netburst: F Token
 303
 304 Syntax: F <time>
 305
 306 This token indicates the end of the netburst, for more information see the 'Y' token.
 307 --------------------------------------------------------------------------------
 308 SERVICE1: / Token
 309
 310 Syntax: / <nickserv nick>
 311
 312 This token is used to indicate the name of a nickname service and is reserved for future use.
 313 --------------------------------------------------------------------------------
 314 End-Netburst-NM: f Token
 315
 316 Syntax: f <time>
 317
 318 This is identical in syntax and operation to the F token, except its use does not cause mesh links, as in the server is added in a disconnected state
 319 to force routing through its uplink. Used by services servers.
 320 --------------------------------------------------------------------------------
 321 Begin-Burst: X Token
 322
 323 Syntax: X <time>
 324
 325 This token when sent indicates that the server is ready to receive the other servers (recipient of this token) netburst data.
 326 --------------------------------------------------------------------------------
 327 Example Server Conversation
 328
 329 This is an example of a services server linking to an InspIRd server. During the 'conversation' two users connect, one of which is an oper, one of
 330 which is a normal user.
 331
 332 >> U services-dev.chatspike.net xxxxxxxx :Developer Services
 333 >> / NickServ
 334 >> N 1111691007 OperServ chatspike.net chatspike.net services-dev +oio 0.0.0.0 services-dev.chatspike.net :Operator Server
 335 >> N 1111691007 Global chatspike.net chatspike.net services-dev +oio 0.0.0.0 services-dev.chatspike.net :Global Noticer
 336 >> N 1111691007 NickServ chatspike.net chatspike.net services-dev +oo 0.0.0.0 services-dev.chatspike.net :Nickname Server
 337 >> N 1111691007 ChanServ chatspike.net chatspike.net services-dev +oo 0.0.0.0 services-dev.chatspike.net :Channel Server
 338 >> N 1111691007 MemoServ chatspike.net chatspike.net services-dev +oo 0.0.0.0 services-dev.chatspike.net :Memo Server
 339 << Y 1111691007
 340 << X 0
 341 << N 1111690997 [Brain] synapse.brainbox.winbot.co.uk netadmin.chatspike.net ~brain +xiwsogh 10.0.0.2 test.chatspike.net :Brain
 342 >> V NickServ [Brain] :This nickname is registered and protected.  If it is your nickname, type msg NickServ...
 343 >> V NickServ [Brain] :If you do not change within one minute, I will change your nickname.
 344 << | [Brain] NetAdmin
 345 << J [Brain] @#chatspike
 346 << M #chatspike +nt
 347 << H services-dev.chatspike.net
 348 << $ test.chatspike.net services-dev.chatspike.net
 349 << F 1111691007
 350 << $ test.chatspike.net services-dev.chatspike.net
 351 >> m ChanServ #chatspike +ntrl 99
 352 << P [Brain] NickServ :identify xxxxxxxx
 353 >> m NickServ [Brain] :+r
 354 >> V NickServ [Brain] :Password accepted -- you are now recognized.
 355 >> m ChanServ #chatspike +q [Brain]
 356 << n [Brain] [Brain
 357 >> m NickServ [Brain :-r
 358 << n [Brain [Brain]
 359 >> m NickServ [Brain] :+r
 360 << P [Brain] NickServ : identify xxxxxxx
 361 >> m NickServ [Brain] :+r
 362 >> V NickServ [Brain] :Password accepted -- you are now recognized.
 363 << N 1111691073 Om xxxxxx.gotadsl.co.uk ChatSpike-7A15BE0A.gotadsl.co.uk ~om +x 81.6.252.165 test.chatspike.net :Om
 364 << b Om ChatSpike-7A15BE0A.gotadsl.co.uk
 365 << m Om Om +x
 366 >> V NickServ Om :This nickname is registered and protected.  If it is your nickname, type...
 367 << m Om Om +wsi
 368 << J Om #chatspike
 369 << P Om NickServ :identify xxxx
 370 >> V NickServ Om :Password incorrect.
 371