View Issue Details

IDProjectCategoryView StatusLast Update
0002990unrealircdpublic2012-12-26 19:33
ReportertabrisnetAssigned Tonenolod 
PrioritynormalSeveritytweakReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinux/x86OSDebian LinuxOS Versiontesting
Product Version3.2.5 
Target Version3.3-alpha0Fixed in Version3.4-alpha1 
Summary0002990: Q:Line Holds and "Erroneous Nickname"
DescriptionSeems that users are getting confused by the "Erroneous Nickname" message (and it's not just the part from the qline reason... I played with that already).

The short and long is that I think that we should look into something like "Enforced nickname" or "Services Enforced Nickname" for qline H (tho not normal qline).
Additional InformationI agree that not many services packages use qline holds yet (tho I understand that Anope 1.7.x can use them, but I don't think they're on by default yet). I started using them to eliminate the races btwn svsnick, nickchange, signon-enforcer. With qlines that's never an issue.

Unfortunately, we now live in the MSN & AIM generation, where users are not familiar with IRC or what certain things mean, and often are 'limited literate'. They're not illiterate, but they have very limited understanding, even those who would be considered native speakers. I hate it, but must live with it.

I am not seeking that the 432 message be changed per se, but that we might use a custom 432 here... I'd even consider using 433, although that has its own problems (NickServ stole my nick! Check bash.org for examples). I want a singular clear message that they'll understand. Plus "Erroneous Nickname" usually means an illegal or inappropriate nickname, not a nick that is being enforced.
TagsNo tags attached.
3rd party modules

Activities

WolfSage

2007-04-15 20:40

reporter   ~0013424

I disagree. If a user doesn't know what a word means, they should look it up or ask someone. This IS the Internet. Information is readily available, and easy to access.

tabrisnet

2007-04-15 21:01

reporter   ~0013426

But wtf does "Erroneous" have to do with it being services enforced?

stskeeps

2007-04-18 05:05

reporter   ~0013502

Isn't Erroneous in RFC1459? I mean, it would cause clients to not touch a nick and realize they can't switch to it, so it serves it's purpose?

Does the message -actually- matter for clients? Anyone want to test?

aquanight

2007-04-19 19:22

reporter   ~0013610

Last edited: 2007-04-19 19:23

A client itself probably won't check the message. I think the point being made is the *humans* behind the client don't get it.

And "Erroneous nickname" is pretty vague. Nearly every other case where we deny something, we tell the user who tried it why (gline: * Closing Link blah (User has been banned from <network> (<blarp>), for example). Perhaps our 432 should start including the qline message?

(edit: er, actually, don't we do that already?)

(edit2: yes we do: /* 432 ERR_ERRONEUSNICKNAME */ ":%s 432 %s %s :Erroneous Nickname: %s" - so is this really an issue?)

tabrisnet

2007-04-19 19:25

reporter   ~0013611

The problem is that the users just see "Erroneous nickname" and think that their nick is not allowed, rather than merely services-enforced.
As I said, I tried editing the qline reason to something that tells a lot more, but users were still confused.

WolfSage

2007-04-19 20:30

reporter   ~0013612

* WolfSage :Erroneous Nickname: Being held for registered user

If a user is too lazy to read that whole sentence, that's their problem.

tabrisnet

2007-04-19 21:05

reporter   ~0013613

Well, back when I had a large population of kids (14 and under) I had a lot of that problem. The channel moved a while ago so it's less of a problem now, but the fact is that assuming or requiring intelligence shifts the burden not onto the stupid user but onto the support staff.

Your attitude on this is making me think I should have just patched the code myself.

stskeeps

2007-04-20 10:10

reporter   ~0013616

Before we start misunderstanding eachother here.. Would it at all be a problem if we simply made the 432 ":%s 432 %s %s :%s" where the actual reason is the reason that is set in Q:line etc etc? I mean, can anyone come with a widely used script/client that REQUIRES the Erroneous nickname being in it?

I'm not against removing the Erroneous part, atleast.

tabrisnet

2007-04-20 10:32

reporter   ~0013618

I'm reasonably confident that irssi doesn't care, as it just pays attn to the numeric, and then prints the payload. I poked around the code, and numeric 432 calls
event_received which calls print_event_received which doesn't do any filtering on the content itself.

stskeeps

2007-04-21 03:13

reporter   ~0013623

Confirmation being that for we switch to the prefix not being Erroneous nickname: but just the actual error itself. I admit this breaks RFC1459 but it really seems a lot better this way.

        432 ERR_ERRONEUSNICKNAME
                        "<nick> :Erroneus nickname"

                - Returned after receiving a NICK message which contains
                  characters which do not fall in the defined set. See
                  section x.x.x for details on valid nicknames.
 

stskeeps

2007-04-24 05:25

reporter   ~0013653

Implemented in .2371

nenolod

2012-12-26 19:33

reporter   ~0017280

http://hg.unrealircd.org/hg/unreal/rev/18324232791c

Issue History

Date Modified Username Field Change
2006-07-05 12:31 tabrisnet New Issue
2007-04-15 20:40 WolfSage Note Added: 0013424
2007-04-15 21:01 tabrisnet Note Added: 0013426
2007-04-18 05:05 stskeeps Note Added: 0013502
2007-04-18 05:05 stskeeps Status new => acknowledged
2007-04-19 19:22 aquanight Note Added: 0013610
2007-04-19 19:22 aquanight Note Edited: 0013610
2007-04-19 19:23 aquanight Note Edited: 0013610
2007-04-19 19:25 tabrisnet Note Added: 0013611
2007-04-19 20:30 WolfSage Note Added: 0013612
2007-04-19 21:05 tabrisnet Note Added: 0013613
2007-04-20 10:10 stskeeps Note Added: 0013616
2007-04-20 10:32 tabrisnet Note Added: 0013618
2007-04-21 03:13 stskeeps Note Added: 0013623
2007-04-21 03:13 stskeeps Status acknowledged => confirmed
2007-04-24 05:25 stskeeps Status confirmed => resolved
2007-04-24 05:25 stskeeps Fixed in Version => 3.3-alpha0
2007-04-24 05:25 stskeeps Resolution open => fixed
2007-04-24 05:25 stskeeps Assigned To => stskeeps
2007-04-24 05:25 stskeeps Note Added: 0013653
2011-07-19 14:09 syzop Assigned To stskeeps =>
2011-07-19 14:09 syzop Status resolved => needs re porting
2011-07-19 17:11 syzop Target Version => 3.3-alpha0
2012-12-26 19:33 nenolod Note Added: 0017280
2012-12-26 19:33 nenolod Status needs re porting => resolved
2012-12-26 19:33 nenolod Fixed in Version 3.3-alpha0 => 3.4-alpha1
2012-12-26 19:33 nenolod Assigned To => nenolod