Re: [Standards] Invisible Command

[Peter Saint-Andre]

On 12/1/16 9:29 AM, Peter Saint-Andre wrote:

Do folks here want to finish off the Invisible Command spec? It has been
"Proposed" for a long time:

http://xmpp.org/extensions/xep-0186.html

If so, a PR for https://github.com/xsf/xeps/issues/109 would be helpful.


I looked at this again yesterday. Matthew Wild's point was that it would 
be good for the client to specify how it wants the server to proceed 
with respect to presence probes. (E.g., it might not want its server to 
ever send probes, or it might want the server to send probes so that it 
can learn about the presence of other entities.)


My feeling is that, traditionally, invisible mode enabled you to see 
others (i.e., it's OK for your server to send probes) but not for others 
to see you. However, I can see why a more paranoid user might not want 
to send probes. Therefore, I propose that we add a boolean 'probe' flag 
for the traditional and paranoid approaches:




or



I'll submit a PR for this.

Peter



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Invisible Command

[Goffi]

Le jeudi 1 décembre 2016, 09:29:44 CET Peter Saint-Andre a écrit :
> Do folks here want to finish off the Invisible Command spec? It has been
> "Proposed" for a long time:
> 
> http://xmpp.org/extensions/xep-0186.html
> 
> If so, a PR for https://github.com/xsf/xeps/issues/109 would be helpful.
> 
> If not, let's kill it off definitively, shall we? ;-)
> 
> Peter
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___


we have not implemented it yet, but I think it's a needed feature to be able 
to connect without sending presence to everybody in he roster (and I would 
love to be able to be visible only to a roster group, which is not the same as 
sending directed presence to all members of the group). 

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Invisible Command

[Sam Whited]

On Thu, Dec 1, 2016 at 11:10 AM, Peter Saint-Andre  wrote:
> You work on MAM, I'll work on invisibility. ;-)

The other thing the angry man I mentioned complained about was that
they'd implemented Message Archiving on the basis that it was draft
and MAM was only experimental, only to find that everyone was using
MAM and that it was "recommended" :)

—Sam


-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Invisible Command

[Peter Saint-Andre]

On 12/1/16 10:11 AM, Sam Whited wrote:

On Thu, Dec 1, 2016 at 10:29 AM, Peter Saint-Andre  wrote:

Do folks here want to finish off the Invisible Command spec? It has been
"Proposed" for a long time:


I was actually at a Go meetup a few days ago and started talking to
someone about XMPP; when I mentioned I was involved at the XSF he
immediately started complaining about how there were often multiple
specs that did the same thing and no clear guidance on what should be
implemented and what was deprecated. When I asked if he has a specific
spec in mind, this is the one he complained about, so I suspect it's
still worth having based on my sample set of 1 angry guy at an
unrelated meetup.


Agreed that it's bad to have multiple ways of doing the same thing! I'll 
work on this soon.


Peter


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Invisible Command

[Peter Saint-Andre]

On 12/1/16 9:59 AM, Matthew Wild wrote:

On 1 December 2016 at 16:29, Peter Saint-Andre  wrote:

Do folks here want to finish off the Invisible Command spec? It has been
"Proposed" for a long time:

http://xmpp.org/extensions/xep-0186.html


I'd like it to survive, it's a good companion to XEP-0191. I don't
believe invisibility is a common feature request nowadays, but I think
it's a good feature to have standardized in a sensible way.

Unless someone else volunteers, I can prepare an update to the XEP.
However my spec-writing time is currently taken up with other
important things, so it may not be immediate.


You work on MAM, I'll work on invisibility. ;-)


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Invisible Command

[Matthew Wild]

On 1 December 2016 at 16:29, Peter Saint-Andre  wrote:
> Do folks here want to finish off the Invisible Command spec? It has been
> "Proposed" for a long time:
>
> http://xmpp.org/extensions/xep-0186.html

I'd like it to survive, it's a good companion to XEP-0191. I don't
believe invisibility is a common feature request nowadays, but I think
it's a good feature to have standardized in a sensible way.

Unless someone else volunteers, I can prepare an update to the XEP.
However my spec-writing time is currently taken up with other
important things, so it may not be immediate.

Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Invisible Command and probes

[Matthew Wild]

On 30 June 2010 06:13, Paul Aurich p...@darkrain42.org wrote:
 While discussing XEP-0186 (Invisible Command) in
 pros...@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.

 Waqas suggested that based on historical discussions, most people think
 the server shouldn't (I disagree, but anyway.)  Regardless of which side
 of that people are on, I think the specification should, at the very
 least, bring up the topic.


I wasn't around for the discussion (I was sleeping for once) but my
plan for a while has been to add a new attribute to signal this.
Setting probe='true' would ask the server to send probes (and thus
risk revealing your connected state) or probe='false' to not do this,
but understand you may not receive presence from your contacts.

Matthew

Re: [Standards] Invisible Command and probes

[Paul Aurich]

On 2010-06-29 23:48, Matthew Wild wrote:
 On 30 June 2010 06:13, Paul Aurich p...@darkrain42.org wrote:
 While discussing XEP-0186 (Invisible Command) in
 pros...@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.

 Waqas suggested that based on historical discussions, most people think
 the server shouldn't (I disagree, but anyway.)  Regardless of which side
 of that people are on, I think the specification should, at the very
 least, bring up the topic.

 
 I wasn't around for the discussion (I was sleeping for once) but my
 plan for a while has been to add a new attribute to signal this.
 Setting probe='true' would ask the server to send probes (and thus
 risk revealing your connected state) or probe='false' to not do this,
 but understand you may not receive presence from your contacts.

+1 from me (if only because I suspect I'd be on the losing side of the
ensuing debate without this option ;) )

~Paul



signature.asc
Description: OpenPGP digital signature

Re: [Standards] Invisible Command and probes

[Matthew Wild]

On 30 June 2010 08:06, Paul Aurich p...@darkrain42.org wrote:
 On 2010-06-29 23:48, Matthew Wild wrote:
 On 30 June 2010 06:13, Paul Aurich p...@darkrain42.org wrote:
 While discussing XEP-0186 (Invisible Command) in
 pros...@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.



 I wasn't around for the discussion (I was sleeping for once) but my
 plan for a while has been to add a new attribute to signal this.
 Setting probe='true' would ask the server to send probes (and thus
 risk revealing your connected state) or probe='false' to not do this,
 but understand you may not receive presence from your contacts.

 +1 from me (if only because I suspect I'd be on the losing side of the
 ensuing debate without this option ;) )


The debate has been rolling on for years, I don't think there are or
will be any winners or losers for some centuries if we allow it to
continue :)

Matthew

Re: [Standards] Invisible Command and probes

[Peter Saint-Andre]

On 6/30/10 12:48 AM, Matthew Wild wrote:
 On 30 June 2010 06:13, Paul Aurich p...@darkrain42.org wrote:
 While discussing XEP-0186 (Invisible Command) in
 pros...@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.

 Waqas suggested that based on historical discussions, most people think
 the server shouldn't (I disagree, but anyway.)  Regardless of which side
 of that people are on, I think the specification should, at the very
 least, bring up the topic.

 
 I wasn't around for the discussion (I was sleeping for once) but my
 plan for a while has been to add a new attribute to signal this.
 Setting probe='true' would ask the server to send probes (and thus
 risk revealing your connected state) or probe='false' to not do this,
 but understand you may not receive presence from your contacts.

When in doubt, introduce an option? ;-)




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] Invisible Command and probes

[Matthew Wild]

On 30 June 2010 16:16, Peter Saint-Andre stpe...@stpeter.im wrote:
 On 6/30/10 12:48 AM, Matthew Wild wrote:
 On 30 June 2010 06:13, Paul Aurich p...@darkrain42.org wrote:
 While discussing XEP-0186 (Invisible Command) in
 pros...@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.

 Waqas suggested that based on historical discussions, most people think
 the server shouldn't (I disagree, but anyway.)  Regardless of which side
 of that people are on, I think the specification should, at the very
 least, bring up the topic.


 I wasn't around for the discussion (I was sleeping for once) but my
 plan for a while has been to add a new attribute to signal this.
 Setting probe='true' would ask the server to send probes (and thus
 risk revealing your connected state) or probe='false' to not do this,
 but understand you may not receive presence from your contacts.

 When in doubt, introduce an option? ;-)


As a wise developer once said: You can please some of the people all
of the time, all of the people some of the time, or you can introduce
an option.

Matthew

Re: [Standards] Invisible Command and probes

[Peter Saint-Andre]

On 6/30/10 9:20 AM, Matthew Wild wrote:
 On 30 June 2010 16:16, Peter Saint-Andre stpe...@stpeter.im wrote:
 On 6/30/10 12:48 AM, Matthew Wild wrote:
 On 30 June 2010 06:13, Paul Aurich p...@darkrain42.org wrote:
 While discussing XEP-0186 (Invisible Command) in
 pros...@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.

 Waqas suggested that based on historical discussions, most people think
 the server shouldn't (I disagree, but anyway.)  Regardless of which side
 of that people are on, I think the specification should, at the very
 least, bring up the topic.


 I wasn't around for the discussion (I was sleeping for once) but my
 plan for a while has been to add a new attribute to signal this.
 Setting probe='true' would ask the server to send probes (and thus
 risk revealing your connected state) or probe='false' to not do this,
 but understand you may not receive presence from your contacts.

 When in doubt, introduce an option? ;-)

 
 As a wise developer once said: You can please some of the people all
 of the time, all of the people some of the time, or you can introduce
 an option.

Where would this option go and how would it be used? Examples would help. :)




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] Invisible Command and probes

[Paul Aurich]

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
 pros...@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).

~Paul



signature.asc
Description: OpenPGP digital signature

Re: [Standards] Invisible Command and probes

[Dave Cridland]

On Wed Jun 30 16:16:35 2010, Peter Saint-Andre wrote:

When in doubt, introduce an option? ;-)


Is it time for an argument over the default value, then?

Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Re: [Standards] Invisible Command and probes

[Matthew Wild]

On 30 June 2010 16:56, Peter Saint-Andre stpe...@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
 pros...@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.

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='bi...@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.

Regards,
Matthew

Re: [Standards] Invisible Command and probes

[Peter Saint-Andre]

On 6/30/10 11:40 AM, Matthew Wild wrote:
 On 30 June 2010 16:56, Peter Saint-Andre stpe...@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
 pros...@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). 

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='bi...@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

-- 
Peter Saint-Andre
https://stpeter.im/





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] Invisible Command and probes

[Philipp Hancke]

Matthew Wild wrote:
[...]

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.


Is there a standard way the contact's server can notify the user about 
the probe?




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.


So we need to decouple initial presence and the ability to receive 
stanzas sent to the bare jid?


philipp

Re: [Standards] Invisible Command and probes

[Philipp Hancke]

Justin Karneges wrote:

On Wednesday 30 June 2010 10:40:38 Matthew Wild wrote:

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.


Have an XMPP server that probes contacts the first time it knows about them, 
and on bootup, but never for any other reason.  Local user logins would never 
trigger probes.  All incoming presence is cached indefinitely.


Advantages:
  Optimized login times (instant presence for remote contacts, no waiting).
  No giving away your availability due to causing probes when you log in.

Disadvantages:
  Use lots of memory to cache presence.

On my 10-person server the advantages would outweigh the disadvantages.


Did you ever implement that? Imo it does not work (i.e. the cache is not 
reliable due to lost presence stanzas), but I would like to hear a 
second opinion.


philipp

Re: [Standards] Invisible Command and probes

[Peter Mount]

A user that never logs out - that could also refer to a bot as they wouldn't 
ever log out.

-- 
Peter Mount (from my BlackBerry)

Email: pe...@retep.org.uk
  Web:  http://retep.org
Phone: +44 (0)7903 155887
 XMPP: pe...@retep.org (Primary)
 XMPP: petermo...@gmail.com (blackberry)


-Original Message-
From: Justin Karneges justin-keyword-jabber.093...@affinix.com
Sender: standards-boun...@xmpp.org
Date: Wed, 30 Jun 2010 11:47:34 
To: XMPP Standardsstandards@xmpp.org
Reply-To: XMPP Standards standards@xmpp.org
Subject: Re: [Standards] Invisible Command and probes

On Wednesday 30 June 2010 11:35:23 Philipp Hancke wrote:
 Justin Karneges wrote:
  Have an XMPP server that probes contacts the first time it knows about
  them, and on bootup, but never for any other reason.  Local user logins
  would never trigger probes.  All incoming presence is cached
  indefinitely.

 Did you ever implement that? Imo it does not work (i.e. the cache is not
 reliable due to lost presence stanzas), but I would like to hear a
 second opinion.

It's no worse than when you have a user who never log out.  You know, the kind 
who stays logged in even at night and sets their status to Sleeping.  
Probing on an interval is probably the right solution for maintaining 
reliable presence.

-Justin