[Standards] XMPP client-centric? [was: Decloaking and Temporary Subscriptions]

Pedro Melo melo at simplicidade.org
Fri Jan 22 11:08:50 UTC 2010


On Fri, Jan 22, 2010 at 8:23 AM, Jason Eacott <jason at hardlight.com.au> wrote:
> I sense more than a small amount of nastiness here, and I dont think its
> warranted.
> I know I'm not alone in thinking this particular issue is an important
> missing capability of xmpp, but if nobody's interested in the discussion
> then I'll drop it.

If my answer came off as nasty, it was not my intention. I do believe
that the only sane way to have  XMPP-based services grow in usefulness
is if we get a way to access, in a controlled fashion, to user data
(roster, private storage, PIP nodes, presence information).

I think the OAuth model is something that would work for the "get an
access token"-part. I'm not sure how much or how little we should
standardize the way that the "what can you do with it"-part is done

This is not a new problem, and I've been paying attention to a lot of
proposals over the years.

I do think that the usual mantra "simple clients, complex servers" is
limiting our current growth in terms of features because the major
XMPP services will not update their servers just because it has cool
new features. Specifically, I don't see GTalk implementing some of the
features that just to tick the XEP-NNNN box.

So I think we should put a little bit more logic on the client side in
future protocols. It would allow us to deploy more advanced
functionality without having to way for servers. I think that servers
should gain protocols that have multiple purposes, so reuse PubSub or
even current MUC for future protocols.

Even access to private data can be implemented in the client, acting
as the proxy and validator for other entities requests. The drawback
is that you need at least one resource with that capability online.

Pedro Melo
xmpp:melo at simplicidade.org
mailto:melo at simplicidade.org

More information about the Standards mailing list