IRC Oddities
Cory McWilliams
between IRC servers and how some popular clients handle certain things
differently than the protocols suggest.
Some examples:
If a person in a channel is given a voice, opped, and then deopped, the
person gets their voice back, but the server doesn't make any clients aware
of that. I've confused people in mIRC by demonstrating how you can make
everyone's screen look different in this way.
EFNet uses just a linefeed character to end a line, not a carriage return
and linefeed, like RFC 1459 suggests.
mIRC doesn't unquote CTCP version replies like the CTCP suggests.
I would like to know if anyone can point me to a site that describes the
most popular implementation of the IRC protocols to clear me up, a bit.
Thanks to any help,
Cory
--Developing vbIRC--
Jesse McGrew
[snip]
: If a person in a channel is given a voice, opped, and then deopped, the
: person gets their voice back, but the server doesn't make any clients aware
: of that.
The server doesn't need to. If your client doesn't realize that the user
still has +v, that's a fault of the client. For example, this is how virc
(incorrectly) does it:
MODE #chan +v Mr2001 - The client puts a + in front of my name.
MODE #chan +o Mr2001 - The client changes the @ to a +.
MODE #chan -o Mr2001 - The client removes the @, even though I'm still +v.
[snip]
: mIRC doesn't unquote CTCP version replies like the CTCP suggests.
I don't know if any client does CTCP quoting.
--
/ Jesse "Monolith" McGrew \ Intel inside. Screwdriver inside.
\ Mr2001 on IRC / Intel outside. AMD inside!
Scott Seufert
taken away and is still voiced when deopped.
kkat
Cory McWilliams
were opped and will return the + when they are deopped, but that doesn't
solve the problem. Suppose someone joins the room after the user is opped
and before the user is deopped. The server doesn't notify the client that
the person ever had a voice and therefore, there is no way to know. This
makes it a problem of the server.
Currently, I'm sneaking around this problem by requesting a names list when
a user is deopped, which clears up any confusion.
Jesse McGrew wrote in message <7akht5$9...@journal.concentric.net>...
>Cory McWilliams <pseu...@rpa.net> wrote:
>[snip]
>: If a person in a channel is given a voice, opped, and then deopped, the
>: person gets their voice back, but the server doesn't make any clients
aware
>: of that.
>
>The server doesn't need to. If your client doesn't realize that the user
>still has +v, that's a fault of the client. For example, this is how virc
>(incorrectly) does it:
>
>MODE #chan +v Mr2001 - The client puts a + in front of my name.
>MODE #chan +o Mr2001 - The client changes the @ to a +.
>MODE #chan -o Mr2001 - The client removes the @, even though I'm still
+v.
>
>[snip]
> / Jesse "Monolith" McGrew \ Intel inside. Screwdriver inside.
> \ Mr2001 on IRC / Intel outside. AMD inside!
Cory McWilliams
Jesse McGrew
: True, better clients will remember that a person had a voice before they
: were opped and will return the + when they are deopped, but that doesn't
: solve the problem. Suppose someone joins the room after the user is opped
: and before the user is deopped. The server doesn't notify the client that
: the person ever had a voice and therefore, there is no way to know. This
: makes it a problem of the server.
Ah, you are correct. EFnet's TS4 patch would have fixed this (by sending
@+ instead of just @ in /names, /who, and /whois), but it was rejected.
--
/ Jesse "Monolith" McGrew \ :) -> TMBG, UCB/TDS, AMD, ROTT/Sin
| Most quotable man on the Internet | :( -> CW/R&B/rap/alt, WWF/WCW/etc,
\ Mr2001 on IRC / Intel/Cyrix/PPC, Q2
LocKDowN
>@+ instead of just @ in /names, /who, and /whois), but it was rejected.
neat idea... i think ill put that in my server
but will mirc see it ? lets see...
Cory McWilliams
>@+ instead of just @ in /names, /who, and /whois), but it was rejected.
>
> / Jesse "Monolith" McGrew \ :) -> TMBG, UCB/TDS, AMD,
ROTT/Sin
> | Most quotable man on the Internet | :( -> CW/R&B/rap/alt,
WWF/WCW/etc,
> \ Mr2001 on IRC / Intel/Cyrix/PPC, Q2
I asked the maker of mIRC about the problem and he said that EFnet handled
it like how you described.
I thought that the best way to handle this matter would be for the server to
send a +v message after any -o message if it needs to restore the voice. It
seems like the simplest way and wouldn't harm existing clients.
Anyway, can anyone direct me to a place that has information about strange
IRC problems like this? It would be extremely helpful.
-=-peas-=-
>>Ah, you are correct. EFnet's TS4 patch would have fixed this (by sending
>>@+ instead of just @ in /names, /who, and /whois), but it was rejected.
>>
>>--
>> / Jesse "Monolith" McGrew \ :) -> TMBG, UCB/TDS, AMD,
>ROTT/Sin
>> | Most quotable man on the Internet | :( -> CW/R&B/rap/alt,
>WWF/WCW/etc,
>> \ Mr2001 on IRC / Intel/Cyrix/PPC, Q2
>
>I asked the maker of mIRC about the problem and he said that EFnet handled
>it like how you described.
>
>I thought that the best way to handle this matter would be for the server
to
>send a +v message after any -o message if it needs to restore the voice. It
>seems like the simplest way and wouldn't harm existing clients.
ooooh no way ! the mode must originate from somewhere as far as the syntax
goes. so what do you do ?
a) it comes as a server mode *** london.uk.eu.undernet.org sets mode +v
BanDit
and people will get very confused.
b) it comes from the nick that deop'ed the user so you would see
*** MrOp sets mode -o BanDit
*** london.uk.eu.undernet.org sets mode +v BanDit
again the result would be confused users.
I actually prefer efnets idea of storing the user mode as @+ this still
doesn't fix the problem that a client joining after a voiced user was opped
will not consider the user to be voiced once deopp'ed without doing a /names
(clients repeatly doing this waste server resources).
>
>Anyway, can anyone direct me to a place that has information about strange
>IRC problems like this? It would be extremely helpful.
>
>
well i can;t think of a place specifically for this sort of info, hence this
newsgroup, thats why we are here i guess.
--
-=-peas-=-
irc.starfusion.org
LocKDowN
Cory McWilliams <pseu...@rpa.net> wrote in message
news:7apcjm$2c...@enews2.newsguy.com...
>>Ah, you are correct. EFnet's TS4 patch would have fixed this (by sending
>>@+ instead of just @ in /names, /who, and /whois), but it was rejected.
>
>it like how you described.
>
>I thought that the best way to handle this matter would be for the server
to
>send a +v message after any -o message if it needs to restore the voice. It
>seems like the simplest way and wouldn't harm existing clients.
>
Hey, i just implemented that @+ in my server and it worked great !
mIRC handles it. This is what i did:
me1 joined channel #test
mode #test +v me1
me2 joined channel #test
mode #test -o me1
and me1 had voice on both clients ! way 2 go !
oddity fixed... on my server !
-=-peas-=-
<SNIP>
>b) it comes from the nick that deop'ed the user so you would see
>*** MrOp sets mode -o BanDit
>*** london.uk.eu.undernet.org sets mode +v BanDit
^^^ that line should read:
*** MrOp sets mode +v BanDit
<SNIP the rest>
--
-=-peas-=-
irc.starfusion.org