Why NOIDPREFIX?

Background
The Problem
How NOIDPREFIX Works
Benefits

Background

The purpose of this change is to more closely couple reputation with IRC nickname.

For those of you who may not know me, I'm the head of staff of freenode. I've run this project, and the ones leading up to it for something over ten years. My job has been to try to adapt IRC to the provision of ongoing, serious community services. The Hyperion NOIDPREFIX capability is part of that continuing effort.

The Problem

One of the problems I've noticed (which NOIDPREFIX is designed to address) is that IRC users don't always have a stake in positive, responsible behavior. It's about each user having a reputation that matters to them. Several conditions are important:

The user should have the ability to assert a unique identity, closely coupled with his or her reputation. If the observer can't distinguish between two users, there is no way for each to develop a unique reputation.

In standard ircd, nickname reservations are session-based. Whenever a session is terminated or interrupted, control of the user's nickname is lost. The user cannot assert a unique identity which cannot simply be hijacked by another user. Some IRC networks, including freenode, have adopted external, DALnet-style authentication daemons, which allow users to own nicknames on a more permanent basis through NickServ. Such solutions are poorly-integrated with ircd and it's difficult to eliminate race conditions (timing problems allowing one user to make use of another user's nickname for brief periods of time) which can be used for social engineering attacks.
The user should have the incentive to assert such an identity. Simply having the capability to assert an identity is not sufficient to create a reputation. Unless users actually assert that unique identity, there's nothing on which to base a reputation.

Unmodified IRC does not recognize any sort of permanent identity and hence provides no incentive to assert such an identity. Beginning prior to 1998, freenode and its precursor projects evolved to allow channel owners to distinguish, when necessary, between users who have and have not asserted unique identities through NickServ. Given the lack of visibility of nickname reservation through NickServ, though, many casual users tend not to notice that channel owners have such capabilities and much of the early incentive is lost.
Community members should be universally capable of distinguishing between users who have asserted such an identity, and those who have not. New users and casual users can be expected to have considerably less reputation stake. If everyone can tell the difference between the two general classes of users, casual users and newbies will have more incentive to develop a positive reputation by becoming part of the class of users which asserts unique identities.

To meet this condition, freenode formulated CAPAB IDENTIFY-MSG, which labels each message sent to a user with a tag which indicates whether the user is identified to NickServ. The main problem with this approach is that it requires special client support and scripting. Relatively few users run the special scripts, and the effect is mostly lost.

How NOIDPREFIX Works

The feature consists of the following components:

A prefix for unregistered users. All unregistered nicknames will begin with a tilde ("~"). The intent is not to discriminate against unregistered users, who will include casual users looking for support and users who are new to their communities. Rather, the intent is to provide an unambiguous visible indicator that distinguishes such new users from regular users. This indicator will be visible to both the user and those around him or her, and will make their initial status visible. Not only will this provide an incentive for long-time users to register; it will also make it clear when a user is a newbie and hence unlikely to be familiar with the customs of an online community. This can help forestall potential misunderstandings.
Race-free control of registered nicknames. When NOIDPREFIX is active, it is possible for a services-like external authentication daemon to use SIGNON/SVSLOGIN to simultaneously change a user's nickname, change their username, and associate their client record with a list of alphanumeric basenames and with an external account identifier. The user is then considered to be signed on and can change to any nickname which is a valid variation of any of the basenames associated with their client record (without further interaction with an authentication daemon). Since only the user who owns a registered nickname can ever change to it, there are no longer "race conditions" allowing other users inappropriate use of a nickname for short periods of time.
Basename-oriented nickname reservation. Nicknames are served for registered users based on an underlying alphanumeric basename, as described elsewhere. Because all variations of a nickname with the same underlying basename are reserved for a single user, it's less likely for users to adopt confusingly-similar nicknames. While this can initially produce conflicts between different users whose nicknames contain the same basename, it will nonetheless help reduce identity confusion, which will in turn help couple nicknames more closely with identities.

It's worth noting that, in recent live snapshots of nickname use on freenode, about 75% of all nicknames for connected sessions were discovered to be purely alphanumeric. Of the nicknames which contained special characters, only 40% (20% prior to the network's implementation of unregistered private message filtering) were reserved by unexpired nickname registration. Staff are not in any hurry to begin production use of NOIDPREFIX before nickname conflicts can be resolved, and indeed the policy page and FAQ reference the policy and urge people to avoid name conflicts.

Benefits

To registered users

It will no longer be possible to easily spoof someone's identity. Only registered users have control of their registered nicknames, and no race condition allows ina ppropriate use of a registered nickname by another user.
Fewer confusingly-similar IRC nicknames will exist. Users will be able to tell at a glance the underlying reserved alphanumeric basename of an IRC nickname. No two users will be able to reserve the same basename.

To unregistered users

Users who are not concerned with registration can use any available IRC nickname in a complete address space. If a user doesn't register, their IRC nickname exists in a separate namespace beginning with tilde. This most closely corresponds to traditional IRC usage, in that nicknames prefixed with tilde can never be registered and can always be preempted.

To all users

Users have a visible incentive to register. Non-transient users who notice they have a tilde will be more likely to register in order to blend in better with long-t ime users. Registered users have a reputation to protect and hence more incentive toward responsible behavior.
Spotting newbies and casual users will become easier. Ease in identifying these users will help prevent misunderstandings in which new users are expected to unders tand channel culture before they've had a chance to become accustomed to IRC.