I don’t want to put words in anyones mouth, but I recall some one from google once telling me that the main reason for XMPP was that google already had a significant XMPP infrastructure because of things like gtalk. And that it had already worked out a federation and authentication trust model. No one ever said it was the best thing to do, but at the time it was the right thing to do. That may or may not be valid so many years later, and doing it from scratch.
On 4/19/16, 4:17 AM, "Pablo Ojanguren" <pablo...@gmail.com> wrote: >I guess that XMPP manages federation aspects like identity and server >discovery that we don't have out-of-the-box with just things like >protobuffers. >To say just "transport" is a simplification, probably is better to say >"federated transport" or "federated communication infrastructure" > >2016-04-19 12:39 GMT+02:00 Dave Ball <w...@glark.co.uk>: > >> 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 >>>>> >>>>> >>
