Single login poll

This is an archaic and now irrelevant discussion of implementation details for single user login. Please do not add new comments. For more information, see the single login documentation page.

Summary

SUL-1: auto-migration of unambiguous usernames to a global namespace; semi-automatic rule-based conflict resolution

automatic merging of unambiguous accounts (into one for all in a global namespace)
new accounts in global namesspace only, must be new and unique (check with namechecker)
conflict resolution (semi-automatic):
rule-based automatic conflict resolution phase 1 (seniority, number and history of edits, wiki-presence ...)

manual remaining conflicts resolution phase 2

automatically uniquifying remaining conflicting usernames (adds a number)

finally abandon local namespaces

SUL-2: coexisting global and local namespaces; conflict resolution is postponed

automatic merging of unambiguous accounts (into one for all in a global namespace)
new accounts in global namesspace only, must be new and unique (check with namechecker)
conflict resolution (no):
conflicting names stay in local namespaces

users may keep local names or may create a new global, different and unique name

SUL-3: local usernames, which might differ, belonging/linked to a globally unique user id (GUID)

automatic merging of unambiguous accounts (into unique user id (GUID) in a global namespace, optionally linked to a new and unique username there)
new accounts in global namesspace only, must be new and unique (check with namechecker)
conflict resolution:
gradual conflict resolution for old user logins in case of name conflicts

users can resolve conflicts for own usernames:

users can keep their different usernames (no need to drop an account) and can link them to a new single unique GUID on their own discretion.

Discussion

Preface

The transition to a single login system for all Wikimedia projects is one of the most frequently requested improvements. It is generally acknowledged that having to create an account manually for every wiki, and having to login separately on each one, greatly impairs the potential for synergy effects among the different projects.

There are three main competing strategies for how a single login system will work and how we can get there. These strategies are discussed below. We, the Wikimedia developers and administrators, ask you, as an informal opinion poll, to tell us which solution you would prefer. We do not guarantee that this solution will be implemented, but it will guide us in our decision making process.

Please try to understand the different proposals fully before voting. If you don't understand something, please ask on the discussion pages before voting. The developers are also usually hanging out on the #mediawiki IRC channel on irc.freenode.net.

You can only vote for one option. The poll will end on November 26, 2004, 20:00 UTC. Feel free to add a brief comment along with your vote. A user account on Meta or a link to a user page on a wikimedia project is required.

SUL-1: Auto-migration of unique usernames to a global namespace; semi-automatic rule-based conflict resolution

(former header was: GLOBAL NAMESPACE, IMMEDIATE CONFLICT RESOLUTION)

mainly automatic migration by

automatic merging of unambiguous accounts (into one for all in a global namespace)
new accounts in global namespace only (name check)
semi-automatic conflict resolution:
- rule-based automatic conflict resolution phase 1
- manual remaining conflict resolution phase 2
- automatically uniquifying remaining conflicting usernames (adds a number)

We try to move towards a single global user namespace for all Wikimedia wikis. If a name is already taken in the global namespace, you have to find one which isn't.

For the migration, any names which clearly belong to the same user are combined into one. If passwords and email addresses are different, the user can manually link together any accounts which belong to him by providing the passwords.

For cases of true name conflicts between the existing wikis, there is a resolution phase, where factors like seniority, use on multiple wikis vs. a single one, etc., are weighed in - the "loser" has to choose a new account name.

After the manual resolution phase, any remaining accounts are converted to the new system automatically by making them unique, e.g. by adding a number to the username. The transition is now complete. The old system no longer exists.

Votes for SUL-1

SUL-2: Coexisting global and local namespaces; postponed conflict resolution

(former header was: GLOBAL NAMESPACE COEXISTING WITH LOCAL ONES, DEFERRED CONFLICT RESOLUTION)

automatic merging of unambiguous accounts (into one for all in a global namespace)
conflicting names stay in the local namespaces
- users may keep local names or create a new global (and different) identity

As in 1), we migrate all existing accounts to the new global namespace automatically if possible. New accounts are created in the global namespace.

Where there are people sharing the same name, the accounts will not be migrated to the global namespace but will stay in the local ones, which will continue to coexist. These people can keep using their local IDs, or create a new, different global identity.

The idea here is that resolving name conflicts is so complicated that we simply defer the issue for now.

Votes for SUL-2

SUL-3: local usernames, which might differ, belonging to a linked globally unique UserID (GUID)

(former header was: GLOBAL COMPUTER-READABLE ID, LOCAL HUMAN-READABLE NAMES)

automatic merging of unambiguous accounts (into one username and one GUID in a global namespace)
gradual conflict resolution for old user logins in case of name conflicts
- users can partially resolve conflicts for their own usernames: when they use different names and emailaddresses, they may choose to keep these but they can link them all, step-by-step, to their single unique GUID

Every user has a global, numeric ID which is unique. But for each wiki, they can have a different username. As in strategy 1), any clearly identical accounts will be linked to a single GUID automatically, others can be hooked up by providing the passwords.

Naming conflicts are not an issue in this system. Let's say I am Eloquence on en: and de:, and there is another Eloquence on fr:. I get the global ID 1233, the fr: user gets the ID 28387. When I go to fr: and try to edit a page, I get a prompt:

        The username you have chosen is already in use on this wiki.
        Please specify a new name:
        ____________________________________

        If this is your account and it has not been linked to your
        global ID yet, please provide the password:
        ___________________________________

If I go to another wiki with no user named Eloquence on it, however, the local username "Eloquence" will be reserved for me the moment I edit it or set my local prefs. This is because the system knows that "Eloquence" is my preferred username, and will automatically try to create it for me when I need it. I can change the name later, if I want, and use different names on different wikis.

It should be noted that this solution requires name disambiguation for things like unified recent changes, unified watchlists, and image uploads directly to the Wikimedia Commons. It also makes it more difficult to combine multiple language databases into one, should this ever be desirable (e.g. a single Wiktionary for all languages). In short, whenever user names from multiple projects are aggregated or combined, naming conflicts will have to be resolved somehow.

Votes for SUL-3

Comments on the differences SUL-1, SUL-2, SUL-3

1) is very complex, and we may not find someone willing to deal with the name conflict resolution issue and take the blame from annoyed users at the same time. Naming conflicts will always be an issue in this scheme, as e.g. all common first names will be taken, and any small wiki hooking up with our SUL system would feel this impact. People can mutate these usernames relatively easily to make them unique - Erik333 - and the system can offer such mutations, but it's still a bit annoying.

2) is easiest to implement by avoiding the conflict issue. Brion has expressed interest in coding this. It will annoy some people who can choose between using their local name and keeping their attributions, or a global one, and losing their attributions, at least until things like linking up local accounts to a global one are implemented. It leads to some ugliness in the system because we are in an "in-between" state for now.

3) does not have the naming conflict problem. Both Jamesday and Kate have expressed interest in implementing it. Jamesday also wants to write a more detailed proposal on Meta about it. For the user, it is fairly straight- forward -- existing accounts can be hooked up easily to the single login, new names are picked only when necessary. It is somewhat vulnerable to trolling, as someone could e.g. register the name Eloquence on a wiki where I am not active, and use it for nefarious purposes. The system could however make it fairly easy to find out that this is not the same person (on the user page: "This user is active on the following wikis: .. under these names: ..").

In any case, we want username changes to be a cheap operation, so that anti-trolling policies should be easily enforcable.

External links

[Foundation-l] Single login - decision 2004