[Social] Roster Sequencing - with labels?

Sergey Nazarov phearnot at renee.ru
Mon Mar 31 11:10:48 CDT 2008

Hello everyone!

On Mon, Mar 31, 2008 at 7:44 PM, anders conbere <aconbere at gmail.com> wrote:

> On Mon, Mar 31, 2008 at 3:05 AM, Pedro Melo <melo at simplicidade.org> 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 (twitter at twitter.com) 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: melo at simplicidade.org
> >  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, romeo at montague.com to juliet at capulet.com(
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080331/7d0dd1f8/attachment.htm 

More information about the social mailing list