fyi a git like ot would be O(n^m) complexity I believe because current implementation forces only one ot tree to save the server from using infinite mem and cpu.
@yuri I think it would only be able to handle the actual trans of blips and stuff, everything else would have to be robot api type stuff On 21/04/2016 11:28 PM, "Dave Ball" <w...@glark.co.uk> wrote: > I quite like the idea of git, or a git-like OT algorithm - although it > wouldn't be a small change... > > If we're signing deltas, then is the additional server/connection level > authentication provided by xmpp superfluous? > > Server discovery (& redirection) would be useful for true federation, but > is there a problem with relying on FQDNs in the short term? > > To me, it wouldn't seem problematic if we lost those aspects of the > current XMPP transport. > > Dave > > > On 21/04/16 14:13, Yuri Z wrote: > >> I was thinking about IPFS, not sure if it does what we need. >> >> >> On Thu, Apr 21, 2016 at 12:20 PM Evan Hughes <ehu...@gmail.com> wrote: >> >> @andreas: Crypto is never solid ;) >>> >>> @yuri: whats your opinion on the IPFS >>> >>> @pablo: following the demo it looks like IPFS is literally file transfers >>> but that incurrs more costs compared to a database solution like >>> cassandra. >>> >>> On Thu, 21 Apr 2016 at 19:15 Yuri Z <vega...@gmail.com> wrote: >>> >>> 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 >>>>> >>>>> >
