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 <[email protected]> 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
