As I’ve started to implemented GUI-part of my IRC-client, I’ve started too see some limitations with the handling of the MODE command. One thing that was apparent to me as a user (well, I didn’t think it was anything special) that one can be both voiced and oped at the same time. That is, if you’re initially voiced, then oped and then deoped, you are still voiced.
However, if you enter a channel where a user i oped, how do you know if that person is also voiced? The simple answer is, you can’t. As you enter the channel, only the highest privilege is displayed (‘@’ instead of ‘+’ in this case).
“But why does my client handle this correctly?”
Well, there are two (maybe three, but I’ll touch on that later) answers to this.
The first one is that your client has been in that room long enough to have seen that the user has been voiced before it become op. This seems to be the behaviour in Pidgin for example. It will, however, not remember this is if you restart your client and the user then becomes deoped (the user will show up as a regular user).
The second one is that your client sends NAMES command which will ask the server to send the list of users whom are in the channel (and therefor will get the current privilege for all of the users). Implementing this will make sure that the correct privilege is always shown, but it will be relatively costly in terms of CPU and bandwidth.
The third possible reason (I have not seen this being the case for any server) is that the server you are connected to either sends the same list that one requested in the second example, or that it will send a second MODE containing the +v parameter for the user. I have not seen this being the case for any server I have tested and I am pretty sure that it is not something that probably is even concidered (due to bandwidth concerns).
As someone who is creating his own client, I will probably go with the first example. Especially since I didn’t even noticed it before I really started looking into it.