summaryrefslogtreecommitdiff
path: root/docs/server_tokens.txt
diff options
context:
space:
mode:
Diffstat (limited to 'docs/server_tokens.txt')
-rw-r--r--docs/server_tokens.txt402
1 files changed, 371 insertions, 31 deletions
diff --git a/docs/server_tokens.txt b/docs/server_tokens.txt
index 3320602c7..8bebb0579 100644
--- a/docs/server_tokens.txt
+++ b/docs/server_tokens.txt
@@ -1,31 +1,371 @@
-This is a list of datagram types supported by this version of
-InspIRCd. The datagrams must be encapsulated in a valid link
-packet, and except for those prefixed with a *, a pseudo-session
-must be established along which secure commands may pass.
-
-S * Active server connect
-s * Passive server connect (response to S)
-O * Exchange session key
-E * Error response
-? Ping
-! Pong
-* No Operation
-Y Begin netburst
-N Introduce new client
-n Client nickchange
-t Change channel topic
-i Invite user
-k Kick user
-J Join a user to one or more channels
-T Server topic change
-M Server mode change
-m User mode change
-P PRIVMSG
-V NOTICE
-L User leaving a channel
-Q User disconnect
-F End netburst
-K Remote kill
-@ WALLOPS
-a Change displayed host
-b Change GECOS
+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
+useful when syncronising module data between different servers on the mesh. All tokens are case sensitive. Token names are given, however these are
+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.
+
+Modules should try to avoid low ascii values. The only illegal token characters are ASCII 0, ASCII 13, and ASCII 10.
+
+--------------------------------------------------------------------------------
+Compatibility Translations
+
+InspIRCd will translate some RFC-style commands into mesh tokens, to maintain compatibility with some services packages. This only occurs if the
+server is a U-type link (see the tokens below for an explaination). The translated commands are:
+
+ * 433 - Translated to *
+ * 432 - Translated to *
+ * PING - Translated to *
+ * NOTICE - Translated to V
+ * PRIVMSG - Translatd to P
+ * QUIT - Translated to Q
+ * SQUIT - Translated to &
+ * SVSMODE - Translated to m
+ * SVS2MODE - Translated to m
+ * MODE - Translated to m
+ * KICK - Translated to k
+ * KILL - Translated to K
+ * SVSJOIN - Translated to J
+
+--------------------------------------------------------------------------------
+Mesh Tokens
+--------------------------------------------------------------------------------
+AuthCookie: - Token
+
+Syntax: - <authcookie> <servername> :<serverdesc>
+
+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
+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,
+otherwise it rejects it.
+--------------------------------------------------------------------------------
+Inbound Server: S Token
+
+Syntax: S <servername> <password> <port> :<description>
+
+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
+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.
+This is known as an 'active' connect, e.g. the initiator always uses the uppercase S token.
+--------------------------------------------------------------------------------
+Set version reply: v Token
+
+Syntax: v <servername> <arbitary version string>
+
+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
+its details either on bursting or if/when the data changes.
+--------------------------------------------------------------------------------
+Outbound Server: s Token
+
+Syntax: s <servername> <password> <port> :<description>
+
+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
+S to avoid loops, and diffrentiate between initiator and receiver in the linking process. Once the initiator accepts the s token, the link is
+established and the burst begins.
+--------------------------------------------------------------------------------
+Non-Mesh Server: U Token
+
+Syntax: U <servername> <password> :<description>
+
+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
+become a fully meshed node, for example IRC Services packages. Upon a successful "U type" (as this is known) authentication, the other servers are
+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
+(messier than meshing it, but if the application is physically incapapable of joining the mesh, this is what must be done).
+--------------------------------------------------------------------------------
+Error: E Token
+
+Syntax: E :<error message>
+
+The E token indicates a protocol error, or invalid credentials etc, and immediately after an E token the connection is dropped. Failure to
+authenticate during a link is usually the cause of such tokens being sent.
+--------------------------------------------------------------------------------
+Begin Netburst: Y Token
+
+Syntax: Y <time>
+
+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
+at the end of the netburst which also contains a time, allowing the delta to match up correctly without clock syncronization)
+--------------------------------------------------------------------------------
+Set Auth Cookie: ~ Token
+
+Syntax: ~ <new auth cookie>
+
+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.
+--------------------------------------------------------------------------------
+Begin Mesh: + Token
+
+Syntax: + <servername> <portnumber> <authcookie>
+
+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
+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
+upon connection.
+--------------------------------------------------------------------------------
+Send Routing Table: $ Token
+
+Syntax: $ <source server> <reachable server> [<reachable server>...]
+
+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
+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
+directly, and inform that server to route the message for it.
+--------------------------------------------------------------------------------
+SQUIT: & Token
+
+Syntax: & <servername>
+
+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
+& symbol, the local server will instantly and recursively (according to its routing table) remove all users along that route.
+--------------------------------------------------------------------------------
+Reroute: R Token
+
+Syntax: R <target-server> <anything>
+
+This is the R or 'reroute' token, which indicates the <anything> provided should be instantly routed to <target-server> and only to <target-server>
+without processing it any further. Usually the server will receive these if it is the only available and direct route to <target-server>.
+--------------------------------------------------------------------------------
+PONG: ? Token
+
+Syntax: ?
+
+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
+required.
+--------------------------------------------------------------------------------
+NOP: * or : Token
+
+Syntax: *|:
+
+This token is a NOP (No-Operation) message.
+--------------------------------------------------------------------------------
+USER: N Token
+
+Syntax: N <time> <nick> <host> <displayed-host> <ident> <modes> <ipaddress> <server> :<GECOS>
+
+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
+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
+(1.2.3.4) form.
+--------------------------------------------------------------------------------
+CHGNAME: a Token
+
+Syntax: a <nick> :<GECOS>
+
+Change realname (GECOS) of a connected user.
+--------------------------------------------------------------------------------
+CHGHOST: b Token
+
+Syntax: b <nick> :<displayed-host>
+
+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
+check this value before sending it out onto the mesh.
+--------------------------------------------------------------------------------
+TOPIC: t Token
+
+Syntax: t <nick> <channel> :<topic>
+
+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
+instead to check which topic 'wins'.
+--------------------------------------------------------------------------------
+INVITE: i Token
+
+Syntax: i <nick> <source> <channel>
+
+Invite a user to a channel. The user specified by <nick> is invited to channel <channel> by <source>.
+--------------------------------------------------------------------------------
+KICK: k Token
+
+Syntax: k <source> <dest> <channel> :<reason>
+
+This token indicates a user was kicked from a channel.
+--------------------------------------------------------------------------------
+NICK: n Token
+
+Syntax: n <old nick> <new nick>
+
+Indicates a nickchange.
+--------------------------------------------------------------------------------
+JOIN: J Token
+
+Syntax: J <nick> [permissions]<channel> [[permissions]<channel>...]
+
+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
+#baz".
+--------------------------------------------------------------------------------
+SERVERTOPIC: T Token
+
+Syntax: T <settime> <nick> <channel> :<topic>
+
+This token indicates the server set or changed a channel topic. This token should be used in netjoins to check which topic 'wins'.
+--------------------------------------------------------------------------------
+SERVERMODE: M Token
+
+Syntax: M <target> <modes> [mode-parameters]
+
+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
+case 'm') in which a user sets the modes.
+--------------------------------------------------------------------------------
+MODE: m Token
+
+Syntax: m <source> <target> <modes> [mode-parameters]
+
+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
+<source> as a server, for this you must use the M token instead.
+--------------------------------------------------------------------------------
+PRIVMSG: P Token
+
+Syntax: P <source> <target> :<text>
+
+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.
+--------------------------------------------------------------------------------
+NOTICE: V Token
+
+Syntax: V <source> <target> :<text>
+
+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.
+
+As of 1.0 Beta 4, there are two special cases for the V token, in which the target may be one of:
+
+ * "*" - Specify a target of * to send the notice to all users upon that server.
+ * "@*" - Specify this target to send to all opers upon that server and place the nickname of the originator within the body of the notice.
+
+--------------------------------------------------------------------------------
+PART: L Token
+
+Syntax: L <nick> <channel> :<reason>
+
+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
+colon (":").
+--------------------------------------------------------------------------------
+QUIT: Q Token
+
+Syntax: Q <nick> :<reason>
+
+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 (":").
+--------------------------------------------------------------------------------
+Non-Mesh-Add: H Token
+
+Syntax: H <servername>
+
+Adds a U-Type server to the map without any other information. This is used to maintain links to services.
+--------------------------------------------------------------------------------
+KILL: K Token
+
+Syntax: K <source> <nick> :<reason>
+
+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,
+not a server, as server kills are always handled locally.
+--------------------------------------------------------------------------------
+WALLOPS: @ Token
+
+Syntax: @ <source> :<text>
+
+This token sends a global WALLOPS. Source may only be a user, not a server.
+--------------------------------------------------------------------------------
+GLINE: # Token
+
+Syntax: # <mask> <who-set-it> <time-set> <duration> :<reason>
+
+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
+arbitary text, and can be a user or a server.
+--------------------------------------------------------------------------------
+UNGLINE: . Token
+
+Syntax: . <mask> <who>
+
+Removes a G-Line from all servers on the mesh.
+--------------------------------------------------------------------------------
+QLINE: { Token
+
+Syntax: { <mask> <who-set-it> <time-set> <duration> :<reason>
+
+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
+a server.
+--------------------------------------------------------------------------------
+UNQLINE: [ Token
+
+Syntax: [ <nickmask> <who>
+
+Removes a Q-Line from all servers on the mesh.
+--------------------------------------------------------------------------------
+ZLINE: } Token
+
+Syntax: } <mask> <who-set-it> <time-set> <duration> :<reason>
+
+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
+a server. If duration is 0, the ban is permenant.
+--------------------------------------------------------------------------------
+UNZLINE: ] Token
+
+Syntax: ] <mask> <who>
+
+Deletes a Z-Line from all servers on the mesh.
+--------------------------------------------------------------------------------
+OPERTYPE: | Token
+
+Syntax: | <nick> <opertype>
+
+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.
+Configuration of oper types and classes should match network wide.
+--------------------------------------------------------------------------------
+End-Netburst: F Token
+
+Syntax: F <time>
+
+This token indicates the end of the netburst, for more information see the 'Y' token.
+--------------------------------------------------------------------------------
+SERVICE1: / Token
+
+Syntax: / <nickserv nick>
+
+This token is used to indicate the name of a nickname service and is reserved for future use.
+--------------------------------------------------------------------------------
+End-Netburst-NM: f Token
+
+Syntax: f <time>
+
+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
+to force routing through its uplink. Used by services servers.
+--------------------------------------------------------------------------------
+Begin-Burst: X Token
+
+Syntax: X <time>
+
+This token when sent indicates that the server is ready to receive the other servers (recipient of this token) netburst data.
+--------------------------------------------------------------------------------
+Example Server Conversation
+
+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
+which is a normal user.
+
+>> U services-dev.chatspike.net xxxxxxxx :Developer Services
+>> / NickServ
+>> N 1111691007 OperServ chatspike.net chatspike.net services-dev +oio 0.0.0.0 services-dev.chatspike.net :Operator Server
+>> N 1111691007 Global chatspike.net chatspike.net services-dev +oio 0.0.0.0 services-dev.chatspike.net :Global Noticer
+>> N 1111691007 NickServ chatspike.net chatspike.net services-dev +oo 0.0.0.0 services-dev.chatspike.net :Nickname Server
+>> N 1111691007 ChanServ chatspike.net chatspike.net services-dev +oo 0.0.0.0 services-dev.chatspike.net :Channel Server
+>> N 1111691007 MemoServ chatspike.net chatspike.net services-dev +oo 0.0.0.0 services-dev.chatspike.net :Memo Server
+<< Y 1111691007
+<< X 0
+<< N 1111690997 [Brain] synapse.brainbox.winbot.co.uk netadmin.chatspike.net ~brain +xiwsogh 10.0.0.2 test.chatspike.net :Brain
+>> V NickServ [Brain] :This nickname is registered and protected. If it is your nickname, type msg NickServ...
+>> V NickServ [Brain] :If you do not change within one minute, I will change your nickname.
+<< | [Brain] NetAdmin
+<< J [Brain] @#chatspike
+<< M #chatspike +nt
+<< H services-dev.chatspike.net
+<< $ test.chatspike.net services-dev.chatspike.net
+<< F 1111691007
+<< $ test.chatspike.net services-dev.chatspike.net
+>> m ChanServ #chatspike +ntrl 99
+<< P [Brain] NickServ :identify xxxxxxxx
+>> m NickServ [Brain] :+r
+>> V NickServ [Brain] :Password accepted -- you are now recognized.
+>> m ChanServ #chatspike +q [Brain]
+<< n [Brain] [Brain
+>> m NickServ [Brain :-r
+<< n [Brain [Brain]
+>> m NickServ [Brain] :+r
+<< P [Brain] NickServ : identify xxxxxxx
+>> m NickServ [Brain] :+r
+>> V NickServ [Brain] :Password accepted -- you are now recognized.
+<< N 1111691073 Om xxxxxx.gotadsl.co.uk ChatSpike-7A15BE0A.gotadsl.co.uk ~om +x 81.6.252.165 test.chatspike.net :Om
+<< b Om ChatSpike-7A15BE0A.gotadsl.co.uk
+<< m Om Om +x
+>> V NickServ Om :This nickname is registered and protected. If it is your nickname, type...
+<< m Om Om +wsi
+<< J Om #chatspike
+<< P Om NickServ :identify xxxx
+>> V NickServ Om :Password incorrect.
+