[Standards] XMPP client-centric? [was: Decloaking and Temporary Subscriptions]
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
> 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.
xmpp:melo at simplicidade.org
mailto:melo at simplicidade.org
More information about the Standards