I am open for any working implementation. I wasn't talking specifically about bitcoin blockchain, but more about decentralized DB, like ipfs as you mentioned.
On Tue, Apr 19, 2016 at 1:09 PM Pablo Ojanguren <pablo...@gmail.com> wrote: > Yuri, it's exciting to think on a blockchain decentralization approach, but > AFAIK blockchain is not suitable for such operation rate that a OT system > like Wave produce. > In that sense is also interesting projects like IPFS <https://ipfs.io/> > In addition, I am still think that the current Wave model federation is > good (even it replicates data), the issues is the transport, so I suggest > to try Matrix.org as replacement of XMPP. I will look into it in following > weeks, and I am trying to get someone in SwellRT's GSoC to work on that > during summer > > 2016-04-19 11:35 GMT+02:00 Yuri Z <vega...@gmail.com>: > > > 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. > > > > On Tue, Apr 19, 2016 at 12:24 PM Andreas Kotes <co...@flatline.de> > wrote: > > > > > Hi, > > > > > > On Mon, Apr 18, 2016 at 09:20:43PM -0700, Michael MacFadden wrote: > > > > However, with respect to a particular wave, the federation model is > > > > very much centralized. It is not decentralized in the same way that > > > > XMPP and SMTP are. This is actually a function of how the Wave OT > > > > algorithm works and not an issue with the transport or XMPP. > > > > > > I'd even say that's the correct way to do it. One server should feel > > > responsible for safeguarding the document regarding security and > > > availability. > > > > > > If a document is decentralized only, versions can diverge and copies > > > might go offline or disappear altogether, with the possibility of no > > > copy remaining. > > > > > > The transport as such shouldn't matter too much - although if we stay > > > in the Java/XML realm, XMPP sounds like a good fit, especially as (via > > > Jabber) it has a lot of established infrastructure. > > > > > > Maybe Apache Wave would even make a good set of (official) XMPP > > extensions? > > > > > > Cheers, > > > > > > 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 > > > > > >
