On Mon, Mar 31, 2008 at 9:10 AM, Sergey Nazarov <[EMAIL PROTECTED]> wrote: > 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'm pretty sure I don't understand all of the nuances of gateways, but it seems to me that it would require a bunch more work on the part of the social networks to support something like this. If we want social networks to use these technologies (and I think we do) then they have to be trivial to use. > > 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. Aye, but doesn't that mean that the social network doesn't have access to the rest of the roster... isn't that part of the power that we want to enable? right now the xmpp network is already a giant distributed social network. I list my friends in my buddy list, I mark them up in groups and I interact with them across servers. The authorization framework is already well established, the tools for server to server communication understood, and the roster interactions are powerful. Despite all that the tools to make this network accessible to social network creators don't really exist yet. Right now as a social network creator if I want to tap into the giant jabber social network, I ask my users for their JID and Password, then spin up a client in a new process and I pull their roster. Unfortunately for my users this also grants me access to do horrible things, but this is the easiest way to allow them to share that data with me. > > 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. But what If I still want the people, who all had JID's from the other service to be my buddies? I don't want to loose all my contacts when I leave a service. There's not reason that the service couldn't push all it's relations into an xmpp server and I could keep chatting with them because we know how to do S2S. ~ Anders > -- > Best Regards, Sergey Nazarov
