[Standards] Namespace delegation and privileged component
goffi at goffi.org
Thu May 8 09:09:24 UTC 2014
I bring up this thread as we are currently having an interesting discussion
with Binary and Edhelas.
Here is the main issue: components are really limited today, they're more
something like server side clients, with very limited access (they can access
entity roster for example, so a pubsub component can't manage roster access
We are thinking about two new XEPs to solve this issue:
- namespace delegation: a server delegate a full namespace to a component,
e.g. a component say "I want to manage 'vcard-temp'"
- privileged component: a component access everything a client can, in the
name of the client. That's mean it can access an entity full roster without
limitation, it's private storage, etc.
That would open XMPP to a huge new step in decentralisation, with these 2 XEPs
you could host your own pubsub or PEP component at home. This is also better
for security: you may want to host your own gateway because you don't want
that the main server access your login/password for the legacy network.
An other huge advantage, would be the ability to overpass servers limitations:
my server's internal PubSub service doesn't manage roster access ? No problem
I had my own PubSub service as a privileged component. That's also mean quick
development cycle when you want to try experimental stuff: you don't have to
wait for server implementation to test something.
Here are the logs of our recents discussions: http://paste.debian.net/98158/
So we'll try to work on protoxep for this now, anybody interested in the
subject please manifest yourself :)
Le mercredi 13 novembre 2013, 18:35:45 Matthew Wild a écrit :
> On 13 November 2013 18:12, Goffi <goffi at goffi.org> wrote:
> > So, is it possible to remove these restrictions from the XEP ? Or at least
> > to have an unsecure mode, and a secure mode with full access to roster ?
> This is related to something we discussed at the summit recently -
> privileged components.
> I have half an implementation already, which allows components to
> handle stanzas to the user's bare JID that the server would otherwise
> handle (or reject). For example it's possible to handle standard vcard
> queries in a component now.
> The point I got to was figuring out how the component should reply,
> since the stanza needs to look like it came from the user.
> I'll also note here that Prosody at least already supports components
> faking JIDs (ejabberd does too) when enabled by the admin. Prosody is
> probably also happy with such components requesting the user's roster,
> as well as other tasks. However this is definitely *not* in any
> standard. I'd like to standardise this (in some form), and it seems
> there are a number of people interested in it too.
> So we need to solve:
> - Sending stanzas from the user
> - Sending stanzas to the user's account, and getting replies
> Someone put together a protoXEP :) (I already have enough XEP work on
> my plate for the moment)
More information about the Standards