mirror of
https://github.com/unrealircd/unrealircd.git
synced 2026-07-01 22:06:37 +02:00
Bram Matthys
2f8cb55e47
Added swhois_add / swhois_delete functions which also take care of broadcasting New remove_oper_privileges() function, will move the rest to use this (svsnoop svsmode etc) Not finished yet...
146 lines
8.9 KiB
Plaintext
146 lines
8.9 KiB
Plaintext
PROTOCTL Documentation (c) 2002 codemastr (Dominick Meglio) [codemastr@unrealircd.com]
|
|
(As of Unreal3.2-beta11)
|
|
|
|
The PROTOCTL command allows servers to negotiate protocol specific features when a link
|
|
occurs. The PROTOCTL command is sent during a link before the SERVER and PASS commands. The
|
|
command contains tokens that list what protocols the server supports.
|
|
|
|
PROTOCTL SPACE <token> SPACE ...
|
|
|
|
UnrealIRCd supports several tokens that add additional protocol support to the server. A
|
|
list of all supported tokens and their function listed below.
|
|
|
|
Token Description
|
|
------------------------------------------------------------------------------------------------
|
|
NOQUIT Informs the server it need not send out a QUIT for each user on the server
|
|
when an SQUIT occurs. Instead an SQUIT is sent out for each server that has
|
|
been disconnected from the network and the server can then assume all users
|
|
that were on those servers have left as well.
|
|
|
|
TOKEN Informs the server that it may send "tokenized commands", that is a shortened
|
|
name for the commands. This allows the server to save bandwidth by sending
|
|
less information to other servers. See doc/technical/token.txt for a list of
|
|
all commands and their respective token.
|
|
|
|
NICKv2 Notifies the server that it supports the extended NICK command (version 2),
|
|
this command allows the server to specify more information in the NICK
|
|
command rather than having to send out a NICK, MODE, and CHGHOST
|
|
command. This token only affects a NICK command introducing a client, not one
|
|
in which a client is changing his/her nickname. The format for a NICKv2 NICK
|
|
command is:
|
|
|
|
:<sender> NICK <nickname> <hops> <TS> <username> <host> <server>
|
|
<servicestamp> <umodes> <vhost> :<info>
|
|
|
|
If the user has no modes set the umodes parameter is a +, if the user has no
|
|
vhost set the vhost parameter is an *.
|
|
|
|
SJOIN SJOIN is an obsolete token that is only supported for backwards
|
|
compatibility. It should not be used.
|
|
|
|
SJOIN2 SJOIN2 is an obsolete token that is only supported for backwards
|
|
compatibility. It should not be used.
|
|
|
|
UMODE2 Informs the server that support for the UMODE2 command exists. The UMODE2
|
|
command is a shortened form of the MODE command but only applys to
|
|
usermodes. In a normal MODE command, when applied to usermodes, the nickname
|
|
is specified two times. Both as the sender prefix and as the first parameter,
|
|
UMODE2 solves this problem in order to save bandwidth, the format for UMODE2
|
|
is as follows:
|
|
|
|
:<sender> UMODE2 <modes>
|
|
|
|
VL Notifies the server that Vline information is included in the info field of
|
|
the SERVER command. Vline information consists of the protocol number of the
|
|
server and compiletime options supported. This allows denial of a server
|
|
based on version and/or features supported. The VL information is passed only
|
|
during connection, it is not filtered to other servers on the network, only
|
|
the uplink. The syntax for a VL supporting SERVER command is:
|
|
|
|
SERVER <servername> <hops> :U<protocol>-<versionflags> <info>
|
|
|
|
If an * appears for either protocol and/or versionflags no Vline checking is
|
|
done, this is often used by services programs where support for all versions
|
|
is desired. See doc/technical/vl.txt for a list of version flags and protocol
|
|
numbers.
|
|
|
|
SJ3 Notifies the server that the SJOIN command with SJ3 syntax is
|
|
supported. SJOIN is used at link time to inform servers about the channels on
|
|
the server. It is a combination of the JOIN commands, and MODE commands
|
|
associated with distribution of channel information. The syntax for the SJOIN
|
|
command with SJ3 syntax is:
|
|
|
|
:<sender> SJOIN <ts> <chname> [<modes>] [<mode para> ...] :<[[*~@%+]member] ...
|
|
[&"ban/except] ...>
|
|
|
|
The ts parameter is the time at which the channel, chname, was created. The
|
|
modes parameter is only included if modes are set, if not modes and mode para
|
|
are excluded. If modes exists and modes requiring parameters (+klLf) are set,
|
|
one mode para parameter is included for each value. The last parameter
|
|
specifies a list of channel members and the channel ban and except list. The
|
|
members are listed with the prefixes they have. * = +q, ~ = +a, @ = +o, % =
|
|
+h, + = +v. If no prefix is specified for the member then the user is a
|
|
normal user. The & prefix is used to denote a +b, and the " prefix denotes a
|
|
+e. It is important that if a & or " is encountered that you do not continue
|
|
to check that entry for other prefixes as a ban/except may contain *~@
|
|
characters which will intefere with prefixes.
|
|
|
|
When synching, if ts lower than the local value, the information supplied by
|
|
the remote server replaces the local (ie remove local +ohv that are not
|
|
recorded on the remote server). The opposite is true when the ts is
|
|
higher. Bans/excepts do not apply to the previous rule. If the ts is the
|
|
same, information is merged therefore the modes from both servers are added
|
|
together. If +l is set and both servers have different values, the highest is
|
|
choosen, for +f the highest of each param, N:M is chosen, and if one server
|
|
has * set, then it is included. For +k and +L the "highest" in a string
|
|
comparison is used.
|
|
|
|
TKLEXT This allows 10 instead of 8 parameters in TKL's for spamfilter, see s_kline.c
|
|
function m_tkl for more info on this (added in 3.2RC2).
|
|
|
|
TKLEXT2 This allows 11 instead of 8 or 10 parameters in TKL's for spamfilter,
|
|
see s_kline.c function m_tkl for more info on this (added in 3.4-alpha3).
|
|
Note that TKLEXT2 implies TKLEXT support as well.
|
|
|
|
NICKIP This token indicates that a (standard) base64 encoded IP address is included
|
|
in the NICK command. The IP is in binary network byte order formated and
|
|
encoded using the standard base64 algorithm. '*' is used if no IP is available.
|
|
|
|
NICKCHARS This specifies a list of language characters that are allowed in nicks.
|
|
USMARC codes are used, with a suffix if needed. See src/charsys.c for the full
|
|
list (ctrl+f, static LangList) of possible languages (2nd column).
|
|
The items in the list sent as NICKCHARS=.. must always be sorted.
|
|
If a server sends NICKCHARS= and if the remote parameters do not match the
|
|
charsets in use locally, then the server link is rejected.
|
|
|
|
CHANMODES Like CHANMODES from the 005 numeric. Useful to see which channel modes are
|
|
supported/used, and can also be used to properly eat parameters in parameter
|
|
modes in the MODE command (for eg: +jk 1:1 a).
|
|
|
|
EAUTH Early Authorization. This makes it possible for servers to authenticate each
|
|
other before the regular SERVER command. Needs to be done prior to using the
|
|
SERVERS token, and possibly other tokens or commands in the future. Hence,
|
|
is recommended to be sent as first (or early) PROTOCTL token. Note also that
|
|
the PASS command should be sent prior to this PROTOCTL token.
|
|
EAUTH=my.server.name[,options]
|
|
|
|
SID This token indicates that the peer server supports UIDs and SIDs in messages,
|
|
as well as provides the SID of the direct peer.
|
|
|
|
ESVID This token indicates that the traditional services stamp value may take any
|
|
arbitrary value for the SVID field, such as an account name or other unique
|
|
identifier, including a traditional timestamp value.
|
|
|
|
TS Upon linking newer servers send TS=<ts> where <ts> is the current unix
|
|
timestamp. This way a link can be rejected if the difference between the
|
|
clock of two servers is too large (since such a difference would lead to
|
|
serious issues).
|
|
|
|
EXTSWHOIS Extended SWHOIS. This allows setting multiple 'swhois' titles for /WHOIS.
|
|
It also allows other servers to see what/who set the 'swhois' and to
|
|
specifiy a 'priority' which is used for the swhois display order in /WHOIS.
|
|
Instead of: SWHOIS <nick> :<swhois title>
|
|
This will send: SWHOIS <nick> <+|-> <setby> <priority> :<swhois title>
|
|
Add example: SWHOIS someuser + vhost 0 :is particularly helpful
|
|
Del example: SWHOIS someuser + vhost 0 :is particularly helpful
|