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
