[Standards-JIG] Re: JEP-126 (Invisibility)
jabber.org at ralphm.ik.nu
Wed Apr 12 17:55:42 UTC 2006
On Wed, Apr 12, 2006 at 07:23:02PM +0200, Remko Troncon wrote:
> On 12 Apr 2006, at 17:23, Peter Saint-Andre wrote:
> >The traditional approach to invisibility has been to stop presence
> >broadcasts at my server, so they would never get to your server (let
> >alone your client).
> Exactly, that's the whole point of being invisible: that your
> contacts don't know you are online. Rather useless if the presence
> still reaches them :-) This is exactly why defining it as a special
> type is not a clean way to go at it, since this means that the
> semantics of presence changes (i.e. presence packets are no longer
> broadcasted to everybody), complicating the spec.
> It's not that because invisibility is not a presence type at the
> protocol level, that clients cannot represent it as a special type of
> presence. Just leave the 'appear offline' in the UI, and translate it
> into <iq invisible>. If the user goes online again, do an <iq
> visible> again and send the selected presence.
I'll assume here that the reasons for wanting invisibility are sound, as
it seems we may never get a compromise. I'll just comment on the
I am with those that say invisibility is not really a presence setting
and we should use iq stanzas. So, you still send your presence to the
local server as usual and use the iq's to steer the broadcasting. That
is practical and conceptually valid.
Not that this doesn't invalidate the use of privacy lists. You can still
block outgoing (presence) traffic, even though it will not be sent when
Really, it is much like node configuration in pubsub. I imagine that it
is also easier to become invisible for subsets of your roster by
tweaking the protocol.
Directed presence will not be affected as it is not destined for your
I would choose having this in a JEP rather than the RFC.
More information about the Standards