IRC Oddities

4 views
Skip to first unread message

Cory McWilliams

unread,
Feb 19, 1999, 3:00:00 AM2/19/99
to
I'm developing my own IRC client and I keep discovering weird differences
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

unread,
Feb 19, 1999, 3:00:00 AM2/19/99
to
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]
: 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

unread,
Feb 19, 1999, 3:00:00 AM2/19/99
to
Actually sence the user can be voiced and opped so the voice was never
taken away and is still voiced when deopped.


kkat

Cory McWilliams

unread,
Feb 20, 1999, 3:00:00 AM2/20/99
to
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.

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

unread,
Feb 20, 1999, 3:00:00 AM2/20/99
to
Cory McWilliams <pseu...@rpa.net> wrote:
: 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

unread,
Feb 21, 1999, 3:00:00 AM2/21/99
to
>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.

neat idea... i think ill put that in my server
but will mirc see it ? lets see...


Cory McWilliams

unread,
Feb 21, 1999, 3:00:00 AM2/21/99
to
>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.

Anyway, can anyone direct me to a place that has information about strange
IRC problems like this? It would be extremely helpful.

-=-peas-=-

unread,
Feb 21, 1999, 3:00:00 AM2/21/99
to
Cory McWilliams wrote in message <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.
>>
>>--
>> / 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

unread,
Feb 21, 1999, 3:00:00 AM2/21/99
to

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.
>
>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.
>

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-=-

unread,
Feb 22, 1999, 3:00:00 AM2/22/99
to
just thought i'd correct myself before someone else did.

<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


Reply all
Reply to author
Forward
0 new messages