AW: [IRCServices] Services Suggestion - NickServ

[Yusuf Iskenderoglu]

Hello;

> We have a number of users that come from Java clients. As is the nature of
> many java based IRC interfaces they have a "default" nickname and use an
> incrementing numerical suffix to maintain some form of unique 
> nicknames.  A

Nice, but we don't have such servers.

> majority of users of this service tend to use the default despite a number
> of encouragements to choose their own nickname first. It was "interesting"
> to see how many people actually joined a chat called TypeYourNameHere...
> hehe.
> 

Possibly yes. Or you modify the java client, that it does not show a default
nickname, but only set an IDENT for a nick. That way, users WILL have to chose
a realistic nickname.

> The problem comes when one of these visitors registers the nickname. E.g.
> JavaGuest. The next JavaGuest coming in with that name will get forcibly
> changed to Guestnnn by Nickserv.
> 

And ?

> NS now seems to correctly prevent the registration of it's own internal
> Guest names and there appears to be an appropriate flag to detect that a
> nick is "guested" so working from this base, I see two possible solutions:
> 

Solutions for a possible Java web interface your network uses ?
Is that case so common, that it has to be solved globally ?
What if I start demanding additions for my network only ?

> 1) The current NS supports suspension and forbidding of 
> nicknames. Add a new
> state that does not forbid the use of the nickname but forbids 
> registration
> of it. This however would be limited in application since each name
> generation by the JavaChat program would have to be set to this status
> creating a human workload that services is largely designed to remove.
>
> 2) Add in support for multiple user defined "guest" nickname types. This
> way, anyone whose nick is say JavaChatnnnn could be handled by 
> the same code
> which handles services native guest names. Although probably easier as a
> configuration file change (as with the native current guest prefix), a
> registration mechanism with NS would be preferable. For the purpose of NS
> processing it could maybe use the new status value described above but
> merely stores a prefix in the database rather than an explicit 
> nickname and
> the nick be flagged to be processed as a guest nick type. Maybe a new
> command /NS REGISTERGUEST <JavaChatPrefix> <PrefixOwnerEmail>.
> 

I do not see your point. I do not think, that services should handle causalities
of what possible JavaChat daemons may have done to your network.
If you really cannot live with that specific daemon, you will need to recode services
to live with it, and not enforce me to compile a code specific to your network.

First of all, that nickname event may be solved in your javachat daemon.
You should be able to modify it to either 
- not suggest a default nick
- change the suggestion to Guest* and not JavaGuest*
Or, you can use another daemon.

And second, that condition is not a case services should handle in my opinion.

> 
> Mark.
> CTCP Networks.
> 

Regards;
yusuf

----------------------------------------------------------------------
| Yusuf Iskenderoglu                | You get to meet all sorts,     |
| eMail - uhc0 at rz.uni-karlsruhe.de  | in this line of work...        |
| eMail - s_iskend at ira.uka.de       |                                |
| ICQ UIN : 20587464 \ TimeMr14C    |                                |
----------------------------------------------------------------------