[Standards] XEP-0126 invisibility interpretation

Andreas Monitzer jig at monitzer.com
Fri Feb 16 17:10:22 UTC 2007


On Feb 16, 2007, at 17:16, Peter Saint-Andre wrote:

> Andreas Monitzer wrote:
>
>> Maybe XEP-0186 should be extended to handle ICQ-style visible/ 
>> invisible-lists.
>
> http://www.icq.com/support/security/availability.html#cre says that  
> in ICQ you have the ability to specify lists of people who will:
>
> 1. Never see you as online even if you are in visible mode (this is  
> your "invisible list").
>
> 2. Always see you as online even if you are in invisible mode (this  
> is your "visible list").

That's correct.

> The thing I like about XEP-0186 is that it is a simple, on-off  
> mechanism for setting your "mode" as visible or invisible. AFAICS,  
> [in]visibility lists (a la ICQ) are something we'd define on top of  
> the mode. It's not clear to me right now how [in]visibility lists  
> would interact with privacy lists. However, it *is* clear to me  
> that this stuff is getting awfully complicated. :-) We have privacy  
> lists, [in]visibility mode, [in]visibility lists, block lists (a  
> subset of privacy lists), etc. That is way too much complexity and  
> we need to simplify, simplify, simplify.

I agree on the simplification part. When I wrote the now-dead Adium  
plugin for XMPP, I also implemented the privacy lists.
I couldn't simply write a user interface for that format, since it's  
far too complicated for casual users. I ended up allowing "block  
everybody except these people:", "allow everyone except these  
people:", "allow everyone" and "block everyone" (the last one isn't  
selectable from the user interface for obvious reasons). These  
options generated new privacy lists from templates I designed.
You simply can't ask for more complicated stuff in an end-user  
application.

However, the flexibility of the privacy lists creates the big  
problem, that your application would have to deal with arbitrary  
settings. You can't anticipate every possible configuration, so  
automatically modifying them to do the thing you want it to do (like  
emulating an invisibility mode) can have massive side-effects, like  
blocking something you didn't want to block.
I didn't solve this problem when I wrote my code, I just created a  
new list and set that one to be the default, removing the user's  
previously used settings (this was only done when the user modified  
the privacy settings inside Adium).

What good is a feature, when only 1% of the users can actually use  
it, and it breaks the whole thing for everybody else?

andy




More information about the Standards mailing list