We don't need any kind of proof, as long as the wave server signed the delta - it is considered valid. Prood of work is used to create decentralized consensus regarding the ordering of transactions. In our case the wave server signs each transaction, and it's up to other federating wave server to decide which signature it trusts - or at least this is the way the federation is supposed to work currently.
On Thu, Apr 21, 2016 at 11:18 AM Andreas Kotes <count-apache....@flatline.de> wrote: > Hi Yuri, > > On Tue, Apr 19, 2016 at 09:35:57AM +0000, Yuri Z wrote: > > I was thinking about Federation via persistence level. In particular when > > all the content persisted into database, but the database is > decentralized > > (like bitcoin blockchain). The content though is encrypted. Each wave is > > encrypted with a new key. Whenever a participant is added to the wave - > > whoever adds him also adds a new record into this user data wavelet with > > the wave private key that is encrypted with the user's public key. This > way > > only the new user gets access the the wave private key. > > I.e. all the content is public, but encrypted. Only those that control a > > certain key can decrypt the message and add new content. > > So, this architecture follows the bitcoin model - anyone can host his own > > wave blockchain (like running his own wallet) or use a web wallet - i.e. > > wave client hosted by someone else. > > I thought about this for a while, and turned it around in my head etc .. > > I kinda like this idea, although the concept of the blockchain's proof > of work would put too much strain on a wave system in my point of view. > > Regarding distributed, version controlled data storage, I think the by > far best current (open) example is git, which might lend itself nicely > to our needs as well. > > There even seems to be an open library implementation at > https://libgit2.github.com/, which might solve a lot of the underlying > problems. > > I haven't look into the details, but there might be merit in evaluating > whether the way git handles deltas might related well to how we want to > do OT, and how git shallow checkouts could help gather the relevant data > for a current-version view of a Wave quickly. > > I'm not sure whether there's anything git offers that gives us some > streaming-style data transfer capability instead of server-style > push/pull interactivity that's probably less suitable for our needs. > > What do you think? > > count > > -- > Andreas 'count' Kotes > Taming computers for humans since 1990. > "Don't ask what the world needs. Ask what makes you come alive, and go do > it. > Because what the world needs is people who have come alive." -- Howard > Thurman >
