[Standards] XMPP client-centric? [was: Decloaking and Temporary Subscriptions]
jason at hardlight.com.au
Thu Jan 21 03:48:41 UTC 2010
Hi Mathew - first of all, sorry for diverting this, thanks for rethreading.
what I mean is that xmpp clients are the only entities with any power.
they are the only entities that can interact with anything on a clients
behalf. this is very different from the webserver paradigm where a user
remotely logs in and then the server has power to BE the user, reuse
other webservices as the logged in user (via any number of
authentication schemes) etc. With xmpp its also possible to use other
webservices, but critically NOT xmpp services! its not possible for
example for an xmpp plugin to access a users pubsub node, or private xml
storage AS the owner unless the plugin knows the users id and password
and opens its own client connection. You cant use a bosh server with
your existing xmpp account without giving it your user/pass details. It
pains me to see all the cool xmpp component functionality about that I
can only leverage from a client application. I dont know how this can
best be resolved but I really think it needs to be. Allowing xmpp server
level oauth style authentication could work, albeit a bit heavy, as
might other strategies.
just my 2 yen.
what do u think?
Matthew Wild wrote:
> 2010/1/21 Jason Eacott <jason at hardlight.com.au>:
>> Matthew Wild wrote:
>>> Downsides are that this requires server support, especially thinking
>>> of e.g. gmail.com here. Probably other things I'm missing too.
>> again this just makes me sure that XMPP as it stands is far too client
>> centric, and needs to become properly extensible from the serverside too.
>> there should be a way for server extensions to do what clients can.
>> (I know thats not what you were suggesting here, but it might make
>> implementing such things easier)
> I didn't want to divert the original thread before it even starts, but
> was curious - what do you mean by this? I don't see how XMPP can
> enforce Google to implement any extension. The issue here is that the
> predominant use case for decloaking is Jingle, and many Jingle users
> happen to be Google Talk users.
> If decloaking was done client-side then the user can simply switch to
> a better client that supports it, switching server is much harder
> I guess I just don't understand your "there should be a way for server
> extensions to do what clients can".
More information about the Standards