[Standards] Namespace delegation and privileged component

Goffi goffi at goffi.org
Thu May 8 09:09:24 UTC 2014


G'day,

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 
model).

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 :)

Cheers
Goffi

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)
> 
> Regards,
> Matthew




More information about the Standards mailing list