On 6/30/10 11:40 AM, Matthew Wild wrote: > 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.
Yep. There's no such thing as invisibility. :) For instance I could send directed presence or send messages while invisible and a malicious buddy of mine could broadcast that activity to everyone else. > 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). Excellent! <invisible xmlns='urn:xmpp:invisible:0' mode='really-invisible'/> vs. <invisible xmlns='urn:xmpp:invisible:0' mode='just-faking-it'/> > 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. I think it is, yes. > 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. Sure, WFM. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
