[Standards] Invisible Command and probes

Peter Saint-Andre stpeter at stpeter.im
Wed Jun 30 17:46:36 UTC 2010

On 6/30/10 11:40 AM, Matthew Wild wrote:
> On 30 June 2010 16:56, Peter Saint-Andre <stpeter at stpeter.im> 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
>>>>> prosody at conference.prosody.im, 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). 


<invisible xmlns='urn:xmpp:invisible:0' mode='really-invisible'/>


<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='bilbo at tolkien.lit/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 Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100630/a924cd40/attachment.bin>

More information about the Standards mailing list