incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Evan Hughes <ehu...@gmail.com>
Subject Re: Persistence via git (Was: Should we remove Federation? Wave as XEP/XMMP Extension)
Date Thu, 21 Apr 2016 14:30:33 GMT
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" <wave@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 <ehugh1@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 <vega113@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.org@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
>>>>>
>>>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message