[jdev] XMPP in the browser -- your thoughts?

[Matthew A. Miller]

Forwarding Rene Treffer's comments, and Joe Hildebrand's responses:

> 
> 1. XMPP requires many roundtrips. This could easily be solved, e.g. by using
> a client-push namespace with some special semantics (e.g. like doing an
> anonymous login on behalf of the user)

It's possible to pipeline a lot of those roundtrips, but you're right this
is something for which we need a best-practices document.  In practice, if
you're going to be doing TLS, the extra round trips aren't *that* bad on
most networks.

> 2. There are some session problems, like syncing an xmpp user and a web
> user. Most sites will like an easy user sharing. This has not yet been
> solved.

Do you mean from an authentication perspective?  There's both SAML and OAuth
mechanisms being worked on.

With both this issue and the previous one, if you're connected to a local
XMPP server at all times and use federation to get to the remote service you
want to access, you won't have issues.

> 3. Websockets enabled binary pushes. XMPP on the other hand is more of a
> protocol framework. It would thus naturally provide a different approach,
> and perhaps even solving different problems.

I'm expecting that we'll write a XEP like:

<message>
<data xmlns='urn:xmpp:data:0' encoding='base64'>aGVsbG8gd29ybGQ=</data>
</message>

<message>
<data xmlns='urn:xmpp:data:0' encoding='none'>hello world</data>
</message>

-- 
Joe Hildebrand

> 
On Feb 21, 2011, at 12:11 , Matthew A. Miller wrote:

> (Apologies for the delay in publicizing; sickness overtook me)
> 
> One of the guerilla conversations at the XSF Summit was about XMPP usage in the browser.  Below is the first documented follow-on.  Most of the rest of the responses were about general acceptance of the concept, hence they're omission.
> 
> I'll try to forward the more substantive comments soon (and/or urge the original participants to respond again here).
> 
> 
> - m&m
> 
> (PS: Originally sent from the "wrong" account; hopefully this doesn't show up twice!)
> 
> Begin forwarded message:
> 
>> From: Adam Brault <adam at andyet.net>
>> Date: February 8, 2011 21:25:58 MST
>> To: mwild1 at gmail.com, nathan at andyet.net, kevin at kismith.co.uk, stpeter at stpeter.im, ralphm at ik.nu, mamille2 at cisco.com, florian at florianjensen.com, jack at metajack.im, will.sheward at isode.com, bear at code-bear.com, nverite at process-one.net, alexey.melnikov at isode.com, simon at buddycloud.com, joe.hildebrand at webex.com, julien.genestoux at gmail.com, laurent at eschenauer.be
>> Cc: henrik at andyet.net
>> Subject: XMPP in the browser -- your thoughts?
>> 
>> Hi, Folks...
>> 
>> So... what do you *really* think about the idea of XMPP in the browser? ;)
>> 
>> After discussions at the XSF Summit this weekend, I feel pretty passionate about this idea and want to do what I can to help push the issue at least to a point of reasonable consideration. (For those of you who weren't a part of the conversations that took place, it sounds as if there is a window of possibility for XMPP in the browser.)
>> 
>> As most of you know, I am not a software engineer and I'm not even close to an XMPP developer. Also note that I myself don't take ownership for these ideas—they belong to people smarter than me. I'm just set on advocating them as much as I can.
>> 
>> Will you take a look at what I've written below and provide your feedback? (My current thought is to post a variation of it based on feedback to the hybi mailing list and to our blog at some point. At Joe's suggestion, I submitted a talk to OSCON with the same general topic.)
>> 
>> The kinds of things to consider as you read: What do I have wrong? Where are the blind spots? Where does it sound naive? What examples should I be pointing to? Is this even a good point—do you yourself think it's a good idea? What other arguments do you perceive there to be for and against it—particularly in terms of benefits, barriers and objections...? Would it be better for someone other than myself to propose the notion? I certainly wouldn't take offense at the suggestion.
>> 
>> I very much appreciate your honest feedback and consideration. Don't be afraid you'll hurt my feelings—just be as blunt as you possibly can. :)
>> 
>> Cheers,
>> 
>> Adam Brault
>> &yet
>> 
>> 
>> ========================
>> 
>> Websockets are a terrific idea that suddenly got put on hold this year. But perhaps Websockets' stumble sets us up to take a closer look at something else.
>> 
>> Giving web developers access to a real transport opens all kinds of opportunities in development and leapfrogs a lot of the hacky methods currently used to push data to end users. Unfortunately, it's highly possible Websockets might be an opt-in feature for the forseeable future in some major browsers due to security concerns (among other things).
>> 
>> It makes sense to seriously evaluate the idea of browser-based XMPP. The idea isn't a new one, but it's beginning to gain some traction for good reason.
>> 
>> It is historical fact and present reality that the Internet as a whole is weakened by monopolies and dramatically strengthened by diversity. Competition and decentralization makes everything about the Internet better. But more than just playing to the web's ideals of decentralization, XMPP's federated, flexible, mature and secure nature as a protocol opens up enormous possibilities for developers, browser creators, business, and consumers.
>> 
>> A few things that browser-based XMPP would help make possible:
>> 
>> 1. Accelerate the growth of realtime/push web applications by providing XMPP's deep feature set via JavaScript API that makes XML easier to deal with for frontend developers and faster to build off of XMPP's strengths instead of continuously reinventing the wheel.
>> 
>> 2. Overcome the last mile of realtime tech which is often ignored—pushing to the end user. Things like PubSubHubBub push between servers and services, but the getting that same data to the end user at this point is not as elegant or straightforward as it could be with XMPP embedded in the browser.
>> 
>> 3. Take federated social networking to the end-user, conceivably allowing them to choose network(s) to interact with, rapidly making federation the norm in this arena and decreasing the likelihood of one or two proprietary social networks to dominate the web.
>> 
>> 4. Enable browser-based authentication, ID and payment to become a reality. In addition to speeding up development by commonly centralizing the most repetitive problems, the whole Internet basically becomes an App Store with a "Buy Now" button baked into the browser—birthing a new industry of webapps aimed at consumer-level impulse purchasing a la the various mobile app stores.
>> 
>> 5. Revolutionary stuff that hasn't even been dreamed of yet.
>> 
>> Ultimately, I think this type of new browser feature set is so beneficial to all parties involved that I think we're looking at a huge increase in the Internet economy once browsers begin to implement such a spec.
>> 
>> These (among other things) provide some very good reasons for strongly considering browser-based XMPP.
>> 
>> Still, I anticipate harsh disagreement and welcome it. At the moment, I actually want to hear why this is a bad idea much more than I want to hear why it's a great one. I believe it's worth giving serious evaluation to the variety of concerns involved.
>> 
>> In inviting criticism, however, I'd like to make the ad hominem aspect of counterarguments moot: I work at a company that has experience with XMPP, node.js, and Websockets, and have had numerous discussions around this topic, but I myself am absolutely not a software engineer. I'm fully aware of my ignorance but generally unafraid of it. :) That said, the notion and its possibilities are not my ideas—I'm just collecting thoughts, ideas and discussion from smarter folks than myself.
>> 
>> I believe the critical opposing arguments that will be voiced fall into one of several categories:
>> 
>> 1. "XMPP sucks for JavaScript developers."
>> As I alluded to above, there needs to be a solid JavaScript API for XMPP in the browser that means developers don't have to do the pain of working with XML in JavaScript. This is an absolute necessity for XMPP in the browser to be at all feasible.
>> 
>> 2. "XMPP doesn't scale and doesn't belong in serious high-volume web services."
>> It is my understanding there's compelling real-life data showing the high level to which XMPP can be scaled. I'm not the right person to provide and discuss this evidence, however.
>> 
>> 3. "Websockets would be better."
>> I think Websockets would be different—better in some ways, for certain—though without XMPP's instant depth of features and flexibility. And I would hope to see an adoption of Websockets. This isn't either/or.
>> 
>> Thanks for reading and I'm looking forward to discussion.
>> 
>> ========================
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2238 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20110222/8be2dd8c/attachment.bin>