I'm not sure that 'XMPP as a transport' is too much of a problem, so
much as the current implementation is quite complex.
Currently wave requires an external XMPP server, and plugs into that as
an extension. This can be scalable but our implementation and
configuration could be simplified by e.g. embedding a simple XMPP server.
Wave doesn't need a lot of the 'instant messaging' functionality
provided by full xmpp servers - iirc our users, buddy lists & message
data are all wave specific on top of xmpp.
If we _are_ considering replacing the transport it might be worth
looking at something like ProtoBuffers directly on tcp, rather than
using an existing instant messaging framework? XMPP is fine, but the
"instant messaging" functionality doesn't really give us anything?
My preference would be for federation that works out-of-the-box without
external components, rather than aiming for google-scale scalability in
the short term?
Dave
On 19/04/16 11:09, Pablo Ojanguren 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
