[Social] Roster Sequencing - with labels?

[anders conbere]

On Tue, Apr 1, 2008 at 3:58 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> 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.
>
>  By labeling do you nean that each sequence or push would be tagged in
>  some way (e.g., this change was initiated by SNA-1)?

yes... much like in a version control system changes are labeled by
those who made the change.

>
>
>  > 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.
>
>  By "delegation solution" do you mean something like OAuth? So that for
>  example I could allow some SNA to modify my roster?

Yes, I would be in the example above authorize the entity of the
social network to act on and modify my roster.

>
>  This sounds similar to remote/shared roster groups -- I allow some other
>  entity to modify a portion of my roster. So for instance if you are a
>  member of the XSF -- and you guys really should be, we have an open
>  membership application period right now! [1] -- then your "XSF" group
>  could be maintained by the Secretary of the XSF and therefore it would
>  be automatically updated when new members are elected. We have been
>  thinking about this kind of feature for a long time. Most of the XMPP
>  server implementations have it but not in a distributed way -- they tie
>  it to LDAP groups inside an organization so that when Suzy joins the
>  marketing department or Bill gets fired in QA, your roster changes
>  without any interaction on your part. Doing this in a decentralized
>  manner is a bit harder, but I'm interested in solving the problem.

This sounds close, I suspect that details about my specific use cases
could be ironed out in the broader XEP discussions. That particular
discussion sounds like it's about modifying a group of roster items
that would be distributed to a set of users, where as mine would only
be distributed to a single particular user. This sounds like a subset
of the functionality of the above but I'm interested in at least
recognizing that use case before looking into solutions.

>
>  If this is what you want, please raise your hand. :)
>
>  Peter
>
>  [1] http://mail.jabber.org/pipermail/jdev/2008-March/026471.html
>
>
>