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
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