User:Jukeboksi/Chat Gallery/26.06.2004 with TimStarling

juxho> hi tim
juxho> and thanks once again for the PHP tutorial
TimStarling> hi
TimStarling> no problem
juxho> now I'm able to read SpecialExport.php and SpecialImport.php
TimStarling> that's good
juxho> we are going to work on those since they are so crucial to our multi-wiki setup but of little interest to wikipedia folk
juxho> i've been wondering about "sharing" the user table between multiple wikis
TimStarling> yeah, I've thought about that sort of thing before
juxho> i know that a database is always distinct from other databases, but i've heard some people pondering about this for wikipedia
juxho> any ideas on how it would be simplest to implement
TimStarling> in mysql you can actually use database selectors
juxho> selectors?
TimStarling> so you could have a $userTable variable
TimStarling> set it to "common.user"
juxho> in php or mysql?
TimStarling> in PHP
TimStarling> the idea is to create a common database, and then replace all instances of the "user" table name with some other name
juxho> so separate the user-table to a distinct database?
TimStarling> yes
juxho> that would require hacking MediaWiki
juxho> we really don't want to fork off
TimStarling> you can reference a table from a different database using dbname.tablename
TimStarling> well, you don't need to fork as long as you do it right
TimStarling> make it flexible, make it compatible with all existing wikis
juxho> well what is needed is db read and also db write hacking
juxho> our top priorities for hacks are:
juxho> 1) http://develop.consumerium.org/wiki/index.php/Export-import
juxho> 2) Shared login
juxho> 3) More user types (besides sysop, bureaucrat and developer) with color coding in HTML
TimStarling> interesting
juxho> 3) eg. "Verified User" that is shown in Green
juxho> thus we have a RGB scheme
TimStarling> ok
TimStarling> for shared logins, one possibility would be to have a function which converts old table names to new table names
juxho> we want to implement all these so that they are included as optional code (defaulting off) in MediaWiki
juxho> hmm
TimStarling> so you could have wfTableName("user"), and that would return something dependent on settings
TimStarling> it's good that you want to work on MediaWiki itself rather than fork
juxho> but that increases the need for distinct db connections quite much?
juxho> yes
TimStarling> the only reason you need more than one DB connection is if you have more than one database machine
TimStarling> well, almost the only reason
juxho> i just wrote in reply to 142 for the upteenth time that i really want a separate Opinion Wiki simply because we can aggregate data (votes on campaigns etc.) via SQL queries so we don't need to mess up MediaWiki
TimStarling> have you seen my board vote code?
juxho> no. i've just voted in the election and i really liked the idea of using public key crypto to enable audit trail
juxho> it's marvellous
juxho> i've been randomly thinking that we might have use for the board vote code in consumerium
juxho> i really must congratulate you on the principle of board vote
TimStarling> I wrote it in a hurry for the specific purpose of the board vote, but it shouldn't be too hard to make it more general
TimStarling> thanks
juxho> i'm very critical of submitting everything to computers because that gives technocrats too much (secret) power
juxho> but in this case there is no prob since the private key could be on a disk in a safe
TimStarling> yes, I wanted to make it so that it was hard for a developer to rig
TimStarling> since a developer was one of the candidates
TimStarling> and he came very close to winning, too
juxho> once again my hat is off for the way you've implemented it
TimStarling> it's also made so that's it's fairly difficult for a developer to work out who is voting for whom
TimStarling> they'd have to constantly run a monitoring program on the server, which is detectable
TimStarling> instead of just get in, grab the results and cover their tracks
juxho> what do the individual records look like in plaintext then?
juxho> how hard it will be to adapt the code to support many "elections" running simultaneously?
TimStarling> the plain text records have three lines
TimStarling> two for the two different positions, and one for "salt"
juxho> salt is just random number?
TimStarling> Contributing: Erik, Shizhao
TimStarling> Volunteer: Angela, Michael Snow
TimStarling> Salt: oirupq5438yqvjvha985yfqpqthlkaj3viuytbe0347f5yn4ifuhtjht3098t7qyn
TimStarling> although it turns out the salt is redundant
TimStarling> the GPG algorithm adds its own salt
TimStarling> since the plain text records don't contain the usernames, it's not trivial for even the private key holder to determine who voted for who
TimStarling> assuming the private key holder doesn't have access to the full DB, which is how we set it up
juxho> so the DB hides the order in which votes were cast or what?
TimStarling> the way we set it up actually had a slight flaw in this respect, but it's not too bad
TimStarling> my original intention was to allow the private key holder to view whatever they want
TimStarling> anyway, the web interface gives two different data displays
TimStarling> the "list", where names and timestamps are displayed
TimStarling> also, an election administrator may use this list to strike out invalid votes
juxho> i noticed that
TimStarling> and the "dump", which lists the encrypted records in chronological order
TimStarling> so there's a few ways an election administrator could match up dump entries with list entries
juxho> but that makes it possible to match records in "dump" with timestamps?
juxho> you were too quick
TimStarling> yes, it would be better if they were shuffled
juxho> btw. do you object to me publishing log of this chat on consumerium.org?
TimStarling> also, if an election administrator has the private key, they could find out which entry belongs to which person by striking it out temporarily, and seeing which dump entry disappears
TimStarling> no I don't mind
juxho> ok. i had to ask. i'd never publish any logs without permission from all
TimStarling> so the way to get around that vulnerability is to make the private key holder a non-administrator
TimStarling> I appreciate that
juxho> what do you figure of adding another color for users that depends on user_rights? where would the code for such be best placed?
TimStarling> it depends on where you want the colours to show up
TimStarling> on all links to the user page?
juxho> let me think
juxho> RC
TimStarling> well, the code for RC is in Skin.php
juxho> all signatures, yes
TimStarling> ok, if you want it to be all signatures, the easiest thing to do would probably be to change the link colour in makeKnownLinkObj
TimStarling> that's in Skin.php
TimStarling> you'd just check if the link is from the user namespace, and colour it accordingly
TimStarling> I'm not sure that it's secure though
juxho> so load all the user_rights to a array or hashtable and use that to set the color?
TimStarling> you could probably use font tags or style attributes to override it
TimStarling> yes
TimStarling> to make it more secure, perhaps you could change the title attribute
TimStarling> that's what comes up when you hover the mouse over a link
juxho> you mean that <font color="green"><a href="User:Juxo">Juxo</a></font> to fool that i'm verified?
TimStarling> yeah
juxho> good point