On Mon Feb 21 19:11:09 2011, Matthew A. Miller wrote:
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).
I'd note that "here" seems to be jdev.
I've copied my response in to both standards and social - the latter
because I think that's the community most likely to be interested,
and it'll prod them into joining the conversation - but for now at
least responses to jdev.
I do think we should work on a solid, thought-through proposal,
ideally with some degree of implementation experience.
> 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.
>
WebSockets appear to be moving again, to my eye - however this is
largely because several people - including myself - who thought the
entire thing had gone to pot have all but quit making any comments.
> A few things that browser-based XMPP would help make possible:
I don't think any of these will be contentious to this community. :-)
> I believe the critical opposing arguments that will be voiced
fall into one of several categories:
However, these were all, I think, way off the mark, based on my
experience with the delights of HyBi.
The criticism will centre on two aspects, and we should ensure we
have a compelling story for both.
Firstly, security.
What we need to understand is that the web browser vendors feel that
security starts and ends at the browser. So WebSockets got derailed
into insanity essentially due to a vulnerability that isn't even
proven to exist, hence the reason that it's now encrypted on the
outflow from the browser.
So we need to ensure that for Web integration, we have suitable hooks
into the Web authorization model, which is basically the SOP and
CORS. So we'll need Origin controls for allowing connections from a
browser.
Now you're forgiven for thinking that since we can't retrofit these
as a mandatory portion of the server, then therefore we also cannot
do anything useful in this regard, but it's important to note that
the browser vendors believe that their products will suitably sandbox
the protocols; in other words, if we mandate that the first thing an
XMPP client in a browser does when setting up a session, or prior to
handing over control to the Javascript, is query the server and/or
service as to whether the Origin is allowed to work its magic, then
we can actually rely on this happening. This is largely because we
won't be allowing unmediated access to XMPP, instead we'll be
providing some kind of Javascript layer onto an XMPP session entirely
under the browser's control.
So, *before* we approach the browser vendors, we need a compelling
story on Origin-based security.
Next, deployability.
There's this myth of the amateur programmer floating about, and many
flocks of ideas have been shot down with that particular cannon.
In practical terms, this means we need to get strong anecdotal
evidence that setting up an XMPP server, and having users provisioned
with XMPP accounts as required, are both simple and straightforward
things to do. I see this as a task for the communications teams of
the XSF, involving interviewing people building services on XMPP and
stressing how easy it all is to do. I can't imagine that there'll be
much resistence from such people to talk about their services, and
it'd be interesting content for the blog anyway.
So, again before approaching the browser vendors, we need a
compelling story on ease of deployment.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
