Hello everyone! On Mon, Mar 31, 2008 at 7:44 PM, anders conbere <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 31, 2008 at 3:05 AM, Pedro Melo <[EMAIL PROTECTED]> wrote: > > Hi, > > > > > > > > On Mar 30, 2008, at 6:52 PM, anders conbere wrote: > > > One of the ideas that came up in a recent discussion about wanting to > > > be able to delegate (or authorize) third parties to act on and > > > interact with our rosters was that if we had a "perfect" rollback > > > solution that wouldn't be so bad. That got me thinking about the new > > > roster sequencing XEP, and how if it supports labeling changes, then > > > we could use that tool to label those changes as being made by a > > > delegate, and rollback those changes as we see fit. > > > > > > This of course totally ignores the fact that we don't seem to have > > > anything close to a delegation solution, but i thought it might be > > > good to bring up that possible unforeseen use case up. > > > > When something like this > > > > http://www.xmpp.org/extensions/inbox/roster-versioning.html > > > > gets deployed, you should have all the needed server-side > > infrastructure to do what you want. You would have to add the source- > > labeling part to each roster diff of course. > > > > I don't know what interaction those third parties would have with my > > roster so I don't know if this is enough. But if third-parties want > > to suggest some roster change, maybe they could use this instead: > > > > http://www.xmpp.org/extensions/xep-0144.html > > > > This way, control is still kept on my client, and I can approve the > > changes before they are made. > > My only problem here is that the goal is to in many ways give up a bit > of control (in essence use some online third party tool as a surrogate > buddy list manager). If I had to approve each change made at three > different social networks I wouldn't ever want to use the tool :) > > I'm thinking more along the lines of being able to grant authorization > to particular jid's to act on my roster. > > so for instance, if I wanted to be able to upload and interact with my > Roster through a service like twitter. I could give them my JID, and > then grant their JID ([EMAIL PROTECTED]) access to making roster > updates. And any changes I made to my "friends list" on twitter would > then be pushed down to my roster on my xmpp server. > > Now that's all fine and dandy, until I authorize someone I shouldn't > have and they delete all my contacts and I think "CRAP!". So it would > be nice to have a "rollback" which I think you could achieve through > roster versioning. > > ~ Anders > > > > > Best regards, > > -- > > Pedro Melo > > Blog: http://www.simplicidade.org/notes/ > > XMPP ID: [EMAIL PROTECTED] > > Use XMPP! > > > > > > > Andreas, could you please provide an example of an application where roster management can take place? I thought about using XMPP as an interface for social networks, when friends/buddies are automatically added to your roster, and the social networking software takes care of maintaining buddy list in a consistent state. But why not to use a transport for such case? I see several advantages of such approach. The first one is that iot's quite safe to register a transport. When one registers a transport, her roster is populated with contact list items from the other service. The transport can take care only of the items it created. It can add/delete items to reflect recent changes in a social network, while you can feel safe about the rest of the roster. It's also easier to track messages between the users of the service to perform various tasks: message archiving, etc. Quite contrary, when a message is sent directly from, say, [EMAIL PROTECTED] to [EMAIL PROTECTED]( montague.com and capulet.com are different servers, but Romeo and Juliet are friends in a social network), the only way to track a memssage is to extend XMPP server functionality at either montague.com or capulet.com. When you are no longer interested in a service, you can simply unregister the transport. -- Best Regards, Sergey Nazarov
