Thomas Corell wrote:
There is the problem that some users want and have different usernames in different wiki's. The only way to handle this is keeping all those 'lokal' users and first of all allow additional sigle-signon on the 'Master user DB' which should handle not only single-sign-on, but even all those lokal user accounts.
Couldn't we use the wikimedia.org domain name for handling user logins? That way a user only has to sign into their WikimediaOne login and will then be logged-in to every Wikimedia project and subproject.
But before that happens (and periodically after) we may want to flush out several thousand en.wikipedia user accounts that have been 1) idle for more than say 3 months and 2) have fewer than 10 total edits since the account was created.
That would free up many user names so that actual contributors can use them.
-- Daniel Mayer (aka mav)
Daniel Mayer wrote:
Couldn't we use the wikimedia.org domain name for handling user logins? That way a user only has to sign into their WikimediaOne login and will then be logged-in to every Wikimedia project and subproject.
The database with the needed tables don't worry about the DNS-name, I'm sure of that. I'm sure we can handle the nessessary rights to access all needed tables, even the user.tables in the different languages, without needing a DNS entry for it.
And the loginpage will be the nearly the same, only with a few more possibilities, most of this change happens in the background, thats the idea behind it. Of course we have to get all the parts in the CVS where there are calls to the user table and change them. But I think if we realy plan to do it this way it's a huge change, usually for more than one developer. I can e.g. try to created a proper proposel and write a lot of the things down, but I don't think i'm able to fix all php-pages etc. because I'm still not read and understand them all.
But before that happens (and periodically after) we may want to flush out several thousand en.wikipedia user accounts that have been 1) idle for more than say 3 months and 2) have fewer than 10 total edits since the account was created.
That would free up many user names so that actual contributors can use them.
1) is ok. but that's needed for all wikipedias, and although it should be a regular thing we need to do. 2) very bad. We will get [[User:foobar]] links marked red, and someone starts filling them (we had one case in the wiki.de). And we get those links in the history of pages.
I would prefere the solution I mentioned in earlier mails, to mark those users, instead of 'sysop' or 'bot' with the keyword 'delete'. If we modify that function that making links, in a way that a deleted user don't get a proper link, but only the text, we are keeping all pages sane (we don't need to fix them) without to much effort. (E.g: [[User:Smurf]] (undeleted) --> <b>Smurf</b> (deleted user)).
Sorry for the stupid subject of the privious mail, I forgot to change it.
GMX don't like yahoo ;)
Daniel Mayer wrote:
Couldn't we use the wikimedia.org domain name for handling user logins? That way a user only has to sign into their WikimediaOne login and will then be logged-in to every Wikimedia project and subproject.
No, that wouldn't work very well. Cookies are domain-specific, and so people need to be on the wikipedia domain so we can set a .wikipedia.org cookie.
--Jimbo
Jimmy Wales wrote:
Daniel Mayer wrote:
Couldn't we use the wikimedia.org domain name for handling user logins? That way a user only has to sign into their WikimediaOne login and will then be logged-in to every Wikimedia project and subproject.
No, that wouldn't work very well. Cookies are domain-specific, and so people need to be on the wikipedia domain so we can set a .wikipedia.org cookie.
Are you sure wikimedia.org can't also set a cookie for the wikipedia.org domain?
Timwi
On Fri, 11 Jul 2003, Timwi wrote:
Jimmy Wales wrote:
No, that wouldn't work very well. Cookies are domain-specific, and so people need to be on the wikipedia domain so we can set a .wikipedia.org cookie.
Are you sure wikimedia.org can't also set a cookie for the wikipedia.org domain?
It could redirect to a page on wikipedia.org that sets a wikipedia.org cookie, but I'm not sure what the point of the exercise would be.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
Are you sure wikimedia.org can't also set a cookie for the wikipedia.org domain?
It could redirect to a page on wikipedia.org that sets a wikipedia.org cookie, but I'm not sure what the point of the exercise would be.
Right. It's absolutely true that wikimedia.org can't directly set a cookie for wikipedia.org. It's also true that we could wing it with some complicated redirects. But I see no good reason to do that!
I'm not sure where this suggestion was coming from, exactly, or what the point was supposed to be.
My thinking is that for the foreseeable future, wikimedia.org will just be a page describing the foundation, with nice pretty pictures of all the Ivy-covered buildings on our expansive campus, and information about how our billion dollar endowment is invested. Oh, wait, I'm dreaming, sorry.
But, anyhow, the wikimedia.org site isn't going to take the place of wikipedia.org as the main portal for people to sign in.
The only reason, really, for the wikimedia name is (a) it sounds cool and (b) it points towards the idea that we have a grand vision for the future that is multi-media, that is beyond just the encyclopedia, etc.
But, for now, we're the encyclopedia.
--Jimbo
Jimmy Wales wrote:
My thinking is that for the foreseeable future, wikimedia.org will just be a page describing the foundation, with nice pretty pictures of all the Ivy-covered buildings on our expansive campus, and information about how our billion dollar endowment is invested. Oh, wait, I'm dreaming, sorry.
Hmm! I wonder if we could adapt Vaughan Monroe's #1 hit from 1949 to "Ghost Writers in the Sky" as a theme song. ;-) Ec
The issue of unifying user names on a new phase, and the problems of maintaining article histories, is related, i think, to the notion i recently stated about the need for cross-langa transfers of articles, and a history related to these transfers. The idea of making something built willy nilly jive with something designed to the tits with structure seems -- as anyone will admit -- far fetched. But structure is whats required when integrating stuff -- and if structure is the key, then its got to be made to fit the hole that WP is in -- namely that of not living up to the teenage imagination.
When looked at from a macro-pedia point of view -- boiling it all down and considering trends in WP's IA -- the "next step" is looking like the long dreamt-of WP XML schema - as the foundation for a highly integrated, cross-langa manifestation of complex yet sublime brilliance. Of course it wasnt built that way... the much lauded simplicity-of-editing is the prime factor in a Wiki. Though compared to what the WP will someday be... the first Meatballish incarnation was but a cheezy homepage. (I wasnt around then, but I see other Meatballs around....)
The question then becomes, how might more advanced technologies actually integrate with Willy Nilly in a reasonable way to create the foundation for something that has titties. If its just a question of porting all of what exists to a new, unified Wikipedia system, then there are bound to be a few conflicts. I'm *not convinced that these anomalies exist in such a quantity that they couldnt be dealt wih by hand, or that these amount to anything thats worth discounting a potentially advantageous paradigm shift.
You cant make an omelet...
Wikilovin be greetin you, -S-
__________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
We *COULD*, but it would be rejected by some browsers. Some browsers don't allow cookies to be set by one domain to be used by another. This also leads to the next question:
If wikimedia.org sets the domain for a cookie to wikipedia.org and the browser DOES acceept the cookie, will the cookie ever be given to wikimedia.org by the browser?
And the answer here is "no". The wikipedia.org cookie would only be included in the HTTP request for pages in the wikipedia.org domain, even if wikimedia.org set it in the first place.
Jason
Timwi wrote:
No, that wouldn't work very well. Cookies are domain-specific, and so people need to be on the wikipedia domain so we can set a .wikipedia.org cookie.
Are you sure wikimedia.org can't also set a cookie for the wikipedia.org domain?
Timwi
Wikitech-l mailing list Wikitech-l@wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Jason Richey wrote:
If wikimedia.org sets the domain for a cookie to wikipedia.org and the browser DOES acceept the cookie, will the cookie ever be given to wikimedia.org by the browser? And the answer here is "no".
It is possible to set several cookies in a single request response. Thus: Set the same cookie for several domains.
We *COULD*, but it would be rejected by some browsers. Some browsers don't allow cookies to be set by one domain to be used by another. This also leads to the next question:
I see where /that/ would be a problem... :(
Nevertheless, I suppose we could still create a central user database. Although users would have to log in for each domain, they would still log in to the same account, retaining the same Wikimedia-wide preferences, etc.
Timwi
Jimmy Wales wrote:
Timwi wrote:
Nevertheless, I suppose we could still create a central user database. Although users would have to log in for each domain, they would still log in to the same account, retaining the same Wikimedia-wide preferences, etc.
Right! Doesn't sound too bad to me.
It still leaves the problem, as someone already mentioned, of people who want a localised user name. For example "Boris the Inquisitive Goat" might want to be known as "Boris la Chèvre Investigatrice" on the French Wikipedia.
We could tell them "tough luck". Or instead of a central database, a user could have a collection of "linked" user accounts, with synchronised preferences (incl. password) and automatically generated interlanguage links on user pages. Implementing this in the current scheme would be relatively simple compared to some of the other suggestions made here. It would require the various wikis to be able to connect to each others' databases. There could be performance issues if users create *lots* of linked accounts, but if that becomes a problem we can always update in batches to save on the connection overhead.
-- Tim Starling <tst.ar.li.ngphy.sicsun.i.melbed.uau> (fix punctuation to email)
Tim Starling wrote:
Jimmy Wales wrote:
Timwi wrote:
Nevertheless, I suppose we could still create a central user database. Although users would have to log in for each domain, they would still log in to the same account, retaining the same Wikimedia-wide preferences, etc.
Right! Doesn't sound too bad to me.
It still leaves the problem, as someone already mentioned, of people who want a localised user name. For example "Boris the Inquisitive Goat" might want to be known as "Boris la Chèvre Investigatrice" on the French Wikipedia.
Just let one account have different nicknames in different languages. This gives us the extra bonus that someone wanting to be named a lengthy "Boris the Inquisitive Goat" could still use something as short as "Boris" for a login identifier.
Timwi
It still leaves the problem, as someone already mentioned, of people who want a localised user name. For example "Boris the Inquisitive Goat" might want to be known as "Boris la Chèvre Investigatrice" on the French Wikipedia.
WARNING: you might not understand this unless you have seen my previous post about the single logins.
We might have a wikimedia domain login, with it's single userID, have mapped nicknames based on each domain, but the actual login name would be the same. We culd have a nickname table that mapped nicknames to a userid based on a domain. Basically an alias system....
Lightning
Before we go tearing our hair out, we should probably actually *check* to see how many duplicate names we've got to deal with.
If the number is quite small, which I expect it is, conflicts could simply be resolved by (consensually) renaming a few accounts.
-- brion vibber (brion @ pobox.com)
Brion Vibber, who may be me, wrote:
Before we go tearing our hair out, we should probably actually *check* to see how many duplicate names we've got to deal with.
If the number is quite small, which I expect it is, conflicts could simply be resolved by (consensually) renaming a few accounts.
Okay, I ran a little script to check over the user tables and spit out names that are registered on multiple wikis which don't all match in either e-mail address or password. I haven't yet checked any of the accounts for activity, nor have I visually checked the e-mail addresses for signs of similarity, nor their user pages. Certainly there are plenty on the list that do belong to the same person. :)
False matches (can follow a chain between matching emails and password hashes but the script didn't catch them): [2] Den fjättrade ankan (da,de,sv,en) Luca Masters (da,de,eo,es,fr,nl,pl,sv,en)
Partial matches: [30] A (de,ja,pl) -- match: de,pl -- out: ja Abc (pl,sv,en) -- match: sv,en -- out: pl Alex (de,fr,nl,sv,en) -- match: sv,en -- out: de,fr,nl Alvaro (meta,da,de,es,fr,nl,pl,sv,en) -- match: meta,de,es,sv,en -- match: nl,pl,da -- out: fr Aoineko (meta,es,fr,ja) -- match: es,ja -- match: meta,fr Brion VIBBER (meta,sep11,cs,da,de,eo,es,fr,ja,ko,ms,nl,pl,ru,tr,zh,sv,en,he,hu,hi,sl) -- hehe, i let one or two get out of sync :) Calimero (nl,sv,en) -- match: sv, en -- out: nl Chd (meta,de,eo,es,fr) -- match: meta,eo,es,fr -- out: de Dexter (de,sv,en) -- match: sv,en -- out: de Emma (fr,sv,en) -- match: sv,en -- out: fr Folken (fr,sv,en) -- match: sv,en -- out: fr Fono (de,es,pl) -- match: es,pl -- out: de Hannes (de,sv,en) -- match: sv,en -- out: de Harald (nl,sv,en) -- match: sv,en -- out: nl JohnOwens (meta,de,ru) -- match: de,ru -- out: meta Kils (da,de,es,pl,sv,en) -- match: da,de,pl,sv,en -- out: es Mm (meta,fr,ru) -- match: meta,fr -- out: ru Pelle (de,sv,en) -- match: sv,en -- out: de Sakura (ja,sv,en) -- match: sv,en -- out: ja Samuel (eo,es,fr,ja,zh) -- match: eo,fr,ja,zh -- out: es Stefan (de,sv,en) -- match: sv,en -- out: de Stevertigo (meta,sep11,es,ar) -- match: meta,sep11,es -- out: ar Taw (meta,de,eo,fr,ja,pl) -- match: meta,de,eo,fr,ja -- out: pl TeunSpaans (meta,de,nl) -- match: de,nl -- out: meta Topory (de,es,fr,nl,pl,sv,en) -- match: de,es,fr,nl,sv,en -- out: pl Tor (pl,sv,en) -- match: sv,en -- out: pl Unukorno (de,eo,nl) -- all match Willy (meta,de,es,nl) -- match: meta,es -- out: de,nl WojPob (meta,de,pl) -- match: de,pl -- out: meta Youssefsan (meta,de,eo,es,fr,ja,nl,pl,ru) -- match: meta,de,eo,es,ja,nl,pl,ru -- out: fr
No two can be found to match: [98] AGiss (meta,fr) Aaa (de,pl) Aki (de,ja) Al (de,fr) Alberto (es,fr) Albin (de,fr) Alexx (de,fr) Ana (es,pl) Andres (de,es) Angel (es,zh) Anna (es,pl) Antonio (eo,es) Arno (meta,fr) Axel (da,de) Barbara (es,pl) Baruch (es,nl) Basil (meta,de) Ben (de,fr) Beyer (da,de) Boud (fr,pl) Cezar (eo,pl) Chris (de,fr) Chuck Smith (meta,de) Cicero (de,nl) Cyril (eo,fr) Daniel (de,bs) Dave (de,fr) Dug (de,pl) Eddy (eo,es,nl) Erich Nohe (de,es) Flo (de,fr) Flor (de,es) Frank (de,ja,nl,zh) Fritz (de,nl) General Wesc (meta,es) Geralmor (meta,es) Hannibal (fr,pl) Hans (da,de,es) Iris (de,nl) James (meta,es) Jerry (fr,pl) Jim (meta,de) Jojo (de,nl) Joselo (es,fr) Juan (es,ja) Jul (meta,fr) Julian (de,es) Kale (de,nl) Kid (de,es) Kriss (fr,pl) Laura (es,pl) Leonardo (de,es) Leonidas (de,es) Lila (de,pl) Lucas (es,nl) M (pl,ru) Marc (de,fr,nl) Marian (de,pl) Mario (de,es) Marisa (de,es) Mars (pl,zh) Martin (fr,nl) Max (de,es) Med (meta,fr) Miguel (eo,es) Miroslav Malovec (cs,eo) Mk (de,ja) Mrwojo (meta,eo,fr) Mswake (meta,fr) Murat (de,tr) Nabla (de,pl) Nick (de,nl) Ok (meta,zh) Pablo (es,pl) Paolo (de,es) Paul (eo,zh) Peter (de,nl) Pieter (meta,cs,nl) Qwerty (fr,nl) Rafael (eo,es) Rene (de,es) Seb (meta,fr) Sebastian (de,es,fr) Sergio (de,es) Shark (de,nl) Simon (de,zh) Snow (de,zh) Solar (pl,zh) Spade (da,de) TJ (meta,de) Tadeusz (da,pl) Thomas (de,fr) Toto (de,fr,ja,zh) Victor (es,nl,ru) Vladimir (eo,es) Wolf (de,es) Woody (fr,nl) 1 (ja,zh)
-- brion vibber (brion @ pobox.com)
Okay, I ran a little script to check over the user tables and spit out names that are registered on multiple wikis which don't all match in either e-mail address or password. I haven't yet checked any of the accounts for activity, nor have I visually checked the e-mail addresses for signs of similarity, nor their user pages. Certainly there are plenty on the list that do belong to the same person. :)
Not bad, but still not that good, I still would like to propose my system since its easy to implement, it centralizes usernames into one table. and it allows us to implement the wikimedia login system without disrupting service or breaking anything, all it would take is a couple of changes to the user login code. the basics are simple, the rest, like the alias system can be worked in at a later time...
I have since changed my idea bit though, I like timwi's idea of using the LJ-style userprop & userproplist tables. I reallythink that the user table should have as little columns as possible, say something like "e-mail, username, userId, password hash, registration date" and thats it. im even sketchy about registration date.
Lightning wrote in part:
I have since changed my idea bit though, I like timwi's idea of using the LJ-style userprop & userproplist tables. I reallythink that the user table should have as little columns as possible, say something like "e-mail, username, userId, password hash, registration date" and thats it. im even sketchy about registration date.
Actually, even e-mail isn't central to our user management. Quite a few users have no e-mail address -- none is required. I say "userId, username, password hash" -- that identifies the user. The rest -- even e-mail -- is for specific tasks of one sort or another, the material for userproplist.
-- Toby
Brion Vibber wrote in relatively small part:
Okay, I ran a little script to check over the user tables and spit out names that are registered on multiple wikis which don't all match in either e-mail address or password.
I've found an error in your results -- either that, or I don't understand their presentation.
False matches:
[Contains no "Miguel".]
Partial matches:
[Contains no "Miguel".]
No two can be found to match: Miguel (eo,es)
So what about [[en:User:Miguel]], who also exists? (And is the only of the 3 to have any user contibutions!)
-- Toby
Toby Bartels wrote:
No two can be found to match: Miguel (eo,es)
So what about [[en:User:Miguel]], who also exists? (And is the only of the 3 to have any user contibutions!)
Urps, bug in my script didn't count the English wiki properly. :)
New results, now also with a vagueified cache-update time* count of edits (from old table) by each account; accounts with no edits are discarded from this version:
* should be reset on each login, save of preferences, or watch/unwatch of page. An active user is fairly likely to trip an update to this field.
False matches, determined by checking chaining of common email/pwd hashes or user pages clearly showing a common user:
AGiss (meta,fr) (user page says same) Alvaro (meta,de,es,fr,nl,pl,sv,en) (one well-known id) Aoineko (meta,es,fr,ja,en) (one well-known id) BoogieMan (zh,en) (same) Brion VIBBER (meta,sep11,cs,da,de,eo,es,fr,ja,ko,ms,nl,pl,ru,tr,zh,sv,en,he,hu,hi,sl) (same!) Carey Evans (meta,en) (same) Castor (fr,en) (same) Chd (meta,de,en) (same) Chuck Smith (meta,de,en) (same) Den fj?ttrade ankan (da,de,sv,en) Elian (meta,de,en) (same) EntmootsOfTrolls (meta,fr,en) (same) Fred Bauder (meta,en) (same) Isis (meta,en) (same) JohnOwens (meta,de,ru,en) (known good id) Juanan (es,en) (presumed same; this is the guy who runs Enciclopedia Libre) Kils (da,de,es,pl,sv,en) Luca Masters (da,de,eo,es,fr,nl,pl,sv) Macar (cs,es,pl,en) (same) Maveric149 (meta,sep11,de,es,en,textbook,quote,wiktionary) Miroslav Malovec (cs,eo) (same) Quintessent (fr,en) (same) Roan (nl,en) (same) SJK (meta,en) (same) Saprtacus (meta,en) (same) Scott REDD (eo,en) (same) Steffen (de,en) (same) Stevertigo (meta,sep11,en,ar) (same) SwPawel (pl,en) (same) Taw (meta,de,eo,fr,ja,pl,en) (known id, same) Tbc (meta,en) (same) TeunSpaans (meta,de,nl,en) (presumed same; single meta edit) Unukorno (de,eo,nl,en) WojPob (meta,de,pl,en) (same) Youssefsan (meta,de,eo,es,fr,nl,pl,en) (known id, same)
Pretty sure they're *not* the same people: Alex (fr,nl,sv,en) (separate fr, en pages; look like different people) [fr] (inactive since April) 117 [nl] (inactive since April) 1 [sv] (inactive since April) 2 [en] (active in July) 267 Arno (meta,fr,en) (fr, en appear to be separate folks) [meta] (active in July) 1 [en] (active in July) 1092
[fr] (inactive since June) 84 Triton (de,en) (look unrelated) [de] (inactive since April) 56 [en] (inactive since June) 302
----
Dupe names, but not same email or password: A.Tigges (de,en) [de] (active in July) 1 [en] (active in July) 30 Al (de,fr) [de] (inactive since April) 19 [fr] (inactive since June) 1 Albin (de,fr) [de] (inactive since June) 2 [fr] (active in July) 101 Alex Anlicker (de,en) [de] (active in July) 806 [en] (inactive since May) 4 Chris (fr,en) [fr] (inactive since April) 1 [en] (inactive since April) 23 Cicero (de,nl) [de] (inactive since June) 25 [nl] (active in July) 6 Cluster (de,en) [de] (active in July) 13 [en] (inactive since May) 70 Cyril (eo,fr) [eo] (inactive since April) 3 [fr] (inactive since May) 5 Dave (de,fr) [de] (inactive since June) 16 [fr] (inactive since April) 34 Dexter (de,sv) [de] (inactive since May) 1 [sv] (active in July) 282 Dlloader (zh,en) [zh] (active in July) 42 [en] (inactive since April) 25 Folken (fr,sv) [fr] (inactive since April) 1 [sv] (inactive since April) 6 Fono (de,es,en) [de] (active in July) 25
[es] (active in July) 1 [en] (active in July) 1 Fritz (de,en) [de] (active in July) 2946 [en] (inactive since May) 3 G (ja,en) [ja] (active in July) 1736 [en] (active in July) 40 Gamma (es,en) [es] (inactive since April) 2 [en] (active in July) 106 Gebeleizis (eo,en) [eo] (active in July) 8 [en] (active in July) 33 General Wesc (meta,es,en) [meta] (inactive since May) 3 [es] (inactive since April) 2 [en] (active in July) 460 Gihelle (fr,en) [fr] (inactive since April) 27 [en] (inactive since April) 4 Graham Chapman (meta,en) [meta] 20030326083933 13 [en] (inactive since April) 394 H. Jonat (de,en) (same) [de] (inactive since April) 59 [en] (inactive since April) 671 Herodotus (nl,en) [nl] (inactive since June) 3 [en] (inactive since April) 1 Hirzel (de,en) [de] (inactive since April) 35 [en] (active in July) 722 Igor (pl,en) [pl] (inactive since June) 27 [en] (inactive since June) 13 Jacco (nl,en) [nl] (inactive since June) 1 [en] (active in July) 5 Jb (cs,en) [cs] (inactive since April) 2 [en] (inactive since April) 1 Jerome (fr,en) [fr] (inactive since April) 2 [en] (inactive since April) 5 Jerry (fr,pl) [fr] (active in July) 6 [pl] (active in July) 486 Jojo (de,en) [de] (inactive since May) 10 [en] (inactive since April) 2 Juergen (de,en) [de] (inactive since June) 549 [en] (inactive since April) 14 K (ja,en) [ja] (active in July) 50 [en] (inactive since April) 1 Kid (de,es) [de] (active in July) 2 [es] (inactive since April) 1 Klaus (de,en) [de] (inactive since April) 10 [en] (inactive since May) 102 Leo (de,en) [de] (inactive since May) 1 [en] (inactive since April) 1 Leonardo (de,es) [de] (active in July) 74 [es] (inactive since April) 42 Maciek (pl,en) [pl] (inactive since May) 14 [en] (inactive since April) 1 Magnus (de,en) [de] (active in July) 1903 [en] (inactive since June) 170 Marc (de,fr,nl) [de] (active in July) 37 [fr] (inactive since April) 13 [nl] (active in July) 1 Marian (de,pl,en) [pl] (inactive since April) 7
[de] (inactive since April) 2 [en] (inactive since April) 52 Marta (pl,en) [pl] (inactive since April) 18 [en] (inactive since April) 5 Marymary (de,es,en) [de] (inactive since May) 3 [es] (inactive since May) 3
[en] (inactive since May) 91 Max (de,en) [de] (inactive since April) 2 [en] (inactive since April) 2 Med (meta,fr,en) [meta] (inactive since March) 1
[fr] (active in July) 1613 [en] (inactive since June) 6 Milan (de,en) [de] (inactive since June) 2 [en] (inactive since April) 5 Nick (de,nl) [de] (inactive since May) 4 [nl] (active in July) 112 Oliver (eo,en) [eo] (inactive since April) 4 [en] (inactive since April) 17 Pascal (de,en) [de] (inactive since June) 10 [en] (active in July) 54 Paul (eo,zh,en) [eo] (active in July) 1339 [zh] (inactive since April) 1 [en] (active in July) 41 Pelle (de,sv) [de] (active in July) 1 [sv] (inactive since April) 33 Pieter (cs,nl) [cs] (inactive since June) 40 [nl] (active in July) 2162 Prometeo (es,en) [es] (inactive since April) 6 [en] (inactive since April) 3 Qwerty (fr,nl,en) [fr] (inactive since April) 2 [en] (inactive since April) 1
[nl] (inactive since April) 1 Reinhard (de,en) [de] (inactive since April) 17 [en] (inactive since June) 41 Rune (da,en) [da] (inactive since May) 6 [en] (active in July) 1 Sebastian (de,fr) [de] (inactive since April) 789 [fr] (inactive since April) 1 Shaihulud (fr,en) [fr] (active in July) 1806 [en] (inactive since April) 4 Sjc (meta,en) [meta] (inactive since March) 4 [en] (inactive since May) 4659 Spino (es,en) [es] (active in July) 1 [en] (active in July) 13 Stefan (sv,en) [sv] (inactive since June) 14 [en] (active in July) 47 TJ (meta,de) [meta] (active in July) 4 [de] (active in July) 4 Thomas (de,fr,en) [de] (inactive since April) 18
[fr] (inactive since May) 1 [en] (inactive since June) 70 Topory (de,es,fr,nl,pl,sv,en) [de] (inactive since June) 20 [es] (inactive since June) 2 [fr] (inactive since June) 2 [nl] (inactive since June) 2 [sv] (inactive since April) 3 [en] (active in July) 184
[pl] (active in July) 6551 Toto (de,ja) [de] (active in July) 105 [ja] (inactive since June) 1 Victor (es,ru) [es] (inactive since April) 1 [ru] (inactive since April) 6 Vinci (de,en) [de] (active in July) 522 [en] (inactive since April) 1 Willy (meta,de,es) [meta] (active in July) 33 [es] (active in July) 76
[de] (inactive since April) 9 Wing (de,en) [de] (active in July) 229 [en] (inactive since April) 28 Wizzer (meta,en) [meta] (inactive since March) 1 [en] (inactive since June) 37 Wshun (zh,en) [zh] (inactive since April) 3 [en] (active in July) 543
-- brion vibber (brion @ pobox.com)
What about me? There's a "Magnus" on de and en, but that's not me. I am (at least) in de and en as "Magnus Manske", as well as in text, textbook, meta, ...
Ok, I would love to see global log-ins, but yeah there is user conflicts and the problem of making the switch smoothly. Here is what I propose.
* Keep all existing Usernames; * Make a new type of global login from Wikimedia *All new users are made with the wikimedia domain *Wikimedia logins require that no one else have that name, anywhere *If one user has Jane@en.wikipedia and Jane@wiktionary and that is THE ONLY conflict present, allow her to merge the accounts (with a password validation) Inwhich case the account is coverted to a wikimedia login. * How does it work? easy.. ---If there is no name conflicts, the user is automatically moved to a wikimedia login, in which case he automatically has a global login name/password ---If there is a conflict, the users stay in their own logins. *We develop new "login" namespaces --For example I would be: Lightning@en.wikipedia --But if there is no conflict I would be Lightning@wikimedia *From then on logins have 2 parts, username and "domain" *That way we could have Jose@en.wikipedia and Jose@sp.wikipedia *If you go to sp.wikipedia.org it automatically assumes your login is @ the sp.wikimedia domain, but if it is not found there, it searches for it in the wikimedia domain. In the future, once more people have wikimedia logins than local ones, we can switch the default to wikimedia. *User pages and user talks: --Keep as it is, make each user have a different user page and user talk per domain. We could untie them all based on a PRIMARY KEY userId, but it would be confusing to have these crazy usertalk pages where people from different projects are leaving messages about different projects in different languages(provided you speak more than 1). It would just get really cluttered. *Eventually, as domains start having 0 users, we elminate them. *Oh, and constant purging of Old abandoned accounts (1 year with no logins? or say 4 months with no logins and less than 5 total edits?) **Easy, thats all, completely transparent!!!!
Techinical Issues: *Purge abandoned accounts to make the switching process easier *Make a new 'user' table, a global one that includes an additional "domain" field. *All user accounts are switched to this table with their respective domain. *Run a script that finds all the usernames with no conflicts, and makes all those global. all the non-uniques would stay in their respective domains until they were merged, deleted or changed (We could give the ability of a user to switch his username, lose his contribution counts, etc, but keep their watch list and preferences) *From now on, internally we refer to users with a PRIMARY KEY 'userId', but the users should never see this
--NOTE: we could additionally (if we wanted to be true to the relational database structure) have a new table called "domains" that kept a domainId and "DomainName" to avoid a varchar field in the new user table (plus it would make that index smaller and matching faster)
PROBLEMS I FORSEE: *character encoding of usernames and people making logins that look exactly the same, but are not (think the #1 and letter l trick.....) *does MYSQL support full UNICODE? does wikipedia? *Since cookies are domain-based you couldnt just log in and access all the sites.. or can wikimedia.org set cookies with other domains on them?? *Never eliminating domains because of people getting into fights about keeping their usernames.. but well.. thats people, no technology can fix that
I spent some time thinking about this solution and I find it elegant, easy and ultimately the easiest to implement for a migration. I know I have never checked in code or am a significant figure here, theres no reason for you to listen to me, or my ideas as I have never really proved my technical abilities, but I do find that this solution could prove beneficial without requiring a major rewrite of existing code. This not a final revision and not complete and exhaustive as I do not know the codebase very well, but the ground work is there and the gist of it too. Opinions and suggestions are, as allways, greatly appriciated.
One more thing, I also see this solution centralizing data, which is allways good. With all the users centralized into one table, we could, inthe future, implement some sort of caching system which would invariably aid in performance. If you remember one of my previous posts, you might remember my reference to "memcached" (www.danga.com) as it already has phpbindings...
Lightning
Hi Lightning,
Lightning wrote:
Ok, I would love to see global log-ins, but yeah there is user conflicts and the problem of making the switch smoothly. Here is what I propose.
Your proposal seems quite fine. You have very well layed out the pros and cons.
However, I would really rather not create just a user database now without thinking about all the other database stuff that needs to be taken care of.
I'll post a separate entry about this.
Timwi
wikitech-l@lists.wikimedia.org