Hi. I work with a project that studies pubsub and we have identified need for publish-only affiliation. I have been discussing this feature with Telepathy developers and it was nice to notice that this issue has been brought to public already.
>-----Original Message----- >From: [email protected] [mailto:[email protected]] >On Behalf Of ext Peter Saint-Andre >Sent: 30 September, 2009 02:06 >To: XMPP PubSub >Subject: Re: [PubSub] Proposed new affiliation: Publish-only > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On 9/17/09 11:16 AM, Guillaume Desmottes wrote: >> Hello, >> >> I had recently a brainstorming session with some Telepathy >hackers to >> discuss how pubsub could be used to improve collaboration between >> applications and web services. >> >> During this discussion we considered some use cases where a web >> service or some of your contacts would be able to push >information to >> one of your pubsub node but without being able to subscribe to this >> node or retrieve its items (so the webservice wouldn't be >able to see >> what your contacts published). >> >> For example, let's say you have a node "photos" to which >your contacts >> can publish URL's of photos on which you are tagged. We >could imagine >> to have a Facebook application pushing to this node as well. We >> wouldn't want that Facebook can see what have been published >by contacts. > >Facebook knows all anyway, doesn't it? ;-) > That's a fact but some other corporations are willing to take care of user privacy. :) >> Another example could be that you have a pubsub node on your own >> jabber server used by mail services to push mail >notifications. Gmail >> and Hotmail should be able to publish information to this >node but not >> to read it. > >Good point. To put this in general level: publish-only affiliation is needed for nodes that have multiple publishers publishing sensitive information which cannot be shared between publishers. > >> In order to properly implement such use cases, we could add a >> "Publish-only" affiliations to the existing ones [1]: >> >> Subscribe: No >> Retrieve Items: No >> Publish Item: Yes >> Delete Item: Yes/No >> Configure Node: No >> Delete Node: No >> Purge Node: Yes/No This looks familiar... I specified yes/no for 'delete item' and 'purge node' because I hesitated if publisher should be able to delete items that are published by it self. Maybe it would be more straight forward if 'publish-only' would allow only publish and nothing else. Any thoughts? >> >> Any thoughts? > >I have no deep objections, and I can see many use cases in >which this would be useful. > >Anyone else? > We have also identified possible need for own access model that applies for publishing (as current access model applies only for subscribing). For some cases setting pubsub#publish model to 'publishers', 'subscribers' or 'open' is not enough. It also does not make much sense why these existing access models are not symmetrical. For example in some cases it would be very handy to define publish access model to 'presence' while subscribe access model is white-list. This would mean that all of my friends could publish to the node while only white-listed, my better friends, could subscribe to this node. We see this as a separate issue from publish-only affiliation but it is closely related to this. Best Regards, Petri Liimatta >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.8 (Darwin) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >iEYEARECAAYFAkrCkvQACgkQNL8k5A2w/vz0FACfZSxq6Y4I8SBcNb8JjXdGy8sV >y+cAnRzg8SUz21dg0pJMy4zqwN62N+0H >=qE14 >-----END PGP SIGNATURE----- >
