Tip of the day: If you still have users on plaintext port 6667, consider enabling Strict Transport Security to gently move users to SSL/TLS on port 6697. |
Server protocol:SJOIN command
The SJOIN command is used to synchronize channel information between servers and for user joins.
Syntax
Syntax:
SJOIN timestamp channel [modes and parameters] :buffer
Where:
- timestamp: creation time of the channel
- channel: the channel name
- modes and parameters: the modes, including parameters, eg:
+lk 666 key
. If the channel has no modes set then this parameter will not exist. - buffer: the sjoin buffer, explained further down
Creation time and behavior
Similar to MODE
, different rules apply depending on how their_ts (the timestamp of the other server) compares to our_ts (the timestamp we have on record for the channel):
Timestamp | Description of the situation | What happens with the MODEs |
---|---|---|
their_ts == our_ts | The channel has the same creation timestamp on both sides of the link. This means that the channel was not recreated. There's no risk of split riding or channel takeover, the channel is more or less in a "safe state". | The IRC server will merge modes. So any modes set only on one side of the link will be added to the other side. This is true for channel modes (eg: +si), bans/exempts/invex (+beI) and privileges (+vhoaq). |
their_ts < our_ts | The other server holds the original channel and our channel was apparently (re)created later. They win. | We will remove all modes on our side. So all channel modes (eg: -si), all lists (-beI) and privileges (-vhoaq). |
their_ts > our_ts | We hold the original channel and their channel was (re)created later. We are the winner. | We simply ignore and do not set their modes. They will take care of removing their own modes. |
So, the channel creation time decides what to do with the contents of the SJOIN command.
SJOIN buffer
Channel members
A simple SJOIN for three users in a channel that only has modes +nt set would look like this:
SJOIN 1548605089 #test +nt :One Two @Three
Upon receipt of such a message, the IRC server will send the following to it's locally connected users:
*** One joins #test *** Two joins #test *** Three joins #test *** other.server sets modes: +o Three
In the SJOIN buffer each item is separated by spaces. The nick can be prefixed with the following characters to give the user certain channel privileges:
Character | Description | Mode |
---|---|---|
+
|
Voice | +v |
%
|
Halfop | +h |
@
|
Op | +o |
~
|
Admin | +a |
*
|
Owner | +q |
IMPORTANT: As you can see, the characters for +a and +q differ from the ones you see in NAMES as PREFIX on IRC. For example, ~
in SJOIN means +a, while on regular IRC it means +q. Do not mix them up!
Multiple characters can be combined if the user holds multiple privileges, eg +vo for user Ein will be communicated as +@Ein
Mode lists
The SJOIN command is also used to communicate +b (bans), +e (ban exempts) and +I (invite exceptions). For example:
SJOIN 1548605089 #test +nt :&[email protected] "[email protected] '[email protected]
The first letter of each item tells the type of the list:
Character | Description | Mode |
---|---|---|
&
|
Ban | +b |
"
|
Ban exemption | +e |
'
|
Invite exception | +I |
Extended information
For lists it is possible to prefix the buffer with additional information to communicate when and who set the +beI. This requires SJSBY to be enabled via PROTOCTL
Example without extended information:
SJOIN 1548605089 #test +nt :&[email protected]
Example with extended information:
SJOIN 1548605089 #test +nt :<1548605202,UserOne>&[email protected]
So, the <setat,setby>
prefix is used to communicate this information. Being <1548605202,UserOne>
in the example.
The server would still show this as:
*** some.server.net sets mode: +b [email protected]
...but if the user queries the list at a later point by doing /MODE #channel b
then it will show the user and time of the ban:
#test [email protected] set by UserOne (Sun Jan 27 17:06:42 2019) #test End of Channel Ban List