[Social] Roster Sequencing - with labels?

Sergey Nazarov phearnot at renee.ru
Mon Mar 31 15:46:53 CDT 2008


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

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


If ready-to-use gateways become available, social network developers will
only need to deploy any generally available XMPP server, optionally create
authentication adapters and deploy a gateway, extending it with custom
functionality. The whole thing becomes generalized, and the developers can
choose any gateway and server implementation.

>
> >
> > 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?
>
It is not obvious for me that we really need to grant roster access to a
third party. Once again, for now, I see no use case for roster item removal,
it'd be great if you provide one.

>
> right now the xmpp network is already a giant distributed social
> network.

Surely, xmpp network is a social network. But there's a difference between
social network and social networking service. The subject of this discussion
is a social networking service (please correct me if I'm mistaken). Social
networking service assumes its members have at least common interests, or
something. Unfortunately, XMPP network is not currently a social networking
service.

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

I think that social networking service application shouldn't care about such
things. The purpose of social netwoking service is to establish connections
between the members of community to make it easier for them to discuss their
favorite music, etc. In social networking services, my buddies are not
actually my friends. But the fact that you wish to preserve your buddy's
contacts after leaving the social networking service means that you are more
than just have similar music tastes. In this case, I see no reason for not
asking your friend to tell you her real JID.

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


-- 
Best Regards, Sergey Nazarov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080401/2b16c883/attachment-0001.htm 


More information about the social mailing list