mirror of
https://github.com/unrealircd/unrealircd.git
synced 2026-07-03 20:03:12 +02:00
- Services coders: Added support for ESVID. Instead of a number you can
now store a string (of max NICKLEN size) as service stamp. See protoctl.txt and serverprotocol.html in doc/technical for more information. Patch from nenotopia (#3966).
This commit is contained in:
Bram Matthys
@@ -106,6 +106,7 @@
|
||||
<li>NICKCHARS : Indicates the set of enabled nickchar options (see the regular documention for info about this).</li>
|
||||
<li>CHANMODES : (Not required to be sent) This is the same as the CHANMODES value in the 005 for client connections. Useful for autodetecting things like what modes are valid for ChanServ MLOCK, for example.</li>
|
||||
<li>CLK : Supports an extra field in NICK for sending the cloaked host (not vhost).</li>
|
||||
<li>ESVID : Supports arbitrary values instead of just numeric timestamps for the services identifier field.</li>
|
||||
</ul>
|
||||
<p>The syntax examples here follow the conventions for TOKEN and also NS in cases of server-only messages.</p>
|
||||
<h2><a name="S2_3"></a>2.3 SERVER - Server Negotiation</h2>
|
||||
@@ -168,11 +169,11 @@
|
||||
<h2><a name="S3_1"></a>3.1 NICK - User Introduction and Nick Change (TOKEN: &)</h2>
|
||||
<p><b>Syntax (nick change):</b> <tt>:<i>oldnick</i> & <i>newnick</i> :<i>timestamp</i></tt></p>
|
||||
<p>This format of the NICK message indicates an existing user is changing his or her nickname. If a collision occurs, see the section on Nick Collisions below. The timestamp is the new nickname's timestamp.</p>
|
||||
<p><b>Syntax (normal):</b> <tt>& <i>nick</i> <i>hopcount</i> <i>timestamp</i> <i>username</i> <i>hostname</i> <i>server</i> <i>servicestamp</i> :<i>realname</i></tt></p>
|
||||
<p><b>Syntax (NICKv2):</b> <tt>& <i>nick</i> <i>hopcount</i> <i>timestamp</i> <i>username</i> <i>hostname</i> <i>server</i> <i>servicestamp</i> <i>+usermodes</i> <i>virtualhost</i> :<i>realname</i></tt></p>
|
||||
<p><b>Syntax (NICKv2+CLK):</b> <tt>& <i>nick</i> <i>hopcount</i> <i>timestamp</i> <i>username</i> <i>hostname</i> <i>server</i> <i>servicestamp</i> <i>+usermodes</i> <i>virtualhost</i> <i>cloakhost</i> :<i>realname</i></tt>
|
||||
<p><b>Syntax (NICKv2+NICKIP):</b> <tt>& <i>nick</i> <i>hopcount</i> <i>timestamp</i> <i>username</i> <i>hostname</i> <i>server</i> <i>servicestamp</i> <i>+usermodes</i> <i>virtualhost</i> <i>nickipaddr</i> :<i>realname</i></tt></p>
|
||||
<p><b>Syntax (NICKv2+NICKIP+CLK):</b> <tt>& <i>nick</i> <i>hopcount</i> <i>timestamp</i> <i>username</i> <i>hostname</i> <i>server</i> <i>servicestamp</i> <i>+usermodes</i> <i>virtualhost</i> <i>cloakhost</i> <i>nickipaddr</i> :<i>realname</i></tt>
|
||||
<p><b>Syntax (normal):</b> <tt>& <i>nick</i> <i>hopcount</i> <i>timestamp</i> <i>username</i> <i>hostname</i> <i>server</i> <i>service-identifier-token</i> :<i>realname</i></tt></p>
|
||||
<p><b>Syntax (NICKv2):</b> <tt>& <i>nick</i> <i>hopcount</i> <i>timestamp</i> <i>username</i> <i>hostname</i> <i>server</i> <i>service-identifier-token</i> <i>+usermodes</i> <i>virtualhost</i> :<i>realname</i></tt></p>
|
||||
<p><b>Syntax (NICKv2+CLK):</b> <tt>& <i>nick</i> <i>hopcount</i> <i>timestamp</i> <i>username</i> <i>hostname</i> <i>server</i> <i>service-identifier-token</i> <i>+usermodes</i> <i>virtualhost</i> <i>cloakhost</i> :<i>realname</i></tt>
|
||||
<p><b>Syntax (NICKv2+NICKIP):</b> <tt>& <i>nick</i> <i>hopcount</i> <i>timestamp</i> <i>username</i> <i>hostname</i> <i>server</i> <i>service-identifier-token</i> <i>+usermodes</i> <i>virtualhost</i> <i>nickipaddr</i> :<i>realname</i></tt></p>
|
||||
<p><b>Syntax (NICKv2+NICKIP+CLK):</b> <tt>& <i>nick</i> <i>hopcount</i> <i>timestamp</i> <i>username</i> <i>hostname</i> <i>server</i> <i>service-identifier-token</i> <i>+usermodes</i> <i>virtualhost</i> <i>cloakhost</i> <i>nickipaddr</i> :<i>realname</i></tt>
|
||||
<p><b>Note:</b> Because each server normally does its own cloak generation, Unreal does not expect to receive NICK messages with the CLK info, so do not send it. It will send this info to a server it has received a PROTOCTL CLK from however.</p>
|
||||
<p>This format of the NICK message introduces a new user to the network. If PROTOCTL VHP is enabled, the user's cloaked host is put in the virtualhost field, otherwise it'll be * unless the user is +t. With the addition of CLK, VHP is no longer necessary for determining the cloak host.</p>
|
||||
<h3><a name="S3_1_1"></a>3.1.1 Nick Collisions</h3>
|
||||
@@ -306,7 +307,7 @@
|
||||
<p><b>Syntax (SVSMODE):</b> <tt>:<i>source</i> n <i>target</i> +<i>usermodes</i></tt></p>
|
||||
<p><b>Syntax (SVS2MODE):</b> <tt>:<i>source</i> v <i>target</i> +<i>usermodes</i></tt></p>
|
||||
<p>Judging by these commands alone, you'd think they are identical. Both commands force a usermode change to occur. This is typically used by services to set +r on a user who has successfully identified. They differ in that SVS2MODE also sends the mode change to the user, while SVSMODE does not (hidden mode change).</p>
|
||||
<p>SVSMODE and SVS2MODE also give special treatment to usermode +d. Rather than setting the deaf mode like you might expect, SVS(2)MODE +d allows services to change a user's services stamp (which is given in the NICK message). This could allow services to set the service stamp to an easily identifiable value that could then be used to say "hey, this person identified already". The syntax of this is: +d <i>newservicestamp</i> and can be combined with setting other usermodes as well. The deaf mode <b>can</b> be set by using +d without the service stamp parameter; however, in this case you <b>cannot</b> set the service stamp in the same SVS(2)MODE message.</p>
|
||||
<p>SVSMODE and SVS2MODE also give special treatment to usermode +d. Rather than setting the deaf mode like you might expect, SVS(2)MODE +d allows services to change a user's services stamp (which is given in the NICK message). This could allow services to set the service stamp to an easily identifiable value that could then be used to say "hey, this person identified already". The syntax of this is: +d <i>newservice-identifier-token</i> and can be combined with setting other usermodes as well. The deaf mode <b>can</b> be set by using +d without the service stamp parameter; however, in this case you <b>cannot</b> set the service stamp in the same SVS(2)MODE message.</p>
|
||||
<p><b>Note:</b> Do <b>NOT</b> use SVSMODE to remove IRCop status from a user. Use the SVSO command for that instead.</p>
|
||||
<p>Alternatively, target can name a channel. In this case, the mode change parameter can consist of a - character, followed by any or all of: b, e, I, q, a, o, h, or v. These characters cause the corresponding lists to be cleared of all entries. For example: SVSMODE #channel -b removes ALL bans from #channel, and SVSMODE #channel -qaohv turns ALL users on #channel into normal users (removes all owner, admin, op, halfop, and voice status). In this case, the uplink will acknowledge with a MODE listing the bans, etc that were removed.</p>
|
||||
<p>To completely clear a channel of all modes: MODE #channel -cfijklmnprstzACGMKLNOQRSTVu (plus any added by third-party module) followed by SVSMODE #channel -beIqaohv.</p>
|
||||
|
||||
Reference in New Issue
Block a user