On Tue, Apr 1, 2008 at 3:58 PM, Peter Saint-Andre <[EMAIL PROTECTED]> 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 > > >
