[Members] Google and XMPP federation

Simon Tennant simon at buddycloud.com
Mon May 27 11:04:19 UTC 2013

Which exact statement by Google is technically wrong?

So by all accounts we cannot do group communication with file-sharing and
video and reliable message delivery across multiple platforms and any
solution would have to do UX workarounds to account for why some users
don't get a file or perhaps might not receive a message. But Google should
have used XMPP.

Also, reading these comments there's an expectation of "you use XMPP and
you should publish any subsequent extensions". (did Stallman just join the
XSF?). This is new to me. It's also a very scary prospect and will only
serve to scare off new companies investigating XMPP as part of a comms

We're sorely misguided if we think that chastising a relatively good
champion of XMPP for many years (compared with complete non-federators like
WhatsApp and Facebook) will help the cause of open communications.

If we are serious about encouraging open, federated communication and
building the standards that others can adopt then now is the time to lay
down our pitchforks and reflect on:

- why so many web developers have such a negative reaction to XMPP,
- why XMPP is perceived as difficult to build on (keyword: perceived),
- what we are doing to grow beyond pure user to user chat and better
address the mobile world.


On 27 May 2013 11:11, Dave Cridland <dave at cridland.net> wrote:

> On 26 May 2013 20:07, "Simon Tennant" <simon at buddycloud.com> wrote:
> > My point is it's easy to get all fired up about Google dropping XMPP.
> But we don't do ourselves any favours by suggesting Google release a
> hobbled version of hangouts because a spec dictates.
> No, nor me. But given the only aspects not known to work right now are
> multiparty file sharing and voip, and the latter especially is not not hard
> to fix, I don't understand why they wanted to throw away everything, and
> understand even less why they're making "statements which lack technical
> justification" - my latest euphemism.
> > I'm not convinced by rebuttals. It puts the XSF on the back foot and
> we're playing catch up. And besides, nobody except us really cares for spec
> details.
> >
> > Far better for us to come out with an "open hangouts" spec that shows
> this can be done with XMPP rather than rebutting individual statements.
> We're never going to win that game.
> >
> Yes and no. If we get into a tit for tat rebuttal, it'll be hard. That
> becomes a he says, she says argument and Google have lots of PR folks. But
> we can be honest and technical, keep a single rebuttal stating both the
> cases where Google's statements are wrong, and where we need to do more
> work.
> > This was my thinking on the topic and how we could enable hangout-like
> features within buddycloud:
> https://groups.google.com/d/msg/buddycloud-dev/jehtPgsCurQ/cDzWDfsvw_wJ(it's a long read and buddycloud specific)
> >
> > I'd be happy to put some time towards a more general XSF proposal for
> "open hangouts" driven by requirements of:
> >
> > - group communication
> > - reliable message delivery
> > - mobile friendly
> > - message history
> >
> > Google building hangouts outside of XMPP shows that there is a need for
> group communication that just works.
> >
> Right, but buddycloud elected to go a current path some time ago,
> sacrificing backwards compatibility and interoperability to build something
> new.
> Nevertheless, I think we can get all of those using existing
> specifications. You'd need a nice client to do it, of course, and a server
> that did things "right", but it'll work. Multiparty fileshare and A/V are
> actual problems that we don't yet have a solution for, but a solution isn't
> obviously beyond XMPP.
> > Now our job is to build great specs, that serve real needs. Not
> complaining when people don't use them.
> >
> Right. The XSF can't complain just because people don't use our specs. We
> can complain, though, when they misrepresent them, and we can also make
> comments in favour of interoperability, using Google's actions as an
> illustration of what not to do.

Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/members/attachments/20130527/1be09b00/attachment.html>

More information about the Members mailing list