XMPP Extensions Editor wrote: > Title: Private Data via PEP > > Abstract: This document specifies XMPP semantics for using the > personal eventing subset of XMPP publish-subscribe to persistently > store private data such as bookmarks and client configuration > options. > > URL: http://www.xmpp.org/extensions/inbox/pdp.html
(Maybe I should have called that Private Information via PEP = PIP? :) AND: > Title: Persisting Objects via PEP > > Abstract: This document specifies XMPP semantics for using the > personal eventing subset of XMPP publish-subscribe to persistently > store semi-public data objects such as public keys and personal > profiles. > > URL: http://www.xmpp.org/extensions/inbox/pop.html I wrote these proposals to see how we could do private data storage (a la XEP-0049) and "public" data storage via PEP. It can be done with the publish-options feature described here: http://www.xmpp.org/extensions/tmp/xep-0060-1.10.html#publisher-publish-options I'm not yet convinced that this is the best way to do things, but it is possible. Thought experiment follows. Don't get too worried that I'm seriously considering the following approach. :) <thoughts> So you may wonder why I didn't define a pubsub/pop service identity and a pubsub/pip service identity. Well, I don't think we can do that because the virtual pubsub service hosted at your bare JID can't be pep, pop, and pip at the same time since they have different default access models and other node configuration options (last_published_item etc.). A slightly different approach would be to narrow the definition of PEP so that it's limited to basic pubsub + support for the "auto-subscribe" and "filtered-notifications" features described here: http://www.xmpp.org/extensions/tmp/xep-0060-1.10.html#presence At that point, PEP (or whatever we call it, I like "virtual pubsub service" or VPS :) consists of two things: 1. Your bare JID is a VPS. 2. Subscribers can easily receive data from your VPS. Then we could define "node types" for pep, pop, and pip along with a way to signal (when publishing) that you want the data to be published according to the definition of the pep, pop, or pip node type. Even something as simple as this: <iq from='[EMAIL PROTECTED]/balcony' type='set' id='pdp1'> <pubsub xmlns='http://jabber.org/protocol/pubsub'> <publish node='storage:bookmarks' type='pip'> ^^^^^^^^^^ <item> <storage xmlns='storage:bookmarks'> <conference name='The Play' the Thing' autojoin='true' jid='[EMAIL PROTECTED]'> <nick>JC</nick> <password>Gl0b3</password> </conference> </storage> </item> </publish> </iq> That kind of approach would mean that "pubsub/vps" is a service identity whereas pep, pop, and pip are node types. Pro: easier. Con: limited. By "limited" I mean that there may be node types (i.e., combinations of node configuration options) other than personal eventing, object persistence, and private information. This is similar to MUC. We defined roles like owner and admin and moderator, but people have always said those are limiting because it would be more flexible to define a granular set of permissions and assign those more dynamically rather than making these "hardcoded" buckets like "admin" and "owner". Personally I think life is easier if you give people something to hang their hats on ("oh, he's an admin" vs. "oh, he has perms 3, 5, and 8") and that excessive flexibility is overrated. Just as we do with MUC, here we could define some basic node types. Like so: PEP -- "oh, that's a pep node, which means it doesn't persist items and sends out the last published item on subscribe or login" POP -- "oh that's a pop node, which means it persists items and never sends out the last published item" PIP -- "oh, that's a pip node, which means the data gets sent only to the account owner" If we define publish-options people could still override those node types, but providing a small set of node types would give people some options they could understand more easily. </thoughts> I'm not necessarily saying we want to go down that road. Maybe it's fine to do publish-options forever. And going down that road would result in simplification only on the publish side, which I see as less important than the fundamental simplification we've achieved on the subscriber side with "auto-subscribe" and "filtered-notifications". But it's at least worth having a discussion so can dismiss the idea. :) /psa
smime.p7s
Description: S/MIME Cryptographic Signature
