XEP-0018: Invisible Presence

3.1 User Becomes Invisible to All Contacts¶

Assuming the user's client has authenticated with the system normally, it would send the following presence stanza to become invisible (note: this can be the initial presence stanza sent by the user). To do so, the client will send undirected presence with a type="invisible" attribute.

<presence type="invisible"/>

3.2 User Becomes Visible to All Contacts¶

If a user chooses to become visible after being invisible, the client will send undirected presence with a type="visible" attribute.

<presence type="visible"/>

3.3 User Becomes Invisible to Selected Contact¶

If a user is visible to all of their contacts, and wishes to become invisible to selected contacts on their roster, then their client will send the following directed presence stanza.

<presence to="joe@foo.com" type="invisible"/>

In this case, the server begins to track that the user is invisible to the contact joe@foo.com, and does not forward further presence updates to joe@foo.com. If the user wishes joe@foo.com to received further presence updates, then their client must send either an undirected presence stanza with a type="visible" attribute (see Example 2), or a directed presence stanza to joe@foo.com with a type="visible" attribute as below.

<presence to="joe@foo.com" type="visible"/>

3.4 User Becomes Visible to Selected Contact¶

The opposite behavior of the previous section should, also, be present in the server. For example, if a user is invisible to all of their contacts, they should be able to become visible to a selected contact by send a stanza similar to the one in Example 4.

As with the previous section, a user can later choose to hide his presence updates for joe@foo.com by either sending an undirected presence stanza (see Example 1), or by sending a directed presence stanza to joe@foo.com (see Example 3).

4.1 Undirected Presence While Invisible to Selected Contacts¶

One of the biggest failings of older invisible mode implementations were client features like auto-away. In most cases, these auto-away stanza would inadvertently cause a user to become visible (although away) to all contacts on its roster. This invisible presence protocol has been designed to deal with that problem elegantly.

Consider the following situation (the protocol for which is shown in the examples below):

1. joe@foo.com has contacts stpeter@foo.com, pgmillard@foo.com and rynok@foo.com on his roster.
2. joe@foo.com has logged into the foo.com sever, but has set his presence to invisible.
3. Assume that stpeter@foo.com, pgmillard@foo.com and rynok@foo.com are all online and visible.
4. joe@foo.com wants rynok@foo.com to see his presence updates, but not stpeter@foo.com or pgmillard@foo.com
5. joe@foo.com sets his presence to extended away.
6. joe@foo.com decides to become visible to all contacts on his roster.
7. joe@foo.com decides to become invisible to pgmillard@foo.com.
8. joe@foo.com set his presence to free to chat.

<presence type="invisible"/>

Since joe@foo.com has just come online, the server SHOULD NOT forward any presence stanzas to contacts on his roster.

<presence to="rynok@foo.com" type="visible"/>

<presence from="joe@foo.com/resource" to="rynok@foo.com"/>

<presence><show>xa</show><status>Away (due to idle)</status></presence>

<presence from="joe@foo.com/resource" to="rynok@foo.com">
    <show>away</show><status>Meeting</status>
</presence>

Note that in this example, presence updates from joe@foo.com are routed only to rynok@foo.com, despite the fact that stpeter@foo.com and pgmillard@foo.com are both online and available. This is because joe@foo.com has chosen to be visible only to rynok@foo.com. If joe@foo.com chooses to become visible to his entire roster, he simply sends an undirected presence stanza with the type="visible" attribute. In this case the server SHOULD forward the last undirected presence stanza received to stpeter@foo.com and pgmillard@foo.com.

<presence type="visible"/>

<presence from="joe@foo.com/resource" to="stpeter@foo.com"/>

<presence from="joe@foo.com/resource" to="pgmillard@foo.com"/>

Now Joe has decided that he doesn't want pgmillard@foo.com to receive further presence updates. Since he is currently visible to all contacts, he simply needs to send a directed presence stanza to pgmillard@foo.com with the type="invisible" attribute set.

<presence to="pgmillard@foo.com" type="invisible"/>

In this case, the server will send a directed presence stanza to pgmillard@foo.com with the type="unavailable" attribute set, which indicates to pgmillard@foo.com's client that joe@foo.com has gone "offline."

<presence from="joe@foo.com/resource" to="pgmillard@foo.com" type="unavailable"/>

Further presence updates sent by joe@foo.com will now be forwarded to stpeter@foo.com and rynok@foo.com, and MUST NOT be forwarded pgmillard@foo.com.

<presence><show>chat</show></presence>

<presence from="joe@foo.com/resource" to="stpeter@foo.com">
    <show>chat</show>
</presence>

<presence from="joe@foo.com/resource" to="rynok@foo.com/resource">
    <show>chat</show>
</presence>

The server MUST NOT forward presence stanzas containing the type="visible" or type="invisible" attribute to a client.

Copyright

This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).

Permissions

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.

Disclaimer of Warranty

## 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. ##

Limitation of Liability

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.

IPR Conformance

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

Visual Presentation

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.

1. RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc6121>.

2. 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/>.

3. 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/>.