3. Practical implementations of Channel modes and User modes in freenode

Feb 23, 2017 · 10 min read

Hi everyone..!!! I think you have enjoyed the previous blog’s stories related to IRC freenode and all the related stuffs like channel modes in detail with practical implementations through the clients and with the proper examples of each mode. Now its time to proceed further and talk about the remaining channel modes and all the user modes in freenode so that we can get full command to manage our channels and the nicks in the IRC network.

In, the previous blog, we discussed about the channel mode +b (ban) and its two subparts simple bans and IP bans. Now we will continue with its next sub part i.e. Extended bans in this blog and then all the remaining channel modes and the user modes will be discussed. So lets begin..!!

19.3 Extended Bans

Normally Bans, quiets and invite and ban exemptions conventionally accept the format nick!user@host. Another format on the freenode, known as "extban", is also accepted. It has the general format $X or $X:data where data refers to the parameters. Some of the extbans do not take the parameters while others do.

19.3.1 $a (accounts logged in)

This extended mode will prevent all the users to speak in the channel who are logged in the channel at that very time. The syntax for this is command is /mode #channelname +b $a.

I used the same command to my channel #jkl and it blocked the logged in user ‘kashif’ to send in the channel because there was only one user other than operator at that time but when another user ‘ijaz’ joined the channel #jkl and spoke in the channel and he was not prevented.

So, we can say that extban $a blocks all the logged in users to speak in the channel who are logged in before this command. The users logged in after this command will not effect from this. The results are shown in the figures below where ‘kashif’ is the logged in user before and ‘ijaz’ is the logged in user after the command.

Figure 67: Mode +b with $a(logged in users) is set to the #jkl

**Figure 68: Logged in user ‘kashif’ cannot send to the channel due to $a**

**Figure 69: External user ‘ijaz’ joined the channel and speaks in the channel even in $a mode**

19.3.2 $j (cannot join other channel)

This mode takes a channel name in its parameter and matches any user who is banned from that channel will ban those users from the current channel. The command for this mode is:

/mode #current_channelname +b $j: otherchannel.

I used the same command in order to see its effects on the users. Firstly, I banned the user ‘ijaz’ from my other channel #nkl and then I used the command /mode #jkl +b $j : #nkl where #jkl is my current channel and I want to ban all those users who are already banned from joining and speaking in the channel #nkl. So this will ban ‘ijaz’ from speaking in my current channel #jkl.

Below figures demonstrate the mentioned example.

Figure 70: User ‘ijaz’ is banned from joining the channel #nkl

Figure 71: User ‘ijaz’ cannot join the channel #nkl because of +b

Figure 72: Extban $j is set on the channel #jkl with parameter #nkl

**Figure 73: User ‘ijaz’ cannot send to channel #jkl because of $j**

**Figure 74: User ‘ijaz’ cannot join the channels #nkl and #jkl**

19.3.4 $r (ircname)

This mode matches on a client’s ircname, or the real name and it takes parameter and the wildcards are also accepted. The command for this will look like: /mode #channel +b $r:Bob* will ban any user whose gecos begins with "Bob".

Real names or gecos have the basic information of any user and this information can be shown with the /whois command. After execution, the real name will be shown after the hostmask and the full collon i.e. (@hostmask : realname).

I used the same command on my channel #jkl with the parameter 119* like /mode #jkl +b $r:119* will ban any user whose real-name begins with “119”. The parameter I used in this command is because the real name shown in the /whois is 119.63.130.84 which is connection through the webchat. The following figures show this scenario in detail.

**Figure 75: Realname 119.63.130.1 is shown with /whois kashif**

Figure 76: Mode +b with $r:119* is set to the channel #jkl

Figure 77: External user ‘ijaz’ cannot join the channel because of extban $r

**Figure78:Internal user ‘kashif’ cannot send to the channel #jkl because of extban $r**

19.3.5 $x (full match)

This mode also takes the parameter and matches it on the client’s full nick!username@host:gecos. The parameter accepts wildcards. For example, /mode #channel +b $x:*abc* will ban any user whose gecos begins with abc, or whose gecos contains "abc".

The realname of the ‘kashif’ as previously discovered is 119.63.130.84 and I want to ban users from this realname with the extended full match ban with passing different parameters to it. I set the mode of the channel #jkl as /mode #jkl +b $x:*130* in which the “130” is taken as parameter for full match . So it will ban any user whose gecos contains “130”. Although “130” comes in the middle but still it will be blocked due to full match $x. This is shown below in the figures.

Figure 79: Mode (+b $x:*130*) is set to the channel #jkl

**Figure 80: Internal user ‘kashif’ cannot send to the channel because of full match ban**

Figure 80: External user ‘user’ cannot join the channel because of full match ban

Figure 81: Mode (+b $x:*kashif*) is set to the channel #jkl

In the figure above, the mode $x with parameter “*kashif*” will ban all the users whose gecos begins with ‘kashif’ or whose gecos contain ‘kashif’. This will match the full nickusername@host:gecos. And search for the word “kashif” in that.

**Figure 82: User ‘kashif’ cannot send to the channel because his nick matches with parameter in $x**

Figure 83: Mode (+b $x:*kash*) is set to the channel #jkl

The above figure shows that the extban $x with parameter only “*kash” is set to the channel and its response is given in the below figure. In this example it is clear that the extended full match ban matches the entire gecos. Although “kash” is neither the nickname nor real name of the ‘kashif’ but still it bans ‘kashif’ to send in the channel. This all is due to the full match extban.

So we can say that whenever any any letters, digits or words matches with the parameters in the extended full ban then it will ban that.

**Figure 84: User ‘kashif’ cannot send to the channel because his first four letter of his nick matches with parameter in $x**

20. Mode e (ban exemption)

This mode takes parameter, just like ban . Wildcards can also be used, like ban. Ban exemption matches override +b and +q bans for all clients it matches, allowing the exempted user to join/speak as if they were not banned or quieted.

Let us take an example of this. I set the mode +b to the users connecting from the webchat having IP 119.63.130.85 to join/speak in the channel #jkl. The command will look like

/mode #jkl +b 119.63.130.85 .

Then I set the exempted ban to the user ‘ kashif’ so that he would be able to join/speak in the channel #jkl. The command for this is /mode #jkl +e kashif. So, this command will override the previous one for only the user ‘kashif’. All others except ‘kashif’ will be blocked.

The following figures will explain the above scenario in detail.

Figure 85: Mode +b is set to channel #jkl with parameter IP “119.63.130.85” to block all users connecting from webchat

Figure 86: Mode +e is set to channel #jkl with parameter ‘kashif’ to exempt him from +b mode set to channel #jkl

Figure 87: User ‘ijaz’ failed in joining the channel #jkl through webchat because of +b mode.

**Figure 88: Exempted user ‘kashif’ joined the channel #jkl even with +b mode set to it**

**Figure 89: Exempted user ‘kashif’ sent to the channel #jkl even with +b mode set to it**

Now let’s see the user modes in free node..!!

User Modes Implementations

There are various modes that can be set on users. Some of them can be set by the users, others are set by the network. Someone can list his/her current user modes with the /mode his_nickname command.

User modes are similar in syntax to channel modes but only channelname is replaced by the nickname of the user in the syntax. The command for changing user modes looks like /mode nickname +mode.

There are many modes which can be set on the users and some of them are mainly used in the freenode network and they are following.

g (Caller-ID)
I (Invisible)
Q (Disable forwarding)
R (block unidentified)
Z (connected securely)

Now, I will explain them one by one with proper example and through practical implementations.

1. User mode g (caller-id)

This user mode ignores private messages from unknown users which you don’t know but at the same time,it informs you that someone is attempting to message you. So, if you want to receive that messages, you can choose to receive those messages with the /accept command. Messaging a user will automatically accept them.

Figure 1: User ‘kashif’ is sending private messages to ‘baseer1’

**Figure 2: ‘baseer1’ received the private messages from ‘kashif’**

Figure 3: User ‘baseer1’ sets +g mode to his nick

**Figure 4: User ‘kashif’ fails in sending private messages to ‘baseer1’ because of +g mode to ‘baseer1’**

**Figure 5: User ‘baseer1’ receives the alerts that user ‘kashif’ is messaging him**

Figure 6: User ‘baseer1’ accepts the messages through /accept command

**Figure 7: User ‘kashif’ now resent the messages to user ‘baseer1’ and he received**

2. User mode i(invisible)

This user mode hides you from global WHO/WHOIS by normal users, and doesn’t show any shared channels in /WHOIS output when +i mode is set while it shows the shared channels when -i mode is set.

Figure 8: User mode -i is set to nick ‘baseer1’

**Figure 9: User ‘kashif’ executes /whois command on user ‘baseer1’ and his shared channel #jkl is shown in the output**

In the above figure, it shows that with the -i mode set to ‘baseer1’, its all details are shown with /whois command including the channels which he is using right away.

Figure 10: User mode +i is set to nick ‘baseer1’

**Figure 11: User ‘kashif’ executes /whois command on user ‘baseer1’ when +i mode is set and no channels is shown in the output.**

3. User mode Q (Disable forwarding)

This mode prevents channel forwards from affecting you. If a channel’s modes like +i,+r prevent you from joining that channel and it has a forwarding mode +f to the next channel,then anyone joining the first channel will be forward to the other channel as discussed in the +f channel mode.

Now if someone doesn’t want to be forwarded to the next channel even if the first channel doesn’t allow him to join, then the user must set the +Q mode to his/her nick. So, this will prevents him/her from the forwarding effect. The user will receive the relevant error message regardless of any forwards.

I implemented this in detailed. Firstly I set my channel #jkl to mode +i(invite only) and then I set the same channel to mode +f (forwarding ) to my next channel #nkl. Then in the first scenario, the user ‘kashif’ wants to join the channel #jkl but he is forwarded to the the other channel #nkl and he is informed about the forwarding effect.

Then in the second scenario, the user ‘kashif’ sets +Q mode to his nick and again tries to join the channel #jkl, but this time, he is not forwarded to the other channel #nkl and he receives the message that you are not invited to the channel. This all story is clearly shown in the figures below.

Figure 12: Mode +i is set to channel #jkl

Figure 13: Mode +f with parameter #nkl is set to #jkl

Figure 14: User ‘kashif’ is forwarded to channel #nkl upon joining #jkl

**Figure 15: User ‘kashif’ sets +Q(disable forwarding) mode to his nickname**

**Figure 16: User ‘kashif’ is not forwarded to #nkl due to +Q mode and he received the messages**

4. User mode Z (connected securely)

This mode is Set automatically by the network when someone connect via SSL (Secure Socket Layer). The other modes are set by the user himself but this mode is set by the network because this is the network responsibility to confirm the secure connection between clients and servers by verifying their cirtificates.

Some clients uses non SSL connection to the server like the webchat, mIRC etc. while other clients like HexChat etc. use the SSL connection with the servers.

I used both clients and see how the network assigns the +z mode to HexChat but not to Webchat. The following figures are shown for the references.

**Figure 17: User Modes +z and +i is set automatically by the network as soon as user ‘baseer1’ connects to the server through client “HexChat”.**

**Figure 18: User Mode only +i is set automatically by the network as soon as user ‘kashif’ connects to the server through the client “Webchat”.**

5. User mode R (block unregistered)

This mode ignores private messages from users who are not registered with servers.

If someone sets mode +R to his nick and if the other person is registered to the servers, then he can send his private messages to him but if someone is not registered, then he cannot send private messages to the person who has set +R mode.

Let us implement this practically. I set the mode +R to user ‘baseer1’ and there are two types of other users who want to send messages to ‘baseer1’ privately. The first one is user ‘kashif’ who is a registered user and the second is user ‘ijaz’ who is not registered with the network. When both of them send messages to the user ‘baseer1’, then the messages from user ‘kashif’ are received and those sent by the user ‘ijaz’ are not received by the user ‘baseer1’ because of +R user mode.