Ido, btw, I made a kanso package so that you can use these crypto libs work both in the couch side (show, lists, updates) and on a browser.
see https://github.com/ryanramage/kanso-encryption On Wed, Sep 19, 2012 at 12:11 PM, Ryan Ramage <[email protected]> wrote: > Ido, > > you could have the game take place in one document. Each move is a > change to the doc, so only one player is allowed to make it. The doc > contains a history of moves. To verify someone has not cheated you > could sign each move with a key. See something like > https://github.com/wwwtyro/cryptico. > > Warning..using crypto in js is really not secure. I think it would be > enough to prevent most cheating, but you would not want to do anything > serious with this. Some browsers are getting close to supporting > crypto extensions, but its not there yet. That being said I am sure it > would be sufficient for a monopoly type game as long as it's not real > money at stake :) > > Ryan > > On Wed, Sep 19, 2012 at 11:57 AM, Jens Alfke <[email protected]> wrote: >> >> On Sep 19, 2012, at 10:39 AM, Ido Ran >> <[email protected]<mailto:[email protected]>> wrote: >> >> I want to build game using CouchApp. >> It's not sensitive data but I don't want very easy way to cheat. >> >> It sounds like you want both players to have their own local CouchDB, and >> they’ll replicate with each other? >> >> In general, with a peer-to-peer system where you don’t trust the other >> peers, you have to strictly validate any updates you receive. So if there’s >> a document representing the game state, you have to verify that the new >> revision represents a valid move made from the state of the old revision. >> Particularly important are that player turns have to alternate, and that a >> revision received in replication has to represent a move by the other >> player. (So the document schema has to include an indication of who made the >> last move.) >> >> It gets trickier if the board state is expressed by multiple documents, >> because then you can’t validate the entire move at once. It might not be >> feasible to do it that way. >> >> —Jens
