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 <[email protected]> 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 <[email protected]> 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 <
[email protected]>
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


Reply via email to