0002833: UHNAMES (and NAMESX too) - UnrealIRCd Bug Tracker

(0011290)
syzop (administrator)
2006-02-24 06:09
edited on: 2006-02-24 06:09

** This post is regarding NAMESX **

I do indeed see this (mirc changelog):
18.Added support for numeric 005 NAMESX token, indicating that
mIRC supports multiple mode prefixes for a nickname in a NAMES
list, eg. @+nickname.

But how does mIRC communicate this to the irc server?

Hmmm.. actually.. when testing this with mirc 5.17, I see it sends a 'PROTOCTL NAMESX' if it sees this in 005... wonderful! ;)
Did someone lobby for us or something? lol

I'm pretty sure I'll implement this then.
Even if it's not as optimal as another negotiate protocol (which is far for finished, true), it will at least be present as "one of the ways to achieve this.." and it would work right now.

(0011291)
syzop (administrator)
2006-02-24 06:12
edited on: 2006-02-24 06:15

Oh and regarding UHNAMES, will have to think about that, but the idea isn't bad... It would solve those poor clients having to mass WHO and getting sendq exceeded and things like that (plus, it will save us a lot of bandwidth if clients are pleased with this and no longer have to WHO).

For the record, relevant mirc changelog entry:
127.Added support for numeric 005 UHNAMES token, indicating that mIRC
supports the nick!user@host format in the NAMES list which it uses
to the fill the IAL on joining a channel.

(since, surprise, not every ircd coder does read mirc changelogs, is good to mention the relevant entries here what you actually meant)

I forgot to mention, this is also sub-optimal just as NAMESX (well you know the whole discussion in the other bugreport regarding auto-join), but still...

(0011293)
syzop (administrator)
2006-02-24 07:11

NAMESX stuff --> 0000606
Will keep this entry for UHNAMES :)

(0011311)
codemastr (reporter)
2006-02-27 21:51

UHNAMES doesn't sound like a bad idea, assuming it too does a PROTOCTL (I'm assuming it does). I just hope clients won't be greedy about it and turn it on when they don't really care about u@h info!

(0011620)
syzop (administrator)
2006-04-27 18:30

Will delay UHNAMES.

'Heard current mIRC has problems (read: bugs) with it anyway...

(0013352)
tabrisnet (reporter)
2007-04-07 17:50

mirc changelog version 6.2 claims to have fixed issues with UHNAMES

21.Fixed /names list display being truncated when a UHNAMES list is
returned with full addresses.

assuming that was the issue you were speaking of anyhow.

(0013509)
stskeeps (reporter)
2007-04-18 05:40

Status wished on this?

(0013957)
tabrisnet (reporter)
2007-04-30 18:59

personally i'd like to see this in 3.2.7 or 3.2.8

(0014050)
syzop (administrator)
2007-05-08 13:40

ok for 3.3*
unknown for 3.2* (low prio)

(0014060)
tabrisnet (reporter)
2007-05-09 11:55

Does anyone know the raw format for what this should look like?
I'm tempted to take a crack at implementing it.

(0014062)
tabrisnet (reporter)
2007-05-09 12:41

I did some poking around ConferenceRoom.
this is a result from NAMESX and UHNAMES

:java.webchat.org 353 testagent = #randchan :@+testagent!test@=O1btrpdw.solunaenterprises.com

(0014064)
aquanight (reporter)
2007-05-09 21:13

[quote]:java.webchat.org 353 testagent = #randchan :@+testagent!test@=O1btrpdw.solunaenterprises.com[/quote]

Is that = a result of a cloaked host (is = even valid in hostnames?), part of the UHNAMES, or a result of mixing UHNAMES and NAMESX?

Also, can you (or indeed, anyone) get numeric samples from other ircds (ie: >1 if possible) known to support UHNAMES (and preferably NAMESX as well)?

(0014069)
tabrisnet (reporter)
2007-05-09 22:56

in the hostname, the = is part of their cloaking.

(0014130)
tabrisnet (reporter)
2007-05-13 21:48

working patch uploaded.
a) compile tested
b) run tested

this is against today's CVS for 3.2

(0014137)
tabrisnet (reporter)
2007-05-14 12:10

previous patch had a bug, it was always retrieving the cloakhost, not checking whether the user was cloaked or vhosted, or not.

(0014194)
stskeeps (reporter)
2007-05-20 15:22

Patched in .2411

Notes
(0011290) syzop (administrator) 2006-02-24 06:09 edited on: 2006-02-24 06:09	This post is regarding NAMESX I do indeed see this (mirc changelog): 18.Added support for numeric 005 NAMESX token, indicating that mIRC supports multiple mode prefixes for a nickname in a NAMES list, eg. @+nickname. But how does mIRC communicate this to the irc server? Hmmm.. actually.. when testing this with mirc 5.17, I see it sends a 'PROTOCTL NAMESX' if it sees this in 005... wonderful! ;) Did someone lobby for us or something? lol I'm pretty sure I'll implement this then. Even if it's not as optimal as another negotiate protocol (which is far for finished, true), it will at least be present as "one of the ways to achieve this.." and it would work right now.

(0011291) syzop (administrator) 2006-02-24 06:12 edited on: 2006-02-24 06:15	Oh and regarding UHNAMES, will have to think about that, but the idea isn't bad... It would solve those poor clients having to mass WHO and getting sendq exceeded and things like that (plus, it will save us a lot of bandwidth if clients are pleased with this and no longer have to WHO). For the record, relevant mirc changelog entry: 127.Added support for numeric 005 UHNAMES token, indicating that mIRC supports the nick!user@host format in the NAMES list which it uses to the fill the IAL on joining a channel. (since, surprise, not every ircd coder does read mirc changelogs, is good to mention the relevant entries here what you actually meant) I forgot to mention, this is also sub-optimal just as NAMESX (well you know the whole discussion in the other bugreport regarding auto-join), but still...

(0011293) syzop (administrator) 2006-02-24 07:11	NAMESX stuff --> 0000606 Will keep this entry for UHNAMES :)

(0011311) codemastr (reporter) 2006-02-27 21:51	UHNAMES doesn't sound like a bad idea, assuming it too does a PROTOCTL (I'm assuming it does). I just hope clients won't be greedy about it and turn it on when they don't really care about u@h info!

(0011620) syzop (administrator) 2006-04-27 18:30	Will delay UHNAMES. 'Heard current mIRC has problems (read: bugs) with it anyway...

(0013352) tabrisnet (reporter) 2007-04-07 17:50	mirc changelog version 6.2 claims to have fixed issues with UHNAMES 21.Fixed /names list display being truncated when a UHNAMES list is returned with full addresses. assuming that was the issue you were speaking of anyhow.

(0013509) stskeeps (reporter) 2007-04-18 05:40	Status wished on this?

(0013957) tabrisnet (reporter) 2007-04-30 18:59	personally i'd like to see this in 3.2.7 or 3.2.8

(0014050) syzop (administrator) 2007-05-08 13:40	ok for 3.3* unknown for 3.2* (low prio)

(0014060) tabrisnet (reporter) 2007-05-09 11:55	Does anyone know the raw format for what this should look like? I'm tempted to take a crack at implementing it.

(0014062) tabrisnet (reporter) 2007-05-09 12:41	I did some poking around ConferenceRoom. this is a result from NAMESX and UHNAMES :java.webchat.org 353 testagent = #randchan :@+testagent!test@=O1btrpdw.solunaenterprises.com

(0014064) aquanight (reporter) 2007-05-09 21:13	[quote]:java.webchat.org 353 testagent = #randchan :@+testagent!test@=O1btrpdw.solunaenterprises.com[/quote] Is that = a result of a cloaked host (is = even valid in hostnames?), part of the UHNAMES, or a result of mixing UHNAMES and NAMESX? Also, can you (or indeed, anyone) get numeric samples from other ircds (ie: >1 if possible) known to support UHNAMES (and preferably NAMESX as well)?

(0014069) tabrisnet (reporter) 2007-05-09 22:56	in the hostname, the = is part of their cloaking.

(0014130) tabrisnet (reporter) 2007-05-13 21:48	working patch uploaded. a) compile tested b) run tested this is against today's CVS for 3.2

(0014137) tabrisnet (reporter) 2007-05-14 12:10	previous patch had a bug, it was always retrieving the cloakhost, not checking whether the user was cloaked or vhosted, or not.

(0014194) stskeeps (reporter) 2007-05-20 15:22	Patched in .2411

Issue History
Date Modified	Username	Field	Change
2006-02-23 21:00	tabrisnet	New Issue
2006-02-24 06:09	syzop	Note Added: 0011290
2006-02-24 06:09	syzop	Note Edited: 0011290
2006-02-24 06:12	syzop	Note Added: 0011291
2006-02-24 06:15	syzop	Note Edited: 0011291
2006-02-24 07:10	syzop	Relationship added	related to 0000606
2006-02-24 07:11	syzop	Note Added: 0011293
2006-02-27 21:51	codemastr	Note Added: 0011311
2006-03-05 15:19	tabrisnet	Issue Monitored: tabrisnet
2006-04-02 16:55	syzop	Relationship added	child of 0002748
2006-04-27 18:30	syzop	Note Added: 0011620
2006-04-27 18:30	syzop	Relationship deleted	child of 0002748
2007-04-07 17:50	tabrisnet	Note Added: 0013352
2007-04-18 05:40	stskeeps	Status	new => acknowledged
2007-04-18 05:40	stskeeps	Relationship added	child of 0003049
2007-04-18 05:40	stskeeps	Note Added: 0013509
2007-04-30 18:59	tabrisnet	Note Added: 0013957
2007-05-08 13:40	syzop	Note Added: 0014050
2007-05-09 11:55	tabrisnet	Note Added: 0014060
2007-05-09 12:41	tabrisnet	Note Added: 0014062
2007-05-09 21:13	aquanight	Note Added: 0014064
2007-05-09 22:56	tabrisnet	Note Added: 0014069
2007-05-13 21:47	tabrisnet	File Added: uhnames.diff
2007-05-13 21:48	tabrisnet	Note Added: 0014130
2007-05-14 12:09	tabrisnet	File Added: uhnames-v2.diff
2007-05-14 12:10	tabrisnet	Note Added: 0014137
2007-05-20 15:08	stskeeps	Status	acknowledged => confirmed
2007-05-20 15:22	stskeeps	Status	confirmed => resolved
2007-05-20 15:22	stskeeps	Fixed in Version	=> 3.3-alpha0
2007-05-20 15:22	stskeeps	Resolution	open => fixed
2007-05-20 15:22	stskeeps	Assigned To	=> stskeeps
2007-05-20 15:22	stskeeps	Note Added: 0014194
2007-06-10 11:36	tabrisnet	Issue End Monitor: tabrisnet