[Social] Roster Sequencing - with labels?

anders conbere aconbere at gmail.com
Mon Mar 31 11:54:51 CDT 2008


On Mon, Mar 31, 2008 at 9:10 AM, Sergey Nazarov <phearnot at renee.ru> wrote:
> 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'm not sure I know what a transport is in this case.

~ Anders

>
> 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


More information about the social mailing list