User:Jukeboksi/Chat Gallery/26.06.2004 with TimStarling

    From Consumerium development wiki R&D Wiki

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