[Social] Roster Sequencing - with labels?
phearnot at renee.ru
Mon Mar 31 11:10:48 CDT 2008
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
Best Regards, Sergey Nazarov
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the social