[IRCServices] Services Suggestion - NickServ

[Mark Hetherington (Eurocom)]

Hi,

I think you may have misinterpreted my original comments as relating to IRCd
when they relate to the behaviour of a Java client which is integrated most
commonly in a web site and gives visitors the opportunity to join IRC and a
channel dedicated to the subject of the web site.

> Still not convinced, why my computer should use cpu time to
> check nicknames for possible guestnick suffices,

As with other features of services which may affect performance, there is
little coding overhead in making it optional at either compile or
configuration time. e.g. Session limiting and Statserv.

> while I do not have any java daemon connected.
> 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 ?

It is a client not a daemon.

I use a modified version of Unreal as my ircd across the network and am in
the process of developing an IRCd from the ground up. I would never dream of
using a pre compiled binary or a java ircd.

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

It is a client used by users. The fear you express as to the collection of
passwords could be just as easily applied to any piece of software. It is
the users which are ultimately responsible for their personal security, we
can only advise them as to course of actions wrt potential security problems
since the client is outside of our control and assist them in securing their
IRC related activities.

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

I have not seen the source to MIRC... should I ban that from the network or
remove the workarounds for the MIRC "status bug" from the IRCd? This may
stem from a potential misunderstanding and I do not advocate supporting
specifics per client since this is obviously the wrong way to go. However,
when a group of clients from different sources share a common theme, it
seems reasonable to implement some form of services that cater to their
needs.

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

Personally I am glad to see there will be native support for Unreal in
services. It saves using patches to add the support required so makes
services available to a wider IRCd audience. Unreal seems to be avoided by
some people but I have yet to see reasons mentioned for this but it does
seem to go beyond a mere personal taste issue wrt IRCd. But I guess that
discussion is beyond the scope of this list :)


Mark.
CTCP Networks.