Hi, there's been some movement forward on the Single User Login (SUL) issue. I ask the Board to review this mail carefully as this has significant long- term implications and we need Board input to go ahead. I also ask other developers to correct me if I misrepresent anything. There are currently three competing strategies. Before I describe these strategies, let me point out that one important consideration for any system is scalability. That is, single login will be used on all existing and future Wikimedia projects, and potentially even on non-Wikimedia sites which we allow to participate in our system. The three strategies are: 1) GLOBAL NAMESPACE, IMMEDIATE CONFLICT RESOLUTION 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. 2) GLOBAL NAMESPACE COEXISTING WITH LOCAL ONES, DEFERRED CONFLICT RESOLUTION 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. 3) GLOBAL COMPUTER-READABLE ID, LOCAL HUMAN-READABLE NAMES 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. - - - - - The differences: 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. The question for the Board is: Given that we have at least two, and possibly three, implementations where there are volunteers, which one should we choose? To me, this seems to be a matter that could be decided by the Board; others have said that a poll will be necessary first. Either way is fine with me - what does the Board say? Regards, Erik