On 30 June 2010 16:56, Peter Saint-Andre <[email protected]> wrote: > On 6/30/10 9:32 AM, Paul Aurich wrote: >> On 2010-06-30 08:16, Peter Saint-Andre wrote: >>> Invisibility is evil. >> >> I'd say 'broken', but poe-tay-toe, poe-tah-toe. :) >> >>> On 6/29/10 11:13 PM, Paul Aurich wrote: >>>> While discussing XEP-0186 (Invisible Command) in >>>> [email protected], I noticed that the specification doesn't >>>> actually mention whether or not a server is supposed to generate any >>>> sort of presence probes. >>> >>> When the user changes from visible to invisible? >> >> When the user wants to "log in" as invisible (so the client doesn't have >> any prior presence activity and most of the user's buddies are going to >> appear offline, regardless of actual presence). > > Ah, I see. > > First, did I mention that invisibility is evil? >
Yes, you did, and I agree. Mainly because there is no such thing as invisibility. However this debate has been rolling on for years since <presence type='invisible'/> (which is still in use by some clients and servers on the network today). However now a simple solution is finally within our reach if we just take it. Then the whole issue will go away and we are freed to focus on more important aspects of the protocol. > Second, I think that if a user authenticates and binds a resource but > does not send initial presence, the server can take an IQ-set with > <invisible xmlns='urn:xmpp:invisible:0'/> as a signal that the user is > interested in receiving presence but not sending presence, at which > point it seems appropriate for the user's server to send presence > probes. Else how will the user receive presence from his buddies and > thereby take advantage of the magic invisibility ring? (I agree that > it's *dark* magic, but if we're going to do invisibility then we might > as well be completely evil.) > This is the problem. It has frequently been raised that the probes sent by the user's server can be detected by a contact's server (think plugins for easily-extensible XMPP servers...) to signal that the user is invisible. This issue is/was present in even ICQ, and they don't need to handle a federated network. Some people prefer "true" invisibility (no probes) and are willing to sacrifice immediate presence (they want to exchange messages with a known JID, or they want to join a chatroom). This isn't the same as not sending presence, because if you don't send presence then you aren't eligible to receive stanzas sent to the bare JID. Other people are happy with their server sending out probes, because they use invisibility as a "super" do-not-disturb, I think this is probably our most common group, but I can't say for sure. You asked for examples of my proposal. The client would simply add an optional 'probe' attribute in the request: <iq from='[email protected]/shire' id='inv1' type='set'> <invisible xmlns='urn:xmpp:invisible:0' probe='false' /> </iq> I think it should default to 'true' if not present because having presence work is likely the least surprising case for the user, and we don't /all/ think our contacts are out to get us. Clients are obviously able to override this decision as they wish. Regards, Matthew
