[Pidgin] #4509: Support XMPP Invisibility

[Pidgin]

#4509: Support XMPP Invisibility
--------------------+-------------------------------------------------------
 Reporter:  js      |        Owner:  deryni
     Type:  defect  |       Status:  new   
Milestone:          |    Component:  XMPP  
  Version:  2.3.1   |   Resolution:        
 Keywords:          |  
--------------------+-------------------------------------------------------

Comment(by deryni):

 Menedas: XEP-0018 is rejected, which means it is not suitable for use by
 XMPP clients and servers, thus making anything it suggests invalid. You
 get that error code because (as I suggested) most server do not support
 XEP-0186 yet (as it is still relatively new).

 js: The fact that no servers support it at the moment doesn't make
 supporting it useless, it does mean that supporting it doesn't have any
 effect at the moment, but until and unless something better comes up that
 is what the current invisibility suggestion is for XMPP.

 Do not let the fact that the name 'privacy list' is used for both ICQ and
 XMPP fool you, they are not at all the same thing.

 The privacy lists in ICQ are (as far as I have ever understood) much
 *much* simpler than the XMPP feature of the same name. In ICQ there is
 exactly one visible list and exactly one invisible list, those lists are
 simple boolean lists (either a name is on the list or it is not), those
 lists are usable by id and can be guaranteed to exist, they only block
 presence notifications (not messages), and (historically) clients could
 only be signed on to an account from any one location at one time.

 Privacy lists in XMPP are incredibly more complicated than that: as many
 lists as the user wishes to create can exist; the lists can support
 entries by jid, by domain, by group, or by subscription status; the lists
 are usable by name (not ID) and cannot be guaranteed to exist (XEP-0126
 was an attempt to standardize a name so that clients could start to depend
 on the lists existing, it never made it very far); the lists can block
 presence (in each direction separately), messages (in each direction
 separately), and iq stanzas (in each direction separately); and clients
 have always been able to be logged in to more than one location (thus
 requiring client-to-client synchronizing of invisibility state and rule
 composition). A few last things, XMPP privacy lists are stackable and
 given the extensibility of XMPP the client (and the server) need to handle
 far more corner-cases in terms of valid and invalid responses than I
 believe ICQ clients (and the server) need to deal with.

 There is a reason that, despite privacy lists being in the core XMPP RFCs,
 so few clients and servers really support them in a reasonable manner and
 that at least three attempts at simplifying, explaining, or replacing them
 as a means for invisibility have occurred. (I challenge you to show me
 multiple clients and servers that correctly and usefully support privacy
 list usage for invisibility purposes.)

-- 
Ticket URL: <http://developer.pidgin.im/ticket/4509#comment:11>
Pidgin <http://pidgin.im>
Pidgin