wiki:P10_Token_Definitions
Last modified 13 years ago Last modified on 07/16/06 03:31:25 PM

​beware P10 Command Token Definitions

AC ACCOUNT


1 <target user numeric>
2 <account name>

sets a user's account name. they are sent by a service which supports ACCOUNT when someone logs in to it. if a user's account name field is set, the ircd knows the user is "logged in", and can have a "is logged in as" line in the whois reply. it can be set exactly once for a user; it can't be changed or unset.

  • account messages with an account name which is longer than the maximum (12 on undernet) are a protocol violation, they are not applied to the user.


  • the source of an account message may be any server, but not a user.


Return to P10 Feature List

Return to P10 Token List

AD ADMIN


1 <target server numeric>

remote administrative info request.

Return to Token List

LL ASLL


1 <server name mask>
2 <target server num>

remote AsLL (asymmetric link latency) request.

the server name mask is as the client entered it

Return to P10 Feature List

Return to P10 Token List

A AWAY


-1 [<away reason>]

a user can be marked as no longer away by having no away reason parameter, or with an away reason parameter of zero lenth. without the parameter is preferred.

Return to P10 Feature List

Return to P10 Token List

B BURST


1 <channel>
2 <timestamp>
3+ [<modes> [<mode extra parameters>]] [<users>] [<bans>]

the first 2 parameters are always the channel name and TS. the others are optional and may or may not exist. a parser may be able to parse modes, users, and bans in any sequence.

rules for generating a B message: there may be at most one <modes> parameter (and it's extra parameters), and it must be before any users or bans. there may be at most one <users> parameter and it must be after any modes and before any bans. there may be at most one <bans> parameter and it must be the last parameter of the B message.

  • if a B message is parsed, the TS is compared with the TS of the existing channel.


if incoming TS is older than the existing TS, all modes/ops/voices/bans on the existing channel are cleared before adding the new items of the burst to the channel. the topic and invites should be cleared as well.

if the existing TS is older than the incoming TS, all modes/ops/voices/bans from the B message are ignored and are not propagared, only the users.

if the timestamps are equal, the modes/bans/etc of the B are merged with the existing modes. if the incoming modes has a limit/ key and the existing modes has a limit/key, the greater one overrules ("a < b")

  • <modes> is a parameter of which the first character is a +, it is parsed as a channel mode change; there can be extra parameters after the mode parameter for key and limit


  • <bans> parameter: the first character is a %, then a space separated list of bans.


  • <users> parameter has no prefix char. it is a comma separated list, where each entry is either <nicknum> or <nicknum>:<modes>. if the colon+modes is present, it defines membership modes which apply to that entry, and to all following entries until there's another entry which defines modes. the modes paramer contains the membership mode chars ("o" for ops, etc). for sending, it must have the modes from high priority to low priority - "ov" is valid, "vo" is not.


note that ircu2.10.12 will have "op levels", which are a number at the end of the membership modes string (???)

in a generated burst message, the users must be sorted by the modes: first users w/o modes, then users with voice, then with op, then with op+voice: num,num:v,num:o,num:ov[[BR]] Note by niklasboelter: This is wrong for ircu (:
example B message:
A0 B #channel 1056560707 +ntslk 10 key A0AAB,A0AAC,ABAAA:v,ABAAB:o :%*!*@banned.host *!another@ban

Return to P10 Feature List

Return to P10 Token List

CM CLEARMODE


1 <channel>
2 <chars>

the channel modes which are in the chars parameter, are cleared. also, "o" clears all ops, "b" clears all bans, etc.
if the chars parameter is empty, it does not clear any modes (invalid). this differs from the client parser for clearmode, which fills in a default set of mode chars.

Return to P10 Feature List

Return to P10 Token List

CNOTICE CPRIVMSG


send private message or notice to user in channel where you have op or voice, to bypass target limiting.
note that they have short tokens in the table, but ircu never sends them on server-server links, instead it sends normal PRIVMSG/NOTICE.

Return to P10 Feature List

Return to P10 Token List

CO CONNECT

1 <server name/mask to connect to>
2 <port>
3 <target server numeric>

the message is sent to the target server.
if the port parameter is 0, the target server must use the port in the C:line or the default port.

Return to P10 Feature List

Return to P10 Token List

C CREATE


1 <channels>
2 <creationtime>

user creates channel - is the first to join and gets op

the <channels> parameter may be a comma separated list. ircu sends them.

if parsing a CREATE message and the channel already exists:

  • if the received TS is younger than the existing channel's TS, or more than TS_LAG_TIME (1 hour) old, send a deop back upstream with the existing channel's TS, and propagate the message as a JOIN


  • if the existing channel TS is younger, update the channel's TS. a deop for the existing user will soon be received.


  • if the existing channel TS is equal to MAGIC_REMOTE_JOIN_TS, update the channel's TS


  • if both TS are equal, both users keep op.


if a JOIN or CREATE message is sent/propagated, it always has the local server's idea of the channel's creationtime after parsing the received message; it may be different from the received TS parameter; it is if a CREATE causes a deop bounce

Return to P10 Feature List

Return to P10 Token List

DE DESTRUCT


1 <channel>
2 <TS>

destruct is going to be used in 2.10.12 where a channel is not destroyed when the last user leaves.
they are not sent earlier versions. current implementation is propagating the message to all other servers if the channel does not exist, and ignore if the channel exists (has users)

Return to P10 Feature List

Return to P10 Token List

DS DESYNCH


-1 <message>

desynch wallops. broadcasted to all servers on the net. they are used as "global server notice". ircu sends them as wallops to all users with mode +g set.

Return to P10 Feature List

Return to P10 Token List

EB/EA END_OF_BURST END_OF_BURST_ACK


no parameters

the END_OF_BURST message (EB token) must be the last message of a netburst. if it is received from a directly connected server which has not ended burst yet, the end of burst must be acknowledged by sending an EOB_ACK (EA token) message back.

Return to P10 Feature List

Return to P10 Token List

Y ERROR


can be sent to a server link before it's closed, to tell about the reason for closing the link. one must send either this, or a SQUIT message.

Return to P10 Feature List

Return to P10 Token List

GL GLINE


from U:lined server:

1 <target>
2 [!][-|+]<mask>
3 <duration>
-1 <reason>

from oper or normal server:

1 <target>
2 [!][-|+]<mask>
3 <duration>
4 <last modification TS>
-1 <reason>

  • <target> is either * (broadcast to all servers) or a server numeric.


  • for the <mask> parameter, the presence of the prefix means "force"; longer duration and wider mask possible. + means add/activate, - means remove/deactivate.


  • a G-line can be sent by an U:lined server, or by anything else. G-lines *not* sent by an U:lined server must have a "last modification time". it is used for proper resynch on burst:

any global G-lines with a last modification time are sent on burst; on parsing, an incoming G-lines with an earlier or equal lastmod time as the existing G-line is ignored. this is why those G-lines are deacticated rather than removed.

  • each server which receives a G-line is responsible for killing it's own clients, and generating QUIT messages for them.


  • mask may be a user@host mask, or a channel name. in the later case (mask starts with a # or &) it is a "BADCHAN". a BADCHAN prevents users from joining a channel with the same name (or matching, depending on the implementation)


Return to P10 Feature List

Return to P10 Token List

F INFO

1 <target server numeric>

remote "info" request

Return to P10 Feature List

Return to P10 Token List

I INVITE


1 <target nick>
2 <channel>

  • note that the target is a nickname, not a numeric.


Return to P10 Feature List

Return to P10 Token List

J JOIN

1 <channel>
2 [<creationtime>]

  • the <channel> parameter must not be a comma separated list.


  • the channel parameter may be "0", this means "leave all channels".


  • the creationtime parameter must be present if the channel parameter is not 0.


  • if the channel is created because of a JOIN, the channel's TS is set to the creationtime parameter. if the TS parameter is 0 or absent, ircu sets the channel TS to MAGIC_REMOTE_JOIN_TS, defined as 1270080000. JOIN messages w/o TS may be sent by ircu2.10.10 and earlier. JOIN messages for not existing channels can exist because of a JOIN crossing a PART which destroyed the channel.


Return to P10 Feature List

Return to P10 Token List

JU JUPE


1 <target>
2 [!][-|+]<server>
3 <duration>
4 <last modification TS>
-1 <reason>

JUPE prevents servers from connecting.

  • <target> is either * (broadcast to all servers) or a server numeric.


  • for the <mask> parameter, + means add/activate, - means remove/deactivate.


  • the "last modification time" is used for proper resynch on burst:

all global jupes are sent on burst; on parsing, an incoming jupe with an earlier or equal lastmod time as the existing jupe is ignored. this is why global jupes are deacticated rather than removed.

  • if a global jupe is received, any local jupe for the same server is removed before the global jupe is added.


Return to P10 Feature List

Return to P10 Token List

K KICK

1 <channel>
2 <target numeric>
-1 <reason>

The target's server must send a PART back upstream. this has to do with ircu's "zombie" behavior:

in ircu, if a user is kicked from the channel and the channel didn't become empty because of it, and the kick didn't come from the direction of the target's server, the user appears removed to other users, but internally the user stays in the channel as "zombie". it is then really removed when the "acknowledgement" PART is received. one reason for this is so mode changes done by the kick target just before he got kicked can apply because the server knows the user was in the channel with ops.

Return to P10 Feature List

Return to P10 Token List

D KILL


1 <target numeric>
-1 <info>

the info parameter should be in the format "path (reason)". when the kill message is generated, the path starts as the source host!nick - the nick is what appears in a kill quit reason like "Killed (nick (reason))". when a server receives a kill message from a server link, it adds the name of the directly linked server where the message came from, and a , to the begin of the path. so the path goes like "host!nick", "server1!host!nick" (on server 2), "server2!server1!host!nick" (on server 3), and so on. if a kill is generated by serivces, the "source host" can be for example the services server name.

Return to P10 Feature List

Return to P10 Token List

1 <target server numeric>
2 <server mask>

remote "links" request.

Return to P10 Feature List

Return to P10 Token List

LU LUSERS

1 <dummy param>
2 <target server numeric>

remote "lusers" request

the dummy parameter is passed on to the next server as is. in ircu it does nothing. on other ircd's (ircnet) it is a kind of "server name mask" parameter.

Return to P10 Feature List

Return to P10 Token List

M MODE


there are 2 kinds of mode messages: those which change user modes, and those which change channel modes.

* user mode change:

1 <target nick>
2+ <mode change>

the target parameter is a nickname (not a numeric). ircu requires the source prefix and the target to be the same user. source may also not be a server.

* channel mode change:

1 <channel>

2+ <mode change>
-1 [<TS>]

TS parameter:

a channel mode change may have an extra parameter, the channel creationtime. on receiving:

  • if the message has no TS, or TS = 0, or the TS equals the existing channel creationtime, the message is parsed always, and the existing TS is unchanged.


  • if it is present and younger than the existing channel creationtime, the server bounces the mode (sends a cancelling mode back upstream with the existing channel creationtime).


  • if the received TS is present and older than the existing creationtime, the mode is parsed and the existing creationtime is overwritten.


Return to P10 Feature List

Return to P10 Token List

MO MOTD

1 <target server numeric>

remote "motd" request

Return to P10 Feature List

Return to P10 Token List

E NAMES

1 <channel>
2 <target server numeric>

remote "names" request

Return to P10 Feature List

Return to P10 Token List

N NICK


nick can be used for 2 different purposes:

for introducing a new user:

1 <nickname>
2 <hops>
3 <TS>
4 <userid>
5 <host>
6 [<+modes>]
7+ [<mode parameters>]
-3 <base64 IP>
-2 <numeric>
-1 <fullname>

  • the source is the *server* which introduces the user.


  • the hops parameter is incremented before relaying the message to other servers; the first time the message is sent (by the source server), hops is equal to "1".


  • the TS is when the client last changed nick (also counting when the client connected)


  • the modes parameter (6) is optional. its presence can be detected by checking the first char of param 6 being a +.


  • the modes can have extra parameters, which then are parameters 7, 8, etc. they can only exist if the modes parameter is present.

known modes with parameters are:

+r, parameter is account name (ircu2.10.11)
+h, parameter is virtual user@host (asuka)

the modes with parameters must only be used in the above mentioned sequence, for compatibility with implementations which support +r but dont support +h (or use +h for something different)

  • the IP is the binary 32 bits network order IP of the user, represented using 6 base64 characters. for example 192.168.0.1 -> $c0a80001 -> DAqAAB.

an IPv6 IP is encoded as 4 dwords of 6 chars in a row and has a length of 24 characters. it is not supported by ircu yet without unofficial patches.


  • the numeric is the numeric of the new client, SSCCC format, the "SS" Part of the numeric must be the same as the source numeric.


an existing user changing nick:

1 <new nick>
2 <TS>

  • the source is the user who changes nick.


  • the TS is when the client last changed nick (also counting when the client connected)


  • the user's nickchange TS does not change if the nick changes only in case (is the same if compared case tolerant), then the existing/old TS is sent in the N message, not "now".


if there is already a user with the new nick and it is not the source of the N message, there is a nick collision.

Return to P10 Feature List

Return to P10 Token List

OM OPMODE


same parameters as MODE for channel mode changes

OPMODE forces channel mode changes; they are not bounced or denied.

the source should be an IRC operator.

Return to P10 Feature List

Return to P10 Token List

L PART


1 <channels>
-1 <reason>

  • the <channels> parameter may be a comma separated list
  • note about blocking a part if the user isn't in the channel: it must be propagated anyway if the user is in the channel as "zombie". a compatible implementation w/o zombies can be done by propagating them always.


Return to P10 Feature List

Return to P10 Token List

G PING


1 <source>
2 [<target server name>]

if the target server parameter is present, the ping is forwarded to the target server.
if the ping has reached the target server or the target server param is not present, the ping is replied with a pong.

the source parameter may be arbitrary text, it will be in the pong as is. but to have the reply of a remote ping come back properly, it needs to be the source.

Return to P10 Feature List

Return to P10 Token List

Z PONG


1 <source numeric of pong>
2 <target>

the target parameter is copied from the source parameter of the ping

Return to P10 Feature List

Return to P10 Token List

P/O PRIVMSG NOTICE


1 <target>
-1 <message>

send normal message, privmsg or notice.

  • the target must not be a comma separated list.


  • target can be: numeric, nick@server, #channel, $servermask.


  • nick@server on server-server protocol is how the target knows the source used "nick@server" and not just "nick" - for sending passwords to services.


  • #hostmask target (rfc1459) is not supported by ircu anymore (disallowed)


the message should be routed only to targets which need it: in case of a message to one user, it is sent only to the direction of the target user. a message to a channel is sent only to the directions which have non +d users in the channel.

Return to P10 Feature List

Return to P10 Token List

Q QUIT


-1 <reason>

a user removing itself from the network.

Return to P10 Feature List

Return to P10 Token List

RI RPING


there are 2 kinds of RPING messages

request to do RPING between 2 remote servers, traveling from an oper to the start server.

0 <requesting oper>
1 <pinged server name mask>
2 <target (start) server numeric>
3 <optional remark>

 RPING from start server to pinged server.

0 <start server>
1 <target (pinged) server numeric>
2 <requesting oper numeric>
3 <start timestamp, seconds>
4 <start timestamp, microseconds>
5 <optional remark>

RPING and RPONG allow an oper to measure IRC ping between 2 servers on the net, with milisecond resolution.

Return to P10 Feature List

Return to P10 Token List

RO RPONG


there are 2 kinds of RPONG messages

from pinged server to start server

0 <pinged server>
1 <start server name>
2 <requesting oper numeric>
3 <start timestamp, seconds>
4 <start timestamp, microseconds>
5 <optional remark>

 from start server to requesting oper

0 <start server>
1 <target (requesting oper) numeric>
2 <pinged server name>
3 <ping time, miliseconds>
4 <optional remark>


Return to P10 Feature List

Return to P10 Token List

S SERVER


1 <name of new server>
2 <hops>
3 <boot TS>
4 <link TS>
5 <protocol>
6 <numeric of new server><max client numeric>
7 <flags>
-1 <description of new server>

introducing a new server on the net or registering the connection to become server link.

in case of an existing server introducing another server (also during burst), the source prefix must be the local end of the new link.

  • <hops> is incremented each time before the message is propagated to the next server; it is "1" the first time the message is sent.


  • the <boot TS> Parameter is the server's boot TS if it is a SERVER message for registering a connection to become server link, and may be 0 for S messages in a netburst.


  • <protocol> is J## when the introduced server does not yet have ended burst, or when the message comes from an unregistered connection which is to become a server link. otherwise it is P##. the protocol number is "10" for P10 protocol, so the parameter is J10 or P10. for remote SERVER messages (received from an existing P10 server link), the number may be different(???)


  • <max clients numerics>: see [32]


  • the <flags> parameter is + (normal server), +h (hub hidden in /map) or +s (services). it may also be "0" for implementations which dont support the "flags" parameter.


Return to P10 Feature List

Return to P10 Token List

SE SETTIME


1 <timestamp>
1 [<target server numeric>]

settime sets the "clock" of one or all servers.

the target server numeric is present if an oper issued "/settime timestamp server". a settime w/o target server numeric is broadcast to all servers. a server with RELIABLE_CLOCK will change the timestamp parameter of any settime message to it's own idea about the TS.

Return to P10 Feature List

Return to P10 Token List

U SILENCE


1 <target>
2 [-]<mask>

adds or removes SILENCE masks.

target can be a client or server numeric, in which case the message is sent to the server of the target. it can be *, in which case the message is broadcasted to all servers. each server on the path which parses the message adds/removes the mask to the source's silence list.

the mask is always in nick!user@host format, such as *!*@*. the mask parameter can have a + prefix for adding, but it is not needed and ircu does not send it. the - prefix means remove the mask.

how it is used:

when you set a mask, it is not yet propagated to all servers. when a privmsg/notice message is sent, the first server on the path which has a matching silence mask blocks the message and sends a silence with the target being the one who sent the message; the next message is blocked at the sender's server. when a silence mask is removed, it is broadcasted with * target.

Return to P10 Feature List

Return to P10 Token List

SQ SQUIT


1 <target name>
2 <link TS>
-1 [<reason>]

remove a server from the network

  • the target is the name of the target server, without wildcards. it is not the numeric.


  • if the <Link TS> parameter is equal to the link timestamp of the target server, or equal to 0, it applies. otherwise the SQ message is ignored.


the message is propagated to all links except the link where the message came from, and the target server if it is directly linked:

if a SQ is to be sent to a directly linked target, the <target server> parameter will be the name of the local server. in this case, ircu sends link timestamp parameter 0.

Return to P10 Feature List

Return to P10 Token List

R STATS


1 <stats char>
2 <remote server numeric>
3 [<stats extra parameter>]

remote stats request


the extra parameter is for example the search mask for /stats G

Return to P10 Feature List

Return to P10 Token List

SJ SVSJOIN


1 <target numeric>
2 <channel>

cause someone else to join a channel. this command is not used on undernet. optional.
channel may be a comma separated list
servers propagate this message until it reaches the target server, which then broadcasts a normal join (J) for the target user.

Return to P10 Feature List

Return to P10 Token List

SN SVSNICK


1 <target numeric>
2 <new nick>

change someone else's nick. this command is not used on undernet. optional.

servers propagate this message until it reaches the target server, which then broadcasts a normal nickchange (N) for the target user. in case of a collision, the target server first kills the existing user.

Return to P10 Feature List

Return to P10 Token List

T TOPIC


1 <channel>
-3 [<channel creationtime>]
-2 [<topic changed time>]
-1 <topic>

  • undernet ircu does not accept topic messages from servers; it doesn't support topicburst. asuka does.


  • if the topic changed time parameter is present, and it is older than the existing topic changed time of the channel, ignore the message.


  • if the channel creationtime parameter is present, and it is younger than the creationtime of the existing channel, ignore the message


Return to P10 Feature List

Return to P10 Token List

TR TRACE


1 <target param>
2 <target server numeric>

trace path to target

the target param is what the user entered (nick or server mask). the message is routed to the target server numeric.

Return to P10 Feature List

Return to P10 Token List

UP UPING


1 <server name mask to ping>
2 <port>
3 <target server numeric>
4 <number of pings>

ircu UDP ping

  • the target server looks for a C:line for the server name mask.


Return to P10 Feature List

Return to P10 Token List

V VERSION


1 <target server numeric>

remote "version" request

Return to P10 Feature List

Return to P10 Token List

WC WALLCHOPS


1 <channel>
-1 <message>

wallchops message. sent to all channel operators in the channel.

  • the channel parameter may not be a comma separated list.


  • note that the @ prefix at the begin of the message is sent on server-server protocol.


Return to P10 Feature List

Return to P10 Token List

WA WALLOPS


-1 <message>

wallops message. sent to all operators with mode +w.

  • the * prefix is not sent on server-server protocol.


Return to P10 Feature List

Return to P10 Token List

WU WALLUSERS


-1 <message>

wallusers message. sent to all operators and users with mode +w.

  • the $ prefix is not sent on server-server protocol.


Return to P10 Feature List

Return to P10 Token List

WV WALLVOICES


wallvoices message. sent to all channel operators and voiced users in the channel.

1 <channel>
-1 <message>

  • the channel parameter may not be a comma separated list.


  • note that the + prefix at the begin of the message is sent on server-server protocol.


Return to P10 Feature List

Return to P10 Token List

W WHOIS


1 <target server num>
2 <search string>

remote whois request.
the search string parameter can be a single nick or nick mask with wildcards, and it can be a comma separated list.
Return to P10 Feature List

Return to P10 Token List

Taken from ​beware, thanks