AW: [IRCServices] Services Suggestion - NickServ

[Yusuf Iskenderoglu]

Hello again;

> It was merely a suggestion and I have every intention of doing it 
> myself for
> the benefit of my users which ultimately is the aim of improvements in
> services and ircd coding.
> 

Still not convinced, why my computer should use cpu time to 
check nicknames for possible guestnick suffices,
while I do not have any java daemon connected.

> > 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
> 
> If you have access to the code to change it yes. Otherwise no. Since most
> Java clients in use are not open source changing them is not an 
> option. I do
> not have any desire to code one myself but see no benefit in 
> avoiding their
> traffic to the network.

Will you tell me, that you CAN take the risk of using a non-opensource daemon
on your network, and still want support for that in an opensource project ?

How will you know, that this specific daemon does not make additional connections
do abnormal destinations like I-am-here-to-collect-nickname-passwords.com ?

I work as a helper at the tutoriate for network security here in my dormitory
(we have 660 users connected to the net, and believe me, it is not small) 
(publicity: www.hadiko.de)
During my researches, I've come accross a patch for ssh2, where the daemon
was not writing into wtmp, to hide specific logins, or, was able to redirect
input to another file.

Your daemon may do the same. And you cannot see that, for it is precompiled java
something.

> Everyone is entitled to that but you seem to be under the impression this
> was specific to my network. It is not otherwise I would handle it locally
> and not suggest an improvement that may benefit others.

I still believe, that it is specific to your network, and others where people
do not have the time to write their own daemon, but instead use precompiled
binaries.

> 
> IRC is constantly evolving with a number of alternatives having 
> appeared but
> none yet to really compete with it. The type of user we see these days is
> increasingly of the layman breed rather than the original more technical
> users of IRC so tend to use easier programs. Java interfaces are something
> which are accessible on a number of platforms and are being 
> integrated into
> other programs as an alternative to coding an IRC client. Rather 
> than ignore
> these users, I hope that networks can evolve to accomodate them. As they
> become regular users they will migrate to a dedicated IRC client 
> program at
> some stage.

If I cannot see the source of that particular software, I cannot risk
letting many people use that. Nor I can risk to add support for a behavior
evolved by the usage of it. I would not code support for something I see,
for I cannot see everything on IRC. If you start that way of coding, your
result will be something full of patches on every line, to compensate special
behaviors. If you had the source, you might result in a better solution
for all those small appliances of patches.

You may be right by saying, that java clients enable even those very
internet newbies to chat. I do not discuss that aspect.

> 
> Obviously there is a line between what should be client side, 
> what should be
> server side and what should be in services. But I do not think we 
> should we
> ignore the grey areas just to stay in black and white.
> 

Those areas are already grayed out, at the moment Mr. Church decided to
support Unreal. But the tone of the gray you are suggesting is simply too
similar to white, just to express it in your words.

> 
> Mark.
> CTCP Networks.
> 

Best 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    |                                |
----------------------------------------------------------------------