Heh funny enough, Ive been talking about this since Portland 2010 and been in my inbox for a while.
I actually also was thinking about a new component XEP or extension for the old XEP-114 XEP which gives you more access to the server. I use almost XEP-0114 for every XMPP project I am doing (most business logic resides there) and it great for most of the purpose I’ve had so far, but sometimes it just don’t quite do the job I want. But also I want stream features for components, SASL, TLS and all the other good stuff which we have on S2S and C2S. I could be great to use SALS and friends instead of handshaking and do roster access, db access and other stuff. Maybe when defining this XEP, it could also be great to have different access level of the different components and NS delegations.. -Cheers! /Steffen On 08 May 2014, at 11:38, Steven Lloyd Watkin <ll...@evilprofessor.co.uk> wrote: > 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 > ll...@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 <go...@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 <go...@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 > >
smime.p7s
Description: S/MIME cryptographic signature
