Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[dissy]

I was wondering if anyone would be interested in creating a module, which would display a registered nicknames 'display nick' for their group, in a whois reply.

One idea is to append the groups display nick to the end of the 307 numeric,
 Ex.  307 YourNick TheirNick :is a registered nick (MainNick)
Where 'TheirNick' and 'MainNick' are in the same group, and 'MainNick' is the display nickname for the group.
Granted that idea may violate the 307 reply standard, but it's just one idea.


The purpose is to provide a sort of 'authentication' available to clients/bot scripts using the network.
Authentication isn't quite the right term, but putting aside the obvious issues with linking nickserv registrations and specific identities, the goal would be to provide a constant ID for a group of nicks, no matter which nick is currently being used, as long as its identified with services.

While this would not serve to prevent someone from having multiple ungrouped nicks,  it would however provide a means for client scripts to recognize a single group of nicknames as the same, as well as show that person is identified with services with the correct credentials.
This way, bot/scripts such as games and other non-critical functions would not require separate nick/user and password registration/authentication with their own seperate hostmask database.  It would be closer to a single-sign on (with services) feature for connivance only.

Thoughts and opinions welcome
Thanks -- Dissy

[Jobe]

The problem with the 307 numeric is that's generated by either the IRCd that the /whois request is sent to so Anope has no control over that. The only 307 response Anope has control over is the response for it's own clients.

[dissy]

Originally posted by Jobe1986
The problem with the 307 numeric is that's generated by either the IRCd that the /whois request is sent to so Anope has no control over that. The only 307 response Anope has control over is the response for it's own clients.

I was afraid of that with the whois reply.

I guess the easiest method would be adding a command to nickserv or something similar.

Thanks for the input
-- Dissy

[katsklaw]

This way, bot/scripts such as games and other non-critical functions would not require separate nick/user and password registration/authentication with their own seperate hostmask database. It would be closer to a single-sign on (with services) feature for connivance only.

This is already possible with current means, You can return if a nick is identified without using /whois.

This is done with NickServ's STATUS command:

Code: [Select]


[17:36] [Notice] -NickServ- Syntax: STATUS nickname...
[17:36] [Notice] -NickServ-
[17:36] [Notice] -NickServ- Returns whether the user using the given nickname is
[17:36] [Notice] -NickServ- recognized as the owner of the nickname.  The response has
[17:36] [Notice] -NickServ- this format:
[17:36] [Notice] -NickServ-
[17:36] [Notice] -NickServ-     nickname status-code
[17:36] [Notice] -NickServ-
[17:36] [Notice] -NickServ- where nickname is the nickname sent with the command, and
[17:36] [Notice] -NickServ- status-code is one of the following:
[17:36] [Notice] -NickServ-
[17:36] [Notice] -NickServ-     0 - no such user online or nickname not registered
[17:36] [Notice] -NickServ-     1 - user not recognized as nickname's owner
[17:36] [Notice] -NickServ-     2 - user recognized as owner via access list only
[17:36] [Notice] -NickServ-     3 - user recognized as owner via password identification
[17:36] [Notice] -NickServ-
[17:36] [Notice] -NickServ- Up to sixteen nicknames may be sent with each command; the
[17:36] [Notice] -NickServ- rest will be ignored. If no nickname is given, your status
[17:36] [Notice] -NickServ- will be returned.


Have the bot perform the status command on a nick, if 3 is returned, the nick is identified. Using STATUS will not return the group a nick belongs to and in my opinion that should remain private information. However, you can have your script maintain a userhost list for for the user in question and so long as the userhost matches the user and their status returns 3, it's relatively safe to assume it's the right person.

[dissy]

Originally posted by katsklaw
Have the bot perform the status command on a nick, if 3 is returned, the nick is identified.

That doesn't accomplish what I was requesting however.

For example, if I registered the nick 'Dissy', then also switched to and grouped 'Dissy|away', 'Dissy|work', 'Dissy|moo' and so on, using the status command will only return if the person on any of those nicks is identified or not.

Using that method, those are 4 totally seperate users, thus with the example of a game script, 4 different profiles with 4 different scores etc.

What I would like is a command that when issued with any of those 4 nicks as the argument (assuming I am on the nick at the time and identified of course) they would all return 'Dissy' (which would be the 'display nick' of the group.)

This way the game script would reconize any of those 4 nicks as the same user, and thus use the same profile, no matter which nick in my group I am currently on.

[PS]
I guess I just don't see how this information not being private would be an issue..  And if it is, there are already methods to obtain it as a regular user (they just arnt easy to automate/script)
If you would like, I can explain/demonstrate how to do so.

--Dissy

[Edited on 16-10-2006 by dissy]

[katsklaw]

I understand perfectly what you want to do. It would be _alot_ easier for you to script such authentication, account linking and tracking methods in your client script rather than having IRC protocols written and support placed into an IRCd as well as Services to support something that would only be useful to a small handful of people. Not to mention the additional resources and memory loads added to both the IRCd and services.

[Edited on 16-10-2006 by katsklaw]

[dissy]

It would be _alot_ easier for you to script such authentication, account linking and tracking methods in your client script

I fully agree with that from the perspective of the programmer (as this was how my scripts previously worked.)

My request came from users complaints (as well as the fact I have been annoyed by this as well) having to manage host lists, usernames, and passwords seperately for each bot, as well as services.
My hope was to provide an easier way to allow services to be the main repository for the hostlist, nicks, and password, and let the bots interface there.

rather than having IRC protocols written and support placed into an IRCd as well as Services to support something that would only be useful to a small handful of people.

I do see how changing the whois output (my original suggestion) would involved all of that work and problems, and agree that method is not an option at all, let alone one worth attempting.

Not to mention the additional resources and memory loads added to both the IRCd and services.

Would those issues still hold true, if the module was to only provide an additional nickserv command, that returned similar output to the status command, with addition of the group name?

I can definatly see why most people would not have use for such a module, and I would imagine as well any such commands name would be rather non-obvious.
But I assumed that would be the perfect use of a module, vs any changes to the anope code.  I don't yet know how to write anope modules, nor have a test envirnment setup to do it properly.  So I definatly appriciate the feedback from someone that knows what they are doing :}


Also (This probably isnt the best place for it, so sorry in advance) the way I am currently doing this may be a bug, if the display nick is suppost to be kept private/restricted.

Note the nicknames in the last two lines below:

Code: [Select]

-!- Irssi: Starting query with nickserv
<Dissy> glist
-NickServ- List of nicknames in your group:
-NickServ-     Dissy (expires in Oct 17 00:07:46 2007 CEST)
-NickServ-     DissyAgony (expires in Oct 15 22:44:35 2007 CEST)
-NickServ- 2 nicknames in the group.

-!- Irssi: Starting query with chanserv
<Dissy> vop #test list
-ChanServ- No matching entries on #test VOP list.
<Dissy> vop #test add dissyagony
-ChanServ- Dissy added to #test VOP list.

The very last line gives away the display nick for the group, no matter which nick in the gorup is used to add the access list entry.

If that isn't a bug, my request is simply for a module to provide a single command to take the place of the multiple commands (ns status, cs add, cs del) as well as the need for the bot/client to be in an unused channel (to avoid removing someone from the list if they are Suppost to be on it for example)

If that is a bug.. then I do see your point..  and I guess I have a bug to report :}

-- Dissy

[katsklaw]

Would those issues still hold true, if the module was to only provide an additional nickserv command, that returned similar output to the status command, with addition of the group name?

Yes it would still be true, but not to the extent of modifying the /whois output. A module can be written for anope to reply with the users group a stored in the nick.db

To make such a request, make a thread on the requests forum and cross your fingers ;P

[Edited on 17-10-2006 by katsklaw]