Several popular instant messaging services implement a feature known as invisibility: the ability to remain online yet appear offline to some or all of one's contacts. A number of Jabber servers and clients have also implemented such a feature, using special values of the <presence/> element's 'type' attribute (e.g., <presence type='invisible'/>). Unfortunately, such implementations are not compliant with XMPP Core [1] and XMPP IM [2], which specify that only the 'type' attribute values defined in the XML schema for the 'jabber:client' and 'jabber:server' namespaces are allowed in XMPP (and those values do not include "invisible"). However, RFC 3921 also defines a privacy lists protocol (i.e., the 'jabber:iq:privacy' namespace) that can be used to implement invisibility in an XMPP-compliant manner. This specification documents how to do just that.
This document addresses the following requirements:
This document addresses the following use cases:
These use cases are defined below in "chronological" order by following a scenario in which a user (1) logs in as invisible, (2) becomes selectively visible to certain contacts, (3) becomes visible to all contacts, (4) becomes selectively invisible to certain contacts, and finally (5) becomes invisible to all contacts.
If a user wants to log in as invisible, a certain order of events MUST be followed. Specifically, after authenticating but before sending initial presence, the user MUST define (if necessary) and set as active a privacy list that blocks all outbound presence notifications.
... authentication / session establishment ...
<iq from='bilbo@tolkien.lit/shire' type='set' id='inv1'>
<query xmlns='jabber:iq:privacy'>
<list name='invisible'>
<item action='deny' order='1'>
<presence-out/>
</item>
</list>
</query>
</iq>
<iq from='bilbo@tolkien.lit/shire' type='set' id='active1'>
<query xmlns='jabber:iq:privacy'>
<active name='invisible'/>
</query>
</iq>
Naturally, the user could have defined this list during a previous session and could simply set the relevant list as active when logging in, rather than defining the list on login. Both steps are shown here for completeness.
The user may now send initial presence to the server.
<presence> <status>I'm not really here, you understand!</status> </presence>
Even though the user has sent initial presence, that presence information will not be broadcasted to any of the user's contacts, since the active privacy list blocks all outbound presence notifications.
Let us now suppose that the user tires of being globally invisible, and decides to become visible to some -- but not all -- contacts (not even famous magic rings possess this feature). The 'jabber:iq:privacy' namespace gives the user three options:
Examples of these options are shown below.
<iq from='bilbo@tolkien.lit/shire' type='set' id='inv2'>
<query xmlns='jabber:iq:privacy'>
<list name='visible-to-Frodo'>
<item type='jid'
value='frodo@tolkien.lit'
action='allow'
order='1'>
<presence-out/>
</item>
<item action='deny' order='2'>
<presence-out/>
</item>
</list>
</query>
</iq>
<iq from='bilbo@tolkien.lit/shire' type='set' id='active2'>
<query xmlns='jabber:iq:privacy'>
<active name='visible-to-Frodo'/>
</query>
</iq>
The foregoing privacy list blocks outbound presence notifications to every JID except one.
In order to ensure synchronization of presence notifications, the client SHOULD now re-send the user's presence for broadcasting to all contacts, which the active rule will block to all but the specified JID:
<presence> <status>I'm not really here, you understand!</status> </presence>
<iq from='bilbo@tolkien.lit/shire' type='set' id='inv3'>
<query xmlns='jabber:iq:privacy'>
<list name='visible-to-Bagginses'>
<item type='group'
value='Bagginses'
action='allow'
order='1'>
<presence-out/>
</item>
<item action='deny' order='2'>
<presence-out/>
</item>
</list>
</query>
</iq>
<iq from='bilbo@tolkien.lit/shire' type='set' id='active3'>
<query xmlns='jabber:iq:privacy'>
<active name='visible-to-Bagginses'/>
</query>
</iq>
The foregoing privacy list blocks outbound presence notifications to every JID except those in a certain roster group. In order to ensure synchronization of presence notifications, the client SHOULD now re-send the user's presence for broadcasting to all contacts, which the active rule will block to all but those JIDs in the specified roster group:
<presence> <status>I'm not really here, you understand!</status> </presence>
Becoming visible or invisible by subscription type is probably much less likely than becoming visible by JID or roster group; however, it is described here for the sake of completeness.
<iq from='bilbo@tolkien.lit/shire' type='set' id='inv4'>
<query xmlns='jabber:iq:privacy'>
<list name='visible-to-both'>
<item type='subscription'
value='both'
action='allow'
order='1'>
<presence-out/>
</item>
<item action='deny' order='2'>
<presence-out/>
</item>
</list>
</query>
</iq>
<iq from='bilbo@tolkien.lit/shire' type='set' id='active4'>
<query xmlns='jabber:iq:privacy'>
<active name='visible-to-both'/>
</query>
</iq>
The foregoing privacy list blocks outbound presence notifications to every JID except those that are in the user's roster with a subscription type of "both".
In order to ensure synchronization of presence notifications, the client SHOULD now re-send the user's presence for broadcasting to all contacts, which the active rule will block to all but those JIDs with the specified subscription type:
<presence> <status>I'm not really here, you understand!</status> </presence>
Let us now suppose that the user wants to become visible to all those who are subscribed to his presence. This easy to do by defining and setting as active a new privacy list (here again, the privacy list may have been defined previously).
<iq from='bilbo@tolkien.lit/shire' type='set' id='inv5'>
<query xmlns='jabber:iq:privacy'>
<list name='visible'>
<item action='allow' order='1'>
<presence-out/>
</item>
</list>
</query>
</iq>
<iq from='bilbo@tolkien.lit/shire' type='set' id='active5'>
<query xmlns='jabber:iq:privacy'>
<active name='visible'/>
</query>
</iq>
Because globally allowing outbound presence notifications is most likely the default behavior of any server, a more straightforward way to become globally visible is to decline the use of any active rule (the equivalent, as it were, of taking off a magic invisibility ring):
<iq from='bilbo@tolkien.lit/shire' type='set' id='active6'>
<query xmlns='jabber:iq:privacy'>
<active/>
</query>
</iq>
In order to ensure synchronization of presence notifications, the client SHOULD now re-send the user's presence for broadcasting to all contacts, which the active rule will block to all but the specified JID:
<presence> <status>I'm back!</status> </presence>
Let us now suppose that the user no longer wants to be globally visible, but desires to be invisible only to some -- but not all -- contacts. As with visibility, here again the 'jabber:iq:privacy' namespace gives the user three options:
Examples of these options are shown below.
In general, the process for becoming selectively invisible is as follows:
This process is necessary so that the contacts covered by the rule will no longer see the user as available.
First, the user sends unavailable presence for broadcasting to all contacts:
<presence type='unavailable'/>
The server then broadcasts that presence to all of the user's contacts.
Second, the user defines and sets a privacy rule that allows selective invisibility:
<iq from='bilbo@tolkien.lit/shire' type='set' id='inv6'>
<query xmlns='jabber:iq:privacy'>
<list name='invisible-to-Gandalf'>
<item type='jid'
value='gandalf@tolkien.lit'
action='deny'
order='1'>
<presence-out/>
</item>
<item action='allow' order='2'>
<presence-out/>
</item>
</list>
</query>
</iq>
<iq from='bilbo@tolkien.lit/shire' type='set' id='active7'>
<query xmlns='jabber:iq:privacy'>
<active name='invisible-to-Gandalf'/>
</query>
</iq>
The foregoing privacy list allows outbound presence notifications to every JID except one.
In order to appear selectively invisible, the client MUST now re-send the user's presence for broadcasting to all contacts, which the active rule will block to the specified JID:
<presence> <status>I'm back!</status> </presence>
First, the user sends unavailable presence for broadcasting to all contacts:
<presence type='unavailable'/>
The server then broadcasts that presence to all of the user's contacts.
Second, the user defines and sets a privacy rule that allows selective invisibility:
<iq from='bilbo@tolkien.lit/shire' type='set' id='inv7'>
<query xmlns='jabber:iq:privacy'>
<list name='invisible-to-Wizards'>
<item type='group'
value='Wizards'
action='deny'
order='1'>
<presence-out/>
</item>
<item action='allow' order='2'>
<presence-out/>
</item>
</list>
</query>
</iq>
<iq from='bilbo@tolkien.lit/shire' type='set' id='active8'>
<query xmlns='jabber:iq:privacy'>
<active name='invisible-to-Wizards'/>
</query>
</iq>
The foregoing privacy list allows outbound presence notifications to every JID except those in a certain roster group.
In order to appear selectively invisible, the client MUST now re-send the user's presence for broadcasting to all contacts, which the active rule will block to those in the specified roster group:
<presence> <status>I'm back!</status> </presence>
Becoming visible or invisible by subscription type is probably much less likely than becoming visible by JID or roster group; however, it is described here for the sake of completeness.
First, the user sends unavailable presence for broadcasting to all contacts:
<presence type='unavailable'/>
The server then broadcasts that presence to all of the user's contacts.
Second, the user defines and sets a privacy rule that allows selective invisibility:
<iq from='bilbo@tolkien.lit/shire' type='set' id='inv8'>
<query xmlns='jabber:iq:privacy'>
<list name='invisible-to-from'>
<item type='subscription'
value='from'
action='deny'
order='1'>
<presence-out/>
</item>
<item action='allow' order='2'>
<presence-out/>
</item>
</list>
</query>
</iq>
<iq from='bilbo@tolkien.lit/shire' type='set' id='active9'>
<query xmlns='jabber:iq:privacy'>
<active name='invisible-to-from'/>
</query>
</iq>
The foregoing privacy list allows outbound presence notifications to every JID except those that are in the user's roster with a subscription type of "to".
In order to appear selectively invisible, the client MUST now re-send the user's presence for broadcasting to all contacts, which the active rule will block to those with the specified subscription type:
<presence> <status>I'm back!</status> </presence>
In order to become globally invisible again, the user does the following.
First, the user sends unavailable presence for broadcasting to all contacts:
<presence type='unavailable'/>
Second, the user sets as active the global invisibility list previously defined:
<iq from='bilbo@tolkien.lit/shire' type='set' id='active10'>
<query xmlns='jabber:iq:privacy'>
<active name='invisible'/>
</query>
</iq>
In order to appear globally invisible, the client MUST now re-send the user's presence for broadcasting to all contacts, which the active rule will block to all contacts:
<presence> <status>I'm not really here, you understand!</status> </presence>
The foregoing text explains the protocol used to implement invisibility. Naturally, client developers will most likely want to hide these protocol details from the end user. For example, rather than forcing the end user to navigate the details of privacy list management, a client could simply provide a "Go Invisible" button that sets as active the appropriate privacy list.
Note well that the privacy lists used to implement invisibility SHOULD be active lists and not the default list.
To help ensure cross-client compatibility, it is RECOMMENDED to use the privacy list names "visible" and "invisible" for simple global visibility and invisibility respectively. It is also RECOMMENDED to use list names of the form "visible-to-GroupName" and "invisible-to-JID" for simple lists that implement visibility or invisibility with regard to roster groups and JIDs. Obviously list names could become rather complex, such as "visible-to-Group1 Group2 Group3". Implementations MUST NOT attempt to derive semantic meaning from privacy list names; these recommendations are provided for ease of use only with regard to basic privacy lists related to visibility/invisibility.
In general it is probably easiest for users to become visible/invisible either globally or based on roster group, since these models are conceptually simple. Although, naturally, a client developer cannot tell users what to do, it probably best to encourage the use of conceptually simple models for privacy lists.
Privacy lists can become complex and must be carefully managed by clients. For example, let us imagine that the user is currently applying another active list unrelated to visibility (e.g., a list that blocks communications with a stalker); if the user then clicks "Go Invisible" and the client is not smart, it could overwrite the stalker blocking. Therefore, if the user has an active list that incorporates rules other than those related to visibility/invisibility, the client SHOULD either assume that visibility/invisibility is an overlay on the list currently in use (generating an appropriate privacy list that takes both into account) or prompt the user regarding their intentions. In the absence of privacy lists unrelated to visibility/invisibility, the client may proceed in a less cautious fashion.
For security concerns related to privacy lists, refer to RFC 3921. Care must be taken regarding privacy lists, especially so that visibility/invisibility rules do not overwrite existing rules the user has set for the sake of security and privacy; for details, see the Implementation Notes section of this document.
It is important to recognize that invisibility can be defeated without more advanced privacy lists than those defined above and an awareness of context on the part of a client. For example, if a user usually logs in as the same resource (e.g., "Home"), a contact can send an IQ request to that resource's full JID using Last Activity (XEP-0012) [3], Service Discovery (XEP-0030) [4], Legacy Entity Time (XEP-0090) [5], or Software Version (XEP-0092) [6] and receive a reply, thus providing information that reveals the user's availability. In addition, Last Activity requests sent by a subscribed contact to the user's bare JID will normally reveal the user's availability as well. To help ensure that the user's invisibility cannot be defeated in this way, the user's client SHOULD add IQ blocking to the relevant privacy list. Finally, the user's client SHOULD NOT return "is-composing" events as defined in Message Events (XEP-0022) [7] or Chat State Notifications (XEP-0085) [8].
This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [9].
No namespaces or parameters need to be registered with the XMPP Registrar [10] as a result of this specification.
The XML schema for the 'jabber:iq:privacy' namespace is defined in RFC 3921.
This document in other formats: XML PDF
This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).
Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.
## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).
The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.
Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.
Errata can be sent to <editor@xmpp.org>.
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
1. RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>.
2. RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc6121>.
3. XEP-0012: Last Activity <https://xmpp.org/extensions/xep-0012.html>.
4. XEP-0030: Service Discovery <https://xmpp.org/extensions/xep-0030.html>.
5. XEP-0090: Legacy Entity Time <https://xmpp.org/extensions/xep-0090.html>.
6. XEP-0092: Software Version <https://xmpp.org/extensions/xep-0092.html>.
7. XEP-0022: Message Events <https://xmpp.org/extensions/xep-0022.html>.
8. XEP-0085: Chat State Notifications <https://xmpp.org/extensions/xep-0085.html>.
9. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
10. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>.
Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/
END