yeah I believe google does have alot of xmpp you can see that from the cloud engine having libraries for xmpp
On Thu, 21 Apr 2016 at 13:58 Michael MacFadden <michael.macfad...@gmail.com> wrote: > 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 > >>>>> > >>>>> > >> > >
