View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002833 | unreal | ircd | public | 2006-02-23 21:00 | 2007-05-20 15:22 |
| Reporter | tabrisnet | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Linux/x86 | OS | Debian Linux | OS Version | testing |
| Product Version | 3.2.4 | ||||
| Fixed in Version | 3.3-alpha0 | ||||
| Summary | 0002833: UHNAMES (and NAMESX too) | ||||
| Description | I figure this is a useful extension, and as I understand mIRC supports it (albeit not until 6.17), X-Chat may. irssi probably doesn't, but it's not used by many ppl (and yes, I use irssi). I know that NAMESX was mentioned in bug 606, but it's rather old and there seems to be little progress on implementing it, and more progress in talking about it. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| 3rd party modules | |||||
| related to | 0000606 | resolved | Setting more than one channel mode (o, h and v) on a user can desync these modes with client |
|
|
** 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. |
|
|
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... |
|
|
NAMESX stuff --> 0000606 Will keep this entry for UHNAMES :) |
|
|
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! |
|
|
Will delay UHNAMES. 'Heard current mIRC has problems (read: bugs) with it anyway... |
|
|
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. |
|
|
Status wished on this? |
|
|
personally i'd like to see this in 3.2.7 or 3.2.8 |
|
|
ok for 3.3* unknown for 3.2* (low prio) |
|
|
Does anyone know the raw format for what this should look like? I'm tempted to take a crack at implementing it. |
|
|
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 |
|
|
[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)? |
|
|
in the hostname, the = is part of their cloaking. |
|
|
working patch uploaded. a) compile tested b) run tested this is against today's CVS for 3.2 |
|
|
previous patch had a bug, it was always retrieving the cloakhost, not checking whether the user was cloaked or vhosted, or not. |
|
|
Patched in .2411 |
| 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 |
|
Note Added: 0011311 | |
| 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 |
|
Status | new => acknowledged |
| 2007-04-18 05:40 |
|
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 |
|
Status | acknowledged => confirmed |
| 2007-05-20 15:22 |
|
Status | confirmed => resolved |
| 2007-05-20 15:22 |
|
Fixed in Version | => 3.3-alpha0 |
| 2007-05-20 15:22 |
|
Resolution | open => fixed |
| 2007-05-20 15:22 |
|
Assigned To | => stskeeps |
| 2007-05-20 15:22 |
|
Note Added: 0014194 |
