The NOIDPREFIX Capability and Hyperion SVSLOGIN/SIGNON Support


Contents



Introduction

Hyperion 1.0 provides the NOIDPREFIX ISUPPORT capability to enforce the ownership of registered nicknames, and to distinguish between registered and unregistered users.

Note: A treatment of the reasons for the use of this capability on freenode can be found elsewhere.


General

When a NOIDPREFIX token is advertised in an ISUPPORT (numeric 005) message, generally at client connect time, NOIDPREFIX mode is entered. This mode creates two nickname domains:

  1. Unregistered users. These users are assigned IRC nicknames prefixed with the NOIDPREFIX character.
  2. Registered users. These users are assigned IRC nicknames not specifically prefixed with the NOIDPREFIX character.

Unregistered user nicknames may contain any valid IRC nickname characters, but are prefixed with a single instance of the NOIDPREFIX character. Registered nicknames consist of a framework of special and other characters built around an easily-identified alphanumeric BASENAME.

The syntax of unregistered user nicknames is the same as that of non-NOIDPREFIX-mode nicknames, except that they always prefixed by a single instance of the NOIDPREFIX character.


Syntax

Unregistered user nickname syntax is as follows:

NOIDPREFIX VALID...

Registered user nickname syntax is as follows:

[ SPECIAL... ] [ BASENAME [ SPECIAL [ VALID... ] ] ]

The individual tokens are:

ALPHA , an upper- or lower-case alphanumeric character
ALPHANUMERIC , an ALPHA or a numeric character
BASENAME , the core registered nickname, defined as:
ALPHA [ ALPHANUMERIC... ]
NOIDPREFIX , a single character denoting an unregistered user, usually a tilde ('~')
SPECIAL , any valid non-alphanumeric nickname character (does not include NOIDPREFIX when it's a tilde)
VALID , any valid nickname character
... , one or more occurrences of the immediately-preceding character or sequence


NOTES:

  1. The NOIDPREFIX character prefixed to the nickname of an unregistered user is considered part of the nickname, not a flag. Hyperion must change the nickname of the user in order to remove this special character.
  2. The tilde ('~') may only appear once in an IRC nickname, as the NOIDPREFIX value.
  3. While any valid nickname character can be used as the NOIDPREFIX character, in practice, tilde ('~') is recommended. Alphanumeric characters in particular are discouraged, except in special circumstances. If tilde is used, the nicknames of registered users will never be prefixed with the NOIDPREFIX character.


Connection Processing

At connect time, hyperion processes the nickname offered by the IRC client, stripping off any leading instances of the NOIDPREFIX character. It then prefixes the nickname with one instance of the NOIDPREFIX character and uses the resulting nickname for the IRC session. (This processing and renaming of the IRC nickname is accomplished as part of the connect process, and no client incompatibilities have been observed to date.)

The NOIDPREFIX capability is advertised in an ISUPPORT (numeric 005) message at the beginning of the IRC session. It appears as follows:

NOIDPREFIX=x

where 'x', the NOIDPREFIX character, may be any valid IRC nickname character, or the tilde ('~') character.


Behavior For Unregistered Users

When an unregistered user attempts to change his or her IRC nickname, leading instances of the NOIDPREFIX character are stripped from the user-supplied nickname. A single NOIDPREFIX character is then prefixed to the nickname. It is not possible for the user to change his or her nickname to one which has no NOIDPREFIX at the beginning.


Signon Process

The NOIDPREFIX capability is designed to be used with Hyperion SVSLOGIN/SIGNON support. A registry entity such as IRC services uses this support to identify the user as "signed-on", by issuing an SVSLOGIN message to the user's local server. The change is subsequently propagated to all servers through the SIGNON message. Both the SVSLOGIN and SIGNON As part of the signon process, SVSLOGIN sets the user's nickname to one which is not prefixed with the NOIDPREFIX character.

SVSLOGIN also adds a set of "reserved nicknames" to the user's session record. Each reserved nickname consists of a BASENAME as defined in the Syntax section.


Behavior For Registered Users

A registered user can change his or her nickname to any variant of any of the BASENAME values provided provided as reserved nicknames via the SVSLOGIN message. For example, if a user is provided with the allowed nickname foo, he or she can change to:

foo
foo_
foo`
`foo`
foo-1
[foo]
foo|ATHOME
foo[WORK]

or one of a number of other possible variations.

The user cannot change to an unregistered nickname or to a registered nickname not in its list. Further, the BASENAME value must be the first alphanumeric token in the nickname. So, for a hyperion session with the ISUPPORT token:

NOIDPREFIX=~

and a single reserved nickname of foo, the following are examples of disallowed nicknames:

foo2
fred[foo]
~foo


Implications For Tab Completion

IRC clients often provide TAB completion, a method of specifying a nickname which involves the user optionally typing one or more characters as a prefix and then hitting the TAB key. The client may offer selections of possible nicks and allow the user to repeat the process. At the end of the process, a complete IRC nickname is inserted into the command line.

Two general methods exist for TAB completion:

  1. Choice completion. The nickname is completed if there is one and only one nickname beginning with the specified prefix. Otherwise, the user is offered one of several choices of nicknames beginning with the prefix. If a complete nickname is not yet provided, the user may type additional characters and repeat the process.
  2. Cyclic completion. The nickname is completed with the first or only nickname beginning with the specified prefix. If more than one nickname matches the prefix, the user may continue to hit the TAB key, replacing the current nickname with the next matching nickname. The client may optionally cycle from the last match back to the first match and allow the user to continue the selection process; the client may also allow the user to add characters to or subtract characters from the prefix to narrow or broaden the selection process.

Special characters specified as part of a nickname prefix may be handled in one of two ways during TAB completion:

  1. Special characters required. In this case, you must specify any special characters as part of the prefix.
  2. Special characters optional. In this case, you need not specify any special characters as part of the prefix. If specified, they may be processed as any other character would be processed; if omitted, the prefix characters will be compared against the first alphanumeric characters in the nickname list in order to find matches.

Two general approaches to TAB completion processing provide improved nickname completion facilities for clients connecting to a server with the NOIDPREFIX capability:


Basic support

Clients which can be configured to provide special characters optional nickname completion provide the minimum necessary support for the NOIDPREFIX capability. These include irssi 0.8.9 and earlier, as well as irssi 0.8.10+ with the strict_completion setting turned off (the default).


Advanced support

Enhanced nickname completion facilities can be provided for clients connecting to a server with the NOIDPREFIX capability by following the following recommendations:

  1. Special characters should be optional. Registered nicks are reserved by BASENAME when the Hyperion NOIDPREFIX capability is active. Making special characters optional allows the user to specify nicknames purely in terms of a BASENAME prefix.
  2. Candidate nicknames produced by TAB completion should be sorted by BASENAME. This allows the user to more easily find nicknames owned by a specific user.
  3. Candidate nicknames with the same BASENAME and a tilde ('~') should be sorted after candidate nicknames with the same BASENAME and no tilde. NOIDPREFIX is designed for networks with a relatively high percentage of registered users.
  4. Candidate nicknames with the same BASENAME and no leading nickname special characters should be sorted first. NOIDPREFIX is designed for networks with relatively few nicknames containing special characters.

So, for example, when the following nicknames occur on a channel, the following is the recommended order in which they would be offered by client TAB completion:

fanboy
[fantasy]
~fantasy
~[fantasy]
foo
`foo`
[foo]
~foo
fred_


NOIDPREFIX Specification v0.1.2 2006/3/2 07:16

Copyright © 2002-2007 by Peer-Directed Projects Center.
Network date and time: Tuesday, 13-May-2008 22:15:36 GMT.
Comments to email address: web at freenode dot net.