--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+ <HEAD>
+ <TITLE> [IRCServices] Services Suggestion - NickServ
+ </TITLE>
+ <LINK REL="Index" HREF="index.html" >
+ <LINK REL="made" HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20Services%20Suggestion%20-%20NickServ&In-Reply-To=3A945934.7266840C%40expres.ro">
+ <META NAME="robots" CONTENT="index,nofollow">
+ <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
+ <LINK REL="Previous" HREF="001474.html">
+ <LINK REL="Next" HREF="001479.html">
+ </HEAD>
+ <BODY BGCOLOR="#ffffff">
+ <H1>[IRCServices] Services Suggestion - NickServ</H1>
+ <B>Mark Hetherington (Eurocom)</B>
+ <A HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20Services%20Suggestion%20-%20NickServ&In-Reply-To=3A945934.7266840C%40expres.ro"
+ TITLE="[IRCServices] Services Suggestion - NickServ">markh at eurodltd.co.uk
+ </A><BR>
+ <I>Thu Feb 22 21:50:03 PST 2001</I>
+ <P><UL>
+ <LI>Previous message: <A HREF="001474.html">[IRCServices] nickserv
+</A></li>
+ <LI>Next message: <A HREF="001479.html">AW: [IRCServices] Services Suggestion - NickServ
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#1478">[ date ]</a>
+ <a href="thread.html#1478">[ thread ]</a>
+ <a href="subject.html#1478">[ subject ]</a>
+ <a href="author.html#1478">[ author ]</a>
+ </LI>
+ </UL>
+ <HR>
+<!--beginarticle-->
+<PRE>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
+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.
+
+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.
+
+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:
+
+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>.
+
+
+Mark.
+CTCP Networks.
+
+
+
+</PRE>
+
+<!--endarticle-->
+ <HR>
+ <P><UL>
+ <!--threads-->
+ <LI>Previous message: <A HREF="001474.html">[IRCServices] nickserv
+</A></li>
+ <LI>Next message: <A HREF="001479.html">AW: [IRCServices] Services Suggestion - NickServ
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#1478">[ date ]</a>
+ <a href="thread.html#1478">[ thread ]</a>
+ <a href="subject.html#1478">[ subject ]</a>
+ <a href="author.html#1478">[ author ]</a>
+ </LI>
+ </UL>
+
+</body></html>
projects / irc.git / blobdiff