Talk:Single login specifications

This page has been superseded by that at Help:Unified login (talk), and is retained mainly for historical purposes. New edits and discussion should be directed there.

This proposal is very outdated and no longer under discussion. For the latest information, see Help:Unified login. Before posting additional discussion about the current version, please first check recent discussions to make sure that your point has not been raised and addressed:

• "SUL" (August 2007, Foundation-l)

To discuss, see the following mailing lists:

• Foundation and community discussion: foundation-l
• technical discussion: Wikitech-l

External discussion

1. [Foundation-l] Single login, et al --SJ
   1. http://lists.wikimedia.org/mailman/htdig/foundation-l/2005-July/thread.html#17063
2. [Foundation-l] Single login --Gerard Meijssen

I added some stuff

I added some stuff without signing, I hope this is okay! --WiseWoman 09:52, 10 July 2005 (UTC)

That's fine. I refactored it and moved some things here:

At a cut-off date all new login names are created in a special namespace to be added after the migration. New users are informed that this will take time.

I don't understand what this means. The logins in the account database are unrelated to namespaces.

Should this be weighted according to N, K? Should entries on pages such as Delete pages be counted higher? Or all all edit created equal?

I believe the answer is no. Our goal is to resolve conflicts without much effort. My guess is that due to the uneven distribution of edits, in most cases, the winners are likely to have much more edits than the losers, and in those few cases where they do not, any weighting system would be criticized due to its inevitable imperfections. I suggest keeping it simple and asking users to accept the result.

Are there user names with special characters, or just ASCII?

Yes, though interestingly, many users on languages with non-Latin characters use Latin1 account names, because they are used to their real names not working properly :-). MediaWiki fully supports UTF-8 in account names, and since all wikis have been migrated to UTF-8, there should be no issue with name migration.--Eloquence 13:22, 10 July 2005 (UTC)

Winners and losers: unacceptable

Process point #5 is really not acceptable. Better alternatives have been proposed; I'll try to talk to Kate about an improvement that minimally affects the rest of the stated plan sometime soon. +sj | Translate the Quarto |+ 22:11, 11 July 2005 (UTC)

There will always be losers in a global accounts system. There is no what of getting away from it.

James F. (talk) 22:36, 11 July 2005 (UTC)

Which is a good reason to not deploy a global accounts system. Few editors edit in multiple projects. Very few edit in multiple projects if you exclude commons and meta. I see this proposal breaking a larger user base for a little ease for a very small base of users. If signon persistance didn't keep getting broken due to memcached bugs (and changing to NFS, etc), then there would be very little need for single signon since the power users would never be signed off. ... though I think it would be useful to check new users against all project to prevent collisions, and in general compare new users to a canonicized list of existing users from all projects to prevent the creation of confusingly simmlar names... but whats done is done. Gmaxwell 23:20, 11 July 2005 (UTC)

We definitly need this, and we need it fast! The German Wikipedia plans to disable the local upload (so you must upload to the commons) and there are many problems caused by the missing single-login. It's not just, that you have to register again, you also have to watch multiple watchlists, talk pages etc. de:Benutzer:iGEL -- 82.83.98.30 16:46, 10 October 2005 (UTC)

Kate and Jamesday prefer a fundamentally different approach, where every user name is local to a particular wiki, e.g. there is one Eloquence on En, but there could be another on De, and if I edit De, I might have to create a different name there in case it clashes. I personally prefer the approach outlined here, but what also matters is that Brion as a developer has committed to a particular strategy, and has voiced strong opposition against the opposite approach. Nevertheless, should Kate volunteer to implement a different strategy, it would be best to revive the single login poll (the page has been wikinautified, try this version) to reach a conclusion.--Eloquence 23:33, 11 July 2005 (UTC)

Yes, we do - the analysis we did moved away from the forced migration approach to a compatible approach, which retained all existing accounts and could still reserve the names in every project where there wasn't a conflict. That eliminated all of the conversion headaches while still delivering a single namespace for all new accounts. Forced name changes are simply unnecessary to get to a common namespace - there's a better way. For obvious reasons, I'm not keen on using the most disruptive possible way of doing things. I'm not even sure the way brion thinks of doing it is legal - copyright law requires preserving the information on the copyright holder and if the names are being changed, that seems to be discarding that information. Jamesday 00:04, 15 February 2006 (UTC)

I think, it might be a good idea to weight the number of articles by age. Articles older than one year could be multiplied by 0.9, older than two years by 0.8 etc. This would increase the chance for active accounts not to loose against one, which isn't in use anymore. It's still not fair, but somehow we have to do this -- 82.83.98.30 17:10, 10 October 2005 (UTC)

I agree in that using whatever strategy there will always be winners and losers when it comes to selecting which local user gets the global name when two different users have the same user name in different projects. But I don't believe using edit counts is entirely appropriate. After all, it is quality what counts not quantity, or at least that's what is preached on every wikipedia. By using his system, wikimedia will contradict its principles and will encourage competing users to create dozens [if not hundreds]] of superfluous mini-drafts or engage in minor unnecessary corrections or edits, to "win the name". Somehow a way to combine number of edits, size of edits and even seniority, and whether a user is an admin or a bureaucrat. --Dúnadan 21:22, 10 January 2007 (UTC)

Scaling issues

(see meatball:CommunityMayNotScale

This action might inadvertantly trigger violations of the Rule of 150.

This is a real physical limit which obeys mathematical laws. Take care to reasonably show that your implementation path does not violate the rule of 150 before applying it!

en:User:Kim Bruning 23:02, 11 July 2005 (UTC)

I disagree that this will add to social scalability issues.

Anyway, if we go with "Dunbar's Number", we're already very much in trouble. w:en alone has 500 sysops and many thousands of contributors - so evidently it's collapsed. Erm.

James F. (talk) 23:19, 11 July 2005 (UTC)

I discussed this a lot with folks at one time. The wiki compartimentalises people per page, so we hardly ever reach the 150 figure (maybe on pages like VFD and so). A Single User Login like you're proposing does break down compartimentalisation somewhat though! I'm just not sure how far. I wish there was some way to Do Th Numbers as opposed to simply "stating on belief" en:User:Kim Bruning / 80.126.238.189 23:37, 11 July 2005 (UTC)

I do not understand this concern. Are you trying to say that because people's accounts will work everywhere, suddenly people will flood across the barriers between projects, increasing the size of their social networks beyond human ability to cope? If having an account was all it took to get people to involve themselves, I'd have a lot more edits on Wikibooks. And meta. And Wikisource. -- Cyrius 23:15, 11 July 2005 (UTC)

Since this is actually about single account creation, not single login, I don't expect it will encourage people to edit cross-project very much more than they do already since they'd still need to re-login in, which doesn't take much less time than creating a new account (typing the password once instead of twice is the only difference). This isn't about merging recent changes or user contribution lists, so the communities themselves will be no more merged than they already were. The only difference might be in the Special:Listusers pages, but since those are basically useless for the large wikis anyway, I don't think that would be much of a problem. Angela 23:22, 11 July 2005 (UTC)

Actually, the implementation proposed is very much compatible with any such "rule of 150". The reason is that the system will transparently create a local account for you on every wiki you use. Special:Listusers will still only show the people actually using this wiki.--Eloquence 23:29, 11 July 2005 (UTC)

Hmmm, though JamesF seems to be wanting to go straight to Single User Login (do not pass go ;-) ). en:User:Kim Bruning / 80.126.238.189 23:37, 11 July 2005 (UTC)

It goes straight to SUL. The implementation still depends on wiki-specific settings being stored on a per-wiki basis, hence, local accounts to store that data will only be created as needed.--Eloquence 00:02, 12 July 2005 (UTC)

Attribution and licensing issues

It's not obvious in the current proposal how we will avoid misattribution of content after a conflict.. Sure if the collided user speaks up, but we shouldn't require users to maintain eternal vigilance just to keep their work from being assigned to someone else. Gmaxwell 23:31, 11 July 2005 (UTC)

Page histories will reflect name changes.--Eloquence 23:34, 11 July 2005 (UTC)

What about image histories and other logs? When we merged the user databases of Wikicities and Memory Alpha, the page histories were fine, but things like the bureaucrat log were not. Please make sure these are considered, not just page histories. Angela 23:51, 11 July 2005 (UTC)

Please test this with the current rename user functionality, as this is the code that will likely be used.--Eloquence 23:58, 11 July 2005 (UTC)

I tested this by uploading an image and then blocking the user who was to be renamed. Special:Imagelist, Special:Newimages, the image description page, and the image page's history all updated properly after the rename. The block log claimed the old name was blocked after the switch and didn't mention the user's new name, but the Ipblocklist showed the new user name. Also, the message I got when I tried to edit told me the reason for the block was that I shared an IP with the new user name. Angela 11:36, 13 July 2005 (UTC)

Semi-manual system

How about this, then? (Note: I don't actually like this scheme.)

• All new accounts are global (with all current names local and global blocking global names).
• All singleton accounts are automatically converted to be global.
• All multiple accounts with the same name and email address are automatically converted to be global.
• All other accounts go into discussion (proof that all of the accounts really are yours, or one user agrees to change their name; inactive accounts would be spontaneously renamed to "w-en-username" or whatever).

Local accounts would continue to be used for a month (or maybe 2) until everything was settled; judges (people who are happy to take lots of flak ;-)) settle things where true dispute arises.

Not as fast, but less upsetting, perhaps.

James F. (talk) 23:45, 11 July 2005 (UTC)

What about everyone who was still not settled after a month (or 2)? Would this hold up the process for everyone else? Angela 23:52, 11 July 2005 (UTC)

They'd get renamed, wisdom-of-Solomon-like, by the judges at the end of the period. Hence the desire to get it done by agreement rather than force.

James F. (talk) 23:59, 11 July 2005 (UTC)

This is a fundamentally different approach, as it requires global/local to coexist. I see no need for this. Conflict resolution can happen swiftly, borderline cases can be examined on a case by case basis. We can always rename users if something needs to be negotiated.--Eloquence 23:57, 11 July 2005 (UTC)

But not quickly enough. If there are conflicts, none of the involved user-sets can edit as global (and so, in the current system, edit at all) without resolving the conflict.

It also minimised downtime - users get converted as-and-when, online, not merely all in one go.

James F. (talk) 00:03, 12 July 2005 (UTC)

In most cases, the conflict resolution happens by logging in. I think it can hardly be simpler. Why does there need to be downtime?--Eloquence 00:12, 12 July 2005 (UTC)

On the other hand, the approach kate and I came up with makes this irrelevant because account merging could happen over as long as necesary without blocking any editing at all by anyone. That gives ample time for humans to non-disruptively fix things. Jamesday 00:09, 15 February 2006 (UTC)

How about make it possible for people to have local or global accounts, and as a nicetohave maybe even allow them to convert between the 2? This is non-disruptive, and costs considerably less human resources and brownie points, and overseeable system resources. en:User:Kim Bruning / 80.126.238.189 00:01, 12 July 2005 (UTC)

World wide banning?

In the new system, when someone has been banned for example for 24 hours at EN.wikipedia for violating the 3RR, will he be banned at the other projects as well? Jcb 17:34, 12 July 2005 (UTC)

No. Blocklists will continue to be local.--Eloquence 18:15, 12 July 2005 (UTC)

... though it might make sense to have a global-ban system, too? For things like bot-attacks, etc.?

James F. (talk) 01:05, 13 July 2005 (UTC)

A global ban would be useful in some cases, but we'd need a way of relaying the reason for the block to all communities. Being able to check user contributions across all wikis would also be useful in the case of spam attacks. Angela 11:38, 13 July 2005 (UTC)

A set of "standardised" reasons for particular causes of block – "Spam-bot account", "open-relay IP", "Legal action threatened against other user/Foundation", etc.? Possibly different wikis could then decide which reasons would cause any block anywhere on the Foundation's wikis to cause blocking locally? (So, say, a wiki that isn't as upset with people threatening legal action against other users could make such categorised blocks not trickle down?) OTOH, right now I imagine that there's not much of a problem with trans-wiki vandals for the effort to be useful (though as we scale, all problems will come to pass, no doubt :-().

James F. (talk) 22:23, 21 July 2005 (UTC)

Or in all cases? —Ilyanep (Talk) 01:12, 6 February 2006 (UTC)

Obviously this would also beg the question who would be allowed to ban site-wide, would that be a meta only feature and useable by Stewards? Certainly not local admins everywhere... - TheDaveRoss 16:30, 17 October 2006 (UTC)

Re: Hook-up dialogue after first login, accessible from prefererences

• Option 1 - Click on "Global account preferences". We'll need to tweak the Javascript such that deep linking is possible.
• Option 2 - All accounts in one table, with separate page to request new password

(comment moved from main spec): These are great, but shouldn't you be able to add local accounts that are differently named (and have them renamed)? So my "JamesF" and "Jdforrester" accounts can all be under the one accounts... James F. (talk) 00:16, 21 July 2005 (UTC)

Good question. Could you spec out the behavior here? In particular, consider these scenarios:

• "JamesF" loses, but "Jdforrester" wins. Is it possible to associate JamesF@fr.wikipedia.org to Jdforrester@global? This seems reasonable.
• Both "JamesF" and "Jdforrester" win, thus the accounts are already associated with a global account. Can the global "Jdforrester" account steal any of the local JamesF@*.wikipedia.org accounts? This seems complicated.

-- RobLa 01:31, 21 July 2005 (UTC)

I thought that local accounts that are associated would be renamed (otherwise, as you say, we have yet more clashes). Thus, if "Jdforrester" wins, then it should be possible to associate each of the JamesF@* accounts, renaming them to Jdforrester@$1 in the process. If you have multiple global winners, you'd have to pick one and merge your accounts into it. So, were both "JamesF" and "Jdforrester" to win, I'd pick one ("Jdforrester", in my case), so I should be able to log in and merge my global account "JamesF" into the global account "Jdforrester".

Basically, there should be (a) a free-form box to add local accounts, and (b) another one (probably on a different and rather special (and temporary!) page/tab) for merging global accounts.

James F. (talk) 22:17, 21 July 2005 (UTC)

It makes sense to allow losing accounts to be associated with a differently-named global account. However, I don't think that we should allow the merging of two winning global accounts. While merging global accounts is potentially an interesting feature, it's more code that can break, and there doesn't seem to be a compelling need for it. -- RobLa 19:24, 22 July 2005 (UTC)

The thing is if "losing accounts [are] associated with a differently-named global account", they are renamed to the global-account name, yes? Otherwise things will be very confused.

As for merging global acounts being yet "more code that can break", I agree, but it's needed - I will end up with at least two winning global accounts, the aforementioned "Jdforrester" and "JamesF" accounts. Clashes are (hopefully) rare, and different names for each user across wikis not wholly uncommon, so... it's unlikely to be a feature that people won't want.

James F. (talk) 14:55, 23 July 2005 (UTC)

Adding stages, comments

I changed the process significantly; adding a number of steps and comments, clarifying some vague points, and separating it into four stages. (Plus 'Stage 0', one thing that should be implemented quickly to keep people from gaming the system.) These are of course just suggestions, boldly added (and there are still aspects of the specifications which I disagree with). Feel free to be just as bold in removing them.

My main thoughts:

• Statistics should be gathered early on, to better inform how long the process is scheduled to take, and how much difficulty/confusion is expected.

  If there may be many conflicts, we might consider something more gradual than the specifications provide for, like SUL-3...

• Functionality that will be needed to make Single Login work, but will be cool even before it is in place -- like a universal "new messages" notice -- should be developed as early as possible.

• Controversial conflict merging should be done last, both to limit controversy while discussing functionality, and to provide as much time as possible for mediation and communication. Bear in mind that many interested wiki editors contribute slowly but surely; they don't have 1000 edits a month, and don't even log in once a week (though they may read every day).

+sj | Translate the Quarto |+ 19:36, 6 November 2005 (UTC)

Todo: Collision Estimation

The last meeting of Wikimedia_Research_Network suggests that knowing a ballpark number of possible conflicts would be nice for planning purposes. Would it be possible to create a unified name database as a start and check the number of overlapping names. This is not directly productive in bringing any change about, but nonetheless seems like someting a non-developer could possibly complete to aid in the planning process? ∴ here…en:♠ 04:01, 15 November 2005 (UTC)

Simple Model

This concept would do if a cookie for dfferent subdomains would work.

• A special new portal/wiki for the login could be offered. A new account with a specific number/ID/user name and a password has to be created there. One gets a cookie when logging in.
• Every user account on a national Wiki should have the opportunity to join the special ID by form (by entering this ID and its password in a form for joining). Only one account per national Wiki is allowed for joining.
• The cookie could be a general key for all accounts on the national Wikis which have been connected to this ID. Instead of the unique number a user name would be ok for this portal as well. It has not effect onto the user names on the national Wikis anyway.
• After a succesful login in this portal one should get a list of connected accounts as hyperlinks to the user pages. So the user can go from there to en:, commons:, fr:, de: and so on.

No opinions? -- Simplicius 04:12, 22 November 2005 (UTC)

Talk Page

Will there be an option for a global talk page for a user? Or will I have to keep the redirects on my 15-odd wmf accounts? This was one of the primary reasons I wanted a single login. —Ilyanep (Talk) 01:11, 6 February 2006 (UTC)

As well as that, I'd like to be able to share preferences -- will that happen? If these two are not implemented, then there go my two primary reasons for being so vocal in favor of these. —Ilyanep (Talk) 02:21, 6 February 2006 (UTC)

Why merge?

It sounds like attempting to merge user namespaces will cause no end of trouble, and yet it's the only proposal people are talking about on the content page. Why do we want to do that? Why can't each user have a home wiki and be identified by that wiki if they go elsewhere? (For example, on en: I would be Rspeer, and here I would be Rspeer@en.wikipedia.org.)

This also has the advantage of being compatible with OpenID, should we ever want to transition to it.

Rspeer 19:51, 1 March 2006 (UTC)

See [1] and [2].--Eloquence 21:16, 1 March 2006 (UTC)

Okay, so there are some things that would be nicer and more cohesive. But look at the proposal. It has 21 steps, many of which have to be implemented by developers in their copious free time. It requires a certain set of users to all go through a process they are unlikely to understand, and gets hung up if any significant proportion of them don't. It also turns editcountitis into a formal institution. More reasonable proposals than this have fallen flat on their face due to complexity.

I imagine that if this were proposed on en: (yes, meta is the appropriate place, but of course due to multiple logins nobody reads meta), it would reach nothing close to consensus.

My proposal would be to use namespaces, and enable linked accounts. A user who really does participate actively in multiple projects already has multiple usernames, they'll just get a common watchlist and the benefit of not being logged out. None of those usernames will be "foreign". For editing on an actually "foreign" wiki, where the user hasn't created a linked account, I think it's actually useful to distinguish such edits. For example, I went and fixed an error on de: that had been copied from en:, despite that I don't know any German. If someone tries to respond to Rspeer@de about it, I'll never see it and I won't understand it anyway. It would be much better for the edit to point to Rspeer@en in that case, marking that I do not regularly contribute in German.

Rspeer 15:40, 2 March 2006 (UTC)

The problem is that the intent is to have a unified account namespace. Not doing it would indeed be easier, yes, but...

James F. (talk) 21:14, 2 March 2006 (UTC)

I thought the intent was a single login, so that people could move between projects without being logged out, and so people could have a unified watchlist. Those seem to be the features requested. People are not asking for a mandatory process of merging linked accounts (look at how badly en: just reacted to Special:Confirmemail) or for their username to be taken away because their edit count is too low. Rspeer 16:18, 4 March 2006 (UTC)

I think it'd be really nice to have a unified talk page. And being identified as "Ilyanep@en.wiki" would just be ugly. And I already have like 15 accounts that I'd like to have merged .—Ilyanep (Talk) 19:44, 4 March 2006 (UTC)

Well, sorry Rspeer, but you're wrong. A single time login would be difficult pan-Wikimedia (read: impossible without a complete bodge to do with cookies for a domain like wikimedialogin.org or whatever). This is about having a single user login - one username, and one password to go with it - which you can use everywhere.

James F. (talk) 09:23, 5 March 2006 (UTC)

Letter A

I propose making it like this:

As part of structural improvements to improve the Wikimedia systems, all user accounts are being migrated to global status across all Wikimedia projects - Wikipedia, Wiktionary, Wikiquote, Wikibooks, Wikisource, Commons, Meta, and all of the others. In order to facilitate this process, we encourage you to set a valid e-mail address on any accounts you may have.
Thank you for your patience during this process. Happy editing!
Yours,
--
The Wikimedia Development Team

(note the addition of the sentence at the end of the first paragraph) —Ilyanep (Talk) 19:45, 4 March 2006 (UTC)

Same user name across sites = bad

Here, on the English Wikipedia, and at the Commons, I'm User:Simetrical. On the Hebrew Wikipedia, however, I'm he:User:סימטריקל. Forcing people who frequent sites that use different scripts to use the same name on all the sites is a bad idea, unless we want tons of untypable Hebrew and Arabic and Cyrillic and Chinese user names on English sites. So unless you want to restrict non-English sites to English characters for usernames, it seems like allowing different names for the same user would be a must.

This would, needless to say, solve the name-conflict problem. An implementation that seems sensible would be 1) create a central table of names used on any Wikimedia project, 2) stop any new signups from using those names, 3) implementing the central profiles with separate names stored for each project, and 4) when a user makes his first edit to a specific project while having made edits previously to one or more other projects, prompt him for a project-specific name, check it against all other project-specific names on all other projects, and use it from then on for that project if it passes. This would mean that conflicting names would be "grandfathered in", but no new ones could be created, while preexisting ones could be resolved by negotiation if desired. Simetrical 02:45, 6 March 2006 (UTC)

There should definitely be allowance for different names in different charactersets, if not one per project. This could be done by having per-project aliases associated with the central user-record. As for grandfathering in old conflicts, that makes it harder to develop good all-project metadata about users. The lack of any prominent hard-to-resolve conflicts makes this a difficult discussion to have in the abstract. (Do you know of any?) Sj 22:02, 7 March 2006 (UTC)

Aliasing would probably be the best idea, although I still go by Ilyanep on the russian wikipedia rather than ильянеп (although I probably have something like 10 edits there so it's not really that important to me) —Ilyanep (Talk) 00:24, 10 March 2006 (UTC)

"As for grandfathering in old conflicts, that makes it harder to develop good all-project metadata about users." Not at all, because the metadata could be based on internal ID (perhaps the internal name could default to "name@project" or something like that if there's a conflict). If, hypothetically, w:User:Simetrical were a different person from me, I would be assigned the internal name "Simetrical@meta" and he the internal name "Simetrical@wp-en" or something, and metadata could be collected accordingly irrespective of the name of my userpage.

And no, I'm not aware of any serious conflicts, but I'm sure there are one or two, plus countless non-serious conflicts. Simetrical 05:14, 12 March 2006 (UTC)

Hoi, the choise of a username is a private choise. I am GerardM everywhere. My bot is called RobotGMwikt everywhere. The choise of how you want to be known is yours. When your user is in Arabic script on a Russian language project that should be fine. GerardM 12:34, 10 March 2006 (UTC)

Not if two users have Arabic usernames, and nobody can tell them apart because nobody knows Arabic. Especially, for that matter, since many people on the Russian project would probably not have bothered installing RTL language support, and consequently would see the Arabic name as a series of boxes or question marks. So if you have to use the same username across namespaces, either everyone would be totally confused by all these Arabic- and Hebrew- and Chinese-project users coming in and posting under borderline-indistinguishable usernames (surely unacceptable), or all languages would be forced to use Latin-like characters (also unacceptable if Mediawiki wants to be in any way global). Simetrical 05:14, 12 March 2006 (UTC)

When people do not bother to install fonts, then that is their option. There are many different fonts that people need to install to see all the possible usernames. I do not have the font for Cherokee on this computer. You consider something "surely unacceptable". I disagree. GerardM 19:13, 12 March 2006 (UTC)

I don't think aliases are a must -- for now you can simply maintain two separate accounts -- but they would be a nice feature to consider once we have completed the first migration stage. I also feel that in principle, the "black rectangle" problem of missing fonts is an operating system and application level problem. Frankly, when your browser sees that you're missing a certain font, it should prompt you to download it. If more black rectangles raise the awareness that this is not the best way to deal with international fonts, so much the better. It's also true that many operating systems these days (I'm working on Ubuntu here, for example) come with very good international font support.--Eloquence 17:50, 29 March 2006 (UTC)

Int size

...user_id int(5) unsigned... WOuld need to allow at least 6 possible 7 digits. Rich Farmbrough 18:42 14 March 2006 (UTC). 18:42, 14 March 2006 (UTC)

Alternative: Parallel Running

If merging multiple accounts proves too complicated and "unacceptable" then what about alternatively running the old local userspaces in parallel alongside a new global userspace?

After a set date, all new account creations are in the new global userspace.

Current users are then "coaxed" with polite messages to create new global user accounts before another set date (sufficiently in the future to give everyone a fair chance), when the old local userspace system will be retired.

Also, on the old local user account pages, a "retire this account" button is added which allows users to retire old local accounts before the secondary date (those who are kind enough to do this, signal that they've made a brand new global account and that their old accounts can be retired and shut down permanently).

This is fractionally less convenient (but it shouldn't prove greatly so: Current users copy over and manually merge their current user and talk pages into the new global user page. It's comparable to editing any other Wikipedia page and should only need to be done the once) than merger but it would handle the majority of "conflicts" automatically. A "start from scratch" mentality.

This is just a suggestion. Feel free to shoot it down, if it proves to have some serious flaw that I've failed to appreciate.

Also, when will the transition be likely to happen? As logging in multiple times is really, really annoying me at the moment and I'm desperate for wanting the new system here. PetrochemicalPete 14:57, 20 April 2006 (UTC)

How shared?

I'm having a little trouble from the proposal understanding exactly how much would be shared across the wikimedia projects. I understand that username and account settings would be shared, but what about User pages? Personally, I'd like to see a single user page for all projects When migrating, user's could choose which of their current user pages would be used. However (and this probably complicates things), I'd imagine the user's talk page would still be project specific, but with the "new messages" alert showing up in any project, with a link to the appropriate talk page. Another (simpler, I believe) option rather than sharing a user page would be to allow inter-wiki redirects, which I don't believe currently works (see User:Bmearns), so user's could just redirect to their preferred user page from all proejcts. But I'd still love to see "new messages" alert pop up on all projects when the user's logged in. Not sure how practical that is.

One last thing would be the watch list. Having to check a seperate watch list for each project you're active on is a bit a of nuisance, it'd be fantastic if it could all be accessed at once (perhaps selectively).

Finally, a quick question: is this feature expected to be part of the MediaWiki software, or implemented specifically for the Wikimedia projects?

Bmearns 13:08, 16 May 2006 (UTC)

Account settings would not be shared (well, not all of them; the email account and password would, obviously). Things like sig, interface language, stub threshold, and skin would be wholly local, and user pages would also remain as they are now.

There is scope, longer-term, for having pan-wiki "new messages" alerts, watchlists, etc., but for now the changes are going to be restricted almost entirely to the login process.

James F. (talk) 19:16, 16 May 2006 (UTC)

Thanks for the clerification. Bmearns 19:32, 16 May 2006 (UTC)

Wait, clarify some more. No pan-wiki watchlists (which is what would actually get people to contribute between projects), and userpages are still local to the particular wiki? Does this proposal do anything except the equivalent of automatically registering you for every wiki when you're registered for one? Rspeer 03:20, 21 May 2006 (UTC)

Not yet; obviously, these features would become possible, but their creation is not within the scope of this phase of the project.

James F. (talk) 14:16, 4 June 2006 (UTC)

I'd be more interested in multiple watchlists for a single wiki - my en.wp watchlist is hard to use due to the sheer number of pages I have watchlisted as it is, and I wouldn't want meta/etc topics added to it to make it worse... - SoM 00:42, 9 July 2006 (UTC)

Yes! Multiple watchlists on a single wiki would be extremely useful. There are pages to be watched constantly (a short list, for me), and others where we just want to check on very occasionally (a long list, for many of us).

On the other hand, it would also be very cool to have the option of showing our watched pages from more than one wiki on one page. Or perhaps linked from our watchlist page. This would be useful for those who only rarely login to certain wikis (e.g. the Indonesian and Malaysian Wikipedias, in my case). --en:User:Singkong2005, Singkong2005 04:02, 7 August 2006 (UTC)

Conflict checker tool

For what it's worth, here is a tool that checks for conflicts across the wikis for a single username. It's slow, but maybe it will give interested individuals an idea of what to expect. --Interiot 22:20, 18 May 2006 (UTC)

Beyond Wikimedia?

Is there any prospect of cross-wiki logins being extended to other wikis that wish to opt-in, in future? I'm active in Appropedia (a development-related wiki) and I'd like to see it as integrated as possible with other wikis.

Or is this kind of thing going to become simpler with some kind of OpenID system in future? (And is this the near or distant future?)

I've suggested the possibility of Appropedia joining Wikia.com, which would achieve some of what I'm thinking about. Any other suggestions welcome. --Singkong2005 05:37, 7 August 2006 (UTC)

OpenID is a possible extension building upon the work that SUL will involve, yes; things are still uncertain post-SUL as to what direction will be taken.

James F. (talk) 09:15, 20 August 2006 (UTC)

OpenID is just one protocol to provide authentication. While it is a step up, it does not fulfil all the needs that we have with respect to authentication. When we implement something we could implement A-Select, this can include OpenID. GerardM 20:06, 20 August 2006 (UTC)

identical e-mail Address - inappropriate and not acceptable

I have different e-mail Adresses on different projects and I need that to remain so. SPAM detection is language dependant. I want e-mails of different projects separated in separate mailboxes, for clean archiving, I am assigning way different base priorities, and varying temporary priorities to them, depending on my role in a project, and actual engagement in ongoing or current activities of that wiki. I currently have ~50 logins (estimated) @ wikimedia projects, having more logins available, I might at least insert more interwiki links in those projects where I currently do not, that would sum up to ~300 projects and mailboxes. Dumping them all almost inseparably in one big whole would imho create an unacceptable mess. -- Purodha Blissenbach 22:48, 9 August 2006 (UTC)

If the e-mail addresses are unique to each project&language account, how on Earth would they get any spam in the first place? We aren't in the habit of revealing contributors' e-mail addresses to spam-bots.

James F. (talk) 09:14, 20 August 2006 (UTC)

Using e-mail addresses in a confirmation e-mail is already enough. You reveal any e-mail address in any email that is not transported entirely using a protocol which encrypts e-mail addresses. SPAMmers spoof or eavesdrop on every online communication. You need not do anything but using them. Btw. mailbox names of up to 8 characters are per se known to SPAMmers since they systematically try them all, with all domains known to them. At the moment I am not getting SPAM to the mailboxes I've given to Wikimedia projects. But they're seldom used, too. -- Purodha Blissenbach 20:31, 20 August 2006 (UTC)

With respect, you are expecting something from e-mail that is intentionally missing. It is, with regard to your request, "broken by design".

James F. (talk) 23:11, 20 August 2006 (UTC)

Failed e-mails should not have any implications

In the transit sectiona: Optionally, e-mail notifications which bounce because of a permanent failure could lead to immediate expiration. is imho a bad idea. It's not necessary. If some troll has his most hated admins e-mail address, he might decide to SPAM flood or DOA his mailbox for a while so as to cause him trouble. "Mailbox full" or "no response from remote stmp server", etc. Why accept this risk? -- Purodha Blissenbach 23:20, 9 August 2006 (UTC)

Wikimedia Login

What are you going to do about accounts on the foundation site. I assume you will attach them to the same system, but only 'approve' certain ones. Still, I thought that I ought to mention it. Daniel (‽) Check out Wikiscope! 18:00, 17 August 2006 (UTC)

The private wikis will probably have the "read" and "write" privs used (and, for some of them, both denied from anons); if this doesn't get done, they will have to keep their own log-in systems.

James F. (talk) 09:11, 20 August 2006 (UTC)

Name changing and the power of bureaucrats

Forgive me if this is discussed elsewhere, didn't notice it after some precursory examinations. With current arrangements, local project appointed bureaucrats are responsible for username changing, which fits in pretty well with their responsibilities. After implementation of single login, assuming this doesn't change, they (people given a status by local procedure) will be able to make a globally reaching decision. While I trust the bureaucrats in general as they represent a consensus of the project they work on, it's still a bit unsettling. 69.255.49.246 (w:en:User:PoptartKing) 07:10, 20 August 2006 (UTC)

That is a consideration, yes; however, asking the Stewards to take back the functionality may mean that renaming requests go the way of all flesh.

James F. (talk) 09:09, 20 August 2006 (UTC)

I have different user names.

Hello! I have several user accounts with different user names. Will I be able to unite these also into an WikiMedia account? I have the same email address. --84.153.80.71 16:02, 15 October 2006 (UTC)

I like it

The longer this is delayed the more difficult it will get to impliment. --Cat out 20:56, 27 October 2006 (UTC)

Talk and other confusion

Would it be possible for an (optional perhaps) talk/user page integration? It would be convenient, you could perhaps only have it in the languages of those Wikis you're involved with, but it would save a hell of a lot of time editing my userpages when I have new accounts and such. Plus with an integrated talk page I wouldn't have to go around checking my talk pages on all the projects I'm involved with every few days. +Hexagon1 ^(t) 08:57, 2 November 2006 (UTC)

Status?

Just curious, but what is the status of the single login implementation? Thue 21:03, 6 November 2006 (UTC)

Yes, is it actually going to go through? -Royalguard11(Talk·@en) 00:52, 16 November 2006 (UTC)

Bad idea

This single logon worldwide project seems like a solution in search of a problem, and likely to create a lot of hard feelings and departures of productive editors from all the Wiki projects. Many of us do not have any email attached to our usernames. I personally do not want to make it easy for someone I have offended to track down my real name and address, and I am not sure how to create a Wiki-only email which is adequately anonymous. The whole notion appears to assume that more people are multilingual than is in fact the case. If people in different language Wikipedias have independently chosen the same username, who wins? Calendar seniority, number of edits, registration in the most projects, or presence of an email? 24.13.253.255 16:44, 28 November 2006 (UTC)

Setting an e-mail address in special:preferences doesn't actually make it public. The only thing it enables is some e-mail functions, including the E-mail this user one - but even that doesn't show your e-mail address to anyone, it's safely stored in the Wikimedia servers. — Timichal 17:30, 28 November 2006 (UTC)

I'm with you here, 24 (as you can see from my comments in other sections above). Here's what I believe about this proposal:

• It only survives because it's hidden away on Meta, which hardly anyone reads.
• If it were run through the proposal process of any large, active Wikipedia, such as en:, it would go down in flames. But here it is on Meta, not even as a proposal, but as a decree that it's simply going to happen. (I'd support seeing this proposal actually proposed on en:, and if it actually got a consensus in favor of implementing it, I'd withdraw my objections.)
• It earns support because of its misleading name. All it gives you is a single username. The phrase "single login" implies that you'd log in once and be logged in on all wikis. That's not part of this proposal, and it may not even be possible given how cookies work. The proposal makes people hallucinate all kinds of nice features, like an actual single login to edit all projects, a single watchlist, a single user page, and a single user talk page to check for messages. These features are not in the proposal, and implementing them would involve difficulties that are independent of the single username issue.
• It asks MediaWiki developers to implement a complicated 21-step process. If we end up with developers having that much free time, I'd like them to resolve 21 bugs and feature requests instead!

Rspeer 00:50, 21 December 2006 (UTC)

This proposal, as written, is not the one that will be implemented. The details are at the Subversion code repository. Titoxd^(?!?) 22:10, 21 December 2006 (UTC)

It looks like essentially the same proposal. Make people use one name across different languages, provide nothing but a consistent username/password across all sites, and have conflicting accounts fight to the death with their edit counts in a many-step process. Rspeer 23:41, 21 December 2006 (UTC)

Disallowed foreign characters on English Wikipedia WILL KILL PROPOSAL!

If I attempt to use a single, trans-wiki login with a Japanese username then attempt to access the English Wikipedia, then BANG! A bot will auto-block it! Why? Because it doesn't use Latin characters!

Unless that rule gets changed, then KAPOW, this proposal will get shot down!

If you have a feasible way to place the single trans-wiki login feature while still disallowing non-latin charactered usernames from the English Wikipedia, please share it with us. Thanks. --72.205.241.187 05:14, 19 January 2007 (UTC)

Indeed. That auto-block is an abhorrent monstrosity and should be killed ASAP. —Nightstallion (?) 15:59, 20 January 2007 (UTC)

That was discussed very recently, and the relevant portion of the policy was abandoned. See Wikipedia talk:Username. Titoxd^(?!?) 23:20, 20 January 2007 (UTC)

So how do I type in a username that includes non-latin charecters into the adress bar? Firefoxman 16:09, 3 June 2007 (UTC)

YOU certainly won't need to. But those who might have the need do know how. (Besides: you don't need to type anything into the address bar to navigate Wikimedia wikis. Ask your elder sister for assistance if you don't know how to click on links.) 84.141.104.232 05:46, 18 July 2007 (UTC)

A pretty dumb comment. Just because you don't have a need or desire to go directly to a page via the address bar or via a command line doesn't mean no one else does. 24.90.17.134 23:30, 4 August 2007 (UTC)

• You may use the unihan database to find their unicodes if you have not got the suitable input system. -- Hillgentleman 22:28, 5 August 2007 (UTC)

Or you might simply enter the characters on the address bar and let the browser do the necessary escaping. Works in all browsers I have. Oh, and Safari even converts the escape codes in the URL's of pages you navigate to back to international characters for display. The rationale is probably that escapes in URL's are part of the encoding and thus shouldn't be visible to the user, just as with normal text in webpages. 82.139.86.4 11:01, 9 June 2008 (UTC)

does sul exist yet?

I'm not clear if this issue is still being worked on or has been implemented already. If it is supposed to work already, I found a bug: I was prompted to create a new account for a different language Wikipedia. 76.80.189.144 01:50, 19 March 2007 (UTC)

EDIT by same user: In fact, I am annoyed that I would need to create a new account on Meta! I didn't realize it until after posting the first comment. If you guys care, I'm Stagefrog2 on en and simple. 76.80.189.144 01:53, 19 March 2007 (UTC)

Not implemented on Wikimedia wiki. So it's not a bug.--Aphaia 05:00, 21 March 2007 (UTC)

All languages and projects?

So your username will be the same for all projects in all languages? (ie. User:ABC will be ABC on the English Wikipedia, Chinese Wikipedia, and Swedish Wiktionary?) — The preceding unsigned comment was added by 69.117.143.204 (talk) 2007-06-05T03:17:25 +0700 (UTC)

Don't like this

moved to Help talk:Unified login#Don't like this

This is completely unacceptable

moved to Help talk:Unified login#This is completely unacceptable

Unified Login is working now !!

It seems SUL is working now and you can see how it works by clicking on Special:MergeAccount.--Cometstyles 13:38, 13 March 2008 (UTC)

There's no such special page. It only exists on the Test Wiki, where it is in testing and does not actually implement the merge. —{admin} Pathoschild 16:00:34, 13 March 2008 (UTC)

nah, actually you missed it, it did work for an hour or so, i have proof..somewhere, but Tim ended the beta test, though some of us have already unified our account :D ...--Cometstyles 16:18, 13 March 2008 (UTC)

Me too. :D

I enjoyed it, and found a problem. Its comparison manner of e-mail address was case-sensitive. I understand that e-mail addresses are generally not case-sensitive.

I don't know whether we, Cometstyles and I, saw exactly same tool or not, however. What I saw was just a demo mode. I understand that it was a "dry run", which allowed us to experience and evaluate its user-interface, and to see what will happen, without changing anything actually. --Kanjy 10:14, 14 March 2008 (UTC)

See en:E-mail address#Limitations: The local-part of an e-mail address (= the part before the @ sign) is in fact case sensitive. --UV 21:07, 14 March 2008 (UTC)

The Wikipedia Signpost just linked to this page as "single user login". The top of this talk page, however, says this isn't the current proposal and is outdated. Can someone in the know redirect this to the actual page? 98.216.48.4 05:17, 23 March 2008 (UTC)

Deletion of Global acc

Hi! I would like my global account deleted so that I can change my en.wiki acountname (en:kaddkaka) to "Moberg". I hope this is an OK place to ask because I didn't know where to ask, but User:WJBscribe pointed me here. –dMoberg 20:06, 16 April 2008 (UTC)

Try Steward requests/SUL requests. EVula // talk // ☯ // 20:25, 16 April 2008 (UTC)

Auto login

I noticed that it now retains my login information as I go to different lang wikipedias, but I still have to log in again for wikiquote, etc. Are there any plans to make it work across all wikis? —Random832 20:10, 29 May 2008 (UTC)