[Standards] Namespace delegation and privileged component

Steven Lloyd Watkin lloyd at evilprofessor.co.uk
Thu May 8 09:38:12 UTC 2014


Yes, this is exactly something I've talked about before (in Portland last
year and again at an XMPP UK event) and something Matthew Wild has partly
implemented somewhere (the "stanza hijacking" as I call it).

If you are putting something together please include me and I'll try and
throw in some ideas.

_____________________________________________________

Steven Lloyd Watkin
Software Engineer
PHP ::: Java ::: Ruby ::: Node.js ::: XMPP
lloyd at evilprofessor.co.uk (email+jid) ::: http://www.evilprofessor.co.uk
Facebook / Twitter / Flickr: lloydwatkin

Organiser of WORLD RECORD breaking charity event:
Scuba Santas ::: http://www.scuba-santas.co.uk
Supporting the RNLI & DDRC - 15th December 2013 - NDAC, Chepstow


On 8 May 2014 10:09, Goffi <goffi at goffi.org> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140508/2dfc686e/attachment.html>


More information about the Standards mailing list