On Tue, Oct 7, 2008 at 11:27 AM, Remko Tronçon <[EMAIL PROTECTED]> wrote: >> Imho this is not a protocol issue, but a client issue > > This has been discussed in length before, and the conclusion was that > there is no user friendly *and* correct way to do invisibility on top > of privacy lists, or any kind of simple operation (such as blocking). > Psi has a 'simple' user interface for blocking contacts on top of > privacy lists, but if you used *any* other client to do some privacy > list operation, then it could break this. We show a warning 'your list > may not work', but this is just a horrible user experience. And things > get even nastier if you do invisibility, with all kinds of problematic > corner cases. > > Maybe you should look up the original discussion. > > You cannot fully abstract something that is fundamentally complex. > Sooner or later, a user of your abstraction will bump into a problem, > and will not understand it unless he understands the concepts > underlying your abstraction.
(sorry for the delays, but in the last two days of many standards_ml mails went into the spam folder :( ) I agree with the fact there is no general abstraction for privacy lists and there complexity is far beyond the capabilities of the average user (the psi interface for example is of little help if you don't know basic xmpp concepts, and even if you know building them is pretty along task). What I was meaning is just that between adding a new namespace (such as in xep-186) or reusing something already present (xep-126), I prefer the second one. If haven't missed a discussion where xep-126 has been definitely turned down, the main obstacle of a "simple" privacy list approach is that there is no agreement between client developers in naming the lists associated to basic blocking or invisibility operations, and about when keeping them active (if there are more issues, please point me to the correct discussion, I'm new in this subject, since I've just started studying it for our mobile clients, where we really need fine grained temporary invisibility or unwanted packet blocking). bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
