couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ido Ran <ido....@gmail.com>
Subject Re: CiuchApp logic
Date Wed, 19 Sep 2012 20:52:10 GMT
Thank you, I'll check it out



ב-19 בספט 2012, בשעה 21:24, Ryan Ramage <ryan.ramage@gmail.com> כתב/ה:

> 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 <ryan.ramage@gmail.com> 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 <jens@couchbase.com> wrote:
>>> 
>>> On Sep 19, 2012, at 10:39 AM, Ido Ran <ido.ran@gmail.com<mailto:ido.ran@gmail.com>>
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

Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message